Enable TypeHoles by default?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Krzysztof Gogolewski
Hello,

I propose to enable -XTypeHoles in GHC by default.

Unlike other -X* flags, holes do not really change meaning of the program,
they only change error messages. Instead of "_x not in scope", we
effectively get "_x not in scope, its expected type is a -> a". You get it
only if you precede the identifier not in scope with underscore, so in some
sense you declare the intention of using holes.

Two possible issues:

(a) If you use -fdefer-type-errors, then a program might compile, while
previously it did not. However, we should facilitate compiling with
defer-type-errors, so I don't think this is a disadvantage.

(b) The identifier _ becomes both a pattern and a hole by default, which
might confuse new users.
Reply: I have never seen anyone ask why code such as "Just _ -> _" does not
work.

IMO the productivity boost by having holes by default outweighs those two
objections. I am open to hearing any other possible issues others might
find.

The change is trivial implementation-wise; add Opt_TypeHoles to the list in
languageExtensions Nothing in DynFlags.

-KG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140112/6107749e/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Daniil Frumin
Hi!

> On 13 Jan 2014, at 02:56, Krzysztof Gogolewski <krz.gogolewski at gmail.com> wrote:
>
> Hello,
>
> I propose to enable -XTypeHoles in GHC by default.
>
> Unlike other -X* flags, holes do not really change meaning of the program, they only change error messages. Instead of "_x not in scope", we effectively get "_x not in scope, its expected type is a -> a". You get it only if you precede the identifier not in scope with underscore, so in some sense you declare the intention of using holes.
>
> Two possible issues:
>
> (a) If you use -fdefer-type-errors, then a program might compile, while previously it did not. However, we should facilitate compiling with defer-type-errors, so I don't think this is a disadvantage.
>
> (b) The identifier _ becomes both a pattern and a hole by default, which might confuse new users.
> Reply: I have never seen anyone ask why code such as "Just _ -> _" does not work.
>

I do think that having _ both as a pattern and a hole might be confusing, I can see that. However that's more of a syntax issue, than an issue about default extensions IMO

> IMO the productivity boost by having holes by default outweighs those two objections. I am open to hearing any other possible issues others might find.
>
> The change is trivial implementation-wise; add Opt_TypeHoles to the list in languageExtensions Nothing in DynFlags.
>
> -KG
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Carter Schonwald
So would this *improve* error message quality for new users? Defaults that
make it easier for haskellers old and new both are a tough balance to make!


On Sun, Jan 12, 2014 at 6:40 PM, Dan Frumin <difrumin at gmail.com> wrote:

> Hi!
>
> > On 13 Jan 2014, at 02:56, Krzysztof Gogolewski <krz.gogolewski at gmail.com>
> wrote:
> >
> > Hello,
> >
> > I propose to enable -XTypeHoles in GHC by default.
> >
> > Unlike other -X* flags, holes do not really change meaning of the
> program, they only change error messages. Instead of "_x not in scope", we
> effectively get "_x not in scope, its expected type is a -> a". You get it
> only if you precede the identifier not in scope with underscore, so in some
> sense you declare the intention of using holes.
> >
> > Two possible issues:
> >
> > (a) If you use -fdefer-type-errors, then a program might compile, while
> previously it did not. However, we should facilitate compiling with
> defer-type-errors, so I don't think this is a disadvantage.
> >
> > (b) The identifier _ becomes both a pattern and a hole by default, which
> might confuse new users.
> > Reply: I have never seen anyone ask why code such as "Just _ -> _" does
> not work.
> >
>
> I do think that having _ both as a pattern and a hole might be confusing,
> I can see that. However that's more of a syntax issue, than an issue about
> default extensions IMO
>
> > IMO the productivity boost by having holes by default outweighs those
> two objections. I am open to hearing any other possible issues others might
> find.
> >
> > The change is trivial implementation-wise; add Opt_TypeHoles to the list
> in languageExtensions Nothing in DynFlags.
> >
> > -KG
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://www.haskell.org/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140112/f5887297/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Simon Peyton Jones
In reply to this post by Krzysztof Gogolewski
This would be fine by me - it's a "user-experience" question.

It would slightly threaten the notion that GHC is, by default, a Haskell-2010 compiler; that is, it accepts H-2010 programs and rejects non-H2010 programs.  But I think it would be an acceptable bending of this principle, if people wanted it.  Maybe ask ghc-users?

Simon

From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Krzysztof Gogolewski
Sent: 12 January 2014 22:56
To: ghc-devs at haskell.org
Subject: Enable TypeHoles by default?

Hello,

I propose to enable -XTypeHoles in GHC by default.

Unlike other -X* flags, holes do not really change meaning of the program, they only change error messages. Instead of "_x not in scope", we effectively get "_x not in scope, its expected type is a -> a". You get it only if you precede the identifier not in scope with underscore, so in some sense you declare the intention of using holes.

Two possible issues:

(a) If you use -fdefer-type-errors, then a program might compile, while previously it did not. However, we should facilitate compiling with defer-type-errors, so I don't think this is a disadvantage.

(b) The identifier _ becomes both a pattern and a hole by default, which might confuse new users.
Reply: I have never seen anyone ask why code such as "Just _ -> _" does not work.

IMO the productivity boost by having holes by default outweighs those two objections. I am open to hearing any other possible issues others might find.

The change is trivial implementation-wise; add Opt_TypeHoles to the list in languageExtensions Nothing in DynFlags.

-KG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140113/d24d535b/attachment-0001.html>

Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Johan Tibell-2
Perhaps we should let type holes be used for one release (so we can get
some feedback) before turning it on by default?


On Mon, Jan 13, 2014 at 9:57 AM, Simon Peyton Jones
<simonpj at microsoft.com>wrote:

>  This would be fine by me ? it?s a ?user-experience? question.
>
>
>
> It would slightly threaten the notion that GHC is, by default, a
> Haskell-2010 compiler; that is, it accepts H-2010 programs and rejects
> non-H2010 programs.  But I think it would be an acceptable bending of this
> principle, if people wanted it.  Maybe ask ghc-users?
>
> Simon
>
>
>
> *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Krzysztof
> Gogolewski
> *Sent:* 12 January 2014 22:56
> *To:* ghc-devs at haskell.org
> *Subject:* Enable TypeHoles by default?
>
>
>
> Hello,
>
>
>
> I propose to enable -XTypeHoles in GHC by default.
>
>
>
> Unlike other -X* flags, holes do not really change meaning of the program,
> they only change error messages. Instead of "_x not in scope", we
> effectively get "_x not in scope, its expected type is a -> a". You get it
> only if you precede the identifier not in scope with underscore, so in some
> sense you declare the intention of using holes.
>
>
>
> Two possible issues:
>
>
>
> (a) If you use -fdefer-type-errors, then a program might compile, while
> previously it did not. However, we should facilitate compiling with
> defer-type-errors, so I don't think this is a disadvantage.
>
>
>
> (b) The identifier _ becomes both a pattern and a hole by default, which
> might confuse new users.
>
> Reply: I have never seen anyone ask why code such as "Just _ -> _" does
> not work.
>
>
>
> IMO the productivity boost by having holes by default outweighs those two
> objections. I am open to hearing any other possible issues others might
> find.
>
>
>
> The change is trivial implementation-wise; add Opt_TypeHoles to the list
> in languageExtensions Nothing in DynFlags.
>
>
>
> -KG
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140113/31c69b34/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Simon Marlow-7
In reply to this post by Krzysztof Gogolewski
On 12/01/2014 22:56, Krzysztof Gogolewski wrote:
> I propose to enable -XTypeHoles in GHC by default.

GHC supports strict Haskell 2010 by default, and enabling any extensions
breaks that property.  That's why we don't have any extensions on by
default.

Cheers,
        Simon

Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Roman Cheplyaka-2
In reply to this post by Simon Peyton Jones
* Simon Peyton Jones <simonpj at microsoft.com> [2014-01-13 08:57:51+0000]
> This would be fine by me - it's a "user-experience" question.
>
> It would slightly threaten the notion that GHC is, by default, a
> Haskell-2010 compiler; that is, it accepts H-2010 programs and rejects
> non-H2010 programs.

But that's not the case even now, is it? Particularly due to
NondecreasingIndentation.

Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140113/94e4fc7b/attachment.sig>

Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Richard Eisenberg-2
In reply to this post by Simon Marlow-7
Maybe I'm missing something here, but how does specifying TypeHoles make GHC not compliant with Haskell 2010? Turning on TypeHoles should change only error messages. The set of programs that compile (and their meanings) should remain unchanged, by my understanding.

I'm mildly in favor of this change, but I agree that perhaps a conversation on the users list and/or waiting a cycle isn't a bad idea.

Richard

On Jan 13, 2014, at 4:51 AM, Simon Marlow <marlowsd at gmail.com> wrote:

> On 12/01/2014 22:56, Krzysztof Gogolewski wrote:
>> I propose to enable -XTypeHoles in GHC by default.
>
> GHC supports strict Haskell 2010 by default, and enabling any extensions breaks that property.  That's why we don't have any extensions on by default.
>
> Cheers,
> Simon
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs


Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Dominique Devriese-2
Perhaps already as part of such a feedback round/bikeshedding
opportunity, I'm wondering if I'm the only one who finds the name
"TypeHoles" confusing, since as far as I understand, the extension
enables holes in *expressions*, not types...  I would personally find
something like TypedHoles (note the added d) or ExpressionHoles or
something similar more intuitive. Not that I have strong feelings
about this, though...  Note that I haven't actually tried the
extension yet, but from the description, it seems like a very nice
addition to GHC, so kudos to whoever did the work...

Regards,
Dominique

2014/1/13 Richard Eisenberg <eir at cis.upenn.edu>:

> Maybe I'm missing something here, but how does specifying TypeHoles make GHC not compliant with Haskell 2010? Turning on TypeHoles should change only error messages. The set of programs that compile (and their meanings) should remain unchanged, by my understanding.
>
> I'm mildly in favor of this change, but I agree that perhaps a conversation on the users list and/or waiting a cycle isn't a bad idea.
>
> Richard
>
> On Jan 13, 2014, at 4:51 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> On 12/01/2014 22:56, Krzysztof Gogolewski wrote:
>>> I propose to enable -XTypeHoles in GHC by default.
>>
>> GHC supports strict Haskell 2010 by default, and enabling any extensions breaks that property.  That's why we don't have any extensions on by default.
>>
>> Cheers,
>>       Simon
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs

Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Simon Marlow-7
In reply to this post by Richard Eisenberg-2
Ah, my apologies, for some reason I thought that -XTypeHoles implied
-fdefer-type-errors, but I see it doesn't.  Ignore me!

Turning on TypeHoles by default looks like a useful thing, yes.

Cheers,
        Simon

On 13/01/2014 12:30, Richard Eisenberg wrote:

> Maybe I'm missing something here, but how does specifying TypeHoles make GHC not compliant with Haskell 2010? Turning on TypeHoles should change only error messages. The set of programs that compile (and their meanings) should remain unchanged, by my understanding.
>
> I'm mildly in favor of this change, but I agree that perhaps a conversation on the users list and/or waiting a cycle isn't a bad idea.
>
> Richard
>
> On Jan 13, 2014, at 4:51 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
>> On 12/01/2014 22:56, Krzysztof Gogolewski wrote:
>>> I propose to enable -XTypeHoles in GHC by default.
>>
>> GHC supports strict Haskell 2010 by default, and enabling any extensions breaks that property.  That's why we don't have any extensions on by default.
>>
>> Cheers,
>> Simon
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>

Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Simon Peyton Jones
In reply to this post by Dominique Devriese-2
| Perhaps already as part of such a feedback round/bikeshedding
| opportunity, I'm wondering if I'm the only one who finds the name
| "TypeHoles" confusing, since as far as I understand, the extension
| enables holes in *expressions*, not types...  I would personally find
| something like TypedHoles (note the added d) or ExpressionHoles or
| something similar more intuitive.

I certainly don't mind adding "TypedHoles" as a synonym, use it in the user manual, and deprecate TypeHoles (and remove it later).  If (a) no one objects and (b) someone wants to send a patch.

Simon


| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
| Dominique Devriese
| Sent: 13 January 2014 12:56
| To: ghc-devs at haskell.org
| Subject: Re: Enable TypeHoles by default?
|
| Perhaps already as part of such a feedback round/bikeshedding
| opportunity, I'm wondering if I'm the only one who finds the name
| "TypeHoles" confusing, since as far as I understand, the extension
| enables holes in *expressions*, not types...  I would personally find
| something like TypedHoles (note the added d) or ExpressionHoles or
| something similar more intuitive. Not that I have strong feelings about
| this, though...  Note that I haven't actually tried the extension yet,
| but from the description, it seems like a very nice addition to GHC, so
| kudos to whoever did the work...
|
| Regards,
| Dominique
|
| 2014/1/13 Richard Eisenberg <eir at cis.upenn.edu>:
| > Maybe I'm missing something here, but how does specifying TypeHoles
| make GHC not compliant with Haskell 2010? Turning on TypeHoles should
| change only error messages. The set of programs that compile (and their
| meanings) should remain unchanged, by my understanding.
| >
| > I'm mildly in favor of this change, but I agree that perhaps a
| conversation on the users list and/or waiting a cycle isn't a bad idea.
| >
| > Richard
| >
| > On Jan 13, 2014, at 4:51 AM, Simon Marlow <marlowsd at gmail.com> wrote:
| >
| >> On 12/01/2014 22:56, Krzysztof Gogolewski wrote:
| >>> I propose to enable -XTypeHoles in GHC by default.
| >>
| >> GHC supports strict Haskell 2010 by default, and enabling any
| extensions breaks that property.  That's why we don't have any
| extensions on by default.
| >>
| >> Cheers,
| >>       Simon
| >> _______________________________________________
| >> ghc-devs mailing list
| >> ghc-devs at haskell.org
| >> http://www.haskell.org/mailman/listinfo/ghc-devs
| >
| > _______________________________________________
| > ghc-devs mailing list
| > ghc-devs at haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs
| _______________________________________________
| ghc-devs mailing list
| ghc-devs at haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs

Reply | Threaded
Open this post in threaded view
|

Enable TypeHoles by default?

Krzysztof Gogolewski
I have re-sent the question to glasgow-haskell-users; to avoid duplication,
let's continue the thread there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140113/24d06c10/attachment.html>