[e-lang] Remaining semantic issues

[Mark Miller]

At <http://www.eros-os.org/pipermail/e-lang/2005-January/010440.html>
Kevin Reid wrote:
> On Jan 24, 2005, at 14:06, Mark Miller wrote:
>> If we do introduce "via" (with some syntax) into Kernel-E, can we 
>> expand away some other existing Kernel-E construct into via?
> [...]
> On continued lack of expressiveness:
> 
> The "via" pattern, while it handles subpatterns whose specimens are 
> derived from arbitrary evaluation, is not a general solution to 
> propagating match failure. [...]
> 
> Again, we lose the failure information. [...]
> 
> A fully general construct would be:
> 
>   SomewhatLikeDefineExpr(<EExpr>, # specimen
>                          <EExpr>, # optEjector
>                          <Pattern>)
> 
> (This is analogous to evm.Pattern#testMatch.)

(For reference, see the bottom of
<http://www.erights.org/javadoc/org/erights/e/elang/evm/Pattern.html>.)


> Not being able to think of a remotely sane syntax for this is what led 
> me to the via-pattern for the specific case of nonprimitive composite 
> patterns.
> 
> If it existed, however, it would:
> 
>   * neatly solve the above pattern-in-guard-implementation problem,
> 
>   * likely be useful in other situations, especially if we use my 
> 'ejectors everywhere' proposal,
> 
>   * be available if we ever want to introduce strange new pattern (or 
> pattern-using) sugars without changing Kernel-E,
> 
>   * potentially replace both DefineExpr and MatchBindExpr, though the 
> expansion for the latter would need contortions analogous to &&/|| 
> expansion to get the bindings out of an escape {} block,
> 
>   * be a way to solve the same problems as "via", by using it on the 
> ejector obtaind by the __MatchContext trick currently used for 
> quasi-patterns. (I find that trick ugly, but keeping it would save on 
> number-of-kernel-constructs versus having both general-match and via.)

Sorry I didn't pay enough attention to this earlier.

Given the above list of implications, I think we should indeed experiment with 
adding this to Kernel-E. IMO, we should then expand the current DefineExpr to 
SomewhatLikeDefineExpr, since this expansion will be straightforward, but we 
should keep MatchBindExpr in Kernel-E, since its further expansion to 
SomewhatLikeDefineExpr would be too obscure and verbose, as you point out. 
However, we should document the equivalence of MatchBindExpr to an expansion 
in terms of SomewhatLikeDefineExpr.

If the pattern successfully matches, what should the value of the 
SomewhatLikeDefineExpr be? My inclination is to have it return the specimen on 
success, making the expansion from DefineExpr into SomewhatLikeDefineExpr be 
that much more straightforward. As for a syntax, perhaps something like

     def <pattern> ~= (<specimenExpr>, <optEjectorExpr>)

so

     def <pattern> := <specimenExpr>

would expand to

     def <pattern> ~= (<specimenExpr>, null)

which still suggests its pre-expansion reading. The downside of this syntax is 
that the left-to-right scoping rule would prevent the <pattern> from using 
identifiers introduced by either of the expressions, which would make the 
expansion of the MatchBindExpr into SomewhatLikeDefineExpr (as well as other 
uses) even more awkward.

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

     Cheers,
     --MarkM