[e-lang] impl: misc

Mark Miller markm at cs.jhu.edu
Sat May 14 14:55:47 EDT 2005


Kevin Reid wrote:
> On May 14, 2005, at 13:41, Mark Miller wrote:
> 
>> In any case, a related bug reported by Kevin may be relevant:
>> <https://bugs.sieve.net/bugs/? 
>> func=detailbug&bug_id=125620&group_id=16380>
>>
>> I recall Kevin suggested a solution for this, which I mysteriously  
>> cannot find in either the email archive nor the bug tracking 
>> database.  Kevin?
> 
> I don't recall suggesting a solution for this bug.
> 
> I did for another HilbertHotel-related bug:
>   <http://www.eros-os.org/pipermail/e-lang/2004-December/010207.html>
> but this is unrelated.

In that email:
>>> Tangentially:
>>>   ? e`${e`a(b) := 1`}; ${e`c(d) := 2`}`
>>>   # value: e`a.setRun(b, def ares__1 := 1)
>>>   #        ares__1
>>>   #        c.setRun(d, def ares__1 := 2)
>>>   #        ares__1`
>>>   ? interp.getResult(0).eval(
>>>   >   e`def a; def c; def b; def d`.evalToPair(safeScope)[1])
>>>   # problem: Failed: ares__1 already in scope
>>
>> Oh bletch. This is horrible! I have no clue what to do about this. Any 
>> ideas?
> 
> Apply something like the HilbertHotel to quasi-substitution. This would 
> assume that code which generates and uses temporaries does not use 
> quasi-substitution where a temporary-usage would cross it.

Yes, that was the one I was thinking of. Thanks.

Steve Jenson is currently moving the E bug database to SourceForge. Once it's 
there, I'll post this bug and suggested fix there. Sorry I'd forgotten to file 
this earlier.


> One thing that comes to mind (ignoring any question of  
> hygenic-or-otherwise expansion):
> 
> Expand the type of E variable-names such that there are 'ordinary'  
> names and other names. Make all Hilbert-affected variables outside of  
> the 'ordinary' namespace.
> 
> One implementation would be to prefix (or suffix) all 'ordinary'  
> variables. That is, "foo_1" is internally "ORDINARY_foo_1", and  
> HilbertHotel renames only "TEMP_foo_1".
> 
> Another would be to name variables with non-string values - tuples,  
> perhaps.
> 
> Current syntax even gives us the escape hatch to do so:
> 
>   ? e`x() := 2`
>   # value: e`x.setRun(def ::[Temporary, "ares", 1] := 2)
>   #        ::[Temporary, "ares", 1]`
> 
> Um. Plenty of interesting issues - time and scope of evaluation, since  
> lists aren't literals, for one - from this. I won't call it a good  
> idea, but it did come to mind.

But either of these still leave us with the HilbertHotel issue: if the 
expansion is itself to be regarded as an E program, then E source programs 
must be able to contain such variable names, since the syntax of your 
expansion must be legal E syntax. We'd still need some way to ensure that 
newly generated non-identifier temporary variable names don't conflict with 
non-identifier variable names in the source. We already have an infinitely 
large namespace. Simply expanding its size further doesn't help. Perhaps we 
need selfish gensyms; but these are disturbing, as the resulting AST is no 
longer DeepPassByCopy nor even serializable.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM



More information about the e-lang mailing list