From ctm at cs.nott.ac.uk Thu Feb 1 01:08:23 2007 From: ctm at cs.nott.ac.uk (Conor McBride) Date: Thu Feb 1 01:03:26 2007 Subject: help from the community? In-Reply-To: References: <20070130220950.GJ13163@iai.uni-bonn.de> <002501c744ee$55c3d0b0$ebea2950@osmet> <20070131104915.GK13163@iai.uni-bonn.de> <45C07D68.60306@cs.nott.ac.uk> Message-ID: <45C183D7.2030609@cs.nott.ac.uk> 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 From bulat.ziganshin at gmail.com Thu Feb 1 04:56:12 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 1 04:51:46 2007 Subject: ADT views Re: [Haskell] Views in Haskell In-Reply-To: <6cf91caa0701311436v524947f9g8809440c45c272dd@mail.gmail.com> References: <1669608254.20070131175308@gmail.com> <20070131161202.GB26052@abridgegame.org> <1548756987.20070131212830@gmail.com> <6cf91caa0701311436v524947f9g8809440c45c272dd@mail.gmail.com> Message-ID: <477280553.20070201125612@gmail.com> Hello J., Thursday, February 1, 2007, 1:36:33 AM, you wrote: > Yes - you've reiterated Wadler's original design, with an automatic > problems with equational reasoning raised by this approach. ok, i can live without it. i mean reasoning :) i guess that anything more complex than Turing machine makes reasoning harder. 18 years ago Haskell fathers chosen to simpilfy language in order to make reasoning easier. may be now we can change this decision? that i've proposed is made on basis of my 15 years of software development experience and i'm sure that abstraction of data representation is very important issue (and much more important than reasoning for practical programming) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gale at sefer.org Thu Feb 1 05:13:48 2007 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 1 05:08:43 2007 Subject: Global variables Message-ID: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> The trick of controlling allocation of external resources by using NOINLINE, unsafePerfromIO, and IORef to create global variables has become an indispensable technique in Haskell. It seems to work well enough with most current compilers. However, it is well known that the semantics of NOINLINE are not sufficient to guarantee that this is safe. In principle, the runtime is permitted to GC and reinstantiate these things at any time. Also, it would be nice if we could have a guarantee that global constants are not instantiated until first use. That would allow us to skip the IORef in some cases. I think this issue needs to be addressed in Haskell'. (If it has already, please accept my apologies.) Since NOINLINE has more general use, perhaps there should be a new pragma for this purpose. Thanks, Yitz From ariep at xs4all.nl Thu Feb 1 06:08:33 2007 From: ariep at xs4all.nl (Arie Peterson) Date: Thu Feb 1 06:03:26 2007 Subject: ADT views In-Reply-To: <477280553.20070201125612@gmail.com> References: <1669608254.20070131175308@gmail.com> <20070131161202.GB26052@abridgegame.org> <1548756987.20070131212830@gmail.com> <6cf91caa0701311436v524947f9g8809440c45c272dd@mail.gmail.com> <477280553.20070201125612@gmail.com> Message-ID: <20318.213.84.177.94.1170328113.squirrel@webmail.xs4all.nl> Bulat Ziganshin wrote: > ok, i can live without it. i mean reasoning :) > > i guess that anything more complex than Turing machine makes reasoning > harder. 18 years ago Haskell fathers chosen to simpilfy language in > order to make reasoning easier. may be now we can change this > decision? that i've proposed is made on basis of my 15 years of > software development experience and i'm sure that abstraction of data > representation is very important issue (and much more important than > reasoning for practical programming) No. Abstractions should (and mostly do) make reasoning easier, not harder, by having clear semantics, suited to the problem domain. The ability to reason about your program is vital in about every part of the programming cycle, and is one of the things that make Haskell work. Another of those things is abstraction of data representation, you're right about that. But I think there is no conflict between those goals. In fact, all the views proposal does is to give the natural meaning to the equation > f (v x) = h x , by letting the programmer specify a partial inverse for 'v'. Greetings, Arie From jon.fairbairn at cl.cam.ac.uk Thu Feb 1 06:26:48 2007 From: jon.fairbairn at cl.cam.ac.uk (=?utf-8?b?SsOzbiBGYWlyYmFpcm4=?=) Date: Thu Feb 1 06:22:31 2007 Subject: A view of views -- something classy? Re: [Haskell] Views in Haskell References: <1669608254.20070131175308@gmail.com> <20070131161202.GB26052@abridgegame.org> <1548756987.20070131212830@gmail.com> <6cf91caa0701311436v524947f9g8809440c45c272dd@mail.gmail.com> <477280553.20070201125612@gmail.com> Message-ID: Bulat Ziganshin writes: > > Yes - you've reiterated Wadler's original design, with > > an automatic problems with equational reasoning raised > > by this approach. > > ok, i can live without it. i mean reasoning :) That's probably not good, but I don't follow that problem yet. I'm afraid I've not had the stamina to follow this thread properly, and I doubt if I'll get any more stamina soon, so let me make a proposal not too disimilar to Bulat's and just hope that people find it appealing enough to flesh it out. The idea I'm presenting is simple enough: allow data constructors as members of classes. (Sure, David, this does have the problem of hiding potentially expensive operations as straightforward pattern matches, but that's abstraction for you). So class Sequence s where (some other stuff) Cons:: a -> s a -> s a Nil:: s a Here Cons and Nil both stand for two things: a constructor and a deconstructor. The question is how to specify the values of the two parts when giving an instance. The easiest way is just to give it in terms of something that already has the two aspects: instance Sequence [] where ... Cons = (::) Nil = [] And so a definition like f Nil = ... f (Cons a l) = ... gets a type like Sequence s => s a -> ... But we also want it to work for cases where the type we are viewing doesn't already have a constructor that does what we want, such as giving a list instance for another member of Sequence: class Sequence s where Snoc:: s a -> a -> s a (some other stuff) The idea here would be to announce that all data constructors really do have two parts and they are accessed via qualified names. So the Snoc part of the list instance would look like this: ... Snoc.construct l x = l ++ [x] Snoc.deconstruct f g [] = g Snoc.deconstruct f g l = f (init l) (last l) (We can of course argue about the precise type used for deconstructors and there is endless bikeshed painting to be done for the names construct and deconstruct, but I hope this gives the general idea). I think this proposal is simpler than the earlier ones presented -- enough that someone in better shape than me could work out the details and implement it. There's no exciting new syntax, just an extension of some current syntax to a new area, and functions declared using a "view" are automatically overloaded for everything that shares the view. As far as equational reasoning goes, I think the approach would be to specify what laws Foo.construct and Foo.deconstruct have to follow to preserve it, and leave them up to the programmer to respect (in the same way that the monad laws aren't tested by the compiler). -- J?n Fairbairn Jon.Fairbairn@cl.cam.ac.uk From brianh at metamilk.com Thu Feb 1 06:40:20 2007 From: brianh at metamilk.com (Brian Hulley) Date: Thu Feb 1 06:34:29 2007 Subject: help from the community? References: <20070130220950.GJ13163@iai.uni-bonn.de><002501c744ee$55c3d0b0$ebea2950@osmet><20070131104915.GK13163@iai.uni-bonn.de><45C07D68.60306@cs.nott.ac.uk> Message-ID: <002801c745f5$c5f636e0$b2cd2950@osmet> 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 From bulat.ziganshin at gmail.com Thu Feb 1 05:27:28 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 1 06:35:46 2007 Subject: Global variables In-Reply-To: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> References: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> Message-ID: <180984589.20070201132728@gmail.com> Hello Yitzchak, Thursday, February 1, 2007, 1:13:48 PM, you wrote: there is common proposal that i support. example of its use: i :: IORef Int i <- newIORef 1 with a semantics equivalent to current use of usafePerformIO+INLINE in GHC -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Thu Feb 1 06:47:25 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 1 06:43:50 2007 Subject: ADT views In-Reply-To: <20318.213.84.177.94.1170328113.squirrel@webmail.xs4all.nl> References: <1669608254.20070131175308@gmail.com> <20070131161202.GB26052@abridgegame.org> <1548756987.20070131212830@gmail.com> <6cf91caa0701311436v524947f9g8809440c45c272dd@mail.gmail.com> <477280553.20070201125612@gmail.com> <20318.213.84.177.94.1170328113.squirrel@webmail.xs4all.nl> Message-ID: <192591691.20070201144725@gmail.com> Hello Arie, Thursday, February 1, 2007, 2:08:33 PM, you wrote: > The ability to reason about your program is vital in about every part of > the programming cycle, and is one of the things that make Haskell work. when i say what i don't use reasoning, you can trust me :) > Another of those things is abstraction of data representation, you're > right about that. But I think there is no conflict between those goals. right now we are discussing such conflict, not be? :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From gale at sefer.org Thu Feb 1 07:48:55 2007 From: gale at sefer.org (Yitzchak Gale) Date: Thu Feb 1 07:43:50 2007 Subject: Global variables In-Reply-To: <180984589.20070201132728@gmail.com> References: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> <180984589.20070201132728@gmail.com> Message-ID: <2608b8a80702010448j670eddeajf37e1917bb53e902@mail.gmail.com> Hi Bulat, You wrote: > there is common proposal that i support. example of its use: > > i :: IORef Int > i <- newIORef 1 > > with a semantics equivalent to current use of usafePerformIO+INLINE in GHC Are the details of this posted anywhere? Is there a ticket for this? I assume you mean that this will work for anything in the IO monad, not just newIORef. I really like this approach - it is much cleaner than a pragma with unsafePerformIO. Regards, Yitz From dmhouse at gmail.com Thu Feb 1 11:51:39 2007 From: dmhouse at gmail.com (David House) Date: Thu Feb 1 11:46:32 2007 Subject: Global variables In-Reply-To: <180984589.20070201132728@gmail.com> References: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> <180984589.20070201132728@gmail.com> Message-ID: On 01/02/07, Bulat Ziganshin wrote: > there is common proposal that i support. example of its use: > > i :: IORef Int > i <- newIORef 1 > > with a semantics equivalent to current use of usafePerformIO+INLINE in GHC I think that's too safe-looking. Anything that translates to something involving unsafe* should be tagged with 'unsafe' somewhere as well. Also, as unsafe* is still compiler specific, I think a pragma is probably most appropriate: {-# GLOBAL-MUTVAR #-} i :: IORef Int i = unsafePerformIO (newIORef 1) -- -David House, dmhouse@gmail.com From flippa at flippac.org Thu Feb 1 11:57:53 2007 From: flippa at flippac.org (Philippa Cowderoy) Date: Thu Feb 1 11:50:44 2007 Subject: Global variables In-Reply-To: References: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> <180984589.20070201132728@gmail.com> Message-ID: On Thu, 1 Feb 2007, David House wrote: > I think that's too safe-looking. Anything that translates to something > involving unsafe* should be tagged with 'unsafe' somewhere as well. > Also, as unsafe* is still compiler specific, I think a pragma is > probably most appropriate: > > {-# GLOBAL-MUTVAR #-} > i :: IORef Int > i = unsafePerformIO (newIORef 1) > There might be a more sensible way to handle it while retaining the meat of Bulat's proposal, but I don't think it can really be done without making significant changes to the module system - it amounts to having initialiser actions, and once you've got those there're all sorts of things that rapidly become desirable. I've had a couple of occasions where being able to treat an entire module as being within a monad or an arrow could've been used to good effect though. -- flippa@flippac.org "The reason for this is simple yet profound. Equations of the form x = x are completely useless. All interesting equations are of the form x = y." -- John C. Baez From droundy at darcs.net Thu Feb 1 12:12:02 2007 From: droundy at darcs.net (David Roundy) Date: Thu Feb 1 12:06:57 2007 Subject: ADT views Re: [Haskell] Views in Haskell In-Reply-To: <1548756987.20070131212830@gmail.com> References: <1669608254.20070131175308@gmail.com> <20070131161202.GB26052@abridgegame.org> <1548756987.20070131212830@gmail.com> Message-ID: <20070201171200.GB30625@abridgegame.org> On Wed, Jan 31, 2007 at 09:28:30PM +0300, Bulat Ziganshin wrote: > Wednesday, January 31, 2007, 7:12:05 PM, you wrote: > >> data Coord = Coord Float Float > >> view of Coord = Polar Float Float where > >> Polar r d = Coord (r*d) (r+d) -- construction > >> Coord x y | x/=0 || y/=0 = Polar (x*y) (x+y) -- matching > > > This is somewhat pretty, but in spite of your desire to avoid creating new > > syntax, you have just done so, and in the process made views more limited. > > Pattern matching sytax remains the same, but a new declaration syntax has > > been added. And now in order to pattern match on a function it needs to > > explicitely be declared as a "view". > > yes. among the possible uses for views i clearly prefers the following: > definition of abstract data views that may differ from actual type > representation. moreover, i think that this facility should be > syntactically indistinguishable from ordinary data constructor patterns > in order to simplify learning and using of language. *defining* view is a > rare operation, using it - very common so my first point is that views > should be used in just the same way as ordinary constructors, both on > left and right side: > > f (Polar r a) = Polar (r*2) a I guess your assumption that views will rarely be defined is rather in conflict with the proposal of Simon, which was to create considerably more powerful views, I presume. > Next, i don't think that ability to use any functions in view buy > something important. pattern guards can be used for arbitrary > functions, or such function can be used in view definition. view, > imho, is not a function - it's a two-way conversion between abstract > and real data representation which has one or more alternative > variants - just like Algebraic Data Types. so, when defining a view, i > want to have ability to define exactly all variants alternative to > each other. for another representation, another view should be > created. so But you *are* using functions in views, that's what they are. And the two-way conversion, while pretty, is likely to be a fiction. It'll be too easy (and useful) for someone to define view RegexpMatch String of String where string | matchesRegexp regexp string = RegexpMatch regexp RegexpMatch regexp = undefined f (RegexpMatch "foo.+bar") = "It has foo bar in it" f s@(RegexpMatch "baz.+bar") = s ++ " has baz bar in it" You can pretend that noone will do this, but it's a nice syntax for pattern guards, which allows us to stick the guard right next to the data being guarded, which is often handy. So I guess you can see this as a promise to subvert your two-way conversion views immediately after they're created. It's worth considering whether one should try to make the syntax friendlier to such uses. One option which is sort of in between would be something like: view regexpMatch String of String where string | matchesRegexp regexp string = regexpMatch regexp f (regexpMatch "foo.+bar") = "It has foo bar in it" f s@(regexpMatch "baz.+bar") = s ++ " has baz bar in it" where the lowercaseness of "regexpMatch" indicates that this is a one-way matching function. I believe this would work just fine, and then we'd have a bit of new syntax for "function-like" views, and your constructor-like syntax for "constructor-like" views. And noone would be tempted to subvert your constructor-like views. And good programmers would have a policy that constructor-like views would really be invertible, for some definition of invertible, analogous to the monad laws, which aren't enforced, but reasonable programmers obey. > view Polar Float Float of Coord where > constructor (Polar r a) means (Coord (r*sin a) (r*cos a)) > match pattern (Polar (sqrt(x*x+y*y)) (atan(y/x))) for (Coord x y) where x/=0 > (Polar y (pi/2)) for (Coord x y) where y>0 > (Polar (-y) (-pi/2)) for (Coord x y) where y<0 > > of course, my syntax is cumbersome. that is important is that view > definition should be explicit (no arbitrary functions), it should > mention all possible alternatives and provide a way to use the same > constructor name both for construction of new values and matching > existing ones. this all together should allow to transparently use ADT > views instead of plain ADTs I definitely agree that being able to transparently switch a library between views and exported constructors would be handy, but don't think it's necesary, provided the view syntax is sufficiently elegant (which I'm not convinced Simon's proposed syntax is). If views have a distinct--but pretty--syntax, people can just move to always using views, and that's that. > > And unless you are planning to allow one-way views (you don't give any > > examples of that), "view functions" must be invertible, which greatly > > weakens their power. If you choose to allow one-way views (non-invertible > > functions), then I'd vote for not allowing two-way views, as it adds > > complexity without adding any appreciable gain. > > > I don't like your use of capital letters for ordinary functions, I enjoy > > having the syntax tell me whether (Foo 1) might or might not be an > > expensive operation. > > the whole idea of abstraction is to not give users any knowledge aside > from algorithmic specifications. when you write (x+y) you don't know > whether this (+) will end in ADD instruction or sending expedition to > Mars :) why you need low-level control over data matchers exported by > library but not over its functions? Granted. It's not necesary, but I find that it can be handy to have a bit of syntactic information about cost. > > Finally, you've replaced Simon's explicit incomplete function using Maybe > > with an implicit incomplete function that returns _|_ when the view doesn't > > match. > > it's an independent idea that can be used for Simon's syntax or don't > used at all. really, we need Prolog-like backtracking mechanism, i.e. > way to say "this pattern don't match input value, please try the next > alternative". Simon emulated backtracking with Maybe, one can does the > same with return/fail, i figured out one more way - just allow > recursive use of function guards. I am less troubled about this than I was before, but I still don't like the implied inequivalence. I like to assume that pattern matching and guards can be translated into if statements with error, and with your syntax I'm not sure whether this is true. i.e. what happens if I wrote data Coord = Coord Float Float view of Coord = Polar Float Float where Polar r d = Coord (r*d) (r+d) -- construction Coord x y = if x /= 0 && y /= 0 then Polar (x*y) (x+y) -- matching else undefined -- not matching Is this an invalid bit of code, i.e. for your views syntax, are you reusing only a subset of the function syntax? Or is this valid code that causes an error when you match f (Polar r a) = ... if the argument is Coord 0 0? If we don't allow this syntax (if statement on the RHS of the matching definition), why not? The syntax you propose can be used to decribe arbitrary functions, so why not allow us coders to use the ordinary Haskell syntax to define these functions, rather than a subset thereof? I have a feeling that with complicated views, coding the entire function on the LHS could get cumbersome pretty quickly. Of course, with pattern guards, one can always get around this by defining a helper function, but I'd prefer to avoid syntax constraints that require that I define a helper function that's only used once. -- David Roundy Department of Physics Oregon State University From dgou at mac.com Thu Feb 1 12:11:55 2007 From: dgou at mac.com (Douglas Philips) Date: Thu Feb 1 12:07:30 2007 Subject: Global variables In-Reply-To: References: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> <180984589.20070201132728@gmail.com> Message-ID: On 2007 Feb 1, at 11:51 AM, David House indited: > On 01/02/07, Bulat Ziganshin wrote: >> there is common proposal that i support. example of its use: >> >> i :: IORef Int >> i <- newIORef 1 >> >> with a semantics equivalent to current use of usafePerformIO >> +INLINE in GHC > > I think that's too safe-looking. Anything that translates to something > involving unsafe* should be tagged with 'unsafe' somewhere as well. > Also, as unsafe* is still compiler specific, I think a pragma is > probably most appropriate: > > {-# GLOBAL-MUTVAR #-} > i :: IORef Int > i = unsafePerformIO (newIORef 1) Hear hear! As a Haskell newbie things are hard enough to keep straight without that kind of magical unsafe stuff going on. Just sayin' --D'gou From droundy at darcs.net Thu Feb 1 12:20:41 2007 From: droundy at darcs.net (David Roundy) Date: Thu Feb 1 12:15:35 2007 Subject: ADT views Re: [Haskell] Views in Haskell In-Reply-To: <20070201171200.GB30625@abridgegame.org> References: <1669608254.20070131175308@gmail.com> <20070131161202.GB26052@abridgegame.org> <1548756987.20070131212830@gmail.com> <20070201171200.GB30625@abridgegame.org> Message-ID: <20070201172039.GC30625@abridgegame.org> On Thu, Feb 01, 2007 at 09:12:02AM -0800, David Roundy wrote: > On Wed, Jan 31, 2007 at 09:28:30PM +0300, Bulat Ziganshin wrote: > > Next, i don't think that ability to use any functions in view buy > > something important. pattern guards can be used for arbitrary > > functions, or such function can be used in view definition. view, > > imho, is not a function - it's a two-way conversion between abstract > > and real data representation which has one or more alternative > > variants - just like Algebraic Data Types. so, when defining a view, i > > want to have ability to define exactly all variants alternative to > > each other. for another representation, another view should be > > created. so > > But you *are* using functions in views, that's what they are. And the > two-way conversion, while pretty, is likely to be a fiction. It'll be too > easy (and useful) for someone to define > > view RegexpMatch String of String where > string | matchesRegexp regexp string = RegexpMatch regexp > RegexpMatch regexp = undefined Never mind. I see that this won't work, and it's not so easy to usefully get around your restrictions. But I must admit that this power was one of the nicest things in Simon's proposal. You'd still be in danger of me subverting your proposal with something like view Odd of Int where i | isOdd i = Odd Odd = undefined but I'll admit that this isn't particularly powerful. It's allowing arguments to the match (e.g. the regexp I was trying to sneak through) that gives Simon's views their power. It's also what forces the syntactic complexity of the -> in the matches, since you need a way to distinguish the arguments from the patterns in something like f (foomatch "x" "y" "z") -- David Roundy Department of Physics Oregon State University From sweirich at cis.upenn.edu Thu Feb 1 15:55:25 2007 From: sweirich at cis.upenn.edu (Stephanie Weirich) Date: Thu Feb 1 15:50:30 2007 Subject: help from the community? In-Reply-To: <1169764741.5904.138.camel@localhost.localdomain> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> Message-ID: <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> 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 From dmhouse at gmail.com Thu Feb 1 16:14:05 2007 From: dmhouse at gmail.com (David House) Date: Thu Feb 1 16:08:58 2007 Subject: Global variables In-Reply-To: <2608b8a80702011119i2be83c81xed372acb1da16603@mail.gmail.com> References: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> <180984589.20070201132728@gmail.com> <2608b8a80702011119i2be83c81xed372acb1da16603@mail.gmail.com> Message-ID: (CCing the list as this is of general concern.) On 01/02/07, Yitzchak Gale wrote: > Why is this unsafe? What could go wrong? It could segfault due to the type safety properties that unsafePerformIO breaks: import System.IO.Unsafe import Data.IORef ref :: IORef [a] ref <- newIORef [] main = do writeIORef ref [42] val <- readIORef ref print (val :: [Char]) If you use the pragma you're forced to import unsafePerformIO and hopefully check the haddock docs [1] where this issue is listed. [1]: http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.html -- -David House, dmhouse@gmail.com From carette at mcmaster.ca Thu Feb 1 16:31:22 2007 From: carette at mcmaster.ca (Jacques Carette) Date: Thu Feb 1 16:29:35 2007 Subject: help from the community? In-Reply-To: <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> Message-ID: <45C25C2A.70402@mcmaster.ca> 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 From bulat.ziganshin at gmail.com Thu Feb 1 16:39:38 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 1 16:35:07 2007 Subject: Global variables In-Reply-To: References: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> <180984589.20070201132728@gmail.com> <2608b8a80702011119i2be83c81xed372acb1da16603@mail.gmail.com> Message-ID: <249854609.20070202003938@gmail.com> Hello David, Friday, February 2, 2007, 12:14:05 AM, you wrote: >> Why is this unsafe? What could go wrong? > ref :: IORef [a] > ref <- newIORef [] it could be easily fixed by disallowing polymorphic types here. if someone really need polymorphism, he can continue to use old trick -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com From bulat.ziganshin at gmail.com Thu Feb 1 16:45:32 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Thu Feb 1 16:40:58 2007 Subject: help from the community? In-Reply-To: <45C25C2A.70402@mcmaster.ca> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> Message-ID: <9210232617.20070202004532@gmail.com> 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 From Malcolm.Wallace at cs.york.ac.uk Thu Feb 1 16:53:12 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Thu Feb 1 16:48:07 2007 Subject: help from the community? In-Reply-To: <45C25C2A.70402@mcmaster.ca> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> Message-ID: 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 From ashley at semantic.org Thu Feb 1 17:14:15 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Thu Feb 1 17:09:26 2007 Subject: help from the community? In-Reply-To: References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> Message-ID: 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 From carette at mcmaster.ca Thu Feb 1 17:14:27 2007 From: carette at mcmaster.ca (Jacques Carette) Date: Thu Feb 1 17:10:37 2007 Subject: help from the community? In-Reply-To: References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> Message-ID: <45C26643.6030000@mcmaster.ca> 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/ From john at repetae.net Thu Feb 1 17:36:49 2007 From: john at repetae.net (John Meacham) Date: Thu Feb 1 17:31:42 2007 Subject: Global variables In-Reply-To: References: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> <180984589.20070201132728@gmail.com> Message-ID: <20070201223649.GB21072@momenergy.repetae.net> On Thu, Feb 01, 2007 at 04:51:39PM +0000, David House wrote: > I think that's too safe-looking. Anything that translates to something > involving unsafe* should be tagged with 'unsafe' somewhere as well. > Also, as unsafe* is still compiler specific, I think a pragma is > probably most appropriate: then pretty much everything will have to be 'unsafe' :) look inside of how the libraries are implemented and they all involve unsafe operations at some point, 'unsafe' does not mean unsafe always, it means it is up to the user to provide proofs of certain properties rather than the compiler. when such a proof is provided and abstracted by an API, then it is safe. As to this particular extension, depending on the exact details it can be safe or unsafe and make different demands on the implementation. luckily, pretty much all of this was worked out in a discussion a while ago, the trick was to create a new type 'ACIO' which contained only 'good' top level operations. There will be an 'unsafeIOToACIO' of course, I mean, ACIO functions have to be implemented somehow. :) John -- John Meacham - ?repetae.net?john? From dgou at mac.com Thu Feb 1 17:57:44 2007 From: dgou at mac.com (Douglas Philips) Date: Thu Feb 1 17:53:11 2007 Subject: help from the community? In-Reply-To: References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> Message-ID: 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 From iavor.diatchki at gmail.com Thu Feb 1 19:03:23 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Feb 1 18:58:16 2007 Subject: Polymorphic components, so far Message-ID: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> Hello, Thanks to everyone who took time to comment on my notes. My & Isaac's previous post spawned a few separate discussions so I though I'd send a separate message to summarize the status of what has happened so far with regard to polymorphic components. * Rank-2 vs Rank-n types. I think that this is the most important issue that we need to resolve which is why I am placing it first :-) Here are our options: - option 1: Hugs style rank-2 types (what I described, very briefly) - option 2: GHC 6.4 style rank-2 types. As far as I understand, these are the details: * Based on "Putting Type Annotations to Work". * Predicative (type variables range only over simple (mono) types) We do not need to compare schemes for equality but, rather, we compare them for generality, using a kind of sub-typing. There * Notation for polymorphic types with explicit quantifiers. The main issue is if we should allow some corner case notational issues, such as empty quantifier lists, and quantified variables that are not mentioned in the type. - option 1: disallow these cases because they are likely to be accidental mistakes. - option 2: allow them because they make automatic program generation simpler. My initial proposal was suggesting 2 but I think that, having heard the arguments, I am leaning towards option 1. * Equality of schemes for labeled fields in different constructors. My suggestion did not seem to be too controversial. Stephanie is leaning towards a more semantic comparison of schemes. Indeed, just using alpha equivalence might be a bit too weak in some cases. Another, still fairly syntactic option, would be to pick a fixed order for the variables in quantifiers (e.g., alphabetic) for the purposes of comparison. * Pattern matching on polymorphic fields. This does not appear to be too controversial, although Atze had some reservations about this design choice. This is all that I recall, apologies if I missed something (if I did and someone notices, please post a replay so that we can keep track of what is going on). -Iavor From iavor.diatchki at gmail.com Thu Feb 1 19:25:08 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Thu Feb 1 19:19:59 2007 Subject: Polymorphic components, so far In-Reply-To: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> References: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> Message-ID: <5ab17e790702011625w311f8c9dwc510c0a3fef1645b@mail.gmail.com> Hello, (Apologies for the two emails, I accidentally hit the send button on my client before I had finished the first e-mail...) * Rank-2 vs Rank-n types. I think that this is the most important issue that we need to resolve which is why I am placing it first :-) Our options (please feel free to suggest others) - option 1: Hugs style rank-2 types (what I described , very briefly, on the ticket) * Based on "From Hindley Milner Types to First-Class Structures" * Predicative * Requires function with rank-2 types to be applied to all their polymorphic arguments. - option 2: GHC 6.4 style rank-N types. As far as I understand, these are the details: * Based on "Putting Type Annotations to Work". * Predicative * We do not compare schemes for equality but, rather, for generality, using a kind of sub-typing. * Function type constructors are special (there are two of them) because of co/contra variance issues. - option 3: GHC 6.6 style rank-N types. This one I am less familiar with but here is my understanding: * Based on "Boxy types: type inference for higher-rank types and impredicativity" * Impredicative (type variables may be bound to schemes) * Sometimes we compare schemes for equality (this is demonstrated by the example on ticket 57) and we also use the sub-typing by generality on schemes * Again, function types are special So far, Andres and Stephanie prefer a system based on rank-N types (which flavor?), and I prefer the rank-2 design. Atze would like a more expressive system that accepts the example presented on the ticket. I think this is all. -Iavor From ashley at semantic.org Thu Feb 1 21:41:54 2007 From: ashley at semantic.org (Ashley Yakeley) Date: Thu Feb 1 21:39:38 2007 Subject: Polymorphic components, so far In-Reply-To: <5ab17e790702011625w311f8c9dwc510c0a3fef1645b@mail.gmail.com> References: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> <5ab17e790702011625w311f8c9dwc510c0a3fef1645b@mail.gmail.com> Message-ID: Iavor Diatchki wrote: > - option 3: GHC 6.6 style rank-N types. This one I am less familiar > with but here is my understanding: > * Based on "Boxy types: type inference for higher-rank types and > impredicativity" > * Impredicative (type variables may be bound to schemes) > * Sometimes we compare schemes for equality (this is > demonstrated by the example on ticket 57) and we also use the > sub-typing by generality on schemes > * Again, function types are special It's buggy in GHC 6.6, see . -- Ashley Yakeley From simonpj at microsoft.com Fri Feb 2 03:35:01 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 2 03:29:53 2007 Subject: Polymorphic components, so far In-Reply-To: <5ab17e790702011625w311f8c9dwc510c0a3fef1645b@mail.gmail.com> References: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> <5ab17e790702011625w311f8c9dwc510c0a3fef1645b@mail.gmail.com> Message-ID: Thank you for the summery Iavor On the rank-2 vs rank-N issue, I can say this: * Rank-N is really no harder to implement than rank-2. The "Practical type inference.." paper gives every line of code required". The design is certainly much cleaner and less ad-hoc than GHC's old rank-2 design, which I dumped with considerable relief. * I think it'd be a pity to have an arbitrary rank-2 restriction. Rank-2 allows you to abstract over a polymorphic function. Well, it's no too long before you start wanting to abstract over a rank-2 function, and there you are. * The ability to put foralls *after* a function arrow is definitely useful, especially when type synonyms are involved. Thus type T = forall a. a->a f :: T -> T We should consider this ability part of the rank-N proposal. The "Practical type inference" paper deal smoothly with such types. GHC's rank-2 design had an arbitrary and unsatisfactory "forall-hoisting" mechanism which I hated. * For Haskell Prime we should not even consider option 3. I'm far from convinced that GHC is occupying a good point in the design space; the bug that Ashley points out (Trac #1123) is a good example. We just don't know enough about (type inference for) impredicativity. In short, Rank-N is a clear winner in my view. Simon | -----Original Message----- | From: haskell-prime-bounces@haskell.org [mailto:haskell-prime-bounces@haskell.org] On Behalf Of Iavor | Diatchki | Sent: 02 February 2007 00:25 | To: Haskell Prime | Subject: Re: Polymorphic components, so far | | Hello, | (Apologies for the two emails, I accidentally hit the send button on | my client before I had finished the first e-mail...) | | * Rank-2 vs Rank-n types. I think that this is the most important | issue that we need to resolve which is why I am placing it first :-) | Our options (please feel free to suggest others) | - option 1: Hugs style rank-2 types (what I described , very | briefly, on the ticket) | * Based on "From Hindley Milner Types to First-Class Structures" | * Predicative | * Requires function with rank-2 types to be applied to all their | polymorphic arguments. | - option 2: GHC 6.4 style rank-N types. As far as I understand, | these are the details: | * Based on "Putting Type Annotations to Work". | * Predicative | * We do not compare schemes for equality but, rather, for | generality, using a kind of sub-typing. | * Function type constructors are special (there are two of them) | because of co/contra variance issues. | - option 3: GHC 6.6 style rank-N types. This one I am less familiar | with but here is my understanding: | * Based on "Boxy types: type inference for higher-rank types and | impredicativity" | * Impredicative (type variables may be bound to schemes) | * Sometimes we compare schemes for equality (this is | demonstrated by the example on ticket 57) and we also use the | sub-typing by generality on schemes | * Again, function types are special | | So far, Andres and Stephanie prefer a system based on rank-N types | (which flavor?), and I prefer the rank-2 design. Atze would like a | more expressive system that accepts the example presented on the | ticket. | | I think this is all. | -Iavor | _______________________________________________ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime From simonpj at microsoft.com Fri Feb 2 03:44:34 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 2 03:39:31 2007 Subject: Polymorphic components, so far In-Reply-To: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> References: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> Message-ID: Iavor Does your proposal cover only higher-rank types for *data constructors*? I don't think there is any problem with extending it to arbitrary functions, as our paper "Practical type inference for higher rank types" shows. But the web page http://hackage.haskell.org/trac/haskell-prime/ticket/57 seems to cover only data constructors. I hate the proposed restriction that a higher-rank function must be applied to all its polymorphic arguments. That's a hang-over from the earlier GHC rank-2 design, and I don't think it's necessary. Again, the paper gives the details. | * Notation for polymorphic types with explicit quantifiers. The main | issue is if we should allow some corner case notational issues, such | as empty quantifier lists, and quantified variables that are not | mentioned in the type. | - option 1: disallow these cases because they are likely to be | accidental mistakes. I lean to this too. | * Equality of schemes for labeled fields in different constructors. | My suggestion did not seem to be too controversial. Stephanie is | leaning towards a more semantic comparison of schemes. Indeed, just | using alpha equivalence might be a bit too weak in some cases. | Another, still fairly syntactic option, would be to pick a fixed order | for the variables in quantifiers (e.g., alphabetic) for the purposes | of comparison. GHC uses equality modulo alpha conversion, but not modulo reordering of type variables or contexts. This is easy to explain to programmers, and of course it's easy for the programmer to ensure. Why would you want the more expressive semantic equality in practice? I think this a solution seeking a problem. Why complicate things? (Same goes for the predicates in the context. Let's insist they are the identical.) | * Pattern matching on polymorphic fields. This does not appear to be | too controversial, although Atze had some reservations about this | design choice. I removed this because I thought it was tricky to implement (given GHC's code structure). But I needed something very similar for associated types, so now GHC's code structure makes it easy, and I'm planning to put it back in. It's a small thing -- I have had one or two bug reports since removing it, but it's not a feature many will miss. Still, it seems "natural" to allow it (e.g. disallowing it requires extra words in the language spec), which is why I think I'll add it. Simon From gale at sefer.org Fri Feb 2 04:35:28 2007 From: gale at sefer.org (Yitzchak Gale) Date: Fri Feb 2 04:30:18 2007 Subject: Global variables In-Reply-To: <20070201223649.GB21072@momenergy.repetae.net> References: <2608b8a80702010213o47a02c39w11b2a5e11897f0ba@mail.gmail.com> <180984589.20070201132728@gmail.com> <20070201223649.GB21072@momenergy.repetae.net> Message-ID: <2608b8a80702020135r4debf244g2b583954d6544fe4@mail.gmail.com> John Meacham wrote: > luckily, pretty much all of this was worked out in a discussion a while > ago, the trick was to create a new type 'ACIO' which contained only > 'good' top level operations. There will be an 'unsafeIOToACIO' of > course Hmm. There was a long thread about this in Nov. 2004 on haskell-cafe with a number of proposals. One person characterized that thread as a "religious war". Is there a ticket for this issue? I know it is a bit late in the process, but this is an important hole in Haskell 98 that should be fairly easy to plug. It would be a shame to miss the opportunity. Thanks, Yitz From ross at soi.city.ac.uk Fri Feb 2 05:02:53 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Fri Feb 2 04:57:46 2007 Subject: rank-2 vs. arbitrary rank types In-Reply-To: References: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> <5ab17e790702011625w311f8c9dwc510c0a3fef1645b@mail.gmail.com> Message-ID: <20070202100253.GA5803@soi.city.ac.uk> On Fri, Feb 02, 2007 at 08:35:01AM +0000, Simon Peyton-Jones wrote: > * Rank-N is really no harder to implement than rank-2. The "Practical > type inference.." paper gives every line of code required. The design > is certainly much cleaner and less ad-hoc than GHC's old rank-2 design, > which I dumped with considerable relief. > > * I think it'd be a pity to have an arbitrary rank-2 restriction. > Rank-2 allows you to abstract over a polymorphic function. Well, > it's not too long before you start wanting to abstract over a rank-2 > function, and there you are. So is the proposed candidate the system described in the "Practical Type Inference" paper, with contravariant subsumption, bi-directional inference judgements (rather than boxes), no impredicativity, etc? As I recall the treatment of application expressions there (infer type of the function, then check the argument) was considered a bit restrictive. (It forbids runST $ foo, for example.) Is there a plan for GHC to have a mode that implements the proposed system? From Malcolm.Wallace at cs.york.ac.uk Fri Feb 2 05:46:32 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Feb 2 05:51:16 2007 Subject: help from the community? In-Reply-To: References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> Message-ID: <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> 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 From simonpj at microsoft.com Fri Feb 2 08:57:55 2007 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Fri Feb 2 08:52:49 2007 Subject: rank-2 vs. arbitrary rank types In-Reply-To: <20070202100253.GA5803@soi.city.ac.uk> References: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> <5ab17e790702011625w311f8c9dwc510c0a3fef1645b@mail.gmail.com> <20070202100253.GA5803@soi.city.ac.uk> Message-ID: | judgements (rather than boxes), no impredicativity, etc? As I recall the | treatment of application expressions there (infer type of the function, | then check the argument) was considered a bit restrictive. (It forbids | runST $ foo, for example.) That requires impredicativity, and that's the bit we don't understand very well yet. Simon From dgou at mac.com Fri Feb 2 10:36:02 2007 From: dgou at mac.com (Douglas Philips) Date: Fri Feb 2 10:31:22 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> Message-ID: 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 From Malcolm.Wallace at cs.york.ac.uk Fri Feb 2 10:55:18 2007 From: Malcolm.Wallace at cs.york.ac.uk (Malcolm Wallace) Date: Fri Feb 2 10:55:10 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <20070202155518.4b1ab500.Malcolm.Wallace@cs.york.ac.uk> 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 From brianh at metamilk.com Fri Feb 2 11:32:25 2007 From: brianh at metamilk.com (Brian Hulley) Date: Fri Feb 2 11:26:07 2007 Subject: List syntax (was: Re: help from the community?) References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com><1169764741.5904.138.camel@localhost.localdomain><2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu><45C25C2A.70402@mcmaster.ca><20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <003b01c746e7$b90cec10$18c32950@osmet> 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 From atze at xs4all.nl Fri Feb 2 11:47:23 2007 From: atze at xs4all.nl (Atze Dijkstra) Date: Fri Feb 2 11:42:15 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <20070202155518.4b1ab500.Malcolm.Wallace@cs.york.ac.uk> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <20070202155518.4b1ab500.Malcolm.Wallace@cs.york.ac.uk> Message-ID: <93685964-90F2-4D31-9C05-E762E73185C8@xs4all.nl> 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 ............ / |___\ From dgou at mac.com Fri Feb 2 12:05:36 2007 From: dgou at mac.com (Douglas Philips) Date: Fri Feb 2 12:01:02 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <003b01c746e7$b90cec10$18c32950@osmet> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> Message-ID: <69400286-01B6-4141-8007-DBCBD6627405@mac.com> 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 ( ',' )* is compelling for eye/brain pattern matching and other silly human factors reasons. :-) ) --Doug From catamorphism at gmail.com Fri Feb 2 12:13:11 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Fri Feb 2 12:08:02 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <69400286-01B6-4141-8007-DBCBD6627405@mac.com> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> Message-ID: <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> 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 From dgou at mac.com Fri Feb 2 12:41:04 2007 From: dgou at mac.com (Douglas Philips) Date: Fri Feb 2 12:36:36 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <1169764741.5904.138.camel@localhost.localdomain> <2A6E33BC-FFF9-44FC-B2E5-0ED00B380892@cis.upenn.edu> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> Message-ID: 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 From catamorphism at gmail.com Fri Feb 2 12:47:52 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Fri Feb 2 12:42:41 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> Message-ID: <4683d9370702020947n5e15422ak1f3536ae9e1262da@mail.gmail.com> 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 From ganesh.sittampalam at credit-suisse.com Fri Feb 2 12:53:17 2007 From: ganesh.sittampalam at credit-suisse.com (Sittampalam, Ganesh) Date: Fri Feb 2 12:49:30 2007 Subject: List syntax (was: Re: help from the community?) Message-ID: <8C984B4799C04D4B8F80F746537145E10D6B1052@elon12p32001.csfp.co.uk> On 2/2/07, Kirsten Chevalier 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 ============================================================================== From ndmitchell at gmail.com Fri Feb 2 13:03:47 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Fri Feb 2 12:58:37 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> Message-ID: <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> 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 From dgou at mac.com Fri Feb 2 18:34:45 2007 From: dgou at mac.com (Douglas Philips) Date: Fri Feb 2 18:30:06 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> Message-ID: <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> 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 _list_, it can't. I don't see the justification for making those two cases different. --D'gou From catamorphism at gmail.com Fri Feb 2 23:17:01 2007 From: catamorphism at gmail.com (Kirsten Chevalier) Date: Fri Feb 2 23:11:48 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> Message-ID: <4683d9370702022017t562667a1w6754418a90112343@mail.gmail.com> 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 _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 From brianh at metamilk.com Fri Feb 2 23:25:08 2007 From: brianh at metamilk.com (Brian Hulley) Date: Fri Feb 2 23:19:31 2007 Subject: List syntax (was: Re: help from the community?) References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com><45C25C2A.70402@mcmaster.ca><20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk><003b01c746e7$b90cec10$18c32950@osmet><69400286-01B6-4141-8007-DBCBD6627405@mac.com><4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com><404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> Message-ID: <001101c7474b$4a0e02e0$ffc62950@osmet> 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 _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 From dgou at mac.com Sat Feb 3 00:35:12 2007 From: dgou at mac.com (Douglas Philips) Date: Sat Feb 3 00:30:10 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <001101c7474b$4a0e02e0$ffc62950@osmet> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> <001101c7474b$4a0e02e0$ffc62950@osmet> Message-ID: <2E8ACEEB-3647-49FE-B013-AEE6642BB284@mac.com> 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 From brianh at metamilk.com Sat Feb 3 02:55:52 2007 From: brianh at metamilk.com (Brian Hulley) Date: Sat Feb 3 02:50:17 2007 Subject: List syntax (was: Re: help from the community?) References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> <001101c7474b$4a0e02e0$ffc62950@osmet> <2E8ACEEB-3647-49FE-B013-AEE6642BB284@mac.com> Message-ID: <003601c74768$baa22d70$ffc62950@osmet> 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 From bulat.ziganshin at gmail.com Sat Feb 3 08:09:40 2007 From: bulat.ziganshin at gmail.com (Bulat Ziganshin) Date: Sat Feb 3 08:06:01 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <003601c74768$baa22d70$ffc62950@osmet> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> <001101c7474b$4a0e02e0$ffc62950@osmet> <2E8ACEEB-3647-49FE-B013-AEE6642BB284@mac.com> <003601c74768$baa22d70$ffc62950@osmet> Message-ID: <312457664.20070203160940@gmail.com> 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 From carette at mcmaster.ca Sat Feb 3 10:27:28 2007 From: carette at mcmaster.ca (Jacques Carette) Date: Sat Feb 3 10:22:31 2007 Subject: Alleged problems with equational reasoning caused by views In-Reply-To: <10723.213.84.177.94.1170294879.squirrel@webmail.xs4all.nl> References: <1669608254.20070131175308@gmail.com> <20070131161202.GB26052@abridgegame.org> <1548756987.20070131212830@gmail.com> <6cf91caa0701311436v524947f9g8809440c45c272dd@mail.gmail.com> <10723.213.84.177.94.1170294879.squirrel@webmail.xs4all.nl> Message-ID: <45C4A9E0.3090105@mcmaster.ca> Arie Peterson wrote: > J. Garrett Morris wrote (to Bulat Ziganshin): > >> Yes - you've reiterated Wadler's original design, with an automatic >> creation of a type class. Erwig and Peyton-Jones, _Pattern Guards and >> Transformational Patterns_ >> (http://research.microsoft.com/~simonpj/Papers/pat.htm) mentions >> problems with equational reasoning raised by this approach. >> > > I just read this paper, in particular the part about the problems with > equational reasoning that come up once you introduce (a certain form of) > views. > The problems are not unsolvable - see the Pattern Matching Calculus http://www.cas.mcmaster.ca/~kahl/PMC/ for one way to re-introduce equational reasoning in pattern-matching. On another front, I am a big fan of the polar/cartesian 'view' of Complex numbers as being a fundamental test case for "full" views. In fact, that is quite restricted, one should instead be looking at the following views for R^2: bipolar, cardioid, cassinian, cartesian, elliptic, hyperbolic, invcassinian, invelliptic, logarithmic, logcosh, maxwell, parabolic, polar, rose, and tangent. In three dimensions, one then gets - bipolarcylindrical, bispherical, cardioidal, cardioidcylindrical, casscylindrical, confocalellip, confocalparab, conical, cylindrical, ellcylindrical, ellipsoidal, hypercylindrical, invcasscylindrical, invellcylindrical, invoblspheroidal, invprospheroidal, logcoshcylindrical, logcylindrical, maxwellcylindrical, oblatespheroidal, paraboloidal, paraboloidal2, paracylindrical, prolatespheroidal, rectangular, rosecylindrical, sixsphere, spherical, tangentcylindrical, tangentsphere, and toroidal. REFERENCES: Moon, P. and D.E.Spencer. "Field Theory Handbook, 2nd Ed." Berlin: Springer-Verlag, 1971. Spiegel, Murray R. "Mathematical Handbook of Formulas and Tables." New York: McGraw Hill Book Company, 1968. 126-130. Jacques From dgou at mac.com Sat Feb 3 11:37:51 2007 From: dgou at mac.com (Douglas Philips) Date: Sat Feb 3 11:32:49 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <003601c74768$baa22d70$ffc62950@osmet> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> <001101c7474b$4a0e02e0$ffc62950@osmet> <2E8ACEEB-3647-49FE-B013-AEE6642BB284@mac.com> <003601c74768$baa22d70$ffc62950@osmet> Message-ID: 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 :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 From brianh at metamilk.com Sat Feb 3 12:33:33 2007 From: brianh at metamilk.com (Brian Hulley) Date: Sat Feb 3 12:27:53 2007 Subject: List syntax (was: Re: help from the community?) References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <45C25C2A.70402@mcmaster.ca> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> <001101c7474b$4a0e02e0$ffc62950@osmet> <2E8ACEEB-3647-49FE-B013-AEE6642BB284@mac.com> <003601c74768$baa22d70$ffc62950@osmet> Message-ID: <000801c747b9$6e226c20$48cf2950@osmet> 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 From dgou at mac.com Sat Feb 3 13:16:09 2007 From: dgou at mac.com (Douglas Philips) Date: Sat Feb 3 13:11:15 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <4683d9370702022017t562667a1w6754418a90112343@mail.gmail.com> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <20070202104632.26924873.Malcolm.Wallace@cs.york.ac.uk> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> <4683d9370702022017t562667a1w6754418a90112343@mail.gmail.com> Message-ID: <1DEA7C7E-FA91-431D-82D9-E66BA86F5684@mac.com> 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 _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 From ijones at galois.com Sat Feb 3 13:56:45 2007 From: ijones at galois.com (isaac jones) Date: Sat Feb 3 13:51:32 2007 Subject: self moderation (or, what is Haskell' about) Message-ID: <1170529005.6031.57.camel@localhost.localdomain> Folks, We all love to talk about fun and exciting new things, and I really don't like to "change the subject", as it were, of a mailing list conversation unless it's very necessary. This list is unmoderated, and will stay unmoderated. Anyone can post whatever they want, and it's up to the community of the list to decide what's appropriate and what's off topic. If you see stuff that you think is off topic, please invite that discussion to move over to haskell-cafe or what-have-you. If you start a discussion about something core to Haskell', especially the "definitely in" topics, and the conversation wanders into strange and unknown territory, please, please re-focus your thread to get back to the important topics. Start a new thread if necessary with a summary of the discussion so far and the open questions. We've had a lot of people unsubscribing from the list in the last few days, for what it's worth. People get a mistaken impression about "What Haskell' is about" based on the discussions of the list, and sometimes it scares people :) So just be aware that the unmoderated list is _not_ a good way to get a sense of what's going on in Haskell'. Watch for announcements from the committee and requests for help from me and others for actually writing the report. Also, keep an eye on the status page of the wiki: http://hackage.haskell.org/trac/haskell-prime peace, isaac From iavor.diatchki at gmail.com Sat Feb 3 14:52:07 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat Feb 3 14:46:52 2007 Subject: Polymorphic components, so far In-Reply-To: References: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> Message-ID: <5ab17e790702031152p3b5650cct7e4d771fc2fe7056@mail.gmail.com> Hello, On 2/2/07, Simon Peyton-Jones wrote: > Does your proposal cover only higher-rank types for *data constructors*? Ticket 57 is about adding polymorphic components to datatypes which is why my notes tried to focus on this issue. Some of the issues are related to the ticket that proposes allowing arbitrary functions to have rank-2/N types and, of course, we should be consistent in our design. > | * Equality of schemes for labeled fields in different constructors. > GHC uses equality modulo alpha conversion, but not modulo reordering of type variables or contexts. This is easy to explain to programmers, and of course it's easy for the programmer to ensure. Why would you want the more expressive semantic equality in practice? I think this a solution seeking a problem. Why complicate things? (Same goes for the predicates in the context. Let's insist they are the identical.) I don't have a strong preference on this issue (although it would be nice if the order of the predicates did not matter, as this would be a first). Stephanie was suggesting that perhaps a more semantics comparison of schems might be useful, perhaps she has some examples? > | * Pattern matching on polymorphic fields. This does not appear to be > | too controversial, although Atze had some reservations about this > | design choice. > > I removed this because I thought it was tricky to implement (given GHC's code structure). But I needed something very similar for associated types, so now GHC's code structure makes it easy, and I'm planning to put it back in. > > It's a small thing -- I have had one or two bug reports since removing it, but it's not a feature many will miss. Still, it seems "natural" to allow it (e.g. disallowing it requires extra words in the language spec), which is why I think I'll add it. So far, most replys seemed to agree that this is not a big restriction. Could you give more details on how you think that should work? If we follow the current rules for pattern simplification, then this feature might be a bit confusing. Here is an example: > data T = C (forall a. [a->a]) > > f (C (f:fs)) = ... > > f x = case x of > C y -> case y of > f : fs -> ... > _ -> undefined Notice that in the translation, when we 'case' on the 'y' the list gets instantiated, so that 'f' is monomorphic. There is nothing wrong with that but I think that the may be more confusing than useful. -Iavor From taralx at gmail.com Sat Feb 3 15:04:34 2007 From: taralx at gmail.com (Taral) Date: Sat Feb 3 14:59:20 2007 Subject: List syntax (was: Re: help from the community?) In-Reply-To: <003601c74768$baa22d70$ffc62950@osmet> References: <5ab17e790701211425j347203b7td898e434d8bb767b@mail.gmail.com> <003b01c746e7$b90cec10$18c32950@osmet> <69400286-01B6-4141-8007-DBCBD6627405@mac.com> <4683d9370702020913t540584d0q200f32631ceaabf0@mail.gmail.com> <404396ef0702021003l30546a55p86e13581d3a44e4@mail.gmail.com> <8849FE78-0873-4C9C-95C6-468EDA96E3FE@mac.com> <001101c7474b$4a0e02e0$ffc62950@osmet> <2E8ACEEB-3647-49FE-B013-AEE6642BB284@mac.com> <003601c74768$baa22d70$ffc62950@osmet> Message-ID: 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 From iavor.diatchki at gmail.com Sat Feb 3 15:43:29 2007 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Sat Feb 3 15:38:16 2007 Subject: rank-2 vs. arbitrary rank types In-Reply-To: References: <5ab17e790702011603m71bd9666h4ce7246db46e562b@mail.gmail.com> <5ab17e790702011625w311f8c9dwc510c0a3fef1645b@mail.gmail.com> <20070202100253.GA5803@soi.city.ac.uk> Message-ID: <5ab17e790702031243o5debaa8focff7147f53b04241@mail.gmail.com> Hello, (I'll respond on this thread as it seems more appropriate) Simon PJ's says: > * Rank-N is really no harder to implement than rank-2. The "Practical type > inference.." paper gives every line of code required". The design is certainly > much cleaner and less ad-hoc than GHC's old rank-2 design, which I dumped > with considerable relief. I am not too concerned about the difficulty of implementation, although it seems to me that implementing the rank-2 extension requires a much smaller change to an existing Haskell 98 type checker. My main worry about the rank-N design is that (at least for me) it requres a fairly good understanding of the type checking/inference _algorithm_ to understand why a program is accepted or rejected. Off the top of my head, here is an example (using GHC 6.4.2): > g :: (forall a. Ord a => a -> a) - >Char > g = \_ -> 'a' -- OK > g = g -- OK > g = undefined -- not OK Simon PJ says: > * I think it'd be a pity to have an arbitrary rank-2