List syntax (was: Re: help from the community?)

[Douglas Philips]

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