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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to