Several things recently gelled in my mind, after
- discussing the built-in Grammar type,
- reading the earlier built-in toJSON proposal, and
- having implemented toMap only to see a request for fromMap pop up.
Generally, there sure seems a lot of demand for extensions to the language of a particular type. Each extension is generally type-safe, and if it could be simply added to Prelude nobody would bat an eye. The trouble is that they can’t be expressed in Dhall: they cannot even be given a Dhall type. That means each construct has to be added to the language specification, and then to every single implementation. That’s a heavy burden to impose.
My first problem formulation attempt called these things language plugins, but that doesn’t help implementors.
Then finally it hit me that many of these extensions could be implementable if we allowed them to operate at meta level, if they were functions on reflections of Dhall expressions. So for example while toMap
doesn’t have a type, at the meta level it would be a function from a reflected record to a reflected list. A reflected record is just a list of reflected fields, and a field is a record of field name and reflected type. Generally speaking, a meta-level function could be given a type of
let MetaFunction = MetaExpression → < result : MetaExpression
| next : MetaFunction
| error : Text >
When a MetaFunction
is pulled into scope — which could be restricted to file or Prelude imports only — its argument would be automatically converted to a MetaExpression
, then the function would be applied, and if successful the result
would be reified back to a surface-level Dhall expression.
I see the main benefit of this approach as shifting the implementation burden from the host language implementations to Prelude. The implementations would need to implement the meta-language support only once, and then fromMap
, toMap
, merge
, and many more untypeable constructs could be implemented in Prelude for everybody’s use. Depending on how Text
values gets reified, other constructs like toJSON
could also be automatically covered.
Now of course the downside of this idea is that it would permit heretofore unpermissible things, so it would lower the security guarantees. I think if we can restrict it to Prelude
alone that is not a problem, but @Gabriel439 may feel differently.