Re: List syntax (was: Re: help from the community?)
On 2007 Feb 5, at 6:13 AM, Ulf Norell wrote: How about instead writing ( expr , expr , expr , expr , expr ) The only extra work is when inserting an element at the beginning, but you have the same problem in your example. This a coding style issue. My point was that the syntax should not be inconsistently enforcing style, which it is, unless there is some payoff (which there doesn't seem to be). I argue for making trailing commas optional everywhere that commas are used to separate items in a grouping (though the syntax snippets I've posted before were only a few of those places, such as in tuples and lists). Enforcing style is not always bad, and layout has some great things going for it. Layout is also flexible where it doesn't need to be rigid. Given the experience with trailing commas in other languages, even some that support a glimmer of functional programming :-), being rigid in this area doesn't seem to have a counterbalancing payoff... I really like Brian Hulley's layout proposal: http://www.haskell.org/haskellwiki/Accessible_layout_proposal because it means I can abandon commas and other syntax noise altogether and thus moot the issue. --D'gou ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2/5/07, Ulf Norell [EMAIL PROTECTED] wrote: On Feb 3, 2007, at 6:35 AM, Douglas Philips wrote: 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. How about instead writing ( expr , expr , expr , expr , expr ) The only extra work is when inserting an element at the beginning, but you have the same problem in your example. That style would be slightly improved by allowing a _leading_ comma: [ , expr , expr , expr , expr , expr ] In the trailing comma style, it looks like: [ expr , expr , expr , expr , ] Both require a similar amount of extra space, but I've found the second useful in python lists that change a lot, so I assume I'd find similar use in Haskell lists. Of course, the layout proposal solves this problem too, but it feels like a larger change. Regarding tuples vs. lists, I care a lot less about tuples because rearranging them usually requires a type change in lots of places, so fixing a comma is the least of my worries. Jeffrey Yasskin ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On Feb 3, 2007, at 6:35 AM, Douglas Philips wrote: 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. How about instead writing ( expr , expr , expr , expr , expr ) The only extra work is when inserting an element at the beginning, but you have the same problem in your example. / Ulf ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re[2]: List syntax (was: Re: help from the community?)
Hello Brian, Saturday, February 3, 2007, 10:55:52 AM, you wrote: bracket_ (enter a) (exit a) (do b c)-- looks like LISP... this pattern is very typical in my programs and i use '$' before last parameter: postProcess_wrapper command $ \postProcess_processDir deleteFiles - do tempfile_wrapper arcname command deleteFiles pretestArchive $ \temp_arcname - do bracket (archiveCreateRW temp_arcname) (archiveClose) $ \archive - do ... ... for compressionOptions $ \option - case option of 'd':rest | Just md - parseDict rest - dict =: md -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
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
Re: List syntax (was: Re: help from the community?)
Douglas Philips wrote: On 2007 Feb 3, at 2:55 AM, Brian Hulley indited: 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 ... Bulat Ziganshin wrote: Saturday, February 3, 2007, 10:55:52 AM, you wrote: bracket_ (enter a) (exit a) (do b c)-- looks like LISP... this pattern is very typical in my programs and i use '$' before last parameter I've written more details (and made some improvements to my original idea) at http://www.haskell.org/haskellwiki/Accessible_layout_proposal Brian. -- http://www.metamilk.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2/3/07, Brian Hulley [EMAIL PROTECTED] wrote: 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. And invariably your code would fail to typecheck. That makes this a lot safer for tuples than for lists, for example. -- Taral [EMAIL PROTECTED] You can't prove anything. -- Gödel's Incompetence Theorem ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
List syntax (was: Re: help from the community?)
On 2007 Feb 2, at 5:46 AM, Malcolm Wallace indited: Since yours is the first actual flame I can remember ever being posted to any Haskell list, I think this counts as the beginning of the end of civilisation as we know it. :-) At least, the beginning of the end of civilised discussion. And couldn't you guess - over lexical syntax! :-) Guess that means civilisation is as fragile as the syntax, eh? :-) -- from: http://www.haskell.org/onlinereport/syntax-iso.html#sectB.4 impspec -( import1 , ... , importn [ , ] ) (n=0) |hiding ( import1 , ... , importn [ , ] )(n=0) exports -( export1 , ... , exportn [ , ] ) (n=0) stmts -stmt1 ... stmtn exp [ ; ] (n=0) stmt- exp ; | pat - exp ; | let decls ; | ; (empty statement) ... What would be the proper way to propose that: | ( exp1 , ... , expk ) (tuple, k=2) | [ exp1 , ... , expk ] (list, k=1) be amended to: | ( exp1 , ... , expk [ , ] ) (tuple, k=2) | [ exp1 , ... , expk [ , ] ] (list, k=1) --D'gou ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
Douglas Philips [EMAIL PROTECTED] wrote: What would be the proper way to propose that: | ( exp1 , ... , expk ) (tuple, k=2) | [ exp1 , ... , expk ] (list, k=1) be amended to: | ( exp1 , ... , expk [ , ] ) (tuple, k=2) | [ exp1 , ... , expk [ , ] ] (list, k=1) I think you just did. :-) Actually, it would eventually need a supporter on the committee to add a ticket on the trac/wiki for this. I believe that ghc at one time did accept any sequence of white-space separated commas as if they were a single comma, leading to code such as [ 1 , , 2 , 3 , ] Whilst programmers might be able to see the obvious meaning when it occurs in list exprs, do stmts, imports, exports, and the like, they might run into difficulties in the tuple case. For instance, (1,2,) has been proposed as syntactic sugar for a tuple-section, meaning \x- (1,2,x) and this would be a perfectly reasonable and intuitive interpretation IMO. The number of commas is a powerful visual indication of the arity of the tuple. More generally, the notation (,,) is already widely used as the name of both the type- and data- constructor for triples. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
Douglas Philips wrote:
What would be the proper way to propose that:
( exp1 , ... , expk ) (tuple, k=2)
[ exp1 , ... , expk ] (list, k=1)
be amended to:
( exp1 , ... , expk [ , ] ) (tuple, k=2)
[ exp1 , ... , expk [ , ] ] (list, k=1)
I think a problem with the above proposal is that by allowing an optional
trailing comma the compiler can no longer detect as an error the case where
the programmer has simply just forgotten to fill in the last element of the
tuple/list. The existing syntax forces the user to do some extra work
fiddling about with commas but the reward is that the compiler can verify
that you haven't forgotten the last argument.
About a year ago I proposed (on the cafe) a syntax sugar to avoid commas in
tuples and lists which made use of the layout rule something like:
let a = #[-- introduces new layout block
first
second
third
let b = #(
one
two
As an aside it would also be nice to be able to use layout for function
arguments as in:
do
a - foo
#bracket_
enter
exit
action
the general idea being that '#' immediately followed by an identifier (which
may be qualified) or the symbol '(' or '[' would start a layout block. ('#'
of course would no longer be able to be used in symbolic identifiers)
Brian.
--
http://www.metamilk.com
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2 Feb, 2007, at 16:55 , Malcolm Wallace wrote: Douglas Philips [EMAIL PROTECTED] wrote: What would be the proper way to propose that: | ( exp1 , ... , expk ) (tuple, k=2) | [ exp1 , ... , expk ] (list, k=1) be amended to: | ( exp1 , ... , expk [ , ] ) (tuple, k=2) | [ exp1 , ... , expk [ , ] ] (list, k=1) I believe that ghc at one time did accept any sequence of white-space separated commas as if they were a single comma, leading to code such as [ 1 , , 2 , 3 , ] Whilst programmers might be able to see the obvious meaning when it occurs in list exprs, do stmts, imports, exports, and the like, they might run into difficulties in the tuple case. For instance, (1,2,) has been proposed as syntactic sugar for a tuple-section, meaning \x- (1,2,x) and this would be a perfectly reasonable and intuitive interpretation IMO. The number of commas is a powerful visual indication of the arity of the tuple. This would be an instance of an arbitrary expression where a subexpression has been omitted, forming a hole. So [ 1 , , 2 , 3 , ] means \x y - [ 1 , x , 2 , 3 , y ] 5 + * 6 means \x - 5 + x * 6 (3 + *) means \x y - (3 + x * y) (operator section) Thus the following interpretations could be chosen from: 1 - an operator/comma without operand is an error (as a safety net against typos) 2 - a comma without operand is redundant, means the same as an expression without 3 - an operator/comma without operand has meaning as described above I do prefer option 1, I do not mind writing \x - 5 + x * 6 explicitly instead of implicitly (and more cryptic) 5 + * 6. I do not feel that stretching the syntax in this way warrants the loss in possibilities to check for errors. regards, - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534093/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 | Email: [EMAIL PROTECTED] / |___\ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2007 Feb 2, at 11:32 AM, Brian Hulley wrote: Douglas Philips wrote: What would be the proper way to propose that: ( exp1 , ... , expk ) (tuple, k=2) [ exp1 , ... , expk ] (list, k=1) be amended to: ( exp1 , ... , expk [ , ] ) (tuple, k=2) [ exp1 , ... , expk [ , ] ] (list, k=1) I think a problem with the above proposal is that by allowing an optional trailing comma the compiler can no longer detect as an error the case where the programmer has simply just forgotten to fill in the last element of the tuple/list. The existing syntax forces the user to do some extra work fiddling about with commas but the reward is that the compiler can verify that you haven't forgotten the last argument. I assert that the trailing comma is a feature, not a programmer forgetting the last element, and that this is already explicitly allowed, as per the syntax fragments already quoted, repeated here for convenience: -- from: http://www.haskell.org/onlinereport/syntax-iso.html#sectB.4 impspec -( import1 , ... , importn [ , ] ) (n=0) |hiding ( import1 , ... , importn [ , ] )(n=0) exports -( export1 , ... , exportn [ , ] ) (n=0) stmts -stmt1 ... stmtn exp [ ; ] (n=0) stmt- exp ; | pat - exp ; | let decls ; | ; (empty statement) (Personally I prefer no separators at all as per your other suggestion, but haven't fully grok'd that yet, but either way, the overall syntax should be consistent, so saying a trailing comma means you forgot the last element should imply removing the trailing commas above, right? Or, perhaps, it means saying that, as Python and Ruby and .. programmers have been able to do, the regularity of ( expr ',' )* is compelling for eye/brain pattern matching and other silly human factors reasons. :-) ) --Doug ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2/2/07, Douglas Philips [EMAIL PROTECTED] wrote: I assert that the trailing comma is a feature, not a programmer forgetting the last element, and that this is already explicitly allowed, as per the syntax fragments already quoted, repeated here for convenience: -- from: http://www.haskell.org/onlinereport/syntax-iso.html#sectB.4 impspec - ( import1 , ... , importn [ , ] ) (n=0) |hiding ( import1 , ... , importn [ , ] )(n=0) exports - ( export1 , ... , exportn [ , ] ) (n=0) Huh? I don't quite see what you're getting at here. The report says that the trailing comma is allowed in import and export lists, yes. But you were talking about trailing commas in lists and tuples, which would be a change to the existing language, not something that's already explicitly allowed. Can you clarify what you meant? Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt and there's too much darkness in an endless night to be afraid of the way we feel -- Bob Franke ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2007 Feb 2, at 12:13 PM, Kirsten Chevalier inquired: On 2/2/07, Douglas Philips [EMAIL PROTECTED] wrote: I assert that the trailing comma is a feature, not a programmer forgetting the last element, and that this is already explicitly allowed, as per the syntax fragments already quoted, repeated here for convenience: -- from: http://www.haskell.org/onlinereport/syntax-iso.html#sectB.4 impspec - ( import1 , ... , importn [ , ] ) (n=0) |hiding ( import1 , ... , importn [ , ] )(n=0) exports - ( export1 , ... , exportn [ , ] ) (n=0) Huh? I don't quite see what you're getting at here. The report says that the trailing comma is allowed in import and export lists, yes. But you were talking about trailing commas in lists and tuples, which would be a change to the existing language, not something that's already explicitly allowed. Can you clarify what you meant? Hmmm...stated another way: I am proposing that the list and tuple syntax change to be consistent with the import and export syntax. The argument that a trailing comma means the programmer forgot the last item in a list / tuple is inconsistent with the deliberately explicit permissiveness of a trailing comma in the import / export lists. In the import / export lists such a trailing comma does not mean programmer forgot additional thing at the end. --D'gou ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2/2/07, Douglas Philips [EMAIL PROTECTED] wrote: Hmmm...stated another way: I am proposing that the list and tuple syntax change to be consistent with the import and export syntax. The argument that a trailing comma means the programmer forgot the last item in a list / tuple is inconsistent with the deliberately explicit permissiveness of a trailing comma in the import / export lists. In the import / export lists such a trailing comma does not mean programmer forgot additional thing at the end. Ok, now I see your point. I agree it does seem inconsistent. I don't know the reasons for the choice to make the import/export lists work that way, but I would guess that it's because when people use import/export lists, they often add/remove items from the lists, and allowing the trailing comma just makes things easier. On the other hand, with constant lists and tuples, you're probably not going to frequently edit the same constant list value. Am I missing something? Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt The world is absurd and beautiful and small -- Ani DiFranco ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: List syntax (was: Re: help from the community?)
On 2/2/07, Kirsten Chevalier [EMAIL PROTECTED] wrote: On the other hand, with constant lists and tuples, you're probably not going to frequently edit the same constant list value. Am I missing something? Sometimes people maintain static configuration items and the like in lists. I've certainly found myself wishing for the trailing ',' to be allowed on some occasions, though it's not a big enough deal for me to argue for it strongly if there is significant opposition. I think record syntax is the other significant place where it'd be useful (more so than tuples, given that adding an item to a tuple generally involves a type change that has an impact in many other places, whereas adding a record item is often just a question of adding it to the type and to a few other locations.) Cheers, Ganesh == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
Hi The argument that a trailing comma means the programmer forgot the last item in a list / tuple is inconsistent with the deliberately explicit permissiveness of a trailing comma in the import / export lists. In the import / export lists such a trailing comma does not mean programmer forgot additional thing at the end. An import list is not a value, you can't examine whats in the list, you can't enumerate it etc. As such, it doesn't really matter how many elements are in there, the important thing is what the elements are. A real list/tuple IS a value. A 3 element tuple is completely different from a 4 element tuple. Thats the difference, there is a real semantic difference - its not a case of inconsistency. Personally I'd make the rule that trailing commas are never allowed, anywhere, but I do see an argument for adding them to import lists. Thanks Neil ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2007 Feb 2, at 1:03 PM, Neil Mitchell indited: The argument that a trailing comma means the programmer forgot the last item in a list / tuple is inconsistent with the deliberately explicit permissiveness of a trailing comma in the import / export lists. In the import / export lists such a trailing comma does not mean programmer forgot additional thing at the end. An import list is not a value, you can't examine whats in the list, you can't enumerate it etc. As such, it doesn't really matter how many elements are in there, the important thing is what the elements are. I don't know enough about it, but mightn't Template Haskell disagree on that point? Or any other source-level manipulators? (perhaps that shouldn't be a consideration?) A real list/tuple IS a value. A 3 element tuple is completely different from a 4 element tuple. I don't dispute that. Thats the difference, there is a real semantic difference - its not a case of inconsistency. Personally I'd make the rule that trailing commas are never allowed, anywhere, but I do see an argument for adding them to import lists. You just highlighted the inconsistency: You refer to import lists... you appear to think of the import syntax _as a list_, and it is precisely that mental processing where the inconsistency hits/grates. If it is an import _list_ it can have trailing commas, but if it is some other _list_, it can't. I don't see the justification for making those two cases different. --D'gou ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2/2/07, Douglas Philips [EMAIL PROTECTED] wrote: On 2007 Feb 2, at 1:03 PM, Neil Mitchell indited: An import list is not a value, you can't examine whats in the list, you can't enumerate it etc. As such, it doesn't really matter how many elements are in there, the important thing is what the elements are. I don't know enough about it, but mightn't Template Haskell disagree on that point? Or any other source-level manipulators? (perhaps that shouldn't be a consideration?) Well, Template Haskell is an extension and not part of the current Haskell 98 standard. And as far as I know there's no effort to make it part of Haskell Prime. So yeah, probably it shouldn't be a consideration. You just highlighted the inconsistency: You refer to import lists... you appear to think of the import syntax _as a list_, and it is precisely that mental processing where the inconsistency hits/grates. If it is an import _list_ it can have trailing commas, but if it is some other _list_, it can't. I don't see the justification for making those two cases different. The thing that I think Neil and Ganesh were trying to get at is that an import list can't appear in just any context (that's what's meant by it not being a first-class value), so Haskell programmers *do* usually think about them differently. Cheers, Kirsten -- Kirsten Chevalier* [EMAIL PROTECTED] *Often in error, never in doubt Man, you're not so perfect / Man, you're not a pearl / You're nothing more, man, than a little piece of sand / That grew up inside of a girl -- Jude ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
Douglas Philips wrote:
On 2007 Feb 2, at 1:03 PM, Neil Mitchell indited:
Personally I'd make the rule that trailing commas are never allowed,
anywhere, but I do see an argument for adding them to import lists.
You just highlighted the inconsistency:
You refer to import lists... you appear to think of the import
syntax _as a list_,
and it is precisely that mental processing where the inconsistency
hits/grates.
If it is an import _list_ it can have trailing commas, but if it is
some other _list_, it can't.
I don't see the justification for making those two cases different.
I don't either, but I'd agree with Neil that trailing commas shouldn't be
allowed anywhere, but would reject the argument of allowing them in import
lists since it just seems to me that this was to save someone making the
trivial effort to make their code look tidy and complete. 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) 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
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?). Also, I think in maths the convention
is to use commas as separators when writing down coordinates etc.
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... :-)
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:
module Foo #-- # introduces a layout block
{;}
Bar #
Con1
Con2
where
import Control.Monad.Trans #
MonadIO{..}
MonadTrans{..}
(Though the above is obviously too radical a departure for Haskell')
Brian.
--
http://www.metamilk.com
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
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
Re: List syntax (was: Re: help from the community?)
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
