> I don't mind that syntax, except for the double quotes. I'd be ok with:
>
> TUPLE: color { red integer 0 } { green integer 0 } { blue integer 0
> } ;
>
> You can provide either a type or an initial value. There is ambiguity if
> you
> provide a type as an initial value. For this case, you could have some rule
> on ordering.
The syntax I'm working with now is
TUPLE: color { "red" integer initial: 0 } ... ;
With the initial: part optional.
>
> Let's put that syntax side by side with the KLF syntax:
>
> TUPLE: color { red integer 0 } { green integer 0 } { blue integer 0
> } ;
> TUPLE: color red/integer=0 green/integer=0 blue/integer=0 ;
>
This would be hard to parse in the case where the initial value is a more
complex literal, such as an array.
With the syntax I'm using, there is a nice correspondence between the
parse-time and run-time tuple definition syntax:
TUPLE: color < paint { "red" integer initial: 0 } ... ;
color paint { { "red" integer initial: 0 } ... } define-tuple-class
If you start using custom lexical conventions, this correspondence becomes
less obvious.
I'm open to getting rid of the double quotes, though.
Slava
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk
