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

[Douglas Philips]

On 2007 Feb 3, at 2:55 AM, Brian Hulley indited:
> 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.

So far as I can tell, this has not been a problem complained about in  
other languages that have this feature. I don't know Ruby well  
enough, but Python far too well, and it just doesn't seem to be a  
problem in practice.

I was about to go through the syntax and construct a proposal that  
added an optional comma to all those places where commas are used as  
separates for the elements of groups (such as in deriving, which by  
the way, already has these other interesting variants: 'deriving ()',  
'deriving A', 'deriving (A)' and 'deriving (A,B)'... But looking at  
the time table for Haskell' that is probably asking too much at this  
stage...

I was going to suggest that a compiler option seems to be the worst  
of both worlds since it still leaves the existing inconsistencies in  
the syntax for your case.

So again, considering the timing, perhaps the right thing to is  
submit compiler patches for GHC and Hugs...
For a starting volley (names are hard, these are just placeholders):
	--98-trailing-commas
	--no-trailing-commas-anywhere
	--WARN-but-accept-trailing-commas
	--trailing-commas-anywhere

At least hypothetically, I haven't looked at Hugs or GHC yet. :-)
I think WARN would go a long way towards relieving the concern that  
someone might have that they are deliberately (maybe even  
subconsciously or habitually) using ",)" as a way to force themselves  
to come back and add something later?


> (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...

I really don't see that making (,,) represent a pair constructor  
makes any sense.

The whole "compressed tuple constructor" seems quite sensible in  
theory, however it is a slippery slope, and the "Cons" from: http:// 
hackage.haskell.org/trac/haskell-prime/wiki/TupleSections are rather  
compelling.

Additionally, it doesn't have the correct inductive properties:
Prelude> (1,2)
(1,2)
Prelude> (,) 1 2
(1,2)
Prelude> ((1,2),3)
((1,2),3)
Prelude> ((,),) 1 2 3
<interactive>:1:5: parse error on input `)'

So I don't think there is much point with pretending that I can take  
an arbitrary tuple sugar and turn it into something functional. It is  
just _not the case_ that the comma in a list or tuple constructor is  
an operator.
And *if* it were an operator, wouldn't it be a binary operator so  
that ( 1, 2, 3 ) would be equal to
either ( (1, 2), 3 ) or ( 1, (2, 3) ) ??? No, it isn't, and wouldn't  
be else you couldn't utter nested tuples with sugar. ;-)

Instead it is a special case of a flat tuple with a magical cascading  
',' "operators" which looks sort of like an operator, but only when  
you don't focus on it very much, or only when you don't try to apply  
it as a general mechanism. Isn't a special case which strongly  
suggests a deeper regular mechanism that actually isn't there a kind  
of confusion/misleadingness that should be avoided?
But this is probably way off topic for Haskell'...


>>> 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,).

Again, you wouldn't "have" to use (1,2,) if you didn't want to.
The medium has changed. We are writing programs with a ease not  
available in the preceding centuries of mathematics. Just as it took  
a while to stop thinking of a computer as a typewriter (tabs,  
backspaces for overstriking, etc.), so I think we need to stop  
saying: Well, I wouldn't have put in a trailing comma if I were  
writing on a chalk board or a piece of paper. Of course not! But then  
I'm writing code / math using a medium that allows me to easily  
rearrange the parts. Compared to rewriting or retyping (typewriter),  
the ease with which I can write on a computer is so quantatively  
different that it demands a qualitative change. (La)TeX is the way to  
typeset beautiful mathematics, but how much does writing \over or  
\cdots look like the final result?


> I know, I find the need to manually delete and insert commas  
> extremely tedious as well. This is why I proposed:
> ...

I like that. (I haven't done enough analysis on the layout part of  
the grammar to personally make sure it is ok.)

> 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.

(see above)


> Another possibility would be to allow trailing semicolons in the  
> {;} syntax, then the #( sugar would work - you could just write:
>
>    #( {a;b;c;}

I didn't think to go looking, but it seems trailing semicolons have  
similar consistency issues.

stmts 	 -> 	 stmt1 ... stmtn exp [;] 	 (n>=0)
stmt 	 -> 	 exp ;
	| 	pat <- exp ;
	| 	let decls ;
	| 	; 	(empty statement)


> 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.

:-)

	--D'gou