RX14 (see @@solnic I really need to get my head around ROM and dry-rb so I can steal the ideas for crystal-lang! I've been looking at and hearing about these libraries for a while but never got the time to play with them.
solnic@RX14 some folks started porting some dry libs to Crystal already. I’m interested in doing so too, it’s just that I can’t find enough time/energy. I’ll get to it sooner or later though. I like ideas behind Crystal.
@solnic I think I only saw a port of the monads lib, and I argued that crystal almost obviates the need for both Maybe and Either monads by having type unions in it's type system already. But then again, I've never actually used the monads so I might be missing something.
I'm mainly interested in ROM itself and dry-validation, which look like excellent tools for building webapps.
@RX14 You might be right re monads. I’d have to take a closer look at Crystal union types to say more. When it comes to rom, we may face some challenges, as there are a couple of fairly advanced meta-programming techniques used that we may not be able to replicate in crystal. It doesn’t mean it’s a blocker though, as alternative solutions should be possible too.
@solnic Crystal's meta-programming is really quite advanced, however the rules of macros go as follows:
1) Don't use macros
2) Don't use macros
3) Do it without macros
4) Check duplicated code in your non-macros solution
5) Eliminate your duplicated code with macros.
So I try to keep the smallest macro surface possible.
That being said, even Crystal without macros is super duper powerful. I'd love to help you out regarding Crystal if you even find the time!
@RX14 haha yeah I totally agree in principle, although I have to say *libraries* are really special type of code, and leveraging more powerful features of a language is typically desirable to achieve better APIs.
Thanks for offering help. So many great langs, so little time…:)
Anyhow, in rom we have a feature where relations are auto-curried, which means that you can refer to them without providing arguments. This is used to compose relations into graphs. No idea if it’s possible in Crystal.
@solnic Libraries are themselves code, and this macro advice is mainly to keep the library devs sane rather than the users! Macros can get really ugly really fast, so keeping their scope and surface area small really helps to get readable library code.
Looking at the example, I think auto-currying could be achieved! Not entirely sure though of course.
@RX14 it’s a matter of redefining an existing method and capturing its arguments and either calling original when all args are present, or currying passed args via a special object that wraps original object. That’s why we have `Relation` and `Relation::Curried` in rom core library. I should mention that relation objects are treated as functions in rom, so they are callable via `#call` method, and this is what enabled various functional solutions in rom (composition, currying, data pipeline).
@solnic We do have Proc#partial in crystal (https://github.com/crystal-lang/crystal/blob/eae419347d3d8df54db811da0daf617e60a680f2/src/proc.cr#L107), I assume that at the very least it would be possible just with a slightly different syntax.
@RX14 is it OK to inherit from Proc?
@solnic no. It's much like inheriting Hash or Array in Ruby, things could go wrong at any moment.
We much prefer composition to inheritance. Composing proc or copying that exact implementation would be trivial though.
@solnic its very easy to delegate some or all methods to an instance variable though, there's macros for that in the stdlib.
@RX14 k I feel inspired to build a PoC with just auto-currying port :grin:
@solnic haha! Good luck!