Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!cmcl2!acf5!sabbagh From: sabbagh@acf5.NYU.EDU (sabbagh) Newsgroups: comp.lang.forth Subject: Re: Vocabularies Message-ID: <1223@acf5.NYU.EDU> Date: 21 Aug 90 17:57:17 GMT References: <1219@acf5.NYU.EDU> <1561.UUL1.3#5129@willett.pgh.pa.us> Reply-To: sabbagh@acf5.UUCP () Organization: New York University Lines: 59 In article <1561.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: >In <1219@acf5.NYU.EDU>, sabbagh@acf5.NYU.EDU (sabbagh) writes: > >> What are vocabularies? They are lists of (key,value) pairs! Why not >> define them abstractly, simply by having each vocabulary provide its own >> words for creation, deletion, listing and finding such pairs in its own >> internal structure? Also, allow each vocabulary to decide what a number >> is. Vocabularies could then be kept on a stack, and the inner interpreter >> would call the FIND word for each vocabulary in the stacked order, until >> one of them recognizes the word. This is the most general solution to >> the vocabulary issue, especially since this would be transparent to the >> user, most of the time. It also addresses the issue of what to do if >> you want to add new number types, literals, etc. to Forth. > >Ok, but how does the inner-interpreter find the FIND words? Perhaps they >must be the first word in the vocabulary? (DEFER would be useful in that >case). I think your earlier point about the history of Forth is relevant >here. The ANSI "process" is not supposed to be a creative effort, its >supposed to be a consensus making effort. I think your idea about >vocabularies, which is similar to other ideas I've seen, makes sense on >paper. I think it would actually work in practice. But that isn't good >enough for ANSI. It has to have really been done. Each item of the vocabulary stack could be a pointer to a vocabulary structure, with the deferred word in a known offset in this structure. Or, one can use an MCF approach: each item of the voc stack is an executable word with multiple code fields. This would have to be slightly different that MCF as is currently implemented, which is state-smart and uses the token stream. Having read very little about ANSI (but reading a lot of net.traffic) I sense that I am going to be very disappointed with the results of the ANSI effort. Consider this: even including PD Forths, the number of Forth systems is FAR LESS THAN the number of applications! The ANSI people are largely vendor-types (from what I understand, correct me if I'm wrong) and may be too concerned with their own ability to produce ANSI Forth! As an application-writer, I am not too worried about the internals of Forth IF I CAN WRITE MY PROGRAMS USING ONLY ANSI FORTH. I agree standardizing Forth is much harder than other languages, but we should worry less about the vendor's problems and more about the users'. What this means is that the standards committee should have worked towards STANDARDIZING A VIRTUAL MACHINE. This way, even though some applications would have to be rewritten, they could be ported to any ANSI Forth ON ANY MACHINE. This is the big win of C (and C++)! This can be accomplished by requiring access to the underlying machine be only through ANSI defined words. Hadil G. Sabbagh E-mail: sabbagh@csd27.nyu.edu Voice: (212) 998-3125 Snail: Courant Institute of Math. Sci. 251 Mercer St. New York,NY 10012 "'He was killed by the usual cabal: by himself, first of all; by the woman he knew; by the woman he did not know; by the man who granted his inmost wish; and by the inevitable fifth, who was keeper of his conscience and keeper of the stone.'" -R. Davies, "Fifth Business"