Hi all,
Soon I will be adding support for optional type declarations on tuple slots.
Here is one tentative syntax:
TUPLE: color red|integer green|integer blue|integer ;
The problem with this is that right now, the default value for tuple slots
is 'f'. So if we had
TUPLE: color red green blue ;
And we say
color new
We get a tuple with all three slots set to f.
Once type declarations on slots are supported, this will no longer make
sense, since 'f' might not be an instance of the declared type. For example,
if you declared that a slot's type is 'integer', you would expect that the
initial value be 0, or something.
At first, I thought I could get away without supporting initial values,
since one approach would be to just prohibit 'new' from being used on tuples
with type declarations on slots. Then,
color new
would be a runtime error, but
1 2 3 color boa
would be fine -- the boa constructor specifies values for all slots, and we
could check that they are of the right type.
However, it turns out that this is insufficient, because even if you only
use BOA constructors, there is still a case where the initial value is
needed; tuple reshaping. Suppose we define
TUPLE: color red|integer green|integer blue|integer ;
Then, we later redefine it as so
TUPLE: color red|integer green|integer blue|integer alpha|integer ;
Now, existing instances need to be updated to contain the new slot, and some
kind of initial value has to be used, and f is unsuitable since it is not an
integer.
I can think of two solutions here:
1) Support a per-type notion of 'default value'. This would be roughly as
follows:
float: 0.0
real: 0
string: ""
array: { }
etc.
For tuple types, the default value would be a shared instance of the tuple,
with all slots filled in to their respective defaults.
This has the advantage of simplicity, and it also allows us to use the
rather elegant | syntax, which would be consistent with the syntax I
proposed for multi-methods at
http://factor-language.blogspot.com/2008/06/syntax-proposal-for-multi-methods.html
.
However, having a per-type default value is not really the most flexible
solution, and it doesn't make sense in all cases either. It would really be
more flexible to allow the default value to be specified as part of the
tuple definition itself.
So, we could have a syntax like the following:
TUPLE: color { "red" integer 0 } { "green" integer 0 } { "blue" integer 0 }
;
Each slot specifier would either be a string, a two element array (name,
default value) or a three element array (name, class, default value).
If you don't care about a default value or type declaration, the old syntax
could still work:
TUPLE: color red green blue ;
But we'd encourage this:
TUPLE: color "red" "green" "blue" ;
What do you guys think? Is being able to specify default values worth the
slightly more verbose syntax?
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
