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
Re: help from the community?
On Mon, Jan 29, 2007 at 10:08:59AM +0100, Andres Loeh wrote: I didn't fully understand this requirement. If Haskell-prime gets rank-2 or rank-n types, then do we need to restrict constructors in this way? Ok, this really boils down to the question of whether we do rank-2 or rank-n types. I'm biased, because I actually use rank-n types frequently, and feel somewhat limited by the rank-2 restrictions. I don't know how many people actually do, though. I can understand Iavor's points that rank-2 might be easier to explain, but at least GHC's rank-n extension has a very detailed paper explaining it, so I guess it's one of the better documented extensions. I would say there is not much point in doing just rank-2. Once you know how to do rank-n (and we do, thanks to SPJ's great paper) then it is just as easy to implement as rank-2. Perhaps even moreso since it is a rather elegant general change to the type inferencer rather than a special case. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
Douglas Philips [EMAIL PROTECTED] wrote: .to fark around with that stoopid ass ... Pisses off users ... domineering compiler writer can feel smug 'bout 'mself. Feh. Feh^2. Hey, man, take a chill pill. I did say it was a _minor_ horror. this is off topic. Sorry, I don't know if that is troll bait or not... 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! :-) Regards, Malcolm ___ 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
Re: help from the community?
Taral wrote:
On 1/31/07, Conor McBride [EMAIL PROTECTED] wrote:
So, as far as Haskell' is concerned, I'd favour forbidding non-empty
cases, but only because I favour having some more explicit syntax for
empty cases, further down the line.
I see nothing wrong with case x of {}, with required braces. The
layout rule never generates empty braces.
main = do
a - do
b - something
case b of
return a
Doesn't the layout rule convert the above to:
main = do { a - do { b - something; case b of {}}; return a}
^^
empty braces
In any case I thought the layout rule was supposed to be regarded as just a
convenience rather than making a distinction between explicit braces and
braces added by the rule?
Also, can anyone explain why empty case constructs are needed? Why not just
write undefined?
Brian.
--
http://www.metamilk.com
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
Here are some of my comments to Iavor's proposals: Notation for Schemes PROPOSAL: be liberal: allow empty quantifier lists allow variables that are not mentioned in the body of a type (but warn) allow predicates that do not mention quantified variables (but warn?) For the reasons that others have expressed, I prefer that we not be liberal here. I think we should reject the first two cases. I'm ambivalent about the last one. I don't think we want to allow types like: forall . Int or forall a b. Int These types are mostly bugs. Furthermore, rejecting them doesn't limit expressiveness: they should both be equivalent to Int, so user could just write Int. I can't really think how allowing these types extends the expressiveness of the language, nor can I imagine a situation where someone would prefer seeing one of these types instead of Int. And in fact, given restrictions on higher-rank and impredicativity, Int would be a much better type to use. (This issue is *slightly* related to the one below. Perhaps different answers for that question may interact with this one.) On the other hand, perhaps there is uses for types like C a = a - a where a is bound in some external context? The last issue doesn't seem very straightforward to me. Equivalence for type schemes PROPOSAL: Use syntactic equivalence modulo alpha renaming order/repetition of predicates (i.e. compare predicates as sets) This proposal doesn't go as far as entailment---which would equate the types forall . Int and Int. And also types that are not alpha-equivalent but differ only in the order of quantification: i.e. forall a b. (a,b) - a =/= forall b a. (a,b) - a are *not* alpha equivalent, but it would be nice if they were semantically equivalent. I guess at this point we need to hear from implementors about how difficult it would be to implement semantic entailment? Is there another point in the space between syntactic equivalence and full entailment? (i.e. normalize types in some way and then compare them?) Higher-rank types and data constructors I'll chime in and say that I'm in favor of rank-n over rank-2 types, and I would like to allow subexpressions to have higher-rank types as well. As a user (not an implementer) I find this to be the easiest to think about, as I only have to worry about the difference between monotypes and polytypes where type inference is concerned. If my program doesn't typecheck, I need only add more annotations. I don't need to rewrite the code. About this example: data T = C1 Int (forall a. (Eq a, Show a) = a - a) | C2 (forall a. (Show a, Eq a) = a - a) h :: a - a - Int h _ _ = 1 test= h (C1 1) C2 Note that even if partial applications (of constructors and other higher-rank functions) are allowed, in this example would still be rejected because it requires impredicative polymorphism. However, -- type abbreviation for convenience type U = forall a. (Eq a, Show a) = a - a h :: U - U - Int h _ _ = 1 test = h (C1 1) C2 should be accepted if we chose the proposal for type scheme equivalence above. ---Stephanie On Jan 25, 2007, at 5:39 PM, isaac jones wrote: On Sun, 2007-01-21 at 14:25 -0800, Iavor Diatchki wrote: Hello, I have written some notes about changes to Haskell 98 that are required to add the polymorphic components extension. The purpose of the notes is to enumerate all the details that need to be specified in the Haskell report. I don't have access to the haskell-prime wiki so I attached the notes to the ticke for polymorphic components: http://hackage.haskell.org/trac/haskell-prime/ticket/57 When there are different ways to do things I have tried to enumerate the alternatives and the PROPOSAL paragraph marks the choice that I favor. Does anyone have any feedback on this work? The critical path for Haskell', at this point, is writing these bits of the report and having them validated by the community. But no one has read and commented on these topics: - Plans for changes to the report relating to Polymorphic Components - Draft changes to the report for pattern guards I understand that taking the time to pour over the report is a bit hard, but we desperately need people who are willing to do so if we're going to make progress. I think Iavor and I will start to make these changes tomorrow; does anyone have feedback before then? peace, isaac ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
On 1 Feb 2007, at 21:31, Jacques Carette wrote: Stephanie Weirich wrote: I don't think we want to allow types like: forall . Int or forall a b. Int These types are mostly bugs. Furthermore, rejecting them doesn't limit expressiveness: If you restrict yourself to programs entirely written by humans, I agree completely. But if you consider programs written by programs (say Template Haskell to be specific, but it could be via many other means), such degenerate types occur rather often. I find the program-generated code argument rather weak. In that past it was used to justify all kinds of minor horrors like excess commas in lists and so on. But if one can write a program to generate syntactically valid but ugly code, one can easily spend a little extra effort on making the result beautiful too. After all, which is the more difficult task - devising the auto-coding schema, or pretty-printing? There is no reason to accept ugly coding practices just because it makes the auto-coder's job slightly simpler. That only encourages humans to use sloppy practices in hand- written code as well. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
Malcolm Wallace wrote: I find the program-generated code argument rather weak. One might satisfy both camps by having a compiler flag to allow auto-generated ugliness. -- Ashley Yakeley ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
Malcolm Wallace wrote: If you restrict yourself to programs entirely written by humans, I agree completely. But if you consider programs written by programs (say Template Haskell to be specific, but it could be via many other means), such degenerate types occur rather often. I find the program-generated code argument rather weak. In that past it was used to justify all kinds of minor horrors like excess commas in lists and so on. But if one can write a program to generate syntactically valid but ugly code, one can easily spend a little extra effort on making the result beautiful too. I used to think so too - but some very hard-won experience [1] has changed my mind. Generating good code is very hard. And if you are doing it in a typeful way (see [1] again), you may not be able to spend a little extra effort to make the results beautiful, because typeful code does not let you do introspection very easily. I will agree with you on one aspect: if the program-generated code done by untyped manipulations, then writing a small type-simplifier is pretty easy, and my argument is weak. But this is Haskell we're talking about, and one should really hope that TH will eventually be typed, no? After all, which is the more difficult task - devising the auto-coding schema, or pretty-printing? If pretty-printing was all there was to it, I would not have made this comment. Pretty-printing is indeed easy. Typeful type-level programming is quite hard. Jacques [1] http://www.cas.mcmaster.ca/~carette/metamonads/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
On 2007 Feb 1, at 4:53 PM, Malcolm Wallace indited: I find the program-generated code argument rather weak. In that past it was used to justify all kinds of minor horrors like excess commas in lists and so on. ... That only encourages humans to use sloppy practices in hand-written code as well. Oh, you mean something like: x = ( asdf, qwer, -- ... foobar, ) Cause I really want to have to fark around with that stoopid ass last comma when I rearrange the order of the itmes in my tuple (or list). Gah, gratuitous syntax pain for what actual benefit? Pisses off users so that some domineering compiler writer can feel smug 'bout 'mself. Feh. Feh^2. It isn't sloppy, it is REGULAR. It is easy to use that trivial human eye/brain pattern matching to see that it _is_ correct. But maybe this is off topic. Sorry, I don't know if that is troll bait or not... --D'gou ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
Just a little remark on the side: 'If' and 'case' demand exactly one expression. In such cases allowing zero expressions is not a generalization but an unnecessary complication. 'Let' and 'where' allow any number of bindings, so allowing zero bindings (instead of demanding at least one) is a simplification. I meant the branches of a case (the report specifies at least 1). I think it's important to keep some possibility for the compiler to detect probable errors as syntax errors. If all syntax is inhabited by strange defaults then this just means simple errors will go undetected eg: let a = case foo of Here, the user has probably got sidetracked into editing some other part of the program and just forgotten to get back to fill in the cases for the case construct. Allowing zero cases means the user will get a strange runtime error instead as the function part of the case is undefined. I agree. On the other hand, if there are uninhabited types (modulo _|_), it might be nice to have an empty case as an explicit eliminator. let z = \y (foo y) Here, it seems clear that the user has just forgotten to type the - which means a simple syntax error would get transformed into a much more puzzling (esp for a newbie) type error. Again, for the lambda I obviously meant the case of 0 variables, i.e. something like (\ - y) which would then just be equivalent to y. I think this case is probably the one that's most comparable to the situation in question (whether to allow empty forall's). Since the designers of previous Haskell versions obviously thought it's a good idea to disallow empty lambdas, let's disallow empty forall's as well. Cheers, Andres ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
Hi Andres Loeh wrote: I think it's important to keep some possibility for the compiler to detect probable errors as syntax errors. If all syntax is inhabited by strange defaults then this just means simple errors will go undetected eg: let a = case foo of Here, the user has probably got sidetracked into editing some other part of the program and just forgotten to get back to fill in the cases for the case construct. Allowing zero cases means the user will get a strange runtime error instead as the function part of the case is undefined. I agree. On the other hand, if there are uninhabited types (modulo _|_), it might be nice to have an empty case as an explicit eliminator. Even if GADTs aren't on the immediate agenda, it's still important to design with them in mind. Empty case analyses are far from odd in that setting. They certainly show up all the time in Epigram programming, and it's important to show them as part of the explanation that a program covers all cases. Whether totality is being enforced or not, it's good to be clear that a piece of code is missing because it isn't needed, not because it's been forgotten or left as an undefined stub. However, it might be worth having a separate notation or keyword, unmistakably for the purpose of refuting bogus elements of empty datatypes: refute foo or nocase foo or foo stinks. Moreover, we could consider having a compiler warning if the programmer seeks to refute an element of a datatype which can contain a constructor pattern. So, as far as Haskell' is concerned, I'd favour forbidding non-empty cases, but only because I favour having some more explicit syntax for empty cases, further down the line. All the best Conor ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
On 1/31/07, Conor McBride [EMAIL PROTECTED] wrote:
So, as far as Haskell' is concerned, I'd favour forbidding non-empty
cases, but only because I favour having some more explicit syntax for
empty cases, further down the line.
I see nothing wrong with case x of {}, with required braces. The
layout rule never generates empty braces.
--
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
Re: help from the community?
Taral wrote:
I see nothing wrong with case x of {}, with required braces. The
layout rule never generates empty braces.
Also consider a simple case x, following the already allowed omission
of where in class and instance decls.
class (This a,That a) = ThisThat a
instance (This a,That a) = ThisThat a
This will be useful for GADTs:
data MyGADT a where
IntGADT :: MyGADT Int
never :: MyGADT Char - t
never x = case x -- no bottom needed
--
Ashley Yakeley
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
Hi
Ashley Yakeley wrote:
Taral wrote:
I see nothing wrong with case x of {}, with required braces. The
layout rule never generates empty braces.
Also consider a simple case x,
[..]
This will be useful for GADTs:
data MyGADT a where
IntGADT :: MyGADT Int
never :: MyGADT Char - t
never x = case x -- no bottom needed
I like it, but I might like it even more if there was a little more noise
(1) to distinguish this syntax from a lapse of concentration
(2) to indicate that the construct is (morally) strict, well-defined
because x is undefined;
remember, case undefined { _ - () } is ().
I don't like case x of {}, because it's just another way of saying
undefined, ie x might have cases but we're not going to handle any of
them. If there was some total variant, cover of case whose coverage
was enforced, I'd be happy with cover x of {}.
How about case ! x ?
Or not
Conor
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
RE: help from the community?
| I can also imagine predicates that do not mention locally-quantified | variables - the assumption must be that they mention variables bound on | the LHS of the datatype decl instead? e.g. the Show predicate here: | | data Foo a b = Foo a b | | Bar (forall c . (Show b, Relation b c) = (b,c)) | | Hmm, maybe a simpler version of this example would illustrate what you | mean by the proposal (first of the three bullets) to allow an empty | quantifier list: | | data Foo a b = Foo a b | | Bar (forall . Show b = b) | | In which case, does this even count as a polymorphic component at all? | Is it not rather GADT-like instead? | | data Foo a b where |Foo :: a - b - Foo a b |Bar :: Show b = b - Foo a b | | I was thinking that we should allow those special cases because I | could not see a reason to disallow them (rather then having a | compelling example to use them). You make a good point though, that | some of them might indicate an error in the program. So, I guess, the | main decision is: do we want to make them illegal (i.e., require an | error) or suggest that implementations report a warning? I have no | strong feelings either way, but I guess we need to pick something. I think I know what we should do on this particular point. I've even documented it here: http://www.haskell.org/ghc/dist/current/docs/users_guide/data-type-extensions.html#gadt-style I would like to urge this design, or one close to it, for Haskell'. Note that this is *not* the same as adopting GADTs. Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
Andres Loeh wrote: I cannot see how an empty list of tyvars is useful or desirable in practice: data Foo = Foo (forall . Int) is equivalent to just data Foo = Foo Int so why bother to permit the former? It probably indicates some error in the thinking of the programmer, so the compiler should bring it to her attention. The only reasons that I could see in favor of allowing empty foralls is that it might be easier to automatically generate code. Haskell seems to be a bit inconsistent in how it treats empty constructs. For example, empty let and empty where seems to be allowed, but not an empty case? Just a little remark on the side: 'If' and 'case' demand exactly one expression. In such cases allowing zero expressions is not a generalization but an unnecessary complication. 'Let' and 'where' allow any number of bindings, so allowing zero bindings (instead of demanding at least one) is a simplification. Upshot: everywhere the syntax allows a 'list' of things, one should consider allowing the empty list, too. Cheers Ben ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
The only reasons that I could see in favor of allowing empty foralls is that it might be easier to automatically generate code. Haskell seems to be a bit inconsistent in how it treats empty constructs. For example, empty let and empty where seems to be allowed, but not an empty case? Just a little remark on the side: 'If' and 'case' demand exactly one expression. In such cases allowing zero expressions is not a generalization but an unnecessary complication. 'Let' and 'where' allow any number of bindings, so allowing zero bindings (instead of demanding at least one) is a simplification. I meant the branches of a case (the report specifies at least 1). Similarly, the report specifies that lambdas must have at least one argument, infix declarations must not be empty and datatype declarations must not be empty (the latter will definitely be fixed). Cheers, Andres ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
Andres Loeh wrote: The only reasons that I could see in favor of allowing empty foralls is that it might be easier to automatically generate code. Haskell seems to be a bit inconsistent in how it treats empty constructs. For example, empty let and empty where seems to be allowed, but not an empty case? Just a little remark on the side: 'If' and 'case' demand exactly one expression. In such cases allowing zero expressions is not a generalization but an unnecessary complication. 'Let' and 'where' allow any number of bindings, so allowing zero bindings (instead of demanding at least one) is a simplification. I meant the branches of a case (the report specifies at least 1). I think it's important to keep some possibility for the compiler to detect probable errors as syntax errors. If all syntax is inhabited by strange defaults then this just means simple errors will go undetected eg: let a = case foo of Here, the user has probably got sidetracked into editing some other part of the program and just forgotten to get back to fill in the cases for the case construct. Allowing zero cases means the user will get a strange runtime error instead as the function part of the case is undefined. let z = \y (foo y) Here, it seems clear that the user has just forgotten to type the - which means a simple syntax error would get transformed into a much more puzzling (esp for a newbie) type error. The difference between the above and 'let' and 'where' is that if the enclosing construct (eg a binding) is complete, we know that the contents of the 'let' are complete (since extra local bindings added afterwards would be irrelevant) similarly for 'where', and if the enclosing construct is not complete the compiler will detect this. Therefore I think the original choices are the best since they don't seem inconsistent when looked at this way. Brian. -- http://www.metamilk.com ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
I cannot see how an empty list of tyvars is useful or desirable in practice: data Foo = Foo (forall . Int) is equivalent to just data Foo = Foo Int so why bother to permit the former? It probably indicates some error in the thinking of the programmer, so the compiler should bring it to her attention. The only reasons that I could see in favor of allowing empty foralls is that it might be easier to automatically generate code. Haskell seems to be a bit inconsistent in how it treats empty constructs. For example, empty let and empty where seems to be allowed, but not an empty case? On the other hand, I can imagine a use for phantom type variables in the quantifier (especially if they occur in multi-parameter predicates, but not in the type). So I think accepting them with a warning is reasonable. I can also imagine predicates that do not mention locally-quantified variables - the assumption must be that they mention variables bound on the LHS of the datatype decl instead? e.g. the Show predicate here: data Foo a b = Foo a b | Bar (forall c . (Show b, Relation b c) = (b,c)) Hmm, maybe a simpler version of this example would illustrate what you mean by the proposal (first of the three bullets) to allow an empty quantifier list: data Foo a b = Foo a b | Bar (forall . Show b = b) In which case, does this even count as a polymorphic component at all? Is it not rather GADT-like instead? data Foo a b where Foo :: a - b - Foo a b Bar :: Show b = b - Foo a b Would these two have the same meaning? I have a feeling what the GADT is, but no idea what the former type means. Constructor that have polymorphic components cannot appear in the program without values for their polymorphic fields. I didn't fully understand this requirement. If Haskell-prime gets rank-2 or rank-n types, then do we need to restrict constructors in this way? Ok, this really boils down to the question of whether we do rank-2 or rank-n types. I'm biased, because I actually use rank-n types frequently, and feel somewhat limited by the rank-2 restrictions. I don't know how many people actually do, though. I can understand Iavor's points that rank-2 might be easier to explain, but at least GHC's rank-n extension has a very detailed paper explaining it, so I guess it's one of the better documented extensions. I very much agree that nested patterns for polymorphic components should be disallowed. Cheers, Andres ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: help from the community?
isaac jones [EMAIL PROTECTED] wrote: http://hackage.haskell.org/trac/haskell-prime/ticket/57 Does anyone have any feedback on this work? Yes, here are my thoughts. PROPOSAL: adopt GHC's convention and treat 'forall' specially in types but allow it to be used in value declarations. Agree. [ scheme = 'forall' tvars '.' opt_ctxt type ] The non-terminal 'tvars' is a sequence of type variables that are separated by blank spaces. We have a choice if we should allow empty quantifier sequences. PROPOSAL: be liberal: * allow empty quantifier lists * allow variables that are not mentioned in the body of a type (but warn) * allow predicates that do not mention quantified variables (but warn?) I cannot see how an empty list of tyvars is useful or desirable in practice: data Foo = Foo (forall . Int) is equivalent to just data Foo = Foo Int so why bother to permit the former? It probably indicates some error in the thinking of the programmer, so the compiler should bring it to her attention. On the other hand, I can imagine a use for phantom type variables in the quantifier (especially if they occur in multi-parameter predicates, but not in the type). So I think accepting them with a warning is reasonable. I can also imagine predicates that do not mention locally-quantified variables - the assumption must be that they mention variables bound on the LHS of the datatype decl instead? e.g. the Show predicate here: data Foo a b = Foo a b | Bar (forall c . (Show b, Relation b c) = (b,c)) Hmm, maybe a simpler version of this example would illustrate what you mean by the proposal (first of the three bullets) to allow an empty quantifier list: data Foo a b = Foo a b | Bar (forall . Show b = b) In which case, does this even count as a polymorphic component at all? Is it not rather GADT-like instead? data Foo a b where Foo :: a - b - Foo a b Bar :: Show b = b - Foo a b Strict Fields: Where should we place the '!'? PROPOSAL: before a schema and the schema has to be in parens. Seems the only reasonable choice. Labelled Fields. PROPOSAL: Use syntactic equivalence modulo * alpha renaming * order/repetition of predicates (i.e. compare predicates as sets) Seems OK. Using entailment looks like it would permit a far more obfuscated programming style, without adding any useful functionality. Constructor that have polymorphic components cannot appear in the program without values for their polymorphic fields. I didn't fully understand this requirement. If Haskell-prime gets rank-2 or rank-n types, then do we need to restrict constructors in this way? We do not allow nested patterns on fields that have polymorphic types. Yes, agree. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
