[e-lang] Draft: Handling Symbolic Data

[Mark S. Miller]

At 09:11 AM 4/13/2004  Tuesday, Constantine Plotnikov wrote:
>BTW I do not remember receiving answer about issue with "_" and "_/"
>tokens described in my mail.

Thanks for the reminder. If we're going to drop "_/", now's the time to do it.


At 10:02 AM 2/8/2004  Sunday, Constantine Plotnikov wrote:
>I have also noticed what I believe is a major problem in E. It
>is "_/" operator that is described in some documents. I do not
>know status of it, because of reasons listed above. Possibly this
>problem has been already addressed. But this operator has major
>presentation problems:
>
>1. It is completely lost in links (see http://www.erights.org/elang/grammar/lexical.html
>  for examples). It could be also lost in underline text style
>  for editors that support underlining in syntax highlighting.

[out of order]
>Because of first reason, I also suggest to replace "_" with
>something other, for example it looks like there are no expression
>where "?" could be start, so it looks like a good candidate.

Underbar is used in enough other places in E and other languages that I 
think we need to learn to live with the link and underlining problem in 
general. The C language naming tradition has been using underbars in 
identifiers forever.


>2. It could be interpreted as "_ /" ("_" space "/") where first
>  token is name placeholder. As I recall, such combination
>  was at least discussed thunk{} expression: thunk{ _ /2}.run(1)

That could have been a problem, but in the end, we didn't do that for 
thunks. I just reviewed all the places in the E grammar where "_" appears, 
and I think the only remaining ambiguity, which I hadn't previously noticed, 
is at the end of an identifier. For example, should we parse

    x_/y

as 'x_  /  y' or 'x  _/  y'? Both the latter are legal expressions.

I think the right answer is to have the E lexer statically reject the 
ambiguous case, forcing the programmer to put in the clarifying whitespace. 
(Fortunately, the "!" we included in our meta-language, taken from Parsing 
Expression Grammars, allow us to easily state this "syntactic predicate" in 
our tokenizing grammar. OTOH, it would still be better to avoid that weird 
special case.)


>Possibly it could be possible to use Pascal names for integer
>operators like "div" and "mod" instead.

Further, if we can agree on a short name, we can just use normal invocation 
syntax and dispense with the operator entirely. How about 'x.div(y)'? I'm 
not sure that I like "div", but I think I do like getting rid of an operator 
for this operation, and just using an explicit message. Is there a short 
name that memorably suggests integer division truncating towards negative 
infinity? What is the semantics of Pascal's "div" anyway?


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

        Cheers,
        --MarkM