strudel
strudel copied to clipboard
tidalcycles
improve haskellish syntax support
the parser already has limited support for haskellish syntax, see https://github.com/tidalcycles/strudel/blob/main/packages/mini/krill.pegjs#L188 . maybe that parser could be generalized to not only support a hard coded set of functions, but any function name. The ast could then be used to generate strudel calls (similar to how the mini function already does it). In the end, we could use this to add playable examples to the tidal docs, using the mini repl in haskellish mode.
Yep this would be really great!
For 'minitidal', estuary uses tidal-parse, using the 'Haskellish' parser, both by @dktr0. This might give an idea of the amount of work needed.
maybe tidal-parse could also be reused via https://gitlab.haskell.org/ghc/ghc-wasm-meta ..
huh. if so, minitidal could probably become an exolang (language provided to Estuary or another platform as a JS library) which is a stretch goal I hadn't really considered as a possibility (my goal is to have as few languages as possible compiled into Estuary - and as many as possible dynamically loaded only when needed). (apologies for thinking out loud in a somewhat off topic issue/thread!...)
@dktr0 yes that'd be a nice outcome I think !
Hard problems
- To really support haskell-like syntax, we have to implement some aspect of the type system. I think tidal-parse does this to some extent, but that haskellish leans on haskell-src-exts which I think leans on ghc itself. Maybe not quite as hard to solve as it might seem? I implemented enough of the type system to get the texture front end working before, both in haskell and in plain c..
- Possibly harder though is producing syntax error messages useful for an end-user to understand. The choice of parser library will have a strong bearing on our ability to achieve this..
if so, minitidal could probably become an exolang (language provided to Estuary or another platform as a JS library)
do you mean a JS rewrite of minitidal or some way of packaging the current version inside estuary for JS (e.g. via wasm)? Do you think the latter would be realistic? (I haven't really looked at the codebase, also generally not quick at readying haskell).
Hard problems
For the sole goal of having playable (possibly read only) snippets in the doc, a parser that inputs haskellish syntax and outputs an ast would already be nice to have.. those harder problems go more into the direction of a full blown interpreter.
Not sure I follow the first point @yaxu - in tidal-parse the types of things are known at all times, and once compiled GHC/JS is nowhere to be seen (except for the runtime components that are part of any built product). You can't currently write "x :: SomeType" in MiniTidal of course but there's usually no need for that (and in rare cases where it was, I actually think adding type annotations to minitidal would probably be very straightforward).
Better error messages is of course, desirable. I think it is relatively easy to do this in miniTidal/tidal-parse - haskell-src-exts provides a complete Haskell AST so there is no constraint there... haskellish provides some basic support for identifying committed vs optional paths in the parsing (via 'required'), which I believe should make better error messages possible... I've never had the time to really follow through with using those haskellish features throughout miniTidal (too many other projects!) but I might do it some time just to see how far it can be taken. I'm unsure what isn't or wouldn''t be covered by the required/optional paradigm that current Haskellish uses (perhaps there is something, don't know!) - but if there is something, I don't think there is anything in Haskellish's structure that would stop someone from matching any pattern of AST fragment with a specific (error) result, FWIW.
From my perspective, what would be a hard addition to tidal-parse/miniTidal that is indeed a common idiom one sees in live coding? support for let expressions / function definitions.
By the way, every now and then I have tinkered with things to automatically collect the definitions of Tidal for miniTidal and auto-construct the parsing tree. I've done enough to believe that this is quite viable. However, from where I sit the cost of doing it vs the benefit doesn't strongly incentivize it: manually adding things to miniTidal is usually easy enough to support my usual, actual, specific goal (facilitate collective live coding as a practice by making Tidal available in Estuary). In any case, this is an area where you potentially do really start re-implementing the type system (so perhaps it is such automation you were thinking of?), I think, because you have to use the types of the auto-collected things, which might be polymorphic, to put things in "bins" that are put together as the parse tree. By contrast, it seems like if you already know what all the possible "bins" are (as in current miniTidal where things are added manually) and how they might be connected in the parse tree, then there's not really anything else to do.
I think where I was left (again., no time to finish it) with the latter task was the thought of exploring a kind of brute force approach - (1) make bins for every possible concrete type that might be used, then for every unary function between each of those types, then for every binary function between all of those types, etc up to some level of depth, (2) place the available definitions into every bin they could be a member of. That should auto-produce a (possibly marginally more complete) version of what miniTidal currently is.
What I would really like: a PureScript version of MiniTidal! That would be easy to make into an exolang.
@felixroos currently miniTidal/tidal-parse is built via GHCJS into JS that is then included with Estuary (as part of the big process of building Estuary) - that was the "old way". Some languages (eg. LocoMotion) in Estuary now exist as prototypical exolangs - they exist as JavaScript libraries that are loaded at runtime instead. I haven't tried out the WASM tool you referenced, but I do imagine it might be used to produce such libraries from anything in Tidal's code base.
Might not help with what you are trying to do (and would be a big-ish payload to download) but I might whip up a pathway for embedding Estuary into other websites in various ways (it's a bit of a tangent from why I want to do any of this, but it's also low hanging fruit at this point, so...)...
Hacked a thing together where you can get an Estuary with no UI and a minitidal expression turned into sound. Haven't tried embedding it yet, or thought much about how it might be controllable (for example, to play/pause)... https://estuary.mcmaster.ca/?noui&minitidal=s%20%22bd%20cp%22