Add syntax to elm to allow for safe type checked embedded languages.
Currently Elm embeds GLSL as a special case for type safe webgl programs. This is somewhat odd as a special case, but prooves to be a really nice feature, that other DSLs could benefit from. The idea here is to implement this in user land, allowing library authors to create functions that expose DSLs to their callers, but allow compile time error checking and reporting.
I believe that using strings as data is often a source of remaining bugs in Elm programs. (See Stringly Typed). Having a richer, type and syntax checked semantic for these could easily improve the reliability and maintainability of these programs.
- Invalid Regex can crash your app #378, different proposal
- String interpolation #905
Allow the definition of special functions that take the form
[|name|] : String -> Result ParseError AST
, which the compiler understands
as macros, rather than runtime functions. Once these are defined (and imported),
the compiler allows the use of string-like blocks of the form of [name| text |]
.
When any of these are identified the compiler will evaluate the special function
with the matching name. If this results in the Error
case, then the compiler
will fail compilation with an error message suplied by the function and the source
location of the original string. (Perhaps some more detail about the error should
be supplied in the error type?)
In the Ok
case, the resulting type will be some representation of valid Elm code,
that will be (hygienically?) put instead of the call site.
The examples in this gist provide some illustration into an implementation of such a macro, but there is probably a nicer way to do this.
This is an embedded language in elm, but is special cased by the compiler.
- Racket and other lisps
- Elixir
- Template Haskell
Paper worth reading. They associate a parser with a type and then allow values to be parsed based on that, so no sigils necessary. Also have the nice idea that the parsers themselves are defined in an embedded language. Pretty neat.
Should these functions be able to accept additional arguments? It's not clear how this would work, since currently the only argument is an actual literal, so there is no actual computation at the macro call site.
GraphQL should be validated against a server-side schema again prefferably at compile time. It could easily be made the responsibility of the user to actually download it, etc. but the macro would still need access to this external source of truth. It's not clear how this could be handled in this proposal.
This seems to always be tricky if the number of embedded languages isn't bound, but the sigil would usually be the name of the embedded language, so hopefully this shouldn't be too bad.