[E-Lang] ERTP-aware MintMaker

[Mark S. Miller]

At 01:40 AM Thursday 2/15/01, Ben Laurie wrote:
>But that would mean repeating the type for complex conditions (e.g.
>:(integer >= 0 && integer < 23)), 

Actually, it would be ":(integer >= 0 & integer < 23)".  Remember that the 
thing to the right of the colon is just an expression.  It's *value* is 
treated specially -- as a guard -- but there's nothing special about its 
syntax or evaluation.  As in C through Java, "&&" is control flow, whereas 
"&" is a normal operator that evaluates both sides.  In E, "&&" expands to 
actual control flow code involving an "if" around the left hand condition.  
OTOH, "&" expands like any other normal operator.  For example, "x & y" 
expands to "x and(y)".

Since "integer >= 0" evaluates to a guard, not a boolean, we can't "&&" 
on it.  This kind of guard, based on the old Udanax Gold/Purple 
IntegerRegions http://grendel.conlang.org/~dgd/udanax/IntegerRegion.html , 
represents a subset of integers.  Such IntegerRegions can be intersected by 
"&", often (as here) yielding an interval.  (They also respond to "|" and 
"!".)  The guard syntax knows nothing of this special behavior; it's all in 
the behavior of the objects themselves, starting with the guard object named 
"integer".  These objects respond to these operators this way in any 
expression context.  

The region code is written in E 
(e/src/esrc/org/erights/e/elang/coord/OrderedRegionMaker.emaker and 
currently e/src/esrc/org/erights/e/elang/coord/any.emaker) and applies to 
any fully ordered data type with a successor and predecessor function, 
mapped to E as the messages "next" and "previous" respectively, but with the 
following weirdness: if x is the minimum element of its kind of data type, 
then x previous == x.  Similarly, if it's the maximal element, then x next 
== x. Among the literal types in E, integers have next and previous methods, 
but no terminal elements.  chars have next, previous and terminal elements. 
Since we specify that float64s are IEEE double precision rather than some 
vague attempt to be real-number like, float64s also have a next, previous 
and terminal elements.  Strings do not have a next nor previous, and so are 
not handled by this region code.  In Udanax there was separate region code 
for dealing with String-like things, including Strings, but I don't expect 
to encounter a strong case for adding this to E.


>which strikes me as yukky.

For your example, since you're constructing an interval, you could also say 
either ":(0..!23)" or ":(0..22)".  "x..!y" means "all objects from x 
inclusive up till y *exclusive*".  "x..y" means "all objects from x inclusive 
thru y *inclusive*".  


        Cheers,
        --MarkM