RE: Polymorphic components, so far
| | * Pattern matching on polymorphic fields. This does not appear to be
| | too controversial, although Atze had some reservations about this
| | design choice.
...
| 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.
Indeed; if you are going to match 'y' against a constructor, you must
instantiate. The translation is untyped so I don't think that's a problem.
Indeed, you can regard the translation as specifying both the static and
dynamic semantics. That is
f (C (f:fs)) = ...
is well-typed iff
f x = case x of { C y - case y of { f:fs -... }}
is well-typed (as a Haskell source program).
Indeed, *not* allowing y to be polymorphic amounts to a special case of this
rule that says f (C (f:fs)) is well-typed iff ... UNLESS one of the variables
bound is polymorphic. It seems simpler to be uniform, no?
The only difficulty in implementation is maintaining the translation into
System F, but I know a tidy way to do that now. And GHC is the only compiler
that does that anyway.
Simon
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
RE: rank-2 vs. arbitrary rank types
| I don't think that the rank-N system is any more expressive then the | rank-2 one. The reason is that by placing a polymorphic value in a | datatype we can decrese its rank. In this way we can reduce a program 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. | This is good to know because it narrows our choices! On the other | hand, it is a bit unfortunate that we do not have a current | implementation that implements the proposed rank-N extension. I have | been using GHC 6.4.2 as an example of the non-boxy version of the | rank-N proposal, is this reasonable? Yes, I think so. | I am not convinced. It seems to me that the higher rank polymorphism | extension is still under active research---after only 1 major version | of existsince, GHC has already changed the way it implements it, and | MLF seems to have some interesting ideas too. Well GHC changed *only* to reach for impredicativity, which is, as I say, a bridge too far for Haskell'. Otherwise it was just fine. MLF is also not relevant here, because its goal too is impredicativity, and it is a *much* more sophisticated type system with substantial implications for type inference. I could say more, but let's see what others think. Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: List syntax (was: Re: help from the community?)
On Feb 3, 2007, at 6:35 AM, Douglas Philips wrote: Well, if we're going to bring personal points of view in, it highly pisses me off that in a construct such as: ( expr , expr , expr , expr , expr , ) I have to be vigilant to remove that trailing comma when it is in _no way_ ambiguous. How about instead writing ( expr , expr , expr , expr , expr ) The only extra work is when inserting an element at the beginning, but you have the same problem in your example. / Ulf ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: rank-2 vs. arbitrary rank types
Iavor Diatchki [EMAIL PROTECTED] wrote: I don't think that the rank-N system is any more expressive then the rank-2 one. The reason is that by placing a polymorphic value in a datatype we can decrese its rank. In this way we can reduce a program of any rank to just rank-2. 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. Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
