[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