The prior design of MAML had assumed that client applications would extend the base Expression trait to implement custom behaviors (especially in the case of the former Source nodes which would ideally be able to use various backings to resolve tiles). It is now very clear that this design was naive. The alternative proposal, encapsulated in this PR, is that we define fully the handling of evaluation when a MAML tree is fully bound with meaningful literals at the leaves and provide niceties for swapping Variable nodes (which have String names) into Literal nodes.
This simplifies the task of evaluation (it can be written ahead of time), provides a bit of extra safety (free exhaustivity checks from the compiler!), and is less different from a proper recursion scheme-based approach than our former strategy
fosskers
commented
6 years ago
The prior design of MAML had assumed that client applications would extend the base
Expressiontrait to implement custom behaviors (especially in the case of the formerSourcenodes which would ideally be able to use various backings to resolve tiles). It is now very clear that this design was naive. The alternative proposal, encapsulated in this PR, is that we define fully the handling of evaluation when a MAML tree is fully bound with meaningful literals at the leaves and provide niceties for swappingVariablenodes (which haveStringnames) intoLiteralnodes.This simplifies the task of evaluation (it can be written ahead of time), provides a bit of extra safety (free exhaustivity checks from the compiler!), and is less different from a proper recursion scheme-based approach than our former strategy