Re: rank-2 vs. arbitrary rank types
Hello, Thanks for the responses! Here are my replies (if the email seems too long please skip to the last 2 paragraphs) Simon PJ says: Hmm. To be consistent, then, you'd have to argue for rank-2 data constructors only, since rank-2 functions can be simulated in the way you describe. I think that this is an entirely reasonable point in the design space. In fact, in the few situations where I have needed to use rank-2 types this has been sufficient. However, there is nothing inconsistent in allowing other constants besides constructors to have rank-2 types. Malcolm says: The same position could be used to argue against higher-order types. All higher-order programs can be reduced to first-order programs by firstification (encoding functional arguments as data values, which are then interpreted). Yet most functional programmers agree that being able to write higher-order definitions directly is more convenient. This is not an accurate comparison: in functional programs functions are first class values, while in the rank-N (and rank-2) proposal type schemes and simple types are different. The rank-N proposal allows programmers to treat type schemes as types in some situations but not others (e.g., the function space type constructor is special). For example, in Haskell 98 we are used to be able to curry/uncurry functions at will but this does not work with the rank-N extension: f :: (forall a. a - a) - Int - Char -- OK g :: (forall a. a - a, Int) - Char -- not OK Your point is well taken though, that perhaps in other situations the rank-N extension would be more convenient. It would be nice to have concrete examples, although I realize that perhaps the added usefulness only comes up for more complex programs. Andres says: Of course it's easier to define abbreviations for complex types, which is what type is for ... However, if you define new datatypes, you have to change your code, and applying dummy constructors everywhere doesn't make the code more readable ... Perhaps we should switch from nominal to structural type equivalence for Haskell' (just joking :-) I am not sure what you mean by changing the code: with both systems we have to change from the usual Haskell style: for rank-N we have to write type signatures, if we can, while in the rank-2 design we use data constructors for the same purpose. Note that in some situations we might not be able to write a type signature, for example, if the type mentions a local variable: f x = let g :: (forall a. a - a) - (Char,?) g h = (h 'a', h x) in ... Of course, we could also require some kind of scoped type variables extension but this is not very orthogonal and (as far as I recall) there are quite a few choice of how to do that as well... Anyways, it seems that most people are in favor of the rank-N proposal. How to proceed? I suggest that we wait a little longer to see if any more comments come in and then if I am still the only supporter for rank-2 we should be democratic and go with rank-N :-) If anyone has pros and cons for either proposal (I find examples very useful!) please post them. I guess another important point is to make sure that when we pick a design, then we have at least one (current) implementation that supports it (ideally, all implementations would eventually). Could we get a heads up from implementors about the the current status and future plans in this area of the type checker? -Iavor ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: rank-2 vs. arbitrary rank types
Hi I guess another important point is to make sure that when we pick a design, then we have at least one (current) implementation that supports it (ideally, all implementations would eventually). Could we get a heads up from implementors about the the current status and future plans in this area of the type checker? To add something as simple as pattern guards to the Yhc/nhc type checker is likely to require rewriting the type checker from scratch. To add rank-N types would also require rewriting the checker from scratch. I guess that means the Yhc team will have to find someone who really wants to write a type checker... Thanks Neil ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2007 Feb 5, at 6:13 AM, Ulf Norell wrote: How about instead writing ( expr , expr , expr , expr , expr ) The only extra work is when inserting an element at the beginning, but you have the same problem in your example. This a coding style issue. My point was that the syntax should not be inconsistently enforcing style, which it is, unless there is some payoff (which there doesn't seem to be). I argue for making trailing commas optional everywhere that commas are used to separate items in a grouping (though the syntax snippets I've posted before were only a few of those places, such as in tuples and lists). Enforcing style is not always bad, and layout has some great things going for it. Layout is also flexible where it doesn't need to be rigid. Given the experience with trailing commas in other languages, even some that support a glimmer of functional programming :-), being rigid in this area doesn't seem to have a counterbalancing payoff... I really like Brian Hulley's layout proposal: http://www.haskell.org/haskellwiki/Accessible_layout_proposal because it means I can abandon commas and other syntax noise altogether and thus moot the issue. --D'gou ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On 2/5/07, Ulf Norell [EMAIL PROTECTED] wrote: On Feb 3, 2007, at 6:35 AM, Douglas Philips wrote: Well, if we're going to bring personal points of view in, it highly pisses me off that in a construct such as: ( expr , expr , expr , expr , expr , ) I have to be vigilant to remove that trailing comma when it is in _no way_ ambiguous. How about instead writing ( expr , expr , expr , expr , expr ) The only extra work is when inserting an element at the beginning, but you have the same problem in your example. That style would be slightly improved by allowing a _leading_ comma: [ , expr , expr , expr , expr , expr ] In the trailing comma style, it looks like: [ expr , expr , expr , expr , ] Both require a similar amount of extra space, but I've found the second useful in python lists that change a lot, so I assume I'd find similar use in Haskell lists. Of course, the layout proposal solves this problem too, but it feels like a larger change. Regarding tuples vs. lists, I care a lot less about tuples because rearranging them usually requires a type change in lots of places, so fixing a comma is the least of my worries. Jeffrey Yasskin ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
