4 ms·
Hmm that's a good point about the pipeline operator. But I'm not sure how I feel about having both idioms readily available. In which cases would you choose for
by DonaldPShimoda 9y ago
Hmm that's a good point about the pipeline operator. But I'm not sure how I feel about having both idioms readily available. In which cases would you choose forwards processing instead of backwards, you know? I'll have to think more about that.
> In Smalltalk, the custom is to name the variable "each"
Ooh I like that! I think I would like it even more if "each" was a reserved word, like "this" in e.g. Java. But maybe that's a bit much.
> Do you mean algebraic data types?
Yes, sorry. I talk to functional people a lot so we tend to use "ADT" for the algebraic ones (those FP people are all about brevity it seems).
Glad to have that confirmed, though. Just wanted to be sure I wasn't missing something.
> I'm a fan of writing and using curried functions by default. I'm not a fan of Reason's syntax that suggests the opposite.
Could you clarify a bit? I'm not sure I follow exactly what you mean about the syntax being unclear. It seems similar to Haskell, except with parentheses, which doesn't seem terrible.
> No. It is adding a new method to an existing class from someone else's library.
Oh I see! I totally misread that example. Thanks for the clarification!
- tom_mellior 9y ago> It seems similar to Haskell, except with parentheses That's the point: In Haskell, the parentheses (and especially the comma) are meaningful, and "foo(x, y)" is not the same as "foo x y". Reason jumps through extra hoops to make the two syntaxes mean the same thing. To a Haskell (or OCaml, or other ML family) programmer, the Reason syntax suggests an uncurried function.
- DonaldPShimoda 9y agoOhh I see what you mean, yeah, fair point!