Kosyrev Serge <_deepfire@feelingofgreen.ru> writes:
How much of this derivation machinery could NOT be implemented by means of some kind of a (hypothetical) type-backed metaprogramming facility?
The beauty of an open implementation[1] allowed by such a thing is that:
I apologize for the unfortunate metacircular logic in the below passage:
1. uniformity of definition of the desugaring transformation would have followed, and from that:
- the "bespoke" derivation mechanism will suddenly become explainable in a language shared by all derivation mechanisms:
- the separate derivation strategies as separate, named macro transformations, using a common library of type-level and other tools -- mostly those already in existence - the combined strategy as an overarching macro tranformation
It should instead read as: 1. uniformity of expression of the desugaring transformation would have followed, in the following way: - the overall derivation mechanism is to become expressible through the following composition: - the separate derivation strategies are to become separate, named macro transformations, using a common library of type-level and other tools -- mostly those already in existence - this aforementioned common library is explicitly required to be sufficiently powerful to able to express the "bespoke" derivation mechanism - the combined strategy as an overarching macro tranformation The rest stands as is:
2. because of above, we get a starting point from which we can evolve something that can be meaningfully standartized, without a feeling of shame or guilt -- we now have a language describing the problem domain, that can be un-tied from a particular implementation
3. in-editor macroexpansion is a proven, working concept in the realm of Proper Metaprogramming (viz. Common Lisp etc.), and it would basically eliminate guesswork from user workflows
..or is this all a violent pipe dream?
-- с уважениeм / respectfully, Косырев Сергей