Kosyrev Serge <_deepf...@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, Косырев Сергей _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs