Somewhat related: I've developed a library for operations involving multi-dimensional arrays [1, 2]. When possible it uses GCC for jit-compilation to achieve higher performance.
It's neat that Ruby has programmable syntax like this, but Haskell's comprehensions are one of its worst syntactic features IMHO. They're inherently non-composable.
They're equivalent to do-notation in the List monad so as long as you don't really need the inline syntax you can just mechanically translate it to do nation and back.
And with -XMonadComprehensions you can have the compiler do that for a whole bunch more Monads.
Haskell person here... I personally find Haskell list comprehensions to be ridiculously ugly, and are an unnecessary bit of syntactic sugar over the List Monad.
I find this interesting. As someone who emphatically doesn't know Haskell, but has recently started learning, I think list comprehensions are wonderful. That said, I haven't got to the chapter on Monads yet, so... :)
List comprehensions as a programming technique are incredibly useful, don't get me wrong. I am just not a fan of syntactic sugar in general.
EDIT: On a more elaborate note, I think that the extreme variety of programming styles enabled by Haskell is more of a weakness than a strength. True, defining your own abstractions and operators is part of the fun, but seeing declarative style (pattern-matching in function defs, where blocks, function args on left-hand side, guards), expression style (let blocks, lambda abstractions, case statements, if clauses), applicative style (<$>, <* >, <$, <* , * >, <|>), and arrow style (* * * , &&&, ^>>, ^<<, >>^, <<^, <+>, +++, |||, >>>, <<<) all in the same file can get pretty overwhelming even if you're already pretty fluent in the language.
We don't need any help being confusing, people. We already have Monads, for god's sake.
As its creator, I would certainly agree. Still, I'd feel bad if some poor soul considered it anything but an interesting demonstration of Ruby's capabilities.
It's awesomely cool, but it also defines a global method_missing, which puts you in for a world of pain before even considering the overloaded operators.
It's one of those hacks that are cute and great to play with and awesome proof of concept for new features, but if I saw it in a production codebase, I'd want to strangle someone.
As someone who is still learning Ruby and would like to learn Haskell I have no idea what is going on here. Would someone be kind enough to explain? Thanks.
Specifically, it is monkey patching the unary - and + operators on array, and has a clever global method missing.
The unary operators `def -@` gets called when you do something like: `-[1,2,3]`.
So in the example code at the bottom, it's doing `bar =+ [x | x <- [1..3]]` that's better parsed as `bar = +[x | x <- [1..3]]` (note the spacing difference).
Side question, rant. I love the syntactic side of list or dict comprehension (in python) and often use them but as soon as I have to debug or expand the functionality, I have to slice them into for loop. And then I hate myself for being lazy/clever and more and more, when I start typing a = [, I hear an internal voice: wait, aren't you being wrongfully clever one again?
I adore list comprehensions, but perhaps for this reason, I generally only use them for operations so simple as to be trivially correct or incorrect without any debugging.
Dict comprehensions are just a little muddier, even for simple things, but a single line of debug output after the comprehension should confirm whether or not you're getting the structure you expect, provided you are still doing only trivial work inside your comprehension.
Wow, that's some nontrivial Ruby, some explanation of this code would be nice, I program in Ruby for some 6 years now and I still had to do a lot of head-scratching to more or less figure this out. I had no idea Ruby allows overloading of prefix operators, for example.
