Simon Marlow wrote:
Here are the possibilities for composition:
0. do nothing
1. use a Unicode operator for composition
2. require spaces around . as an operator
3. require spaces around all operators
4. use another ASCII operator for composition, e.g. <<<
Nothing has been decided yet, but most of the committee tends to favour
(2), with some expressing a slight preference for (0). We've pretty
much ruled out (1) and (3) as too radical, and as you say using Unicode
is still too impractical.
There is some uncertainty about the precise details of (2), and thinking
about that is what lead to my proposal about changing the syntax of
qualified operators.
Ok, I'm going to try to make some progress on this. I think it's fair
to say that the only possible options are (0) do nothing, or (2) require
spaces around "." as an operator.
I'll explore how we might do (2). We discussed this a bit on the
committee mailing list, here's where we got to. The proposal amounts to
making certain sequences illegal. Let's try to implement the informal rule
dot is only allowed adjacent to a varid or conid when
it is part of a qualified name
so that would make these illegal:
length.lines
(.f)
(f.)
++.x
x.++
Just.(+1)
Here's an interesting case:
[Monday..Friday]
which I imagine we would like to be legal. (currently it's illegal, or
rather 'Monday..' is interpreted as a qualified operator; see separate
proposal for changing the syntax of qualified operators).
The way to implement this is to add the following productions to the
lexical syntax:
reservedlexeme ::= ({symbol} '.')<reservedop> (varid | conid)
| (varid | conid) ('.' {symbol})<reservedop>
The idea is that reservedlexemes are illegal, and work via the
maximal-munch rule. (note that this version relies on the alternate
qualified operator syntax proposal, because it makes the existing
qualified operator syntax into a reservedlexeme).
My personal view is that this is somewhat ugly. However, it does have
the benefit of releasing the 'foo.x' syntax for future use, e.g. in a
new record system - but some people find that a bit tasteless too, and I
might be inclined to agree.
Thoughts?
Cheers,
Simon
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
