Re: Class names
Hi,
I just realized there are two issues here.
1) Having a convention for class names
2) Making it safe to define words that shadow class names
I'm not really interested in 1) because it doesn't seem useful to me
to know that something if something is a class or not. Mousing over a
word will tell you that. Also, most of the time, a class name is
followed by new or boa, or this is encapsulated in a constructor.
I think a better distinction is "inert word" or "live explosive
word". In this vein, it would make sense to find a single syntax for
this, which is what \ does for symbols, word names, and class
names. If you're passing around classes to be constructed later,
then I think just knowing they're inert and having "class" in the
stack effect is enough.
We have several types of symbol-like things in Factor. First we have symbols. These are a bit like common-lisp symbols, except that they must be manually interned, and they are executable. When executed they simply push themselves:
SYMBOL: foo
foo .
=> foo
\ foo .
=> foo
foo execute .
=> foo
Next we have tuple classes. I haven't looked into the implementation, but these seem to be semantically equivalent to symbols:
TUPLE: bar ;
bar .
=> bar
\ bar .
=> bar
bar execute .
=> bar
And then we have words. These are also symbols, but when executed they do something arbitrary. This could include pushing their own symbol, so in a way symbols are a subset of words:
: blah ( -- symbol ) \ blah ;
blah .
=> blah
\ blah .
=> blah
blah execute .
=> blah
I think the core of Ed's complaint was that symbols quote themselves implicitly, rather than requiring an explicit \, which leads to code that reads inconsistently. Worse than this, it means that the behaviour of code can change when a new vocab is USEd, because tuple class symbols push themselves up until a word is defined with the same name.
A more general version of this problem is: Should adding a vocab to your USING statement (or a change in a USEd vocab) ever change the behaviour of your program?
I don't think it should, and always using an explicit \ is one way of ensuring this. Of course, we can put our IN: below our USING: so that anything we define takes precedence over anything USEd, but this is a bit of a hack. It doesn't work consistently when we're experimenting in the listener, and any vocab using our vocab has to put our vocab last (or is it first?) in their USING: statement if they want to use our unquoted symbol rather than the other vocab's conflicting word.
Alex
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Factor-talk mailing list
Factor-talk@...
https://lists.sourceforge.net/lists/listinfo/factor-talk
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
RSS Feed