The 17 at the end should be 12, or the 2 passed into (f+g+2) should be 3. On Mon, Mar 19, 2012 at 10:38 AM, Ozgur Akgun wrote:

Hi,

If you are feeling adventurous enough, you can define a num instance for functions:

{-# LANGUAGE FlexibleInstances #-}

instance Num a => Num (a -> a) where     f + g = \ x -> f x + g x     f - g = \ x -> f x - g x     f * g = \ x -> f x * g x     abs f = abs . f     signum f = signum . f     fromInteger = const . fromInteger

ghci> let f x = x * 2 ghci> let g x = x * 3 ghci> (f + g) 3 15 ghci> (f+g+2) 2 17

HTH, Ozgur

On 19 March 2012 16:57, wrote:

...

By arithmetic I mean the everyday arithmetic operations used in engineering. In signal processing for example, we write a lot of expressions like f(t)=g(t)+h(t)+g'(t) or f(t)=g(t)*h(t). I feel it would be very natural to have in haskell something like   g::Float->Float   --define g here   h::Float->Float   --define h here   f::Float->Float   f = g+h --instead of f t = g t+h t   --Of course, f = g+h is defined as f t = g t+h t

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On Mar 19, 2012 11:40 AM, "Ozgur Akgun" wrote:

{-# LANGUAGE FlexibleInstances #-}

instance Num a => Num (a -> a) where

You don't want (a -> a) there. You want (b -> a). There is nothing about this that requires functions to come from a numeric type, much less the same one. -- Chris Smith

This instance can be made more general without changing the code; change the first line to instance Num a => Num (e -> a) where I think this version doesn't even require FlexibleInstances. This lets you do f x = if x then 2 else 3 g x = if x then 5 else 10 -- f + g = \x -> if x then 7 else 13 -- ryan On Mon, Mar 19, 2012 at 10:38 AM, Ozgur Akgun wrote:

Hi,

If you are feeling adventurous enough, you can define a num instance for functions:

{-# LANGUAGE FlexibleInstances #-}

instance Num a => Num (a -> a) where f + g = \ x -> f x + g x f - g = \ x -> f x - g x f * g = \ x -> f x * g x abs f = abs . f signum f = signum . f fromInteger = const . fromInteger

ghci> let f x = x * 2 ghci> let g x = x * 3 ghci> (f + g) 3 15 ghci> (f+g+2) 2 17

HTH, Ozgur

On 19 March 2012 16:57, wrote:

...

By arithmetic I mean the everyday arithmetic operations used in engineering. In signal processing for example, we write a lot of expressions like f(t)=g(t)+h(t)+g'(t) or f(t)=g(t)*h(t). I feel it would be very natural to have in haskell something like g::Float->Float --define g here h::Float->Float --define h here f::Float->Float f = g+h --instead of f t = g t+h t --Of course, f = g+h is defined as f t = g t+h t

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

On 20/03/2012, at 2:21 PM, Chris Smith wrote:

On Mon, Mar 19, 2012 at 7:16 PM, Richard O'Keefe wrote:

...

One problem with hooking functions into the Haskell numeric classes is right at the beginning:

class (Eq a, Show a) => Num a

This is true in base 4.4, but is no longer true in base 4.5.

I didn't say "GHC", I said "Haskell". class (Eq a, Show a) => Num a where (+), (-), (⋆) :: a -> a -> a negate :: a -> a abs, signum :: a -> a fromInteger :: Integer -> a -- Minimal complete definition: -- All, except negate or (-) x - y = x + negate y negate x = 0 - x comes straight from the Haskell 2010 report: http://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009 There are other Haskell compilers than GHC.

On 21/03/2012, at 9:06 AM, Albert Y. C. Lai wrote:

On 12-03-19 10:05 PM, Richard O'Keefe wrote:

...

http://www.haskell.org/onlinereport/haskell2010/haskellch9.html#x16-1710009

Haskell 2010 is already beginning to be out of date.

Was there any point in me pointing out that the latest release of a well known Haskell compiler downloaded and installed YESTERDAY still conformed to Haskell 2010, not this change? Was there any point in me pointing out that the latest release of the Haskell Platform downloaded YESTERDAY still conformed to Haskell 2010, not this change? Or was I shouting into the wind? The change is a Good Thing. No disagreement there. The latest GHC supports it, and that's a Good Thing. No disagreement there. Some time there will be a new version of the Haskell Platform incorporating new versions of the library and compiler, and that will be a Good Thing too. The point I was making remains valid: right NOW, using current releases of things other than GHC, the odds are that you will have to manually upgrade your system, and (a) you might not know how to do that (as I don't know how to upgrade UHC), and (b) until the change is more widely adopted, your shiny new code will work for some people but not others.

On 20 March 2012 12:27, Jerzy Karczmarczuk wrote:

Richard O'Keefe:

class (Eq a, Show a) => Num a where (+) (-) (*) negate abs signum fromInteger

where functions are for good reason not members of Eq or Show.

This is an old song, changed several times. I have no intention to discuss, but please, Richard O'Keefe: WHICH GOOD REASONS??

Because there are no sensible ways of writing such instances? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

I don't understand this discussion. He explicitly said "If you are willing to depend on a recent version of base". More precisely, he meant GHC 7.4 which includes the latest version of base. Yes, this is incompatible with the Haskell2010 standard, but it did go through the library submission process (unless I'm mistaken). It is also easy to add nonsense instances for functions to make this work with the Haskell2010 definition of the Num class. instance Eq (a -> b) where f == g = error "Cannot compare two functions (undecidable for infinite domains)" instance Show (a -> b) where show _ = "<function>" Yes, these instances are not very useful, but they let you get around this unnecessary restriction of the Num class. (I expect this to be fixed in future versions of the Haskell standard.) On 20 March 2012 02:37, Richard O'Keefe wrote:

On 20/03/2012, at 2:27 PM, Jerzy Karczmarczuk wrote:

...

Richard O'Keefe:

...

    class (Eq a, Show a) => Num a       where (+) (-) (*) negate abs signum fromInteger

where functions are for good reason not members of Eq or Show.

This is an old song, changed several times. I have no intention to discuss, but please, Richard O'Keefe: WHICH GOOD REASONS??

It is still there in the Haskell 2010 report.

The UHC user manual at http://www.cs.uu.nl/groups/ST/Projects/ehc/ehc-user-doc.pdf lists differences between UHC and both Haskell 98 and Haskell 2010, but is completely silent about any change to the interface of class Num, and in fact compiling a test program that does 'instance Num Foo' where Foo is *not* an instance of Eq or Show gives me this response:

[1/1] Compiling Haskell                  mynum                  (mynum.hs) EH analyses: Type checking mynum.hs:3-11:  Predicates remain unproven:    preds: UHC.Base.Eq mynum.Foo:

This is with ehc-1.1.3, Revision 2422:2426M, the latest binary release, downloaded and installed today. The release date was the 31st of January this year.

GHC 7.0.3 doesn't like it either.  I know ghc 7.4.1 is out, but I use the Haskell Platform, and the currently shipping version says plainly at http://hackage.haskell.org/platform/contents.html that it provides GHC 7.0.4.

You may have no intention of discussing the issue, but it seems to *me* that "this will not work in 2012 Haskell compiler mostly conforming to Haskell 2010 because Haskell 2010 says it shouldn't work" is a pretty sound position to take.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Push the envelope. Watch it bend.

On 21/03/2012, at 2:14 AM, Jerzy Karczmarczuk wrote:

...

The existence of standards is not an answer concerning their "goodness".

Whoever said it was? Not me! But the existence of implementations that conform to standards *IS* an answer concerning 'will this WORK?' I do appreciate that the latest and greatest version of 'base' can do all sorts of things. However, I _don't_ know how to install that so that UHC and GHC will both use it. I'm no different from all the other Haskellers who've been frustrated by Num wanting Eq and Show, which I would have thought was an obviously bad idea from the beginning. I have my own potential uses for Eq-less Nums. But I want it to *work* and to work in more than one Haskell compiler.

This general applicative pattern for numbers is packed up in the applicative-numbers package [1]. In addition to Ralf's paper, there's a discussion in section 10 of *Denotational design with type class morphisms* [2] and an application in sections 2 & 4 of *Beautiful differentiation* [3]. [1]: http://hackage.haskell.org/package/applicative-numbers [2]: http://conal.net/papers/type-class-morphisms/ [3]: http://conal.net/papers/beautiful-differentiation/ -- Conal On Mon, Mar 19, 2012 at 9:58 PM, wren ng thornton wrote:

On 3/19/12 12:57 PM, sdiyazg@sjtu.edu.cn wrote:

...

By arithmetic I mean the everyday arithmetic operations used in engineering. In signal processing for example, we write a lot of expressions like f(t)=g(t)+h(t)+g'(t) or f(t)=g(t)*h(t). I feel it would be very natural to have in haskell something like

You should take a look at Ralf Hinze's _The Lifting Lemma_:

http://www.cs.ox.ac.uk/ralf.**hinze/WG2.8/26/slides/ralf.pdfhttp://www.cs.ox.ac.uk/ralf.hinze/WG2.8/26/slides/ralf.pdf

The fact that you can lift arithmetic to work on functions comes from the fact that for every type T, the type (T->) is a monad and therefore is an applicative functor. The output type of the function doesn't matter, except inasmuch as the arithmetic operations themselves care.

This pattern has been observed repeatedly, even long before Haskell was around. But one reason it's not too common in production Haskell code is that it's all too easy to make a mistake when programming (e.g., you don't mean to be adding functions but you accidentally forget some argument), and if you're using this trick implicitly by providing a Num instance, then you can get arcane/unexpected/unhelpful error messages during type checking.

But then you do get some fun line noise :)

twiceTheSumOf = (+) + (+) squareTheSumOf = (+) * (+) cubeTheSumOf = (+) * (+) * (+)

-- N.B., the names only make sense if all arguments -- are numeric literals. Don't look at the types. addThreeThings = (+) . (+) addFourThings = (+) . (+) . (+) addFiveThings = (+) . (+) . (+) . (+)

-- Live well, ~wren

______________________________**_________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe