Re: [Haskell-cafe] A better syntax for qualified operators?
Brandon Moore wrote:
Brian Hulley wrote:
I would *like* to be able to use the syntax:
ith = Data.Array.IArray.(!)
Why does the nice argument not apply equally well to infixifying
things? Shouldn't I be able to write
myArr Data.Arr.`get` ix
Good point. This would also remove the need for allowing double conversion
as in OpIdOp which was an element of asymmetry in my original proposal. Thus
I revise my proposal to the following:
varId ::= id
varOp ::= symbol
varIdOp ::= ` varId `
varOpId ::= ( varOp )
qx ::= {conId .}+ x
so the concerns of qualification and Id, Op, Id-Op would now be separated
(the point being that you can only make a decision regarding Id-Op when
you know whether or not you're starting with an Id or an Op and you only
know this latter fact when you've already arrived at the module by typing
the qualifier).
(Also the trailing backquote in the existing syntax is redundant)
The trailing backquote is just as redundant as the trailing close
paren in the syntax for using a symbol as a prefix function and just
as important for my comment on backticks as the closing paren is to
your proposal for sections -
it means it's lexically apparent at least at one side of the
identifier that it's a section/infixification
I'm not sure I understand this argument for why a trailing backquote is
needed, though I can see it would be needed if the dist-fix idea proposed by
Benjamin Franksen in
http://www.haskell.org/pipermail/haskell-cafe/2006-August/017373.html was
adopted eg:
Control.K.`if cond Control.K.`then` t Control.K.`else` f Control.K.fi`
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
Re[2]: [Haskell-cafe] A better syntax for qualified operators?
Hello Bas,
Thursday, September 28, 2006, 2:39:13 AM, you wrote:
foo :: {MonadIO m} a - m a
Or move contexts to the end of a type and separate it with a | like Clean
foo :: a - m a | MonadIO m
i've proposed both these constructs here at list some time ago :
but we don't decide...
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A better syntax for qualified operators?
On Wed, 27 Sep 2006, Brian Hulley wrote: 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. This cool editor is able to show a list of functions with the given qualification but is not able to enclose the qualified identifier in parentheses? I don't think that it is a good idea to move the qualification away from the qualified identifier. The parentheses around the infix operator are a special case of sections. With the proposed syntactic change, we would have two meanings of parentheses: Section and making an infix operator prefix. One can also mix up Data.Array.IArray.(!) more easily with function composition Data.Array.IArray . (!) if Data.Array.IArray is also a constructor. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] A better syntax for qualified operators?
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.
Re: [Haskell-cafe] A better syntax for qualified operators?
Brian Hulley wrote:
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.
This is a nice argument
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.
Why does the nice argument not apply equally well to infixifying things?
If I think I want to use infix some thing from Data.Array
and start typing
myArr Data.Array.
and find out element access has become get while I wasn't looking,
it's not my fault the author of Data.Array decided to use a function
when I was expecting an identifier - Shouldn't I be able to write
myArr Data.Arr.`get` ix
(Also the trailing backquote in the existing syntax is redundant)
The trailing backquote is just as redundant as the trailing close paren
in the syntax for using a symbol as a prefix function and just as
important for my comment on backticks as the closing paren is to your
proposal for sections -
it means it's lexically apparent at least at one side of the identifier
that it's a section/infixification
Brandon
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A better syntax for qualified operators?
On Wednesday 27 September 2006 22:20, Brian Hulley wrote:
(The other change needed for LL(1) is to give contexts a marker before they
appear eg:
foo :: {MonadIO m} a - m a
)
Or move contexts to the end of a type and separate it with a | like Clean
does: (See 6.2 of http://clean.cs.ru.nl/download/Clean20/doc/CleanRep2.0.pdf)
foo :: a - m a | MonadIO m
Personally I like this style because I always think first about what the type
of the function should be (a - m a) and then about the contexts /
restrictions that hold for the variables (MonadIO).
I do the same thinking when writing list comprehensions. First I think of the
general form of the elements in the list: [ (a, b) ...
then I think about the restrictions on the variables: | a - [1..10], b -
[1..10], a b]
Bas van Dijk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
