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 delt
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 wrote:
> On Thu, Dec 23, 2010 at 09:46:29AM +0
On Thu, Dec 23, 2010 at 09:46:29AM +, 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 ma
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
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
all. 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 exte
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 exp
t; 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
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
Hi all,
Per request I've made a ticket and proposal page for adding
ExplicitForall to Haskell'2010:
http://hackage.haskell.org/trac/haskell-prime/ticket/133
http://hackage.haskell.org/trac/haskell-prime/wiki/ExplicitForall
Cheers
On Thu, Jul 23, 2009 at 7:36 AM, Niklas Broberg wrote:
>> Alright, let's set an actual discussion period of 2 weeks for
>> ExplicitForall. If there is no opposition by then, we can add
>> ExplicitForall to the registered extensions in cabal as a first step.
>
> Sligh
> Alright, let's set an actual discussion period of 2 weeks for
> ExplicitForall. If there is no opposition by then, we can add
> ExplicitForall to the registered extensions in cabal as a first step.
Slightly more than two weeks later, there has been no voices against
and at least
> What you suggest would be fine with me. Presumably ExplicitForall would be
> implied by RankNTypes and the other extensions?
Yes, that's the idea. Rank2Types, RankNTypes, PolymorphicComponents,
ScopedTypeVariables and LiberalTypeSynonyms would all imply
ExplicitForall.
> There
Hello Brandon,
Wednesday, June 24, 2009, 8:56:30 AM, you wrote:
> but also e.g. if you are actually compiling Haskell98, hierarchical
> modules should be illegal.
afaik, HM and FFI are just considered to be included in H98 later, so
these are part of (revised) standard
--
Best regards,
Bulat
| I would thus like to propose the following formalisation of the
| ExplicitForall extension:
What you suggest would be fine with me. Presumably ExplicitForall would be
implied by RankNTypes and the other extensions?
There is a danger of having too *many* choices.
(http
do with this at all!
So, what I'm getting at is an idea that Isaac Dupree gave as a comment
to my blog post. He said:
"I wish there was a plain old ExplicitForall extension that enabled
the keyword in types (without extending the type checker -- only like
(id :: forall a. a -> a)
16 matches
Mail list logo