...
As can be seen, this is unreasonably verbose for a textual form, and there was a further discussion on how to relate together the use of the various styles that would arise, possibly as transformations were authored in different modalities (visual/non-visual/textual)
Three approaches for defining transformations
Summarising and expanding the previous discussion, we describe here the three approaches for writing transformer rules:
| Unordered List |
|---|
a) Expand the transformer fully in terms of elementary transforms - with one JSON node per expression node. This is extremely verbose and not suited to the needs of those using textual representations. It may be reasonable for those using visual or non-visual tools. b) Adjust the definition of the base transformer with "decorators" or further options which try to customise its behaviour for more situations. This may result in a compact definition but creates a "findability" burden - the additional options need to be document and users must be able to find them - and somehow enough value added to this process so that users are recompensed for the cost of searching for the transform and its options c) Make as much use as possible of "ad hoc" short functions written in conventional JavaScript operating the transform. This might be the most compact option and eliminates any "findability" burden - however, it inhibits reuse and code sharing by users of the system. It is also not transparent to tools, cutting non-textual users out of the system. |