Kay Schluehr ha escrito: > Juan R. wrote: > > > Kay Schluehr ha escrito: > > > Note also that a homogenous syntax is not that important when > > > analyzing parse trees ( on the contrary, the more different structures > > > the better ) but when synthesizing new ones by fitting different > > > fragments of them together. > > > > Interesting, could you provide some illustration for this? > > My approach is strongly grammar based. You start with a grammar > description of your language. This is really not much different from > using Lex/Yacc except that it is situated and adapted to a pre-existing > language ecosystem. I do not intend to start from scratch. > > Besides the rules that constitute your host language you might add: > > repeat_stmt ::= 'repeat' ':' suite 'until' ':' test > > The transformation target ( the "template" ) is > > while True: > <suite> > if <test>: > break > > The structure of the rule is also the structure of its constituents in > the parse tree. Since you match the repeat_stmt rule and its > corresponding node in the parse tree you immediately get the <suite> > node and the <test> node: > > class FiberTransformer(Transformer): > @transform > def repeat_stmt(self, node): > _suite = find_node(node, symbol.suite) > _ test = find_node(node, symbol.test, depth = 1) > # > # create the while_stmt here > # > return _while_stmt_node > > So analysis works just fine. But what about creating the transformation > target? The problem with the template above is that it can't work > precisely this way as a Python statement, because the rule for a while > statement looks like this: > > while_stmt: 'while' test ':' suite > > That's why the macro expander has to merge the <suite> node, passed > into the template with the if_stmt of the template, into a new suite > node. > > Now think about having created a while_stmt from your original > repeat_stmt. You return the while_stmt and it has to be fitted into the > original syntax tree in place of the repeat_stmt. This must be done > carefully. Otherwise structure in the tree is desroyed or the node is > inserted in a place where the compiler does not expect it. > > The framework has to do lots of work to ease the pain for the meta > programmer. > > a) create the correct transformation target > b) fit the target into the syntax tree > > Nothing depends here particularly on Python but is true for any > language with a fixed grammar description. I've worked exclusively with > LL(1) grammars but I see no reason why this general scheme shall not > work with more powefull grammars and more complicated languages - Rubys > for example.
Thanks. > > > The next question concerns compositionality of language > > > enhancements or composition of even completely independent language > > > definitions and transformers both on source and on binary level. While > > > this is not feasible in general without creating ambiguities, I believe > > > this problem can be reduced to ambiguity detection in the underlying > > > grammars. > > > > A bit ambiguous my reading. What is not feasible in general? Achieving > > compositionality? > > Given two languages L1 = (G1,T1), L2 = (G2, T2 ) where G1, G2 are > grammars and T1, T2 transformers that transform source written in L1 or > L2 into some base language > L0 = (G0, Id ). Can G1 and G2 be combined to create a new grammar G3 > s.t. the transformers T1 and T2 can be used also to transform L3 = (G3 > = G1(x)G2, T3 = T1(+)T2) ? In the general case G3 will be ambigous and > the answer is NO. You mean direct compositionality. Is there any formal proof that you cannot find a (G2' , T2') unambiguously generating (G2, T2) and combining with L1 or this is always possible? This would not work for language enhancements but for composition of completely independent languages. > But it could also be YES in many relevant cases. So > the question is whether it is necessary and sufficient to check whether > the "crossing" between G1 and G2 is feasible i.e. doesn't produce > ambiguities. -- http://mail.python.org/mailman/listinfo/python-list
