Hi -
Consider the scenario when you want to find a function that returns the i'th
element of an array but all you know is that there is a module called
Data.Array.IArray that will probably have such a function in it. So you
start typing in your program:
let
ith = Data.Array.IArray.
at this point, you'd hope the editor you're using would somehow display a
list of avaliable values exported from Data.Array.IArray including the
indexing function, so you could select it, thus I would *like* to be able to
use the syntax:
let
ith = Data.Array.IArray.(!)
because it's not the user's fault that the person who wrote
Data.Array.IArray decided to use a symbol instead of an identifier for this
function - the user of Data.Array.IArray in this case just wants to see
normal identifiers to use with prefix application so the use of (!) at this
point effectively gets rid of the unwanted operatorness associated with the
function.
However the current syntax of Haskell would not allow this. Instead you have
to write:
let
ith = (Data.Array.IArray.!)
The problem is that the user of Data.Array.IArray has to know already in
advance, before typing the 'D' of "Data", that the indexing function has
been named with a symbol instead of an identifier, but this knowledge is
only available later, when the user has typed the '.' after "IArray", so the
current syntax would be frustrating for the user because the user then has
to go all the way back and insert an opening paren before the 'D'.
Also, consider the appearance of:
let
ith = (Data.Array.IArray.!) arr i
b = Data.Array.IArray.bounds arr
vs
let
ith = Data.Array.IArray.(!) arr i
b = Data.Array.IArray.bounds arr
I'm not sure if I've managed to explain this problem clearly enough, but my
proposal is that we might consider changing the lexical syntax of Haskell as
follows:
varId ::= id
varOp ::= symbol
varIdOp ::= ` varId
varOpId ::= ( varOp )
varOpIdOp ::= ` varOpId
qvarId ::= {conId .}+ varId -- { }+ denotes 1 or more times
qvarIdOp ::= ` qvarId
qvarOp ::= {conId .}+ varOp
qvarOpId ::= {conId .}+ varOpId
qvarOpIdOp ::= `qvarOpId
In other words, to turn an operator symbol into an id, the parentheses would
be put immediately around the symbol (with no spaces since this is lexical
syntax), and to turn an id into an operator the backquote is put in front of
the entire (qualified) id.
(Also the trailing backquote in the existing syntax is redundant)
The above syntax would have 3 advantages:
1) It allows the client of a module to write code without having to
worry if the author of the module used symbols or identifiers to name
functions - everything exported from the module can be made to appear as if
it was named by an identifier (ie OpId)
2) Moving the parentheses to the lexical syntax makes syntax
highlighting easier (because there are no comments to worry about inside the
OpId) and also makes parsing simpler because all the mess associated with
Ops versus Ids is handled by the lexer
3) It allows an editor to make a distinction between
(+) -- an operator turned into an identifier - varOpId
( + ) -- an expression with 2 gaps in it which should be
marked as incomplete
(+ ) -- a section with 1 gap
Some examples of the proposed syntax are:
let
ith = Data.Array.IArray.(!) arr i
foo = k `Math.(+) 6 -- default precendence
bar = k Math.+ 6 -- using precedence of + in module Math
When you try to write an editor for Haskell (or some subset of it), you
quickly discover these areas of Haskell syntax like the above which need to
be changed to get an optimum interactive editing experience. I think it *is*
possible to adjust the Haskell grammar so that it is LL(1) and the only
reason it is not already LL(1) seems to be that the grammar has been
designed with compilers (which only need to deal with complete modules) in
mind rather than programmers interactively editing in mind.
(The other change needed for LL(1) is to give contexts a marker before they
appear eg:
foo :: {MonadIO m} a -> m a
)
By LL(1) I'm really meaning that the grammar for interactive editing needs
to be adjusted so that it is possible to maintain the invariant that as code
is entered from left to right constructs and identifiers can be highlighted
according to their grammatical role and highlighting (modulo incompleteness)
must remain unchanged regardless of whatever is typed afterwards to the
right otherwise it can become more of a liability than a help, hence my hope
that some future revision of Haskell grammar might consider taking the above
points into account.
Regards, Brian.
--
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.
http://www.metamilk.com
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
