[e-lang] Atomic expansion of MatchBindExpr to trinary-define
Kevin Reid
kpreid at mac.com
Mon May 15 12:14:22 EDT 2006
On May 15, 2006, at 11:39, Mark S. Miller wrote:
> Kevin Reid wrote:
>> Is it truly necessary to provide left-to-right-define to support
>> this? Isn't (using the "into" syntax I just posted)
>>
>> (def a := 1) into ^(fail) ==a
>>
>> equivalent to
>>
>> def specimen__1 := (def a := 1)
>> def ejector__2 := fail
>> def ==a := (specimen__1, ejector__2)
>
> It took a while for the significance of the above observation to
> sink in.
>
> ... Introducing an LTR define into Kernel-E makes the language
> formally simpler but less familiar. It makes the overall E system
> seem more complex, because the expansion to Kernel-E now seems more
> different than the E program the programmer originally wrote.
>
> Sorry for the backtracking, distraction, and confusion, but I now
> think we
> should go back to having the Kernel-E construct be LTR define.
I still like the benefit of the kernel structure reflecting actual
evaluation order, and not having the apparent-recursion restriction.
I'm going to think about this some more before doing anything about it.
> When expanding a match-bind-expression to Kernel-E, if there's a
> scope conflict, we can use Kevin's expansion above.
Actually, for MatchBindExpr, since the user pattern is always
actually evaluated inside a block, there will never be a conflict.
> There remains the question of what should be the syntax of trinary
> define. I
> think the current LTR trinary define syntax is mysterious. On first
> encountering it, it gives no clue about the significance of the
> "extra"
> argument expression. I think I like Alan's suggested:
>
> "def" <pattern> "eject" <ejectorExpr> ":=" <specimenExpr>
I don't like "eject" here, as the semantics of Kernel-E don't require
that the object be an Ejector. How about "exit"?
--
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the e-lang
mailing list