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.
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.
I think this would just be far too confusing: the choice to use (,)
to represent the pair constructor is IMHO too deeply ingrained in
existing Haskell code to change it to mean a 1-tuple (also do we
want to add the concept of 1-tuples to the language?).
Prelude> :t (1,)
ERROR - Syntax error in expression (unexpected `)')
Prelude> :t (,) 1
(1,) :: Num a => b -> (a,b)
Again, this would not break existing code, there is no expectation
for section'd tuples.
And no, I am not arguing for one-tuples. What I am asking for is to
change:
| ( exp1 , ... , expk ) (tuple, k>=2)
| [ exp1 , ... , expk ] (list, k>=1)
to:
| ( exp1 , ... , expk [ , ] ) (tuple, k>=2)
| [ exp1 , ... , expk [ , ] ] (list, k>=1)
I'm not arguing to change 'k'.
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...
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. Python and Ruby and who knows how many other
languages have dealt with this for years. The (,) operator is not
being used to build tuples (nor to build lists, to which this
discussion also applies). The trailing comma makes the code very
convenient to rearrange without having to worry about gratuitous and
annoying manipulations that exist solely for the pedantry of the
syntax. Said gyrations in no way remind me of some deep, useful, or
helpful language feature that I'm "violating." Instead, I get brought
up short, and instead of focusing on the problem I'm trying to solve
it makes me pay attention attention to babying the parser.
Furthermore I can see that the code is correct because it is all
visually _the same_. I don't have to think about it, my eye/brain
pattern matcher just does it. Forcing me to pay attention to minutia
of syntax is like using a tool with a bur on the handle that keeps
biting me instead of just doing its job.
I'm not saying that _you_ have to use it, and I'm not saying that all
the standard library code has to change, what I am saying is for
crying out loud, for those of us that find a trailing comma to be an
aid, something which does not diminish the expressiveness or power of
the language, what reason do you have, besides pedantic meanness, to
reject it? Are we reduced to merely a popularity vote? I don't even
see a slippery slope here, as I've already pointed out places in the
syntax where trailing commas are explicitly allowed. So far as I can
see, the arguments against have come down to "This is the way it
always was, and even if I'm not being forced to use this feature, I
sure don't want anyone else to have that option either." Or is the
the issue really just "maybe you forgot there should be another token
there"? Cause if it is, then for hellfire sure I'll say "are you sure
you wanted a section (or partial application) there? Looks like you
forgot a parameter--You'd better put in a gratuitous piece of syntax
to indicate you really meant not to have something there".
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?
Regarding import/export lists, in some ways I think the {;} syntax
should have been used instead then the layout rule could have been
applied to good effect to get rid of the need for any separators eg:
...
(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...
--D'gou
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
