Along these lines I’ve been working off and on on a Haskell wrapper for Stan, a bespoke MCMC language. The idea is to manage the data pipeline in Haskell, use a nice dsl to write the model code, then manage the input data, running and output in Haskell and pull the results back into Haskell for further analysis.
It’s data-frame agnostic, though I mostly use the Frames library, which I find beautiful and maddening in roughly equal measure.
Another EDSL to consider is GitHub - hakaru-dev/hakaru: A probabilistic programming language. It takes the philosophy that probabilistic models are code (no more, no less), and that model transformations (e.g., sampling, conditioning) are code-to-code compiler passes. This makes those transformations very nicely composable and theoretically sound, and therefore provides a much nicer framework than things like Bugs.
On the subject of types, ‘standardisation’, and ‘bureaucracy’, I understand types to be intended to be useful to people, and they can be useful if they make code more expressive to people reading it or if their use allows the compiler to spot errors that people can make when coding.
‘Standardisation’ is obviously useful,‡ as it reduces certain sorts of ‘cost’ of use, but I don’t see that is a prerequisitive for types to be useful. What does seem to me to be a prerequisite is good documentation, both reference-like and tutorial-like (as different people have different ways of understanding things).
‘Bureaucracy’ can be in the eye of the beholder, but if the majority of users of a certain scheme of types (or types full stop) find that the ‘costs’ of using them outweigh the ‘benefits’, even given good documentation, then something needs to be revisited (perhaps the choice of programming language for that user and their specific needs).
Last I checked (both when I was working on the project and when talking to some friends about it after I left), it was still an EDSL. It is definitely a “deep” embedding not a “shallow” embedding, but it isn’t/wasn’t a standalone language.
Though yes, it was an academic project and hasn’t received much love since the funding ended. If you were interested in using/pursuing it however, I’m sure the folks who worked on it1 would be willing to chat.
[1]: The folks and our particular foci are:
me: all the GADT stuff, ABT stuff, implementation of pattern matching, some details around disintegration, and generalist. Also the logfloat library.
Rob: anything and everything to do with inference, mcmc, etc. He’d also be the best person to contact re whatever other Haskell inference stuff is out there these days.
Jacques: everything around Maple and simplifying/optimizing the mathematical expressions.
Praveen: mainly focused on how to get disintegration, loops, etc to work for arrays. He has since pivoted to other stuff, and may not be interested in revisiting Hakaru.
Ken: project lead and the main driver behind the idea of using disintegration. I haven’t talked with him recently, so I’m not sure if he’d still be invested in discussing Hakaru.
From outside state of hakaru is very confusing. Documentation that README in github repo point to gives examples of clearly python-inspired syntax. And all hackage releases from 0.3 are marked as non-preferred.
And using abandoned library could be fine but using it for statistical modelling is basically asking for trouble. And it doesn’t seems there’re any unique features to justify it.