scalatest has such human like DSL… it is crappy and hard to deal with. It is also one of the reasons why this lib is so BIG.
I’m working on my DSL for more than 3 years now, and recently we joined the EU funded LEGaTO project. So believe me, I take this very seriously. I don’t think DSL features should be ignored. They can provide a huge user-base to Scala.
Yea… and this is place where i disagree. DSLs rarely work well when created to “just looks great”. At some point you always ends up with “just scala” because your DSL cannot do something. This is reason why I’m against any of ad-hoc scala keyword overridings.
It this posibility could be in scala itself then the story is bit different.
Even successful DSLs (like slick) are in fact well structured API and in allows to fallback to scala (I think it is VERY important).
as I’ve said:
I think that was fully designed for the rewritten Scala pattern matcher. The implementation was never finished or documented (except in source comments), but the desugaring was similarly hard as the one for for-comprehensions.
Interesting. Is there somewhere to read about it?
“Fully designed” might have been a stretch, but I remember I wrote code trying to use this (which of course didn’t work).
Here are the "docs"
And here are some of my old experiments from when I did LMS-like work:
EDIT so actually googling
scala virtualized pattern matcher is not entirely unhelpful.
Are you interested in this language feature?
Yes, but only if it includes overriding the more interesting parts, like lambda syntax (i.e. anonymous functions) and pattern matching.
For that, LMS’s higher-order functions have types like
Rep[List[T]].map(Rep[T] => Rep[U]): Rep[List[U]], and standard type inference does the rest. It’s important they take
Rep[T] => Rep[U] and not
Rep[T => U], you can have such a conversion but it must be explicit (but usually doesn’t appear in user code). Slick uses the same trick.
I hope that’s enough for you. It’s been enough for me and I’ve never seen an alternative.
I used the same trick in LambdaCart, which eliminates variables (λ-abstraction) by conversion to a variable-less combinator calculus (namely to operations of a cartesian closed category). Thanks for pointing out prior art in LMS, I wasn’t aware of it.
It is enough where the expressivity of simply-typed λ-calculus is sufficient (which is in a lot of cases).
However, I think that built-in language support will make overridden lambda syntax easier to use and consequently help it proliferate and consequently [insert a little bit of imagination] make a lot of software simpler and safer.