> Of course once you've got ifthenelse you find yourself wanting explicit
> desugaring of pattern matching (could view patterns help here?),
Could you be more specific about what you want there, perhaps
with a small example? I recognize the other problems from my own
forays into EDSLs, but I'm not sure I recognize this one. If you want
to reuse the existing 'lhs=rhs' syntax for patterns specific to your EDSL,
both QuasiQuotes and ViewPatterns might help, if you want to be able
to compose patterns beyond the limitations of that syntax, one of the
proposals and libraries for first-class patterns might help, adding
functionality at the expense of more complex syntax.
>recursion (into an explicit use of fix), etc...
Yes, in principle (you're thinking of sharing, and of lifting pure code?).
In practice, too much machinery is attached to the existing 'let' to
make that likely.
But this reminds me of another closely related issue: GHC offers a
lot of help in moving stuff from compiler-baked-in to library-provided,
but almost none of the mechanisms works at the level of syntax/AST
(where most other languages do their meta-programming/language
extension support).
RULES and compiler plugins work on core, where it is too late to
do EDSL-specific source-level rewrites, TH requires quoted things
to parse and type-check in the un-extended language, making it less
useful for EDSL-specific language extensions. For instance, think of
the arrows syntax: there doesn't seem to be any way that this could
have been defined in a library, so it had to be baked into GHC?
QuasiQuotes seem to be the only feature that gives source-level
control, and they suffer from the lack of easily available parsers
(eg, if my EDSL requires an extension of some Haskell construct,
I'd like to be able to reuse the Haskell parsers for the baseline).
There is a package on hackage targetting that issue (haskell-src-meta),
but it relies on a second frontend (haskell-src-ext), and only works
with a single GHC version.
Claus