www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - crazy tuple ideas.

reply Knud Soerensen <4tuu4k002 sneakemail.com> writes:
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
next sibling parent BCS <BCS pathlink.com> writes:
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
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
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
prev sibling next sibling parent Jarrett Billingsley <kb3ctd2 yahoo.com> writes:
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
prev sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
parent reply Russell Lewis <webmaster villagersonline.com> writes:
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
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Russell Lewis wrote:
 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.

Well, for reference, Python "explodes" tuples using what is essentially C's dereference syntax.
 def print_words(word1, word2):



 words = ("Hello", "World!")
 print_words(*words)



Incidentally, this also works...
 words = {"word1":"Hello", "word2":"World!"}
 print_words(**words)



As does this :P
 pos_args = ("Hello",)
 named_args = {"word2":"World!"}
 print_words(*pos_args, **named_args)



-- 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 05 2007