Elm solves these problems. Html, css and javascript are simply encapsulated as pure functions, and all you need do is combine them together in straightforward ways and you get no surprises. All messages are routed sequentially through one single place, so that you simply pattern match on the signal stream and you thus retain control of your application's behaviour. Elm code compiles down to a safe subset of javascript in such a manner that you virtually never see any kind of runtime exception. Also you get a very simple interactive development environment with truly informative compiler error messages.
This means that I can now approach the web tier in the same way that I approach the server tier - for the first time I'm feeling comfortable. I suppose this is elm's main value proposition - you can control both your application's look-and-feel and its behaviour and it's all in the context of a simple mental model.
But I want to approach things from left-field. I'm less interested in how the application looks than in how it sounds. Audio has been the poor relation in web programming for such a long time now, and elm is no exception. However, once Evan comes clean about his plans for wrapping the web platform API, I fully expect audio to blossom in elm. What I find exciting is that it's now possible to build, quite quickly, relatively sophisticated tools and have them run in the browser in a manner that I would previously have thought to be impossible.
Functional Parsers
I've now written two fairly substantial parsers - one for MIDI and the other for the ABC notation (which describes musical scores). Both use the wonderful elm-combine parser combinator library from Bogdan Popa. This has proven itself to be a great choice - not just because you can write practical parsers with it but also because of the great support Bogdan provides.
If you come from a javascript background, you're perhaps not too sure of what a functional parser is. A traditional imperative parser is monolithic - it will usually employ a lexer for building tokens from the individual characters and a single parser for checking that the token stream fits the grammar and for building a parse tree. By contrast, a functional parser is built from lots of very tiny parsers, combined together. For example, you may have one that just parses a particular character sequence such as the word 'import' or another that just parses integers and so on.
It turns out that you can combine these little parsers together very simply. Just to give one example, the ABC notation has a concept of a tuplet which is a generalisation of a triplet (three notes taking the time allotted to two) or a quadruplet (four notes taking the time allotted to three) and so on. For example, a triplet for three successive notes on a keyboard from middle C would be notated as (3CDE.
You might want to represent it in a parse tree like this to imply that a tuplet consists of a signature part (e.g. 3 or 4) and a list of notes (e.g. A,B and C):
type Music =
Tuplet TupletSignature (List AbcNote)
| ....
another way of looking at this is that Tuplet is a constructor function that builds a Music type and which has the signature:
Tuplet : TupletSignature -> (List AbcNote) -> Music
Now, a parser for this part of the ABC language might look like this:
tuplet : Parser Music
tuplet = Tuplet <$> (char '(' *> tupletSignature) <*> many1 abcNote
I'm well aware that this looks like hieroglyphics and that elm discourages the use of infix operators like these but in the case of functional parsers, I think their use is entirely justified and, once you get used to them, makes life considerably simpler.To deconstruct this statement - there are three primitive parsers - for the left bracket character, the tuplet signature (i.e. 3 or 4) and for a note in ABC notation (i.e. A, B or C). The abcNote parser is used with the many1 combinator which means that one or more instances of a note are recognised, producing a list. The *> and <*> operators mean that you process the parser at their left followed by the one on their right in sequence. The difference being that the first of these throws the left hand result away whilst retaining the right hand side result, whilst the second retains both results. So at this stage, we've successfully parsed (say) a triplet and retained the '3' and the 'ABC'. Finally, the <$> combinator just applies the Tuple constructor function we defined earlier to the two results, building the Music type. (All types are, however wrapped inside a Parser type). This is an example of what is called the applicative style.
The full parser for ABC is merely extends this technique to cover the entire grammar.
Web-Audio Players
Once you have a parse tree, it is then a relatively simple job to translate it into a set of instructions for playing each individual note (at the correct pitch and for the intended duration). This can then be dispatched to web-audio so that the tune can be played. Web-audio is supported in recent versions of most 'modern' browsers like Chrome, Firefox and Opera. Unfortunately, elm 0.16 has no simple way of integrating with javascript APIs like these and so you have to resort to the frowned-upon technique of wrapping a javascript integration layer inside an elm interface. The hints coming from elm-dev suggest that this might be solved in 0.17.
The net result of all this? You can accept an ABC tune from a user, parse it, and if it is valid, play it immediately. All this takes place in the browser. All the applications that I know about that do this sort of thing do the processing on the server before returning something playable to the client. So, my contention is that elm allows you to attempt applications in the browser that simply were not possible before (or at least not without superhuman effort).
If all this has given you a thirst for learning the ABC notation, there's an interactive tutorial here and an ABC editor here. The code is here.
If all this has given you a thirst for learning the ABC notation, there's an interactive tutorial here and an ABC editor here. The code is here.
No comments:
Post a Comment