7 ms·

> You're pulling data from someplace, manipulating it, etc, and then sending it somewhere else. Like this? stream = (manipulate(item) for item in producer_s

> You're pulling data from someplace, manipulating it, etc, and then sending it somewhere else. Like this? stream = (manipulate(item) for item in producer_stream() if passes_filters(item)) consumer(stream)

JoelMcCracken 5y ago
of course, but its more normal to do: fmap manipulate $ filter passes_filters producer_stream And GHC has list fusion rules in this case (not sure if they exactly apply for list comprehensions; they probably do, but i'm not certain of that.) so IIRC the xyntax in haskell syntax your example would be smth like: [ manipulate x | passes_filters x, x <- producer_stream ] which is transformed to: do x <- producer_stream guard (passes_filters x) manipulate x Which I believe does not have the same run-time performance as my fmap/filter example; even if it does, I'm just saying I don't see it often, and its not idiomatic. Its different in python though because, well, python is more cursed.
- tome 5y ago
  I think you probably want `pure (manipulate x)` at the end of your do block.
  - JoelMcCracken 5y ago
    Ya could be. It depends upon the type of manipulate really. Thanks.
- da39a3ee 5y ago
  Right, thanks. Don't get me wrong, I like Haskell (though haven't got good at it yet; keep getting lost somewhere between fmap and applicatives/monads). However, I prefer the comprehension and `do` version over your `fmap` expression. The reason is that I think that filtering and transforming a stream is sufficiently common/important that a language should provide declarative syntax / a DSL for it. Whereas your `fmap` version makes too many implementation details explicit: all that should be needed is for the programmer to say "lazily filter and transform these values". I think it would be ideal for the programmer not to have to worry about `fmap` and `$`, and I think the expression should read more naturally than your fmap example. The Python and Haskell comprehension versions pass the "read naturally" test very well: "create a set/stream of manipulated items where the items pass the filter". The Haskell `fmap` version reads as "apply the manipulate function to a functor where, oh by the way the functor is a kind of list, and oh by the way use $ to separate arguments in this expression, but as I was saying do that but filter the list first". EDIT: I don't mean to imply that I know how Haskell should be written, I defer to you; the sophistication of Haskell's functor-related abstractions is such that I bet you're right that the special case syntax of a comprehension is kind of an annoying presence in the language (but that still leaves two ways to do it?). But, we were talking about javascript and there I think it makes a lot of sense to give the world a way to construct collections declaratively.
  - JoelMcCracken 5y ago
    This is all just my POV too. I'm sure there are people out there who use list comprehensions all day every day. I just haven't seen them. I tend to vastly prefer a small, beautiful, principled, "growable" language over one that has many builtin forms. e.g. Scheme. Because, as I said, each of these features just makes it harder for other implementations. FWIW I also don't think it made sense for JS to get a pipeline operator; only reaosn I like those is when a language supports user-defined operators. But, anyway.

JoelMcCracken 5y ago

of course, but its more normal to do: fmap manipulate $ filter passes_filters producer_stream And GHC has list fusion rules in this case (not sure if they exactly apply for list comprehensions; they probably do, but i'm not certain of that.) so IIRC the xyntax in haskell syntax your example would be smth like: [ manipulate x | passes_filters x, x <- producer_stream ] which is transformed to: do x <- producer_stream guard (passes_filters x) manipulate x Which I believe does not have the same run-time performance as my fmap/filter example; even if it does, I'm just saying I don't see it often, and its not idiomatic. Its different in python though because, well, python is more cursed.

tome 5y ago
I think you probably want `pure (manipulate x)` at the end of your do block.
- JoelMcCracken 5y ago
  Ya could be. It depends upon the type of manipulate really. Thanks.
da39a3ee 5y ago
Right, thanks. Don't get me wrong, I like Haskell (though haven't got good at it yet; keep getting lost somewhere between fmap and applicatives/monads). However, I prefer the comprehension and `do` version over your `fmap` expression. The reason is that I think that filtering and transforming a stream is sufficiently common/important that a language should provide declarative syntax / a DSL for it. Whereas your `fmap` version makes too many implementation details explicit: all that should be needed is for the programmer to say "lazily filter and transform these values". I think it would be ideal for the programmer not to have to worry about `fmap` and `$`, and I think the expression should read more naturally than your fmap example. The Python and Haskell comprehension versions pass the "read naturally" test very well: "create a set/stream of manipulated items where the items pass the filter". The Haskell `fmap` version reads as "apply the manipulate function to a functor where, oh by the way the functor is a kind of list, and oh by the way use $ to separate arguments in this expression, but as I was saying do that but filter the list first". EDIT: I don't mean to imply that I know how Haskell should be written, I defer to you; the sophistication of Haskell's functor-related abstractions is such that I bet you're right that the special case syntax of a comprehension is kind of an annoying presence in the language (but that still leaves two ways to do it?). But, we were talking about javascript and there I think it makes a lot of sense to give the world a way to construct collections declaratively.
- JoelMcCracken 5y ago
  This is all just my POV too. I'm sure there are people out there who use list comprehensions all day every day. I just haven't seen them. I tend to vastly prefer a small, beautiful, principled, "growable" language over one that has many builtin forms. e.g. Scheme. Because, as I said, each of these features just makes it harder for other implementations. FWIW I also don't think it made sense for JS to get a pipeline operator; only reaosn I like those is when a language supports user-defined operators. But, anyway.