digitalmars.D - crazy tuple ideas.
- Knud Soerensen (15/15) Mar 02 2007 With people starting to write compiler time parsers,
- BCS (14/32) Mar 02 2007 Um, I'm not so sure about that syntax...
- Sean Kelly (4/14) Mar 02 2007 mixin( Parse( "(=,E,(*,m,(^,c,2)))" ) );
- Jarrett Billingsley (2/20) Mar 02 2007 Actually, Andrei and Walter have hinted several times at D getting some ...
- Daniel Keep (15/33) Mar 02 2007 +1 on nested tuples, although the symbols appearing unquoted is somewhat
- Russell Lewis (20/23) Mar 05 2007 I agree that nested tuples would be cool, though I'm not 100% sure what
- Daniel Keep (15/49) Mar 05 2007 Well, for reference, Python "explodes" tuples using what is essentially
With people starting to write compiler time parsers, maybe it would be a good idea to have a standard way for representing syntax trees. By allowing tuples to contain tuples we will have something very similar to the lisp list expression. Example: Tuple!(=,E,Tuple!(*,m,Tuple!(^,c,2))); // E=m*c^2; or maybe allowing the programmer to write just (=,E,(*,m,(^,c,2))) By using a standard way for representing syntax trees we allow for more code sharing between project which uses them. Also if the D compiler made the programs syntax tree available doing compilation if would be possible to make modules which could modify the programs syntax tree at compiler time.
Mar 02 2007
BCS <BCS pathlink.com> Knud Soerensen wrote:With people starting to write compiler time parsers, maybe it would be a good idea to have a standard way for representing syntax trees. By allowing tuples to contain tuples we will have something very similar to the lisp list expression.There's nothing crazy about that. <g>Example: Tuple!(=,E,Tuple!(*,m,Tuple!(^,c,2))); // E=m*c^2; or maybe allowing the programmer to write just (=,E,(*,m,(^,c,2)))Um, I'm not so sure about that syntax...By using a standard way for representing syntax trees we allow for more code sharing between project which uses them.vote++Also if the D compiler made the programs syntax tree available doing compilation if would be possible to make modules which could modify the programs syntax tree at compiler time.That could make for some nasty debugging, going with a "here's some AST, build it" would do lots and not be so nasty. Even allowing for AST literals would do a lot without being quite as hard to work with. This template foo(A...){...} foo!(a+bc/d, i+jk*f); ends up like: foo!(Tuple!(a, +, Tuple!(bc, /, d)), Tuple!(i, +, Tuple!(jk, *, f))); with the IDs being aliases and the ops being something somewhat like a type (compile time only symbol).
Mar 02 2007
Knud Soerensen wrote:With people starting to write compiler time parsers, maybe it would be a good idea to have a standard way for representing syntax trees. By allowing tuples to contain tuples we will have something very similar to the lisp list expression. Example: Tuple!(=,E,Tuple!(*,m,Tuple!(^,c,2))); // E=m*c^2; or maybe allowing the programmer to write just (=,E,(*,m,(^,c,2)))mixin( Parse( "(=,E,(*,m,(^,c,2)))" ) ); :-P Sean
Mar 02 2007
Knud Soerensen Wrote:With people starting to write compiler time parsers, maybe it would be a good idea to have a standard way for representing syntax trees. By allowing tuples to contain tuples we will have something very similar to the lisp list expression. Example: Tuple!(=,E,Tuple!(*,m,Tuple!(^,c,2))); // E=m*c^2; or maybe allowing the programmer to write just (=,E,(*,m,(^,c,2))) By using a standard way for representing syntax trees we allow for more code sharing between project which uses them. Also if the D compiler made the programs syntax tree available doing compilation if would be possible to make modules which could modify the programs syntax tree at compiler time.Actually, Andrei and Walter have hinted several times at D getting some kind of Lisp-like AST manipulation, so this possibility may not be that far off..
Mar 02 2007
Knud Soerensen wrote:With people starting to write compiler time parsers, maybe it would be a good idea to have a standard way for representing syntax trees. By allowing tuples to contain tuples we will have something very similar to the lisp list expression. Example: Tuple!(=,E,Tuple!(*,m,Tuple!(^,c,2))); // E=m*c^2; or maybe allowing the programmer to write just (=,E,(*,m,(^,c,2))) By using a standard way for representing syntax trees we allow for more code sharing between project which uses them. Also if the D compiler made the programs syntax tree available doing compilation if would be possible to make modules which could modify the programs syntax tree at compiler time.+1 on nested tuples, although the symbols appearing unquoted is somewhat iffy. That said, I've always thought that parentheses should be the syntax for instantiating tuples. After all, everywhere parentheses are used, you could conceivably put a tuple instead (and they would still work for operation precedence since you'd need to evaluate a tuple's contents before you could build the tuple). Meh; just rambling. -- Daniel -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
Mar 02 2007
Daniel Keep wrote:+1 on nested tuples, although the symbols appearing unquoted is somewhat iffy.I agree that nested tuples would be cool, though I'm not 100% sure what the syntax should be. Perhaps the existing syntax (where tuples are unrolled by default) needs to be made more explicit. However, you can already roll your own nested tuples, at least for some things. You can take a type-tuple and create a struct: struct TupleBoxer { MyTuple elements; } and although I haven't written one, yet, I bet that you could write a template which would do the same with expression-tuples. Note that you can encapsulate an expression in a struct like this: struct ExpressionBoxer { static const uint foo = <myExpression>; } and so you should be able to write a template which takes an expression-tuple and builds a struct like that for you. Perhaps type deduction makes this really easy? I'm not saying that any of this is as good as nested Tuples, but it's a start.
Mar 05 2007
Russell Lewis wrote:Daniel Keep wrote:Well, for reference, Python "explodes" tuples using what is essentially C's dereference syntax.+1 on nested tuples, although the symbols appearing unquoted is somewhat iffy.I agree that nested tuples would be cool, though I'm not 100% sure what the syntax should be. Perhaps the existing syntax (where tuples are unrolled by default) needs to be made more explicit. However, you can already roll your own nested tuples, at least for some things. You can take a type-tuple and create a struct: struct TupleBoxer { MyTuple elements; } and although I haven't written one, yet, I bet that you could write a template which would do the same with expression-tuples. Note that you can encapsulate an expression in a struct like this: struct ExpressionBoxer { static const uint foo = <myExpression>; } and so you should be able to write a template which takes an expression-tuple and builds a struct like that for you. Perhaps type deduction makes this really easy? I'm not saying that any of this is as good as nested Tuples, but it's a start.print word1, word2def print_words(word1, word2):Hello World! Incidentally, this also works...words = ("Hello", "World!") print_words(*words)Hello World! As does this :Pwords = {"word1":"Hello", "word2":"World!"} print_words(**words)Hello World! -- Daniel -- Unlike Knuth, I have neither proven or tried the above; it may not even make sense. v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/pos_args = ("Hello",) named_args = {"word2":"World!"} print_words(*pos_args, **named_args)
Mar 05 2007