Chris Smith | 8 Jul 21:54 2013
Picon

Possible extension to Haskell overloading behavior

So I've been thinking about something, and I'm curious whether anyone
(in particular, people involved with GHC) think this is a worthwhile
idea.

I'd like to implement an extension to GHC to offer a different
behavior for literals with polymorphic types.  The current behavior is
something like:

1. Give the literal a polymorphic type, like (Integral a => a)
2. Type check the whole program, possibly giving the term a more
constrained type.
3. If the type is still ambiguous, apply defaulting rules.

I'd like to add the option to do this instead.

1. Take the polymorphic type, and immediately apply defaulting rules
to get a monomorphic type.
2. Type check the program with the monomorphic type.

Mostly, this would reduce the set of valid programs, since the type is
chosen before considering whether it meets all the relevant
constraints.  So what's the purpose?  To simplify type errors for
programmers who don't understand type classes.  What I have in mind is
domain-specific dialects of Haskell that replace the Prelude and are
aimed at less technical audiences - in my case, children around 10 to
13 years old; but I think the ideas apply elsewhere, too.  Type
classes are (debatably) the one feature of Haskell that tends to be
tricky for non-technical audiences, and yet pops up in very simple
programs (and more importantly, their error messages) even when the
programmer wasn't aware of it's existence, because of its role in
(Continue reading)

Chris Smith | 8 Jul 22:23 2013
Picon

Re: Possible extension to Haskell overloading behavior

Oops, when I wrote this, I'd assumed it was possible to export
defaults from a module, like an alternate Prelude.  But it looks like
they only affect the current module.  So this whole thing depends on
also being able to either define defaults in an imported module, or in
options to GHC.

On Mon, Jul 8, 2013 at 12:54 PM, Chris Smith <cdsmith <at> gmail.com> wrote:
> So I've been thinking about something, and I'm curious whether anyone
> (in particular, people involved with GHC) think this is a worthwhile
> idea.
>
> I'd like to implement an extension to GHC to offer a different
> behavior for literals with polymorphic types.  The current behavior is
> something like:
>
> 1. Give the literal a polymorphic type, like (Integral a => a)
> 2. Type check the whole program, possibly giving the term a more
> constrained type.
> 3. If the type is still ambiguous, apply defaulting rules.
>
> I'd like to add the option to do this instead.
>
> 1. Take the polymorphic type, and immediately apply defaulting rules
> to get a monomorphic type.
> 2. Type check the program with the monomorphic type.
>
> Mostly, this would reduce the set of valid programs, since the type is
> chosen before considering whether it meets all the relevant
> constraints.  So what's the purpose?  To simplify type errors for
> programmers who don't understand type classes.  What I have in mind is
(Continue reading)

Aleksey Khudyakov | 9 Jul 20:46 2013
Picon

Re: Possible extension to Haskell overloading behavior

On 08.07.2013 23:54, Chris Smith wrote:
> So I've been thinking about something, and I'm curious whether anyone
> (in particular, people involved with GHC) think this is a worthwhile
> idea.
>
> I'd like to implement an extension to GHC to offer a different
> behavior for literals with polymorphic types.  The current behavior is
> something like:
>
Probably RebidableSyntax[1] could work for you. From description it
allows to change meaning of literals.

[1] 
http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/syntax-extns.html#rebindable-syntax
Chris Smith | 9 Jul 22:47 2013
Picon

Re: Possible extension to Haskell overloading behavior

Oh, yes.  That looks great!  Also seems to work with OverloadedStrings
in the natural way in GHC 7.6, although that isn't documented.

Now if only it didn't force NoImplicitPrelude, since I really want to
-hide-package base and -package my-other-prelude.  Even adding
-XImplicitPrelude doesn't help.

On Tue, Jul 9, 2013 at 11:46 AM, Aleksey Khudyakov
<alexey.skladnoy <at> gmail.com> wrote:
> On 08.07.2013 23:54, Chris Smith wrote:
>>
>> So I've been thinking about something, and I'm curious whether anyone
>> (in particular, people involved with GHC) think this is a worthwhile
>> idea.
>>
>> I'd like to implement an extension to GHC to offer a different
>> behavior for literals with polymorphic types.  The current behavior is
>> something like:
>>
> Probably RebidableSyntax[1] could work for you. From description it
> allows to change meaning of literals.
>
> [1]
> http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/syntax-extns.html#rebindable-syntax
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
(Continue reading)

Chris Smith | 9 Jul 22:51 2013
Picon

Re: Possible extension to Haskell overloading behavior

Oh, never mind.  In this case, I guess I don't need an extension at all!

On Tue, Jul 9, 2013 at 1:47 PM, Chris Smith <cdsmith <at> gmail.com> wrote:
> Oh, yes.  That looks great!  Also seems to work with OverloadedStrings
> in the natural way in GHC 7.6, although that isn't documented.
>
> Now if only it didn't force NoImplicitPrelude, since I really want to
> -hide-package base and -package my-other-prelude.  Even adding
> -XImplicitPrelude doesn't help.
>
> On Tue, Jul 9, 2013 at 11:46 AM, Aleksey Khudyakov
> <alexey.skladnoy <at> gmail.com> wrote:
>> On 08.07.2013 23:54, Chris Smith wrote:
>>>
>>> So I've been thinking about something, and I'm curious whether anyone
>>> (in particular, people involved with GHC) think this is a worthwhile
>>> idea.
>>>
>>> I'd like to implement an extension to GHC to offer a different
>>> behavior for literals with polymorphic types.  The current behavior is
>>> something like:
>>>
>> Probably RebidableSyntax[1] could work for you. From description it
>> allows to change meaning of literals.
>>
>> [1]
>> http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/syntax-extns.html#rebindable-syntax
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
(Continue reading)

Chris Smith | 9 Jul 23:13 2013
Picon

Re: Possible extension to Haskell overloading behavior

Ugh... I take back the never mind.  So if I replace Prelude with an
alternate definition, but don't use RebindableSyntax, and then hide
the base package, GHC still uses fromInteger and such from base even
though it should be inaccessible.  But if I do use RebindableSyntax,
then the end-user has to add 'import Prelude' to the top of their
code.  Am I missing something?

On Tue, Jul 9, 2013 at 1:51 PM, Chris Smith <cdsmith <at> gmail.com> wrote:
> Oh, never mind.  In this case, I guess I don't need an extension at all!
>
> On Tue, Jul 9, 2013 at 1:47 PM, Chris Smith <cdsmith <at> gmail.com> wrote:
>> Oh, yes.  That looks great!  Also seems to work with OverloadedStrings
>> in the natural way in GHC 7.6, although that isn't documented.
>>
>> Now if only it didn't force NoImplicitPrelude, since I really want to
>> -hide-package base and -package my-other-prelude.  Even adding
>> -XImplicitPrelude doesn't help.
>>
>> On Tue, Jul 9, 2013 at 11:46 AM, Aleksey Khudyakov
>> <alexey.skladnoy <at> gmail.com> wrote:
>>> On 08.07.2013 23:54, Chris Smith wrote:
>>>>
>>>> So I've been thinking about something, and I'm curious whether anyone
>>>> (in particular, people involved with GHC) think this is a worthwhile
>>>> idea.
>>>>
>>>> I'd like to implement an extension to GHC to offer a different
>>>> behavior for literals with polymorphic types.  The current behavior is
>>>> something like:
>>>>
(Continue reading)

Aleksey Khudyakov | 10 Jul 00:08 2013
Picon

Re: Possible extension to Haskell overloading behavior

On 10.07.2013 01:13, Chris Smith wrote:
> Ugh... I take back the never mind.  So if I replace Prelude with an
> alternate definition, but don't use RebindableSyntax, and then hide
> the base package, GHC still uses fromInteger and such from base even
> though it should be inaccessible.  But if I do use RebindableSyntax,
> then the end-user has to add 'import Prelude' to the top of their
> code.  Am I missing something?
>
If base is hidden GHCi refuses to start becaus it can't import Prelude 
(with -XNoImplicitPrelude it starts just fine).

According to documentation GHC will use whatever fromInteger is in 
scope. But I never used extension in such way.
Chris Smith | 10 Jul 01:09 2013
Picon

Re: Possible extension to Haskell overloading behavior

This is working now.  Trying to use -XRebindableSyntax with -XImplicitPrelude seems to not work (Prelude is still not loaded) when the exposed Prelude is from base, but it works fine when the Prelude is from a different package.  Counterintuitive, but it does everything I need it to.  Thanks for the suggestion!

On Jul 9, 2013 4:20 PM, "Aleksey Khudyakov" <alexey.skladnoy <at> gmail.com> wrote:
On 10.07.2013 01:13, Chris Smith wrote:
Ugh... I take back the never mind.  So if I replace Prelude with an
alternate definition, but don't use RebindableSyntax, and then hide
the base package, GHC still uses fromInteger and such from base even
though it should be inaccessible.  But if I do use RebindableSyntax,
then the end-user has to add 'import Prelude' to the top of their
code.  Am I missing something?

If base is hidden GHCi refuses to start becaus it can't import Prelude (with -XNoImplicitPrelude it starts just fine).

According to documentation GHC will use whatever fromInteger is in scope. But I never used extension in such way.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Gmane