ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/08/90)
Category 3, Topic 18 Message 3 Wed Mar 07, 1990 R.BERKEY [Robert] at 01:07 PST Re: Interpretable numeral constants Dennis Ruffer writes, 900306: > Re: PETE KOZIAR > > Here's today's trivial speed-up. Three of the most-used > > constants are certainly -1, 0 and 1. F83 defined them as CODE > > words, but F-PC does not. > A warning is in order here. polyFORTH defined 0 and 1 as constants > for years. Recently, however, we implemented a way to revector the > number conversion and interpetation process. Under this system, it > is occasionally neccessary for 0 and 1 to pass through the number > conversion process. Then, defining numbers as constants can get you > into a lot of trouble. ... I've had problems with interpretable numeral constants, too, using F-PC. In response, I've created a NUMERALS vocabulary that is searched by the number compiler, during colon compilation. Once or twice I've tried to ' (tic) a numeral constant and forgotten for a moment that they weren't in the usual search order, but that's the only problem I can recall having. Most of work was going through the F-PC source code and changing the relevant literals to base-insensitive syntax, i.e., 10 to #10 or $0A . Then the reverse occurred when 3.5 came out and I used file compares to find out what was new, and each of those changes showed up as differences. Here are the words now in the NUMERALS vocabulary: >browser numerals these words --[ NUMERALS ]-- 2, 1, 0, #100 #60 #10 1K $200 $100 $0FF $80 $7F $40 $30 $20 $1F $18 $10 $0F $0A 9 8 7 6 5 4 3 2 1 0 -1 -2 Here's a note from the file, CONSTANTS, which includes '0' and '~' along with 17 other ascii-value constants: \ 890902 Constants save $90 segments, i.e., \ #2300 bytes, in the creation of FORTH.EXE I asked Tom Zimmer about constants, and he asserted that in-line constants are faster on an 8088. I think it was Mark Smiley he cited as someone who had encountered a problem with interpreting numerals defined as constants. As for speed, I'm using an 80286, and use the push immediate opcode to define constants. This along with identifying 2CONSTANTs adds several tests to the decompiler, as code fields are not as easy to interpret, but it all seems to have worked out. ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/14/90)
Date: 03-12-90 (19:23) Number: 3021 (Echo)
To: DENNIS RUFFER Refer#: NONE
From: STEVE WHEELER Read: NO
Subj: HEADLESS CONSTANTS Status: PUBLIC MESSAGE
>A warning is in order here.
I agree. A few years ago, the Forth we offered our customers was
"vanilla" Laxen & Perry, and one of our customers had an application
which didn't work because he was presuming that the number conversion
side effects (DPL, etc.) would be consistent for all numbers. Since
then, we have added more constants to the kernel in ROM, but they are
all headerless.
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/15/90)
Date: 03-12-90 (02:24) Number: 3026 (Echo) To: R.BERKEY [ROBERT] Refer#: NONE From: CHRIS WATERS Read: NO Subj: VOCABULARIES Status: PUBLIC MESSAGE > > A warning is in order here. polyFORTH defined 0 and 1 as constants > > for years. Recently, however, we implemented a way to revector the > > number conversion and interpetation process. Under this system, it > > is occasionally neccessary for 0 and 1 to pass through the number > > conversion process. Then, defining numbers as constants can get you > > into a lot of trouble. ... > >I've had problems with interpretable numeral constants, too, using F-P One possible solution to this type of problem might be to create a new data type for numeric constants. This data type could be revectored along with the numeric input routines. This would allow you to gain the speed and compactness of constants while keeping the flexability of the vectored numeric input. Of course, this would add another data type to the nucleus, and the data type would have to be used correctly. This could be a problem if numbers were redefined in an application (though it sounds like that might be a problem anyway). This brings up issues of training and ghod knows what all else. I suppose it would depend on exactly what you were doing with the numeric input. I don't know if this is any help. I haven't tried it yet; I can't think of an application where you wouldn't be better off just re-vectoring ALL the constants, but I can certainly believe that there is one. If you could, I'd like some more details about why you have problems with these constants. It can't be something as simple as multiple stacks or floating point, can it? I'm just curious why there isn't a easier solution to this. NET/Mail : The Snake Pit - 408-287-2353 - San Jose, CA - Home of ProBBS ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/16/90)
Category 3, Topic 18 Message 6 Thu Mar 15, 1990 D.RUFFER [Dennis] at 01:53 EST RE: CHRIS WATERS > If you could, I'd like some more details about why you have > problems with these constants. I wasn't at Forth, Inc. (or at least not locally) when the problem came up, but from what I know, it has to do with resetting the flags that tells LITERAL what type of number was just interpreted. In our case, we allow LITERAL to be vectored as well as NUMBER. Thus when you add a new number type, such as floating point, LITERAL can still be used to compile them into a definition. Since NUMBER is the only thing that knows what the number was, it sets the flag. It becomes essential that all numbers go through the process since new flags may be added with new number converters. You may even need to use the flags further down the line, so LITERAL can not just reset them. Also, since LITERAL is used in the compiler (]) it sometimes needs to be revectored on the fly to know how to compile a number that appears right in a definition. I just looked at how pF handles floating point numbers. NUMBER is revectored to scan for a decimal point followed by a non-blank character. When a number such as this is encountered, LITERAL is revectored to another vector which can handle either 32 or 64 bit real numbers. Otherwise, the system number conversion is used which vectors LITERAL back to its default behaviour, which may have been revectored by the user. Adding the support to handle this complexity would be too involved for CONSTANT. We don't want the user to have to change too many vectors just to add a number type. NUMBER and LITERAL are essential, and sufficient to solve the problem. Besides, any overhead that they incure would only be at compile time or when interpreting user input where execution time is not critical. Adding support for this to CONSTANT would incure run time overhead, which in the case of real-time applications, can be very critical. DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/19/90)
Category 3, Topic 18 Message 7 Sun Mar 18, 1990 R.BERKEY [Robert] at 04:44 PST Re: Constant Numerals Chris Waters writes, 900312: > If you could, I'd like some more details about why you have > problems with these constants. It was involved with a colon-definition structure that contains a table of numbers. In order to allow comments in the table, the compiler/interpreter that created the table first searched the dictionary, and the search needed to fail to correctly compile the number. To complicate things, that particular implementation is gone. There's now an INTERPRETERS vocabulary that contains, among others, the ( and \ words. That vocabulary is used to advance the input stream pointer over the comments. So I may not currently need NUMERALS . > It can't be something as simple as multiple stacks or floating > point, can it? I'm just curious why there isn't an easier > solution to this. The NUMERALS implementation can be simple. It adds one vocabulary to the compiler search order, without affecting the normal search order. An essential element is a word that searches a single vocabulary. As an example, the following code adds ['] NUMERALS ACQUIRE to the guts of a colon compiler. Both the inputs and the outputs of ACQUIRE are the same as the outputs from FIND . #SP WORD FIND ( a1 false | compilation-token flag ) ['] NUMERALS ACQUIRE \ if the flag is non-zero, the search is \ bypassed. Otherwise, search NUMERALS for \ the string at a1. Outputs are the same as \ FIND ?DUP IF 0> IF EXECUTE ELSE X, THEN ELSE NUMBER DOUBLE? IF [COMPILE] DLITERAL ELSE DROP [COMPILE] LITERAL THEN THEN Chris, It looks as if you're right around the corner, relative to ForthNet land. I can be reached in Fremont at (415) 659-1334 x352. Robert ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/21/90)
Date: 03-18-90 (09:38) Number: 3045 (Echo) To: CHRIS WATERS Refer#: NONE From: STEVE WHEELER Read: NO Subj: CONSTANT PROBLEMS Status: PUBLIC MESSAGE > If you could, I'd like some more details about why you have problems >with these constants. It can't be something as simple as multiple >stacks or floating point, can it? I'm just curious why there isn't a >easier solution to this. The problem arises when you want to make use of some of the "side effects" of number entry, such as using the value in DPL for a scaling factor. If you have, say, 0 through 4 defined as constants, then when you enter one of those numbers, DPL will contain the value produced by the PREVIOUS non-constant number. Although you can work around it in several ways, such as changing (and slowing down) the run-time operation of CONSTANT. I felt the problem was significant enough to make any constants in the kernel headerless. It certainly makes the Forth system easier to explain to customers. ("Well, you can do this except with 3, 5, and 12 on alternate Thursdays during leap years with interrupts disabled, etc.") NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth! ----- This message came from GEnie via willett through a semi-automated process. Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/23/90)
Date: 03-18-90 (00:04) Number: 3055 (Echo)
To: DENNIS RUFFER Refer#: 3030
From: CHRIS WATERS Read: NO
Subj: VOCABULARIES Status: PUBLIC MESSAGE
DR(what type of number was just interpreted. In our case, we allow LITE
DR(vectored as well as NUMBER. Thus when you add a new number type, suc
DR(floating point, LITERAL can still be used to compile them into a defi
DR(Adding support for this to CONSTANT would incure run time overhead, w
DR(the case of real-time applications, can be very critical.
Well, my original question had to do with why constants such as 0
and 1 would cause problems with re-vectored number interpreters. The
"it's-there-but-you-can't-use-it" technique of hiding these these
constants by removing their headers seems extremely un-forth-like to
me. It should be the system's job to provide tools, and the
application's responsibility to protect the user from those tools. :)
Extending the syntax understood by NUMBER is very useful, but
changing the default syntax strikes me as extremely dangerous. If I
enter '20' and the interpreter does not return the single precision
value 20 to the stack, I'm going to be in serious trouble the first
time I enter 'PAD 20 ERASE.' If FORTH is not in the search path, this
is not a problem, but constants such as 0 should be in the Forth
vocabulary anyway.
I do not think that the small class of applications that conflict
with these limitations should penalize all other applications. No one
has said that they have removed these constants to avoid data-type
conflicts. Removing their heads seems to be the preferred method.
This would indicate to me that these constants are useful. Useful
enough to make available. I often use conditional interpreting to
include some of these constants in my applications if they are not
already defined.
Chris
-> MegaMail(tm) #0:he used to cut the grass, he was a very nice boy
1.12
NET/Mail : The Snake Pit - 408-287-2353 - San Jose, CA - Home of ProBBS
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/23/90)
Date: 03-18-90 (00:36) Number: 3056 (Echo)
To: STEVE WHEELER Refer#: NONE
From: CHRIS WATERS Read: NO
Subj: HEADLESS CONSTANTS Status: PUBLIC MESSAGE
SW( >A warning is in order here.
SW( I agree. A few years ago, the Forth we offered our customers was
SW( "vanilla" Laxen & Perry, and one of our customers had an application
SW( which didn't work because he was presuming that the number conversio
SW( side effects (DPL, etc.) would be consistent for all numbers. Since
SW( then, we have added more constants to the kernel in ROM, but they ar
SW( all headerless.
Hmm, seems like a "cutting off your nose..." type of response.
After all, the customer made what was, at the time, an invalid
assumption. And his application will still fail if run on many other
Forth systems, or even if someone defines a new numeric constant at
his site and his application references it. He should find another
solution, such as setting default values for the flags before
attempting number conversion. Then you could provide all the
constants you wanted in the kernel, and they could be used in other
applications. ;-)
Chris
-> MegaMail(tm) #0:the plural of paradox is paradise
1.12
NET/Mail : The Snake Pit - 408-287-2353 - San Jose, CA - Home of ProBBS
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/23/90)
Date: 03-21-90 (01:09) Number: 3057 (Echo)
To: ALL Refer#: NONE
From: CHRIS WATERS Read: (N/A)
Subj: VOCABULARYS/CONSTANTS Status: PUBLIC MESSAGE
re: R.Berkey to all, re: Chris Waters
RB( CW> If you could, I'd like some more details about why you have
RB( CW>problems with these constants.
RB( ...
RB( To complicate things, that particular implementation is gone. There
RB( INTERPRETERS vocabulary that contains, among others, the ( and \ wor
RB( vocabulary is used to advance the input stream pointer over the comm
Well, it sounds like you already did what I suggested in another
post: sidestep the problem by using vocabularies. It's nice to see
that at least some of my (admitted) speculation about this subject
has been borne out in the field. For your particular application,
have you considered trying the input as a number first, and then, if
that fails, searching the dictionary? (Probably too much work for a
simple data-structure definition, oh well...)
RB( The NUMERALS implementation can be simple. It adds one vocabulary t
RB( compiler search order, without affecting the normal search order. An
I jumped into this discussion purely from an instinctive sense
that anything that reacted badly to the _name_ of a constant, even
if that name _could_ be interpreted as a number, must be wrong. It
still seems like the kind of problem that might arise in a pascal-
to-forth port; very un-forthlike. I never thought that implementing
or supporting it would _difficult_... <grin>
My original suggestion of new data-types for the constants was
based on gross overestimation of what these problems might be. I am
glad that no such drastic solution seems to be needed.
I'd like to thank everyone for their interesting and informative
replies on this matter.
-> MegaMail(tm) #0:to be read while thinking of Maude
1.12
NET/Mail : The Snake Pit - 408-287-2353 - San Jose, CA - Home of ProBBS
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: 'uunet!willett!dwp' or 'willett!dwp@gateway.sei.cmu.edu'wmb@MITCH.ENG.SUN.COM (08/03/90)
> I'm curious if anyone knows of a system that does these things > [enumerating words in vocabulary, save/restore search order, > remove single word from vocabulary, search just one vocabulary]? Sure, my system does all these things. I'm sure there must be many others that do at least some of them. I have seen (non-portable, of course) code fragments for doing some of these things on particular systems in published code. > Would it still be Forth as we know it? Sure. Adding these capabilities doesn't detract from what is already there, unless "Forth as we know it" implies "missing obvious functionality" > Are vocabularies *really* part of Forth, or something that is added on > on top of it? I claim yes, based on the fact that nearly all Forth systems have them in some form or other. Unfortunately, there is very little consistency among implementations in this area. Mitch
dwp@willett.UUCP (Doug Philips) (08/07/90)
[Questions are "aimed" at Mr. Bradley only as a "stylistic" device, so please feel free to reply. -dwp] In <9008031606.AA06458@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM writes: > Sure. Adding these capabilities doesn't detract from what is already > there, unless "Forth as we know it" implies "missing obvious functionality" Hmm. If you started grafting postscript's "def" and other "true postfixness" on top of Forth, would you still call it Forth? Could you "have the best of both worlds" that way? (Not intended as a rhetorical question.) > I claim yes, based on the fact that nearly all Forth systems have them > in some form or other. Unfortunately, there is very little consistency > among implementations in this area. Given that diversity, I'm prompted to ask: Why? Is the diversity due to (more than one answer is OK): A) Different needs shaping different implementations B) Vocabularies are a not yet well understood part of Forth, so that the different implementations are more of the nature of experiments? C) Due to the independent nature of Forth programmers: "Oh, I can do it better *my* way" (1/2 :-) D) ??? (Fill in the blank here if you chose this answer). I'm not familiar with many Forth implementations, so I'll put this out to those that are: Is there some underlying commonality that can be factored "out of" the existing vocabulary implementations, such that each may be "rebuilt" from those more primitive words? I don't mean to imply that every hare-brained vocabulary definition must be considered, but I would hope that most of the "high-use as defined by number of users" implementations would be. -Doug --- Preferred: willett!dwp@hobbes.cert.sei.cmu.edu OR ...!sei!willett!dwp Daily: ...!{uunet,nfsun}!willett!dwp [in a pinch: dwp@vega.fac.cs.cmu.edu]
ForthNet@willett.UUCP (ForthNet articles from GEnie) (08/07/90)
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
UNBCIC@BRFAPESP.BITNET (08/07/90)
Doug, what about the ONLY ALSO concept. You can search in just
one vocabulary with SEAL. You can choose the search order with ONLY and
ALSO. You can possibly save the search order with PREVIOUS (fetching
CONTEXT). And it's an proposal for 83 Standard (well, it is in the
description of the 83 Standard I have).
(8-DCS)
--------------------------------------------------------------------
DCS@CIC.UNB.ANDF.BR (8-DCS)
UNBCIC@BRFAPESP.BITNET Daniel C. Sobral
Don't Panic!
- The Hitchhikers Guide to the Galaxy
(by Douglas Adams)ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/10/90)
Date: 08-05-90 (03:17) Number: 3613
To: ALL Refer#: NONE
From: BRAD PEPERS Read: HAS REPLIES
Subj: LATEST Status: PUBLIC MESSAGE
What is the 'proper' defn of LATEST?
1) : LATEST CONTEXT @ @ ;
or 2) : LATEST CURRENT @ @ ;
I would think it to be (2) since CURRENT is the dictionary where the
last word was likely entered. But in Object-Oriented Forth (by Dick
Pountain) he says (1) is the defn of LATEST. What gives?
Brad Pepers
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.uswmb@MITCH.ENG.SUN.COM (08/10/90)
> Doug, what about the ONLY ALSO concept. You can search in just > one vocabulary with SEAL. You can choose the search order with ONLY and > ALSO. You can possibly save the search order with PREVIOUS (fetching > CONTEXT). And it's an proposal for 83 Standard (well, it is in the > description of the 83 Standard I have). ALSO/ONLY is a step in the right direction, but: a) A lot of systems don't implement it. b) There are two different definitions for SEAL - one definition removes all occurrences of the ONLY vocabulary from the search order, and the other definition removes everything except the CONTEXT vocabulary. c) PREVIOUS is not mentioned in the 83 Standard. F83 has it, but that doesn't make it standard. d) Fetching CONTEXT is problematical because you don't know what is in it. In particular, in polyFORTH, the variable CONTEXT contains a *list* of vocabularies, each encoded as 4 bits (I think). Thus, fetching and storing CONTEXT can change more than just the first vocabulary in the search order. The ANS standard addresses these problems as follows: a) by standardizing a search order wordset (Forth 83 just "suggested it" as an experimental proposal. People then took the liberty of twiddling the semantics of SEAL, for instance). b) by changing the name SEAL to ISOLATE and giving it exactly one meaning (which is the same as one of the definitions of SEAL but I forget which) c) by including PREVIOUS in the standard search order wordset. d) by eliminating CONTEXT from the standard (since we eventually determined that there was absolutely nothing that a program can do with it and hope to remain portable; you can still use it if your system has it, but don't fool yourself into thinking such use is portable). Elimination of CONTEXT unfortunately leaves a hole, in that you can't save and restore the search order. Note that the ANS standard didn't create this hole; it was already there because there isn't a portable way to save the search order right now. The committee just hasn't seen fit to fill the existing hole. Mitch
wmb@MITCH.ENG.SUN.COM (08/10/90)
> What is the 'proper' defn of LATEST? > > 1) : LATEST CONTEXT @ @ ; > or 2) : LATEST CURRENT @ @ ; 2, definitely. Otherwise you could screw up royally by typing, for instance: : FOO [ ASSEMBLER ] SWAP ; In F83, there is a separate variable LAST that remembers the most recent word. This is necessary because F83 implements "smudging" by unlinking the word from the vocabulary thread while it is being defined, and hooking it back in when the definition is complete. Actually, my personal belief is that there should not be a separate CURRENT vocabulary. Definitions should go into the first vocabulary in the search order. But we've already had that discussion... Mitch
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/16/90)
Category 18, Topic 92 Message 17 Tue Aug 14, 1990 W.FEDERICI at 20:47 PDT I am constantly surprised that in all these prefix/postfix debates, no one seems to point out that Forth's CREATE is really not a prefix operator -- rather, it is a function which parses a name from the current input stream, where ever that may be. This is a hairsplitting distinction, and one which probably wouldn't occur to users of conventional languages whose compiler isn't a "distributed process", but I believe its neglect is a primary reason that beginners have problems with CREATE...DOES> defining words. . Seen in this light, the arguments for a "postfix" CREATE ( or colon, or VARIABLE or...) are simply another case of deciding how to factor a function -- do we want to separate the name-parsing from the definition-creation? I'm sure most of us have encountered cases where we need this factoring. (I'm still comfortable with the normal Forth syntax for normal circumstances.) . - Wilson ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
dwp@willett.pgh.pa.us (Doug Philips) (08/16/90)
In <1529.UUL1.3#5129@willett.pgh.pa.us>, W.FEDERICI writes: > I am constantly surprised that in all these prefix/postfix debates, no one > seems to point out that Forth's CREATE is really not a prefix operator -- > rather, it is a function which parses a name from the current input stream, > where ever that may be. This is a hairsplitting distinction, and one which > probably wouldn't occur to users of conventional languages whose compiler > isn't a "distributed process", but I believe its neglect is a primary reason > that beginners have problems with CREATE...DOES> defining words. I see where you are coming from, I think. The classification of prefix postfix doesn't have to do with a strict ordering of source code words. Just because you can bury CREATE inside a colon definition and execute it later has nothing to do with whether or not it is "prefix". CREATE is prefix because it does *not* take an argument on the stack. CREATE is prefix because it cosumes INPUT after it starts executing. CREATE or words that have CREATE compiled in to them violate the idea that Forth is a series of words that are executed in turn. The idea that the sequence: FOO BAR BAZ BLETCH results in executing the code for FOO followed by executing the code for BAR, etc... breaks down when in fact BAR contains a CREATE and results in BAZ not being executed but rather being "quoted" by BAR. If BAR is appropriately spelled, it *may* be obvious that it is quoting the next word. That doesn't change the "prefix" nature of CREATE. > Seen in this light, the arguments for a "postfix" CREATE ( or colon, or > VARIABLE or...) are simply another case of deciding how to factor a function -- > do we want to separate the name-parsing from the definition-creation? I'm > sure most of us have encountered cases where we need this factoring. (I'm > still comfortable with the normal Forth syntax for normal circumstances.) This is precisely the issue. Are the non-postfix Forth words built from reusable components or not? Considering the fanatical factoring in Forth, one wonders why some words are so poorly factored. I guess CM is merely a genius and not a diety. :-) :-). (BTW: Just because Forth has traditionally been filled with mixed-fixed words doesn't mean it can't grow into a more cleanly factored language which contains both the old style prefix words *and* the components that such words are built from. I'm still not clear on how much you can bend Forth and still call it Forth. Fig-Forth, Forth-79, Forth-83. Perhaps in the end it is merely the philosophy which allows you to call the language Forth. But this is really a different topic). -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]
sabbagh@acf5.NYU.EDU (sabbagh) (08/19/90)
In article <1530.UUL1.3#5129@willett.pgh.pa.us> dwp@willett.pgh.pa.us (Doug Philips) writes: >(BTW: Just because Forth has traditionally been filled with mixed-fixed >words doesn't mean it can't grow into a more cleanly factored language >which contains both the old style prefix words *and* the components that >such words are built from. I'm still not clear on how much you can bend >Forth and still call it Forth. Fig-Forth, Forth-79, Forth-83. Perhaps >in the end it is merely the philosophy which allows you to call the >language Forth. But this is really a different topic). > Time for my $0.02 1) Poorly factored CREATE This is one of my all-time gripes about Forth. I think that the reason this wasn't factored properly from the beginning is that strings were added to Forth AFTER its original inception. (Aside: most of the discussions about Forth ignore its history, which I believe to be very important in understanding why a language is the way it is). CREATE (and other words) can be easily refactored as "take next word from input stream then invoke $CREATE" which takes a string argument. THis means that strings would have to be standardized. (Are you listening ANSI dudes?). 2) Mixed-fixed I do not have any problems with the mixed-fixed nature of Forth; for those who are real purists, check out Postscript which is an entirely postfix language. It uses the concept of anonymous code blocks delimited by {} then {...(code)...} /foo def would define a new word named foo. This works too, but I like Forth better. 3) A modest proposal for vocabularies (ANSI dudes out there?) 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. 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"
dwp@willett.pgh.pa.us (Doug Philips) (08/20/90)
In <1219@acf5.NYU.EDU>, sabbagh@acf5.NYU.EDU (sabbagh) writes: > CREATE (and other words) can be easily refactored as "take next word from > input stream then invoke $CREATE" which takes a string argument. THis > means that strings would have to be standardized. (Are you listening > ANSI dudes?). Agreed! HERE! HERE! :-) Does it have sufficient existing practice? I suspect not. :-( :-( > I do not have any problems with the mixed-fixed nature of Forth; for those > who are real purists, check out Postscript which is an entirely postfix > language. It uses the concept of anonymous code blocks delimited by {} then > > {...(code)...} /foo def > > would define a new word named foo. This works too, but I like Forth better. I would agree if the mixed-fixed parts of Forth were actually built from accessible post-fix forms, as in your CREATE $CREATE example. I don't think I'd want to write code in the postscript style (i'm not sure of course, not having tried it), but I would certainly like to be able to write code that itself writes code, and that would be much easier with the $CREATE form. > 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. -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]
sabbagh@acf5.NYU.EDU (sabbagh) (08/22/90)
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"
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/23/90)
Category 18, Topic 92 Message 27 Tue Aug 21, 1990 W.FEDERICI at 20:04 PDT I don't think we have any disagreement here, but I really do feel the need to make the distinction between "generating an argument by scanning the current input stream" and "always preceding the argument". Both are "prefix", but they aren't quite the same thing. . I certainly agree with your postscript about being able to add new, useful factorings while maintaining current practice. I find the current colon and CREATE work well just as they are, and I also want some functions to build dictionary entries from arbitrarily generated strings. . - Wilson ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
dwp@willett.pgh.pa.us (Doug Philips) (08/24/90)
In <1579.UUL1.3#5129@willett.pgh.pa.us>, W.FEDERICI writes: > I don't think we have any disagreement here, but I really do > feel the need to make the distinction between "generating an > argument by scanning the current input stream" and "always > preceding the argument". Both are "prefix", but they aren't > quite the same thing. I'm not sure what you mean by "always preceding the argument". Could you give an example that doesn't fall into the first category? i.e. Where would the argument come from if not the input stream and yet still be "prefix"? -Doug --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu] --- Preferred: ( dwp@willett.pgh.pa.us OR ...!{sei,pitt}!willett!dwp ) Daily: ...!{uunet,nfsun}!willett!dwp [last resort: dwp@vega.fac.cs.cmu.edu]
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/30/90)
Category 18, Topic 92 Message 41 Wed Aug 29, 1990 D.RUFFER [Dennis] at 01:24 EDT Re: ir230@sdcc6.ucsd.edu (john wavrik) > ARE USERS ALLOWED TO ASK QUESTIONS YET? Of course John! I don't see anyone telling you to stop, nor do I see anyone saying that your questions are stupid. What I do see is some honest attempts to answer some very difficult questions. In some cases, the answers are not what you want to hear, but they are answers none the less. > "Can I (or how will I be able to) do in the proposed > Standard what I currently do in my work now?" As we have said repeatedly, the answer is a definite maybe! The reason for the maybe is that you may have been using a technique on your Forth that is not possible on some other architecture. For example setting SP0 to increase the return stack depth just is not possible when the return stack is implemented in hardware such as on most Forth CPUs. Thus, some other mechanism must be provided. On those machines, it is not possible to address into the return stack so the best that the standard can do is allow you to find out how big it is. To do more would prevent those systems from complying with the standard. > Vectored execution is essentially the only mechanism we have in > Forth for changing the action of pre-defined works. Your point is well understood John, but the point is that a line has to be drawn somewhere on how many words the standard will contain. The TC has choosen to draw that line at those things that can not be implemented using standard words. Vectored execution just does not fall into that category. > NO the vendors have not agreed on a mechanism for vectoring > the basic system words (i.e. redirection of output, error > trapping, etc. will not be portable). You are drawing conclusions here that are not based in fact. All that has been stated is that the TC has choosen not to specify how some of the internals of a Forth system must work. The redirection of output goes along with a whole class of words dealing with displays and tasks that is being left out due to lack of concensus and time to establish it. Error trapping has been specified, although you will need to change the way you are used to dealing with it. > Dennis Ruffer's code will work (provided that POSTPOSE is > equivalent to ' , in all systems; and that one can move around in > the input stream by storing things in the variable >IN). POSTPONE is better because it works! I know many systems where ' , will not compile a word into a definition. Messing with Forth's compiler is not standard now, but with POSTPONE and EVALUATE we are a lot closer to portability than we have ever been before. > [All of the standard control structures in traditional Forth are > implemented by just this mechanism.] Not true! However, I'm sure the ones you are accustomed to working with have all worked the same. The point is that there are many ways to skin a cat. Just because you have done something one way all your life does not mean that is the only way to do it. You might be suprised how much easier it is when you kill the cat first. <crooked grin with front teeth missing> > What I was after is whether the proposed Standard has general > portable mechanisms for controlling compilation -- which can be > used to define control structures, for example. Again, I say, YES IT DOES! If the previous example where you got at least two acceptable solutions did not convince you, then PLEASE, hit us with another one. I, for one, would be glad to take a wack at solving another puzzle. > I feel somewhat embarrased at feeling obliged to explain in > detail why I asked my questions. I just thought it a natural and > normal thing to do at this stage of the game. Please don't feel a need to explain for my sake! I enjoy good arguments, er I mean discussions. :-) DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/30/90)
Category 18, Topic 92 Message 43 Wed Aug 29, 1990 R.BERKEY [Robert] at 06:00 PDT Subject: Custom Compilers Dennis Ruffer writes: > Re: ir230@sdcc6.ucsd.edu (john wavrik) > > What I was after is whether the proposed Standard has general > > portable mechanisms for controlling compilation -- which can be > > used to define control structures, for example. > > Again, I say, YES IT DOES! If the previous example where you > got at least two acceptable solutions did not convince you, then > PLEASE, hit us with another one. I, for one, would be glad to > take a wack at solving another puzzle. Perhaps my posting on Monday wasn't clear enough: > Category 3, Topic 45 > Message 2 Mon Aug 27, 1990 > R.BERKEY [Robert] at 21:39 PDT > > > > This is to be used in the form IF( c1 e1 ... ck ek )IF > > The solutions given to this problem depend on the source code being on one > line. Let's pretty print it: > > This is to be used in the form: > > IF( > c1 e1 > ... > ck ek > )IF > > Now what? The point is that the solutions offered are only valid if the source code is on one line, such as the specific formulation proposed as the problem. Note that John Wavrik's original requirement included more than one line of source code: > From: ir230@sdcc6.ucsd.edu (john wavrik) > Newsgroups: comp.lang.forth > Subject: Domain of Forth > Keywords: algorithms permutations Baden > Message-ID: <12353@sdcc6.ucsd.edu> > Date: 21 Aug 90 05:00:06 GMT > Organization: University of California, San Diego > The state of the system is given by the position (0 < pos <= 2n) > within the cycle. The position must be maintained for each n. Here > is the code for the required function: > > : Perm ( n -- t ) DUP 2 = \ terminal condition > IF DROP 1 > ELSE DUP Next-Pos ( n pos ) > If( <n? Ascending > =n? p(n-1) > <2n? Descending > true p(n-1)+1 )If > THEN ; > > Where, of course, we must explain the meaning of a few words 8-) So, no. None of the posted solutions work. At least to the problem for which a solution was sought. Another closely related issue is whether comments are to be allowed within the range of the custom compiler. Robert ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/31/90)
Category 18, Topic 92 Message 44 Thu Aug 30, 1990 D.RUFFER [Dennis] at 00:28 EDT Re: R.BERKEY [Robert] > IF( > c1 e1 > ... > ck ek > )IF > So, no. None of the posted solutions work. At least to the > problem for which a solution was sought. > Another closely related issue is whether comments are to be > allowed within the range of the custom compiler. I believe I could solve the multiple line problem easily (if it isn't already solved by using blocks), but adding comments does invalidate both Mitch's and my solutions (not to mention invalidating John's original solution). So, we just need to think about it a little more closely. (no one said it was going to be easy :-). What we really have here is a case statement and the "problem" is that John has typically written it without including "markers" to separate the cases. This organization makes it essentually impossible to put anything between the start of the case statements and the end except pairs of logical tests and execution phrases. The fact remains that John's code allows multiple lines and excludes intervening comments. Therefore I contend that my solution works just as well as his version, and Mitch's is probably also correct. However, since you have added an additional requirement to the problem, I will suggest an alternate solution. Even if I were to solve the problem without adhearing to the ANS Standard, I really don't see any way to add comments without adding in the missing markers. So, if you don't mind, I will change the format to allow the requirements to be satisfied. Here is the new format that I will try to implement CASE( ... OF ... ELSE ... OF ... ELSE . . . ... )CASE Now, without even looking at all the ways case statements have been implemented before, here is a way that will work within the standard: VARIABLE #CASES : CASE( 0 #CASES ! ; IMMEDIATE : )CASE BEGIN #CASES @ WHILE POSTPONE THEN -1 #CASES +! REPEAT ; IMMEDIATE : OF 1 #CASES +! POSTPONE IF ; IMMEDIATE Now, ain't that easy enough? Of course, there is the multi-user implications with using a variable to count the cases, but that can be easily solved by making the variable a stack. That would even allow nesting the case structures. Although this solution to John's problem does not look as "pretty", the added functionality more than makes up for the the loss of asthetics. Here is how John's original problem would look: : Perm ( n -- t ) DUP 2 = \ terminal condition IF DROP 1 ELSE DUP Next-Pos ( n pos ) CASE( <n? OF Ascending ELSE =n? OF p(n-1) ELSE <2n? OF Descending ELSE true OF p(n-1)+1 )CASE THEN ; Of course, I should also mention the range problems that are inherant with the "embedded IF" method on some Forths (16 bit polyFORTH for one), but the ANS Stanadard hasn't touched that problem so I will ignore it also. <grin> Now, can I say again, YES IT DOES! DaR ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (09/03/90)
Category 18, Topic 92 Message 45 Thu Aug 30, 1990 W.FEDERICI at 21:10 PDT . Consider typing the following two lines into your Forth system: . . create new-word 0 , . : word-maker create 0 , ; . . Since CREATE is a prefix operator, we can clearly see that, in the . first line, the parameter of create is "new-word", and in the . second line the parameter is " 0" -- right? . Now, I know we can construct long explanations why CREATE . "behaves differently" in these two cases, but I think . shorter explanations result if we keep in mind that CREATE . actually reads the input stream. Operators in conventional . languages don't do this -- the compiler does it for them, which . is why we can write things in 'C' like . int /* strangely placed comment */ myint . yet we don't expect Forth to accept . create ( 'nother comment ) my-word . . ( I'm beginning to regret my offhand comment that started this, . because I have ended up making lengthy commentary on something . that seems to me almost trivial -- that Forth just isn't a . conventional language and that discussing it in conventional . terms can mislead. Forth's "distributed compiler", for lack of . a better term, is rather an oddity amongst languages, and it . determines several of the strengths and weaknesses of the . Forth approach. ) . . - Wilson ----- This message came from GEnie via willett through a semi-automated process. Report problems to: uunet!willett!dwp or dwp@willett.pgh.pa.us
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/21/90)
To: RAY DUNCAN Refer#: NONE From: CHARLES WILSON Read: 10-17-90 (08:45) Subj: QUICK&DIRTY SCREEN EDITOR Status: PUBLIC MESSAGE Do you know of any FORTH source code for a relatively simple text screen editor? Looking to port an application to UR/FORTH which used a screen editor designed for word processing (but was very complex, and far exceeded my requirements). Hoping that I can save a week or two if some source code exists already. If no such thing available, do you know of a `small' screen editor that could be run from a SHELL command that will use less than 100K? NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/21/90)
To: CHARLES WILSON Refer#: 1773 From: RAY DUNCAN Read: NO Subj: QUICK&DIRTY SCREEN EDITOR Status: PUBLIC MESSAGE 1. I think Tom Zimmer's F-PC has a text file editor written in Forth. I've been thinking about writing one for LMI Forths but haven't gotten around to it. 2. If you are looking for a tiny text editor that could be run from a SHELL" command, I recommend VDE153.ZIP in directory #20. I use this on my portable, it's small and very fast. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 ----- This message came from GEnie via willett through a semi-automated process. Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwp
wmb@MITCH.ENG.SUN.COM (11/05/90)
> If the semantic difference between VOCABULARYs is sufficient to break > code, then the semantic difference between WORDSET and VOCABULARY is > likewise sufficient, and you can't fix it with a global search > and replace. > Or was it your intention to have each transitional system implement two > different vocabulary mechanisms? There are 3 cases to consider: 1) A system where the semantics of that system's VOCABULARY are the same as WORDSET . Examples: F83 , F-PC Resolution: : VOCABULARY WORDSET ; and everybody is happy. Old code still works, new code can use WORDSET and be portable. Or do the global search-and-replace. 2) A system where the semantics of VOCABULARY are different from WORDSET . Examples: FIG-Forth, MVP-FORTH, MAC Forth, LMI Forth, polyFORTH. Resolution: The system vendor will support both VOCABULARY , meaning whatever it has always meant on that system, and also WORDSET , meaning what ANS Forth says it means. Customers will not revolt, because their old code will still work, and they can migrate to the portable use of WORDSET as desired. 3) Brand-new systems, with no installed base: Resolution: Implement WORDSET . If compatibility with some existing system is needed, for marketing reasons or whatever, implement VOCABULARY to be compatible with the desired system. With WORDSET , most people lose a little bit (i.e. they have to learn a new word, or a modest amount of memory is wasted). If VOCABULARY was chosen, some people wouldn't lose at all, and others would lose a lot (i.e. either their system vendor would choose not to implement ANS Forth for fear of alienating his existing customers, or their programs would break in hard-to-isolate ways). Mitch