Polymorphic Components

Iavor Diatchki

21 Jan 2007 21 Jan '07

10:25 p.m.

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

Show replies by date

isaac jones

25 Jan 25 Jan

10:39 p.m.

New subject: help from the community?

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

Malcolm Wallace

26 Jan 26 Jan

12:19 p.m.

New subject: help from the community?

isaac jones 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

Iavor Diatchki

27 Jan 27 Jan

12:26 a.m.

New subject: help from the community?

Hello, On 1/26/07, Malcolm Wallace wrote:

...

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

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.

...

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

The issue is the same as for rank-2 types. My suggestion is based on the design adopted by Hugs. The basic idea is that by requiring that functions with rank-2 types (in particular, constructors that have polymorphic fields) are applied to all their polymorphic arguments, we ensure that expressions can be typed by simple types as in HM (and not type schemes). On the pragmatic side this has the benefit that the rank-2 type extension is quite easy to add to a Haskell'98 implementation: the arguments to rank-2 functions are checked pretty much in the same way as expressions with explicit type signatures. The only difference is that the type signature may contain free type variables which doesn't happen in Haskell 98. On the theoretical side we have the benefit that this fairly conservative extension to the type system (we are still working essentially in HM) gives us a big increase in expressiveness (e.g., we can encode System F programs in Haskell). The reason that the type system extension is quite simple is that Haskell 98 compares types for equality by name (as opposed to examining their structure). Other alternatives are systems like MLF (by Didier Le Botlan and Didier Rémy) and the relaxed system implemented by GHC. I think that they are both quite interesting but I must admit that for the purposes of Haskell' I am partial to the simplicity of Hug's design. The reason is that I feel that I can explain it to an ordinary Haskell programmer without too much difficulty and it has been sufficient for the situations when I've used rank-2 types. I could be unfairly biased, however, which is why discussions are most welcome! :-) -Iavor

Andres Loeh

29 Jan 29 Jan

9:08 a.m.

New subject: 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 "forall"s 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

Benjamin Franksen

30 Jan 30 Jan

9:23 p.m.

New subject: 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 "forall"s 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

Andres Loeh

10:09 p.m.

New subject: help from the community?

...

...
The only reasons that I could see in favor of allowing empty "forall"s 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

Brian Hulley

31 Jan 31 Jan

4:14 a.m.

New subject: help from the community?

Andres Loeh wrote:

...

...
...
The only reasons that I could see in favor of allowing empty "forall"s 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

Andres Loeh

10:49 a.m.

New subject: 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

Conor McBride

11:28 a.m.

New subject: 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

Taral

10:11 p.m.

New subject: help from the community?

On 1/31/07, Conor McBride 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 "You can't prove anything." -- Gödel's Incompetence Theorem

Ashley Yakeley

1 Feb 1 Feb

12:51 a.m.

New subject: 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

Conor McBride

6:08 a.m.

New subject: 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

Brian Hulley

11:40 a.m.

New subject: help from the community?

Taral wrote:

...

On 1/31/07, Conor McBride 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

John Meacham

3 Feb 3 Feb

10:13 p.m.

New subject: 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⑈

Simon Peyton-Jones

30 Jan 30 Jan

4:27 p.m.

New subject: 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-extension... 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

Stephanie Weirich

1 Feb 1 Feb

8:55 p.m.

New subject: 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

Jacques Carette

9:31 p.m.

New subject: help from the community?

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

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. Haskell does have 'const' at the value-level, and it is very useful. And so is 'const' at the type-level, especially for code generators. If there were a standard library of type-simplifiers, that could preprocess "forall a b. Int" to "Int", I again would be fine with only allowing Int. Jacques

Bulat Ziganshin

9:45 p.m.

New subject: Re[2]: help from the community?

Hello Jacques, Friday, February 2, 2007, 12:31:22 AM, you wrote:

...

If there were a standard library of type-simplifiers, that could preprocess "forall a b. Int" to "Int", I again would be fine with only allowing Int.

i think that we shouldn't reduce reliability in order to make tools author's life easier. Haskell is the language for programming in the first place. there are other languages like C-- that is used primarily for automatic code generation -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

Malcolm Wallace

9:53 p.m.

New subject: 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

Ashley Yakeley

10:14 p.m.

New subject: 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

Jacques Carette

10:14 p.m.

New subject: 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/

Douglas Philips

10:57 p.m.

New subject: 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

Malcolm Wallace

2 Feb 2 Feb

10:46 a.m.

New subject: help from the community?

Douglas Philips 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

Douglas Philips

3:36 p.m.

New subject: 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

Malcolm Wallace

3:55 p.m.

New subject: 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 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

Atze Dijkstra

4:47 p.m.

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

On 2 Feb, 2007, at 16:55 , Malcolm Wallace 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 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: atze@cs.uu.nl ............ / |___\

Brian Hulley

4:32 p.m.

New subject: 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

Douglas Philips

5:05 p.m.

New subject: 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

Kirsten Chevalier

5:13 p.m.

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

On 2/2/07, Douglas Philips 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* chevalier@alum.wellesley.edu *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

Douglas Philips

5:41 p.m.

New subject: 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 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

Kirsten Chevalier

5:47 p.m.

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

On 2/2/07, Douglas Philips 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* chevalier@alum.wellesley.edu *Often in error, never in doubt "The world is absurd and beautiful and small" -- Ani DiFranco

Neil Mitchell

6:03 p.m.

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

...

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

Douglas Philips

11:34 p.m.

New subject: 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

Kirsten Chevalier

3 Feb 3 Feb

4:17 a.m.

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

On 2/2/07, Douglas Philips 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* chevalier@alum.wellesley.edu *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

Douglas Philips

6:16 p.m.

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

On 2007 Feb 2, at 11:17 PM, Kirsten Chevalier indited:

...

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

If that is the case, the question becomes: How should "how one thinks about them" be reflected in the syntax? Aren't [ 1, 2, 3 ] and ( 1, 2, 3 ) thought about differently? Yet isn't it enough that a mere bending of the brackets is enough to distinguish them? To exaggerate for effect: :-) Are we "fooled" by the commas? Are newbies wailing at the gates for being confused and thwarted in their understandings by the heinous comma? Already there are many places in the syntax where commas are used as "separators for items in a larger-group". Yet if "how one thinks about those groups" were a driving factor at the syntax level, the syntax would not be as unified as it is, would it? How can we (humans) unify all that: Yes, this is a _list_, that is a _tuple_, over there is a _deriving_ clause ... and yet are we confused that they all use commas? Apparently not. We are confused that in certain contexts a trailing comma is permitted and in others it is not, because there is no underlying or unifying principle apparent. It is just rote memorization that does not serve a higher principle/purpose. What power have I gained by allowing a trailing comma in some places, but not uniformly everywhere that a comma is used _as a separator_? Cause I sure gain a lot by not having to remember niggling details about "Oh yes, I can use it here, but not there." And that has nothing to do with "how I think about the larger semantics"... "comma separated items in a group" is just too prevalent for it to belong to only one little domain... So yes, I agree, how I think about those groups is very different. And the syntax of grouping things is similar enough that it gets out of the way... I'd just like to make it uniform in this one regard. --D'gou

Brian Hulley

4:25 a.m.

New subject: 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

Douglas Philips

5:35 a.m.

New subject: 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 separators eg: ... (Though the above is obviously too radical a departure for Haskell')

Perhaps too radical? but I like it. I am all for eliminating syntax noise whenever/wherever unambiguously possible, and for making what remains as _regular_ as possible. Sometimes it is the foolish inconsistencies which are the hobgoblins... --D'gou

Brian Hulley

7:55 a.m.

New subject: 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 compiler option for allowing the optional trailing comma could be used so that people who prefer the existing syntax (and who might rely on the positive enforcement of "no trailing commas allowed" to catch some of their mistakes) would not be affected. Another possibility would be to allow trailing semicolons in the {;} syntax, then the #( sugar would work - you could just write: #( {a;b;c;}

...

...
Regarding import/export lists,... ... (Though the above is obviously too radical a departure for Haskell')

Perhaps too radical? but I like it. I am all for eliminating syntax noise whenever/wherever unambiguously possible, and for making what remains as _regular_ as possible. Sometimes it is the foolish inconsistencies which are the hobgoblins...

I agree. Some particularly warty hobgoblins are: (-1) as opposed to (+1) f (x+3) = g x but not f (x * 3) = g x though a problem with Haskell' is the conflict between the knowledge of these pesky warts and the desire to maintain backwards compatibility with H98, hence we may need to wait till the next major revision to see them finally vanquished. Best regards, Brian. -- http://www.metamilk.com

Bulat Ziganshin

1:09 p.m.

New subject: 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, Bulat mailto:Bulat.Ziganshin@gmail.com

Douglas Philips

4:37 p.m.

New subject: 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 mathematics. Just as it took a while to stop thinking of a computer as a typewriter (tabs, backspaces for overstriking, etc.), so I think we need to stop saying: Well, I wouldn't have put in a trailing comma if I were writing on a chalk board or a piece of paper. Of course not! But then I'm writing code / math using a medium that allows me to easily rearrange the parts. Compared to rewriting or retyping (typewriter), the ease with which I can write on a computer is so quantatively different that it demands a qualitative change. (La)TeX is the way to typeset beautiful mathematics, but how much does writing \over or \cdots look like the final result?

...

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

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

...

The #( sugar would only go part of the way to address your proposal since it doesn't address tuples written inline. But a compiler option for allowing the optional trailing comma could be used so that people who prefer the existing syntax (and who might rely on the positive enforcement of "no trailing commas allowed" to catch some of their mistakes) would not be affected.

(see above)

...

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

#( {a;b;c;}

I didn't think to go looking, but it seems trailing semicolons have similar consistency issues. stmts -> stmt1 ... stmtn exp [;] (n>=0) stmt -> exp ; | pat <- exp ; | let decls ; | ; (empty statement)

...

I agree. Some particularly warty hobgoblins are:

(-1) as opposed to (+1) f (x+3) = g x but not f (x * 3) = g x

though a problem with Haskell' is the conflict between the knowledge of these pesky warts and the desire to maintain backwards compatibility with H98, hence we may need to wait till the next major revision to see them finally vanquished.

:-) --D'gou

Brian Hulley

5:33 p.m.

New subject: 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

Taral

8:04 p.m.

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

On 2/3/07, Brian Hulley 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 "You can't prove anything." -- Gödel's Incompetence Theorem

Ulf Norell

5 Feb 5 Feb

11:13 a.m.

New subject: 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

Douglas Philips

7 Feb 7 Feb

3:17 a.m.

New subject: 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

Jeffrey Yasskin

4:43 a.m.

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

On 2/5/07, Ulf Norell 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

6726

Age (days ago)

6743

Last active (days ago)

List overview

Download

45 comments

20 participants

participants (20)

Andres Loeh
Ashley Yakeley
Atze Dijkstra
Benjamin Franksen
Brian Hulley
Bulat Ziganshin
Conor McBride
Douglas Philips
Iavor Diatchki
isaac jones
Jacques Carette
Jeffrey Yasskin
John Meacham
Kirsten Chevalier
Malcolm Wallace
Neil Mitchell
Simon Peyton-Jones
Stephanie Weirich
Taral
Ulf Norell