[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