combinators | 易学教程

Combining two expressions into a pipeline

阅读更多关于 Combining two expressions into a pipeline

问题 Let us say I have the following two expressions: Expression<Func<T, IEnumerable<TNested>>> collectionSelector; Expression<Func<IEnumerable<TNested>, TNested>> elementSelector; Is there a way to "combine" these in order to form the below: (?) Expression<Func<T, TNested>> selector; EDIT: Performance is very critical, so I would appreciate an optimal solution with very little overhead, if possible. Many Thanks! 回答1: static Expression<Func<A, C>> Foo<A, B, C>( Expression<Func<B, C>> f, Expression

What is a general scheme for writing a function in pointfree style?

阅读更多关于 What is a general scheme for writing a function in pointfree style?

问题 I am working through the 20 Intermediate Haskell Exercises at the moment, which is quite a fun exercise. It involves implementing various instances of the typeclasses Functor and Monad (and functions that takes Functor s and Monad s as arguments) but with cute names like Furry and Misty to disguise what we're doing (makes for some interesting code). I've been trying to do some of this in a point-free style, and I wondered if there's a general scheme for turning a point-ful (?) definition into

parser combinator: how to terminate repetition on keyword

阅读更多关于 parser combinator: how to terminate repetition on keyword

I'm trying to figure out how to terminate a repetition of words using a keyword. An example: class CAQueryLanguage extends JavaTokenParsers { def expression = ("START" ~ words ~ "END") ^^ { x => println("expression: " + x); x } def words = rep(word) ^^ { x => println("words: " + x) x } def word = """\w+""".r } When I execute val caql = new CAQueryLanguage caql.parseAll(caql.expression, "START one two END") It prints words: List(one, two, END) , indicating the words parser has consumed the END keyword in my input, leaving the expression parser unable to match. I would like END to not be matched

foldr and foldl further explanations and examples

阅读更多关于 foldr and foldl further explanations and examples

问题 I've looked at different folds and folding in general as well as a few others and they explain it fairly well. I'm still having trouble on how a lambda would work in this case. foldr (\y ys -> ys ++ [y]) [] [1,2,3] Could someone go through that step-by-step and try to explain that to me? And also how would foldl work? 回答1: Using foldr f z [] = z foldr f z (x:xs) = x `f` foldr f z xs And k y ys = ys ++ [y] Let's unpack: foldr k [] [1,2,3] = k 1 (foldr k [] [2,3] = k 1 (k 2 (foldr k [] [3])) =

Haskell: surprising behavior of “groupBy”

阅读更多关于 Haskell: surprising behavior of “groupBy”

I'm trying to figure out the behavior of the library function groupBy (from Data.List), which purports to group elements of a list by an "equality test" function passed in as the first argument. The type signature suggests that the equality test just needs to have type (a -> a -> Bool) However, when I use (<) as the "equality test" in GHCi 6.6, the results are not what I expect: ghci> groupBy (<) [1, 2, 3, 2, 4, 1, 5, 9] [[1,2,3,2,4],[1,5,9]] Instead I'd expect runs of strictly increasing numbers, like this: [[1,2,3],[2,4],[1,5,9]] What am I missing? Have a look at the ghc implementation of

Combinatory method like tap, but able to return a different value?

阅读更多关于 Combinatory method like tap, but able to return a different value?

I'm going through a phase of trying to avoid temporary variables and over-use of conditional where I can use a more fluid style of coding. I've taken a great liking to using #tap in places where I want to get the value I need to return, but do something with it before I return it. def fluid_method something_complicated(a, b, c).tap do |obj| obj.update(:x => y) end end Vs. the procedural: def non_fluid_method obj = something_complicated(a, b, c) obj.update(:x => y) obj # <= I don't like this, if it's avoidable end Obviously the above examples are simple, but this is a pretty common coding style

Are there “type-level combinators”? Will they exist in some future?

阅读更多关于 Are there “type-level combinators”? Will they exist in some future?

问题 Much of what makes haskell really nice to use in my opinion are combinators such as (.) , flip , $ <*> and etc. It feels almost like I can create new syntax when I need to. Some time ago I was doing something where it would be tremendously convenient if I could "flip" a type constructor. Suppose I have some type constructor: m :: * -> * -> * and that I have a class MyClass that needs a type with a type constructor with kind * -> * . Naturally I would choose to code the type in such a way that

Haskell: surprising behavior of “groupBy”

阅读更多关于 Haskell: surprising behavior of “groupBy”

问题 I'm trying to figure out the behavior of the library function groupBy (from Data.List), which purports to group elements of a list by an "equality test" function passed in as the first argument. The type signature suggests that the equality test just needs to have type (a -> a -> Bool) However, when I use (<) as the "equality test" in GHCi 6.6, the results are not what I expect: ghci> groupBy (<) [1, 2, 3, 2, 4, 1, 5, 9] [[1,2,3,2,4],[1,5,9]] Instead I'd expect runs of strictly increasing

S combinator in Haskell

阅读更多关于 S combinator in Haskell

问题 Can an analog of the S combinator be expressed in Haskell using only standard functions (without defining it by equation) and without using lambda (anonymous function)? I expect it to by of type (a -> b -> c) -> (a -> b) -> a -> c . For example, an analog of the K combinator is just const . In fact i am trying to express the function \f x -> f x x using standard functions, but cannot think of any standard non-linear function to start with (that is a function that uses its argument more than

Combinatory method like tap, but able to return a different value?

阅读更多关于 Combinatory method like tap, but able to return a different value?

问题 I'm going through a phase of trying to avoid temporary variables and over-use of conditional where I can use a more fluid style of coding. I've taken a great liking to using #tap in places where I want to get the value I need to return, but do something with it before I return it. def fluid_method something_complicated(a, b, c).tap do |obj| obj.update(:x => y) end end Vs. the procedural: def non_fluid_method obj = something_complicated(a, b, c) obj.update(:x => y) obj # <= I don't like this,