Re: [Haskell-cafe] 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.sklad...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 cdsm...@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.sklad...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 cdsm...@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 cdsm...@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.sklad...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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.sklad...@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 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 overloaded literals. In some cases, I think it's a good trade to remove overloaded literals, in exchange for simpler error messages. This leaves new programmers learning a very small, simple language, and not staring so much at cryptic error messages. At the same time, it's not really changing the language, except for the need to explicitly use type classes (via conversion functions like fromInteger) rather than get them thrown in implicitly. With GHC's extended defaulting rules that apply for OverloadedStrings, this could also be used to treat all string literals as Text, too, which might make some people happy, too. Of course, the disadvantage is that for numeric types, you would lose the convenience of overloaded operators, since this is only a sensible thing to do if you're replacing the Prelude with one that doesn't use type classes. But in at least my intended use, I prefer to have a single Number type anyway (and a single Text type that's not sometimes called [Char]). In the past, explaining these things has eaten up far too much time that I'd rather have spent on more general skills and creative activities. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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 cdsm...@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 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 overloaded literals. In some cases, I think it's a good trade to remove overloaded literals, in exchange for simpler error messages. This leaves new programmers learning a very small, simple language, and not staring so much at cryptic error messages. At the same time, it's not really changing the language, except for the need to explicitly use type classes (via conversion functions like fromInteger) rather than get them thrown in implicitly. With GHC's extended defaulting rules that apply for OverloadedStrings, this could also be used to treat all string literals as Text, too, which might make some people happy, too. Of course, the disadvantage is that for numeric types, you would lose the convenience of overloaded operators, since this is only a sensible thing to do if you're replacing the Prelude with one that doesn't use type classes. But in at least my intended use, I prefer to have a single Number type anyway (and a single Text type that's not sometimes called [Char]). In the past, explaining these things has eaten up far too much time that I'd rather have spent on more general skills and creative activities. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
