Douglas Philips wrote:
On 2007 Feb 2, at 11:25 PM, Brian Hulley indited:
Apart from the extra possibility for errors (yes I understood that
you'd define it to not be an error but this doesn't change the fact
that for people who always wrote their tuples using the normal
mathematical convention not using an optional trailing comma it
would be an error in their code)
Well it would now, but in my proposal it wouldn't be. So it would not
make any correct code incorrect.
Of course, but when I said "error" I meant "error with respect to the
intentions of the programmer" not "syntax error detected by the compiler".
The problem with your proposal is that if optional trailing commas were
allowed, if *I* wrote:
(1,2,)
by mistake, forgetting to add in the last element, the fact that the
compiler would now treat the trailing comma as optional means it would now
accept the code as being syntactically ok. If *you* wrote that same code, it
*would* correspond to what you meant ie just (1,2), for me it would not
because I'd have meant to write something like (1,2,3), so for me, instead
of a nice simple syntax error I'd get a confusing type error possibly
somewhere else in the code therefore my net productivity would be reduced.
However a compiler option could be used to switch the optional trailing
comma feature on and off and therefore suit everyone.
to go undetected, it would just substitute one inconsistency for
another: as Malcolm pointed out the syntax (,,) represents the
constructor for a 3-tuple therefore:
let a = (x,y,) -- in your proposal a 2-tuple
let b = (,,) x y -- still a 3-tuple with a missing element
Prelude> :t (1,2,) 3
ERROR - Syntax error in expression (unexpected `)')
Prelude> :t (1,2,)
ERROR - Syntax error in expression (unexpected `)')
Prelude>
Again, this would not break existing code, since there is no
mechanism for section'd tuples.
What I meant was that the number of commas for a constructor is fixed:
always 2 commas means a constructor for a 3-tuple. However you'd now have a
choice of how many commas to use when writing out the "sugared" saturated
application - either 2 or 3 commas. Which seems inconsistent, since in 5
years time someone used to always writing a pair like:
let pair = (1,2,) -- trailing commas now very popular
might quite sensibly want to write this as
let pair = (,,) 1 2
(since the whole point of the (,,) syntax is that the number of commas is
the same as that used when writing out the value in tuple notation) but we
can't have a programmer choice when it comes to the constructor: the
compiler writer must choose one way or the other. So I don't think there
should be a choice in the sugar syntax either. Then if we choose to use (,,)
to represent the pair constructor because of the popularity of trailing
commas in the applied syntax, this would beg the question of what (,) would
represent hence the "spectre" of introducing 1-tuples...
Also, I think in maths the convention is to use commas as
separators when writing down coordinates etc.
??? I don't quite get the applicability here...
Perhaps it is not applicable, but I thought a guiding principle of Haskell
syntax was to try and stay as close to normal mathematical notation where
possible, and I remember learning 2d coordinates in school as (x,y) not
(x,y,).
From a personal aesthetic point of view the appearance of a
trailing comma is highly irritating to me like passing a shelf in a
shop where someone has left a book "unsettled" with the cover
twisted over the edge at an annoying angle and some pages crumpled
up, that forces me to stop and fix it... :-)
Well, if we're going to bring personal points of view in, it highly
pisses me off that in a construct such as:
( expr ,
expr ,
expr ,
expr ,
expr ,
)
I have to be vigilant to remove that trailing comma when it is in _no
way_ ambiguous.
I know, I find the need to manually delete and insert commas extremely
tedious as well. This is why I proposed:
#(
expr
expr
as sugar for (expr, expr), because it seems crazy to me that we've got all
the machinery in place in the form of the layout rule yet we can only use it
for a handful of built in constructs, when everywhere else we still need to
juggle with commas and try to make parentheses as invisible as possible eg:
bracket_
(enter a)
(exit a)
(do
b
c) -- looks like LISP...
instead of just:
#bracket_
enter a
exit a
do
b
c
[snip]
I don't think we're ever going to get agreement on apparently
irreconcilable personal aesthetics, but perhaps we can apply some
principles, such as regularity and consistency and both get what we
want?
The #( sugar would only go part of the way to address your proposal since it
doesn't address tuples written inline. But a compiler option for allowing
the optional trailing comma could be used so that people who prefer the
existing syntax (and who might rely on the positive enforcement of "no
trailing commas allowed" to catch some of their mistakes) would not be
affected.
Another possibility would be to allow trailing semicolons in the {;} syntax,
then the #( sugar would work - you could just write:
#( {a;b;c;}
Regarding import/export lists,...
...
(Though the above is obviously too radical a departure for Haskell')
Perhaps too radical? but I like it. I am all for eliminating syntax
noise whenever/wherever unambiguously possible, and for making what
remains as _regular_ as possible. Sometimes it is the foolish
inconsistencies which are the hobgoblins...
I agree. Some particularly warty hobgoblins are:
(-1) as opposed to (+1)
f (x+3) = g x but not f (x * 3) = g x
though a problem with Haskell' is the conflict between the knowledge of
these pesky warts and the desire to maintain backwards compatibility with
H98, hence we may need to wait till the next major revision to see them
finally vanquished.
Best regards, Brian.
--
http://www.metamilk.com
_______________________________________________
Haskell-prime mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-prime
