Hi all, I've completed the ExplicitForAll proposal, started by Niklas Broberg (but any errors are doubtless mine!): http://hackage.haskell.org/trac/haskell-prime/wiki/ExplicitForall http://hackage.haskell.org/trac/haskell-prime/ticket/133 I imagine this is too late for H2011 (if that will actually be happening?), but there wasn't an H2012 milestone, so I put it in H2011 anyway. Please feel free to remilestone. Thanks Ian
Hello,
I have no strong feelings for or against allowing explicit foralls in
types but I have a few questions/suggestions on the proposal in its
current form (21 Nov 2010):
* Why is "forall" promoted to a keyword, rather then just being
special in types as is in all implementations? I like the current
status quo where "forall" can still be used in value expressions.
* It seems that allowing "superflous" values in "foralls" could be
useful for some future extensions. For example, if we had scoped type
variables and explicit type application, then it may make sense to
have quantified variables that do not appear
in the rest of the type (but do appear in the definition of the
function). I guess, we could revise things again if that was to ever
happen but still, it seems to me that this might be more appropriate
as an "unused variable" warning, rather then an error?
* Is there any case where an empty "forall" is useful, and if not,
why allow it? I guess it is a way to make it explicit that a value is
monomorphic but i think that types like "forall. Int" look odd.
-Iavor
On Fri, Nov 19, 2010 at 5:08 PM, Ian Lynagh
Hi all,
I've completed the ExplicitForAll proposal, started by Niklas Broberg (but any errors are doubtless mine!):
http://hackage.haskell.org/trac/haskell-prime/wiki/ExplicitForall http://hackage.haskell.org/trac/haskell-prime/ticket/133
I imagine this is too late for H2011 (if that will actually be happening?), but there wasn't an H2012 milestone, so I put it in H2011 anyway. Please feel free to remilestone.
Thanks Ian
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Hi Iavor, Thanks for your comments. On Sun, Nov 21, 2010 at 06:25:38PM -0800, Iavor Diatchki wrote:
* Why is "forall" promoted to a keyword, rather then just being special in types as is in all implementations? I like the current status quo where "forall" can still be used in value expressions.
You can't use "case" as a type variable, so I don't see why you should be able to use "forall" as an expression variable. I imagine that the reason implementations currently allow it is to minimise the chance of an extension breaking existing programs, but I believe that when making new versions of the standard we should, where feasible, write them in the way that they would have been written if the previous versions had never existed.
* It seems that allowing "superflous" values in "foralls" could be useful for some future extensions. For example, if we had scoped type variables and explicit type application, then it may make sense to have quantified variables that do not appear in the rest of the type (but do appear in the definition of the function). I guess, we could revise things again if that was to ever happen but still, it seems to me that this might be more appropriate as an "unused variable" warning, rather then an error?
"Eq a => Int" isn't a valid type, so I don't think "forall a . Int" should be either. As you say, it's possible that future extensions will generalise this.
* Is there any case where an empty "forall" is useful, and if not, why allow it? I guess it is a way to make it explicit that a value is monomorphic but i think that types like "forall. Int" look odd.
I don't mind either way. Thanks Ian
On 11/22/10 06:41, Ian Lynagh wrote:
On Sun, Nov 21, 2010 at 06:25:38PM -0800, Iavor Diatchki wrote:
* It seems that allowing "superflous" values in "foralls" could be useful for some future extensions. For example, if we had scoped type variables and explicit type application, then it may make sense to have quantified variables that do not appear in the rest of the type (but do appear in the definition of the function). I guess, we could revise things again if that was to ever happen but still, it seems to me that this might be more appropriate as an "unused variable" warning, rather then an error?
"Eq a => Int" isn't a valid type, so I don't think "forall a . Int" should be either. As you say, it's possible that future extensions will generalise this.
In functions with typeclass overloading, the typeclass must be picked in order to call the function, even if this means resorting to defaulting. In functions with parametric polymorphism (no (context)=>), it never needs to be decided. For example, "exitFailure :: IO a" can be called on a line where the return value is never used (besides being unified with (>>=) types and stuff); it can remain "a". So I don't think that analogy works for me. Still not sure whether we should allow "forall a . Int" or not (no strong opinions either way). I think it would compile and type-inference fine (although GHC experts may correct me.. and/or people familiar with other compiler implementations too).
* Is there any case where an empty "forall" is useful, and if not, why allow it? I guess it is a way to make it explicit that a value is monomorphic but i think that types like "forall. Int" look odd.
I don't mind either way.
It looks odd, but it would be annoying (to tools and otherwise) to exclude it from being allowed, even if it's not used much. P.S. IMHO capitalization, ExplicitForAll vs ExplicitForall, let's stick to one. The extension is written ExplicitForall. -Isaac
On Mon, Nov 22, 2010 at 02:36:51PM -0500, Isaac Dupree wrote:
P.S. IMHO capitalization, ExplicitForAll vs ExplicitForall, let's stick to one. The extension is written ExplicitForall.
GHC only knows about ExplicitForAll. I think this was a mistake, but I don't think it's worth changing now (assuming the proposal is accepted), as shortly after it is part of H' it won't be necessary to refer to it by name in new code anyway. Thanks Ian
On 22/11/10 11:41, Ian Lynagh wrote:
Hi Iavor,
Thanks for your comments.
On Sun, Nov 21, 2010 at 06:25:38PM -0800, Iavor Diatchki wrote:
* Why is "forall" promoted to a keyword, rather then just being special in types as is in all implementations? I like the current status quo where "forall" can still be used in value expressions.
You can't use "case" as a type variable, so I don't see why you should be able to use "forall" as an expression variable.
I imagine that the reason implementations currently allow it is to minimise the chance of an extension breaking existing programs, but I believe that when making new versions of the standard we should, where feasible, write them in the way that they would have been written if the previous versions had never existed.
We tend not to make new global keywords when we can avoid doing so. 'hiding', 'qualified', 'as', 'safe', 'unsafe', 'dynamic' etc. are all examples of identifiers interpreted as keywords only in certain contexts. I don't think it's feasible to allow 'case' as a type variable, but it's certainly feasible to allow 'forall' as a term variable. On the other hand, it makes life difficult for syntax highlighters. Cheers, Simon
On Thu, Dec 23, 2010 at 09:46:29AM +0000, Simon Marlow wrote:
I don't think it's feasible to allow 'case' as a type variable, but it's certainly feasible to allow 'forall' as a term variable.
Why is 'case'-only-in-expression harder than 'forall'-only-in-type?
On the other hand, it makes life difficult for syntax highlighters.
Yup. Thanks Ian
I think they are equally feasible, but as Simon says, we have avoided
introducing new global keywords.
And I think we should avoid it this time too. Why break programs when we
don't have to.
-- Lennart
On Fri, Dec 24, 2010 at 9:31 PM, Ian Lynagh
On Thu, Dec 23, 2010 at 09:46:29AM +0000, Simon Marlow wrote:
I don't think it's feasible to allow 'case' as a type variable, but it's certainly feasible to allow 'forall' as a term variable.
Why is 'case'-only-in-expression harder than 'forall'-only-in-type?
On the other hand, it makes life difficult for syntax highlighters.
Yup.
Thanks Ian
_______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
On Fri, Dec 24, 2010 at 11:31:17PM +0100, Lennart Augustsson wrote:
I think they are equally feasible, but as Simon says, we have avoided introducing new global keywords. And I think we should avoid it this time too. Why break programs when we don't have to.
I've added an alternative delta to the page, where forall is only a keyword in types. The committee can choose which they prefer. Thanks Ian
participants (5)
-
Ian Lynagh -
Iavor Diatchki -
Isaac Dupree -
Lennart Augustsson -
Simon Marlow