[clean-list] Wish list, part 3

[F.S.A.Zuurbier@inter.nl.net]

This is a multi-part message in MIME format.

--_----------=_1018519085150351
Content-Disposition: inline
Content-Length: 2140
Content-Transfer-Encoding: binary
Content-Type: text/plain

Rinus wrote:
> Hi Marco,
[snip] 
> > - The clean rules for identifiers are such that they can either
> > consist of ordinary characters, or of some special characters, but
> > not both. Otherwise the compiler has trouble interpreting things like
> > 'n+1'. In my opinion this is a pity, because:
> > a) I have no trouble writing 'n + 1' (i.e. with spaces, which I often
> > do anyway)
> > b) I prefer a simple rule that all symbols are separated by
> > whitespace (and brackets)
> > c) I would very much like to markup my symbols like >add<,  >sub< for
> > dyadic operators, or symbol+, symbol*, symbol? for parsing functions,
> > or @node for labels, or <elem> and </elem> for constructors.
> > d) I don't believe that things like (<?@) make your code any more
> > readable (taken from parser combinator stuff).
> 
> I understand and I agree.
> I have to think what we can do about it.

There may be a solution where n+1 would mean what it means today in Clean - OR - it would refer to an object named n+1, depending on whether such an object is in the name space, and depending on which of these alternative meanings typecheck. Only in the case where both meanings would typecheck, would the compiler complain. (Note that more readings in this case are possible, for instance a function named n+ applied to 1). What you need for this kind of flexibility is a non-deterministic parser that interacts with the type-checker. I don't know whether the advantages would be worth the trouble. And I don't know whether the programmer would be able to make sense of the error messages. I do know that the parser/typechecker would become dead slow. More serious: the parser/typechecker could indeed find exactly one interpretation that typechecks ... but not the interpretation the programmer intended. The Clean team is aiming for 'reliable software systems', so the language should not only be handy for the programmer, but its syntax and semantics should also be easy to grasp. Considering all this, I vote against my own proposal :-)

Erik Zuurbier 

Groeten,
Erik Zuurbier
Vruchtengaard 44
3941 LK DOORN
0343 - 416382
--_----------=_1018519085150351--