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.

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).

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

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..

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/

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.

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):
        print word1, word2
>>> words = ("Hello", "World!")
>>> print_words(*words)
Hello World!

Incidentally, this also works...

>>> words = {"word1":"Hello", "word2":"World!"}
>>> print_words(**words)
Hello World!

As does this :P

>>> pos_args = ("Hello",)
>>> named_args = {"word2":"World!"}
>>> print_words(*pos_args, **named_args)
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/