I guess we can have something similar for rationals as well, I haven't considered those. On Mon, Jun 15, 2015 at 12:41 PM, Ivan Lazar Miljenovic wrote:

On 12 June 2015 at 17:04, Michael Baikov wrote:

...

Hi Cafe!

Now that we have OverloadedList and OverloadedStrings extensions it might make sense to add something similar for numerals - right now if you want to be able to specify some items as numbers you have to implement Num instance, unfortunately not everything that can be represented as number can have sensible operations required by Num: negation makes no sense for set of natural numbers for example, multiplication for some applications of currency values which results in Num instance full of (*) = error "No multipication for Foos", (+) = error "No addition for Foos".

I don't have any statistics from hackage or github, but in codebase I'm working with there are 3 such instances.

Proposal: add OverloadedNumerals language pragma, IsNumeric typeclass and some methods to make that class useful with behavior similar to Lists and Strings.

Is this strictly to replace/augment fromInteger or are you proposing one for fromRational as well?

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

have you tried using rebindable syntax + noImplicitPrelude? That *should* allow you to model this by just having a distinguished fromInteger function in scope during desugaring/type checking. At the very least, its worth experimenting with. On Mon, Jun 15, 2015 at 12:56 AM, Michael Baikov wrote:

I guess we can have something similar for rationals as well, I haven't considered those.

On Mon, Jun 15, 2015 at 12:41 PM, Ivan Lazar Miljenovic wrote:

...

On 12 June 2015 at 17:04, Michael Baikov wrote:

...

Hi Cafe!

Now that we have OverloadedList and OverloadedStrings extensions it might make sense to add something similar for numerals - right now if you want to be able to specify some items as numbers you have to implement Num instance, unfortunately not everything that can be represented as number can have sensible operations required by Num: negation makes no sense for set of natural numbers for example, multiplication for some applications of currency values which results in Num instance full of (*) = error "No multipication for Foos", (+) = error "No addition for Foos".

I don't have any statistics from hackage or github, but in codebase I'm working with there are 3 such instances.

Proposal: add OverloadedNumerals language pragma, IsNumeric typeclass and some methods to make that class useful with behavior similar to Lists and Strings.

Is this strictly to replace/augment fromInteger or are you proposing one for fromRational as well?

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

---

Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

Ivan Lazar Miljenovic wrote:

On 15 June 2015 at 18:05, Chris Wong wrote:

...

On Fri, Jun 12, 2015 at 7:04 PM, Michael Baikov wrote:

...

Now that we have OverloadedList and OverloadedStrings extensions it might make sense to add something similar for numerals - right now if you want to be able to specify some items as numbers you have to implement Num instance, unfortunately not everything that can be represented as number can have sensible operations required by Num: negation makes no sense for set of natural numbers for example, multiplication for some applications of currency values which results in Num instance full of (*) = error "No multipication for Foos", (+) = error "No addition for Foos".

I don't have any statistics from hackage or github, but in codebase I'm working with there are 3 such instances.

Proposal: add OverloadedNumerals language pragma, IsNumeric typeclass and some methods to make that class useful with behavior similar to Lists and Strings.

As for naming: it should be named IsInteger/fromInteger by analogy with IsString/fromString and IsList/fromList.

The problem with calling it "fromInteger" is that it would clobber the existing fromInteger method in the Num class (thus hiding tricks/qualification would be needed when defining/using instances) unless it is split out of Num, but that will probably be more of an uphill battle.

Can anyone explain to me why IsString was named so and not FromString? I wonder about that every time I encounter this class. Would it not make more sense to break with this rather unfortunate naming convention? Cheers Ben -- "Make it so they have to reboot after every typo." ― Scott Adams