Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!dsl.pitt.edu!pitt!willett!ForthNet
From: ForthNet@willett.UUCP (ForthNet articles from GEnie)
Newsgroups: comp.lang.forth
Subject: Vocabularies
Message-ID: <1476.UUL1.3#5129@willett.UUCP>
Date: 7 Aug 90 02:25:13 GMT
Organization: String, Scotch tape, and Paperclips.  (in Pgh, PA)
Lines: 73

Category 3,  Topic 18
Message 16        Mon Aug 06, 1990
R.BERKEY [Robert]            at 06:11 PDT
 
  Subj: Vocabularies

Doug Phillips writes, 90-08-01:

 > In <9007310619.AA15045@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM
 > writes:

 >>    Unfortunately, there are important
 >> omissions from most Forth standards in this area [Vocabularies]:
 >>  a) No standard way to programmatically enumerate the words in
 >>     a vocabulary (i.e. the primitives you need to build VLIST
 >>     or WORDS)
 >>  b) No standard way to save and restore the search order.
 >>  c) No standard way to selectively remove a single word from a
 >>     vocabulary.
 >>  d) No standard way to search just one vocabulary.

 > I'm curious if anyone knows of a system that does these things?

I have each of these capabilities in my modified F-PC.  I'd be handicapped
without (a).  It's not just WORDS , it's the ability to relate an execution
token (nee "compilation address") to it's word name.  I've needed (b) in the
past, but not currently.  I find (c) useful in retrofitting parts of the F-PC
nucleus.

I see (d), the ability to search a single vocabulary, as a particularly
important need as a standard capability with vocabularies.  I say this due to
its need in application development, experience as a consultant using
commercial systems, and the obviousness that systems with vocabularies can
search vocabularies.  The alternative in implementing a vocabulary structure
from scratch seems pointless, except that romability is a consideration.

 >Would it still be Forth as we know it?  Are vocabularies *really*
 >part of Forth, or something that is added on on top of it?
 >Not dictionaries, vocabularies.

Insofar as Forth is a tool I'd say yes.  I've used/needed vocabularies
routinely in my commercial Forth work.

I see a vocabulary as what associates a word name with an action.
Conceptually, each of the interpreter, compiler, and assembler may have word
names with the same name and different actions.  As Frank Sergeant notes,
naming conventions ( XOR, instead of XOR ) can be used to differentiate the
assembler from the interpreter lexicons.  Insofar as the assembler is an
application for programmer use this is practicable.

But when the parser is being written for a customer's use, it's no longer
reasonable to allow just any word name to be recognized.  For a simple example
of an interpreter, I might have the words:

   TRUE CONSTANT Y    TRUE CONSTANT Yes   TRUE CONSTANT YES
   TRUE CONSTANT y    TRUE CONSTANT yes
   FALSE CONSTANT N   FALSE CONSTANT No   FALSE CONSTANT NO
   FALSE CONSTANT n   FALSE CONSTANT no

in a vocabulary, and given that these are the only word names I am willing to
allow as recognizable, the conflict with finding any other word names is
obvious.

Even in the prom system I presently work with, which includes no Forth
interpreter, compiler, or assembler; the code came to me with a form of
vocabulary for identifying "word names" entered by the user, and these tokens
are then associated with actions.

 Robert

-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or willett!dwp@hobbes.cert.sei.cmu.edu