[e-lang] Trinary-define syntax, and ejector behavior (was Re: Atomic expansion of MatchBindExpr ...)

[Kevin Reid]

On May 15, 2006, at 16:35, Karp, Alan H wrote:
> Mark Miller wrote:
>> On 5/15/06, Kevin Reid <kpreid at mac.com> wrote:
>>>>      "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"?
>>
>> I like "exit".
>
> Exit implies that the process is ending.  If the ejector expression  
> doesn't have to be an ejector, how about "else" as in "define this  
> pattern if it matches else do this other thing".

I considered "else" but decided not to suggest it because it might  
suggest that the relevant effect occurs simply by evaluating the  
expression (as in the else block of an IfExpr); in this case, the  
expression is always evaluated and the result is *called* if there is  
a problem.

The expression does not have to evaluate to an ejector; what does  
happen is that its value is called, and if that does not cause a  
nonlocal exit, a throw is performed instead. I believe "exit" is  
appropriate because an exit always happens, whether or not the  
provided object performs it.

That is, roughly:

   def exit := eval(exitExpr, &env)
   def specimen := eval(specimenExpr, &env)

   if match fails {
     exitExpr.run(problem)
     throw(...)
   }

(Actually, the ejector-or-whatever is passed to the pattern, and all  
patterns perform this check, using throw#eject/2 or a primitive  
equivalent.)

(E-on-Java throws the match failure problem with a note in the stack  
trace. E-on-CL throws a new exception reporting that the 'ejector'  
returned. MarkM, have we discussed this behavior? Is there a reason E- 
on-CL's is inappropriate?)

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>