Re: [Haskell-cafe] Re: currying combinators
I wrote: > keep :: (forall c . (t -> c) -> u -> c) -> ((t1 -> t) -> b) -> (t1 -> > u) -> b > keep transform rec = \fn -> rec $ transform id . fn Just to clarify - you don't really need the RankNTypes here, I just wrote it that way so you could see what I had been thinking, and to make it clear how the first parameter of keep takes transformers like drop'. But you could write it as keep :: ((t -> t) -> u -> t) -> ... and it would work just fine, because transformers like drop' would specialize nicely to what you need for keep. If you let GHC deduce the type of keep from its definition, GHC comes up with something else: keep :: ((a -> a) -> u -> t) -> ((t1 -> t) -> b) -> (t1 -> u) -> b That also works, but it's weird. It generalizes in a direction that we don't really need here, and thus obscures the meaning of what we're doing. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: currying combinators
I wrote: >> keep :: ((t -> b) -> u -> b) -> ((t1 -> t) -> b) -> (t1 -> u) -> b >> so then >> nameZip = keep (drop' . drop') names Günther Schmidt wrote: > don't be tease man, show me what you got :) Ivan Miljenovic wrote: >> Methinks Yitzchak made a typo Yes, sorry about that. Tested in ghci this time :). keep :: (forall c . (t -> c) -> u -> c) -> ((t1 -> t) -> b) -> (t1 -> u) -> b keep transform rec = \fn -> rec $ transform id . fn Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: currying combinators
2010/5/26 Daniel Peebles : > Djinn can't figure it out, and neither can I :P Methinks Yitzchak made a typo; for starters, where does the t1 value come from (since it seems to be the base of the rest of it)? > > 2010/5/25 Günther Schmidt >> >> Hi Yitz, >> >> embarrassingly I was unable to deduce the implementation from the type >> signature, don't be tease man, show me what you got :) >> >> Günther >> >> Am 25.05.10 18:27, schrieb Yitzchak Gale: >>> >>> Günther Schmidt wrote: http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=25694 in which I attempt to develop a "currying combinator" library. I'm stuck at some point and would appreciate any help. >>> >>> How about this: >>> >>> keep :: ((t -> b) -> u -> b) -> ((t1 -> t) -> b) -> (t1 -> u) -> >>> b >>> >>> so then >>> >>> nameZip = keep (drop' . drop') names >>> >>> Regards, >>> Yitz >> >> >> ___ >> 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 > > -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: currying combinators
Djinn can't figure it out, and neither can I :P 2010/5/25 Günther Schmidt > Hi Yitz, > > embarrassingly I was unable to deduce the implementation from the type > signature, don't be tease man, show me what you got :) > > Günther > > Am 25.05.10 18:27, schrieb Yitzchak Gale: > > Günther Schmidt wrote: >> >>> http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=25694 >>> in which I attempt to develop a "currying combinator" library. >>> I'm stuck at some point and would appreciate any help. >>> >> >> How about this: >> >> keep :: ((t -> b) -> u -> b) -> ((t1 -> t) -> b) -> (t1 -> u) -> >> b >> >> so then >> >> nameZip = keep (drop' . drop') names >> >> Regards, >> Yitz >> > > > ___ > 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
[Haskell-cafe] Re: currying combinators
Hi Yitz, embarrassingly I was unable to deduce the implementation from the type signature, don't be tease man, show me what you got :) Günther Am 25.05.10 18:27, schrieb Yitzchak Gale: Günther Schmidt wrote: http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=25694 in which I attempt to develop a "currying combinator" library. I'm stuck at some point and would appreciate any help. How about this: keep :: ((t -> b) -> u -> b) -> ((t1 -> t) -> b) -> (t1 -> u) -> b so then nameZip = keep (drop' . drop') names Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Currying and Partial Evaluation
Derek Elkins <[EMAIL PROTECTED]> wrote: > Can we stop using confusing, misleading or outright wrong definitions > and analogies? > No, we can't, ever, that's plain impossible. And will never stop to use enlightening, inspiring or vastly approximate or aggregate definitions and analogies, and I won't stop laughing about my mistakes. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Currying and Partial Evaluation
Hello Jules, I'm not sure you got a straight answer, although you provoked some discussion. Thanks for your answer, now everything is much clearer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Currying and Partial Evaluation
On 8 Jan 2008, at 9:01 PM, Derek Elkins wrote: On Tue, 2008-01-08 at 21:44 -0800, Jonathan Cast wrote: On 8 Jan 2008, at 7:56 PM, Derek Elkins wrote: Can we stop using confusing, misleading or outright wrong definitions and analogies? What, and bring CS to a halt? CS wouldn't be the only thing brought to a halt... Good point. We're really discussing what, the end of humanity as we know it? jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Currying and Partial Evaluation
On Tue, 2008-01-08 at 21:44 -0800, Jonathan Cast wrote: > On 8 Jan 2008, at 7:56 PM, Derek Elkins wrote: > > Can we stop using confusing, misleading or outright wrong definitions > > and analogies? > > What, and bring CS to a halt? CS wouldn't be the only thing brought to a halt... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Currying and Partial Evaluation
On 8 Jan 2008, at 7:56 PM, Derek Elkins wrote: Can we stop using confusing, misleading or outright wrong definitions and analogies? What, and bring CS to a halt? jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Currying and Partial Evaluation
On Wed, 2008-01-09 at 04:32 +0100, Achim Schneider wrote: > Derek Elkins <[EMAIL PROTECTED]> wrote: > > > On Wed, 2008-01-09 at 03:37 +0100, Achim Schneider wrote: > > > Derek Elkins <[EMAIL PROTECTED]> wrote: > > > > > > > On Wed, 2008-01-09 at 00:51 +0100, Achim Schneider wrote: > > > > > Fernando Rodriguez <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Is currying in Haskell the same thing as Partial Evaluation > > > > > > (http://en.wikipedia.org/wiki/Partial_evaluation)? Am I > > > > > > getting partial evaluation for free just by using Haskell? > > > > > > > > > > > No, currying is this: > > > > > > > > No, it is not. This is partial application. See the wiki page > > > > Neil referenced. > > > > > > > Which works because of the functions being curried... > > > > and therefore partial application can't be currying. Currying is the > > operation of turning (a,b) -> c into a -> b -> c. Nothing more. > > > > > of course, the > > > usage is to "partly" apply a function, which is not possible, as all > > > Haskell functions are, by default, curried, and thus only have one > > > parameter, which can either be applied or not. > > > > Indeed. Partial application is a fuzzy term. I give a potential > > objective definition here: > > http://lambda-the-ultimate.org/node/2266#comment-33620 > > > Yes, it seems kind of obvious that eating a chicken isn't the same as > currying a chicken, but then there's a difference between eating > a grilled and a curried chicken... and cooking is always more complex > than eating. And you just can't have a curried chicken when there's > no one around that curries them. > > So, currying can also be the operation of turning > > (define (foo x y) (+ x y)) > > into > > foo x y = x + y > > or, mere syntactically, > > foo x y = x + y > > into > > foo = \x -> \y -> x + y > > > > > > > Partial evaluation, OTOH, goes into the direction of laziness vs. > > > eagerness: Iff the compiler sees that a thunk is only dependent on > > > data known at compile-time, it may choose to evaluate this thunk > > > already at compile-time, if you're lucky and the compiler isn't > > > lazy, > > > > Partial evaluation has little to do with lazy v. eager evaluation. > > > Well, enough for a thunk to be a reasonable metaphor for a candidate > partial evaluation. The compiler is eager, so that the result is > memoized before it is used... or not, but then that may not be > deducible for the compiler. It's a bit like stop and go traffic. > "Opportunistic evaluation" probably fits the concept better than > "eager". > > > Can we stop nit-picking, please? Can we stop using confusing, misleading or outright wrong definitions and analogies? This is how we end up with people thinking 'currying' = 'partial application' = 'partial evaluation' or 'laziness' = 'memoization' or 'monads' = 'state passing' = 'continuations' or 'type classes' = 'OO classes' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Currying and Partial Evaluation
Derek Elkins <[EMAIL PROTECTED]> wrote: > On Wed, 2008-01-09 at 03:37 +0100, Achim Schneider wrote: > > Derek Elkins <[EMAIL PROTECTED]> wrote: > > > > > On Wed, 2008-01-09 at 00:51 +0100, Achim Schneider wrote: > > > > Fernando Rodriguez <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > Hi, > > > > > > > > > > Is currying in Haskell the same thing as Partial Evaluation > > > > > (http://en.wikipedia.org/wiki/Partial_evaluation)? Am I > > > > > getting partial evaluation for free just by using Haskell? > > > > > > > > > No, currying is this: > > > > > > No, it is not. This is partial application. See the wiki page > > > Neil referenced. > > > > > Which works because of the functions being curried... > > and therefore partial application can't be currying. Currying is the > operation of turning (a,b) -> c into a -> b -> c. Nothing more. > > > of course, the > > usage is to "partly" apply a function, which is not possible, as all > > Haskell functions are, by default, curried, and thus only have one > > parameter, which can either be applied or not. > > Indeed. Partial application is a fuzzy term. I give a potential > objective definition here: > http://lambda-the-ultimate.org/node/2266#comment-33620 > Yes, it seems kind of obvious that eating a chicken isn't the same as currying a chicken, but then there's a difference between eating a grilled and a curried chicken... and cooking is always more complex than eating. And you just can't have a curried chicken when there's no one around that curries them. So, currying can also be the operation of turning (define (foo x y) (+ x y)) into foo x y = x + y or, mere syntactically, foo x y = x + y into foo = \x -> \y -> x + y > > > > Partial evaluation, OTOH, goes into the direction of laziness vs. > > eagerness: Iff the compiler sees that a thunk is only dependent on > > data known at compile-time, it may choose to evaluate this thunk > > already at compile-time, if you're lucky and the compiler isn't > > lazy, > > Partial evaluation has little to do with lazy v. eager evaluation. > Well, enough for a thunk to be a reasonable metaphor for a candidate partial evaluation. The compiler is eager, so that the result is memoized before it is used... or not, but then that may not be deducible for the compiler. It's a bit like stop and go traffic. "Opportunistic evaluation" probably fits the concept better than "eager". Can we stop nit-picking, please? -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Currying and Partial Evaluation
On Wed, 2008-01-09 at 03:37 +0100, Achim Schneider wrote: > Derek Elkins <[EMAIL PROTECTED]> wrote: > > > On Wed, 2008-01-09 at 00:51 +0100, Achim Schneider wrote: > > > Fernando Rodriguez <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Hi, > > > > > > > > Is currying in Haskell the same thing as Partial Evaluation > > > > (http://en.wikipedia.org/wiki/Partial_evaluation)? Am I getting > > > > partial evaluation for free just by using Haskell? > > > > > > > No, currying is this: > > > > No, it is not. This is partial application. See the wiki page Neil > > referenced. > > > Which works because of the functions being curried... and therefore partial application can't be currying. Currying is the operation of turning (a,b) -> c into a -> b -> c. Nothing more. > of course, the > usage is to "partly" apply a function, which is not possible, as all > Haskell functions are, by default, curried, and thus only have one > parameter, which can either be applied or not. Indeed. Partial application is a fuzzy term. I give a potential objective definition here: http://lambda-the-ultimate.org/node/2266#comment-33620 > > Partial evaluation, OTOH, goes into the direction of laziness vs. > eagerness: Iff the compiler sees that a thunk is only dependent on data > known at compile-time, it may choose to evaluate this thunk already at > compile-time, if you're lucky and the compiler isn't lazy, Partial evaluation has little to do with lazy v. eager evaluation. > main = putStrLn $ show $ 1 + 2 > > might end up being > > main = putStrLn "3" > > in the object file. > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Currying and Partial Evaluation
Derek Elkins <[EMAIL PROTECTED]> wrote: > On Wed, 2008-01-09 at 00:51 +0100, Achim Schneider wrote: > > Fernando Rodriguez <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi, > > > > > > Is currying in Haskell the same thing as Partial Evaluation > > > (http://en.wikipedia.org/wiki/Partial_evaluation)? Am I getting > > > partial evaluation for free just by using Haskell? > > > > > No, currying is this: > > No, it is not. This is partial application. See the wiki page Neil > referenced. > Which works because of the functions being curried... of course, the usage is to "partly" apply a function, which is not possible, as all Haskell functions are, by default, curried, and thus only have one parameter, which can either be applied or not. Partial evaluation, OTOH, goes into the direction of laziness vs. eagerness: Iff the compiler sees that a thunk is only dependent on data known at compile-time, it may choose to evaluate this thunk already at compile-time, if you're lucky and the compiler isn't lazy, main = putStrLn $ show $ 1 + 2 might end up being main = putStrLn "3" in the object file. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Currying and Partial Evaluation
On Wed, 2008-01-09 at 00:51 +0100, Achim Schneider wrote: > Fernando Rodriguez <[EMAIL PROTECTED]> wrote: > > > > > Hi, > > > > Is currying in Haskell the same thing as Partial Evaluation > > (http://en.wikipedia.org/wiki/Partial_evaluation)? Am I getting > > partial evaluation for free just by using Haskell? > > > No, currying is this: No, it is not. This is partial application. See the wiki page Neil referenced. > > Prelude> let f x y = 1 + x * ( y - 3 ) > Prelude> let g = f 1 > Prelude> let h = f 2 > Prelude> g 1 > -1 > Prelude> g 2 > 0 > Prelude> h 1 > -3 > Prelude> h 2 > -1 > > or, a bit more confusing and possibly enlightening, > > Prelude> let y f = f $ y f > Prelude> :t y > y :: (b -> b) -> b > Prelude> let fixpoint f n = if n <= 1 then 1 else n * (f $ n - 1) > Prelude> :t fixpoint > fixpoint :: (Num b, Ord b) => (b -> b) -> b -> b > Prelude> let fac = y fixpoint > Prelude> :t fac > fac :: Integer -> Integer > Prelude> fac 10 > 3628800 > > Prelude> fac 100 > 933262154439441526816992388562667004907159682643816214685929638952175 > 3229915608941463976156518286253697920827223758251185210916864 > > > Note that "fixpoint 3" won't work, and that's good. > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Currying and Partial Evaluation
Fernando Rodriguez <[EMAIL PROTECTED]> wrote: > > Hi, > > Is currying in Haskell the same thing as Partial Evaluation > (http://en.wikipedia.org/wiki/Partial_evaluation)? Am I getting > partial evaluation for free just by using Haskell? > No, currying is this: Prelude> let f x y = 1 + x * ( y - 3 ) Prelude> let g = f 1 Prelude> let h = f 2 Prelude> g 1 -1 Prelude> g 2 0 Prelude> h 1 -3 Prelude> h 2 -1 or, a bit more confusing and possibly enlightening, Prelude> let y f = f $ y f Prelude> :t y y :: (b -> b) -> b Prelude> let fixpoint f n = if n <= 1 then 1 else n * (f $ n - 1) Prelude> :t fixpoint fixpoint :: (Num b, Ord b) => (b -> b) -> b -> b Prelude> let fac = y fixpoint Prelude> :t fac fac :: Integer -> Integer Prelude> fac 10 3628800 Prelude> fac 100 933262154439441526816992388562667004907159682643816214685929638952175 3229915608941463976156518286253697920827223758251185210916864 Note that "fixpoint 3" won't work, and that's good. -- (c) this sig last receiving data processing entity. Inspect headers for past copyright information. All rights reserved. Unauthorised copying, hiring, renting, public performance and/or broadcasting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Currying
[EMAIL PROTECTED] skrev: Hello, what is so great about "currying"? What are its uses, apart from letting one define functions with less parentheses? Letting one apply them with less extra characters: add x y = x + y map (add 2) [1..5] instead of add (x,y) = x + y let add2 y = add(2,y) in map add2 [1..5] end (The last might not technically be partial application, but it serves the same purpose without using currying.) I believe it makes code shorter and more readable, but I do not believe it gives more power. / johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Currying
On Thu, Jan 18, 2007 at 11:00:26AM +0100, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote a message of 15 lines which said: > what is so great about "currying"? The name is very cool. > What are its uses, apart from letting one define functions with less > parentheses? Partial applications. http://fr.wikipedia.org/wiki/Curryfication ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Currying confusion
On Fri, 12 Nov 2004, John Goerzen wrote: > On 2004-11-12, Henning Thielemann <[EMAIL PROTECTED]> wrote: > > > > test3 :: Int -> (Int -> String) -> String > > > > ? > > Yes. > > > Then the implementation could be written as > > > > test3 x f = (show x ++) . f > > Tried that, but: Sorry, it must be: test3 :: Int -> (Int -> String) -> Int -> String ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Currying confusion
On 2004-11-12, Henning Thielemann <[EMAIL PROTECTED]> wrote: > > On Fri, 12 Nov 2004, John Goerzen wrote: > >> I like the partial application feature (and used it in test1). So, I >> thought I could use that to my advantage in test3 and test4: >> >> test3 :: Int -> Int -> String >> test3 x f = (show x) ++ f > > You mean > > test3 :: Int -> (Int -> String) -> String > > ? Yes. > Then the implementation could be written as > > test3 x f = (show x ++) . f Tried that, but: test.hs:13: Couldn't match `String' against `Int -> [Char]' Expected type: String Inferred type: Int -> [Char] In the expression: (((show x) ++)) . f In the definition of `test3': test3 x f = (((show x) ++)) . f > > > But I believe currying means conversion between functions of two arguments > and functions of pairs. > > > pairMap :: (a -> b) -> (a,a) -> (b,b) > pairMap f (x,y) = (f x, f y) > > test5 :: Int -> Int -> String > test5 = curry (uncurry (++) . pairMap show) > > This is something including partial application and currying. Is this what > you are looking for? -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
