ForthNet@willett.UUCP (ForthNet articles from GEnie) (02/28/90)
Date: 02-26-90 (10:45) Number: 2968 (Echo) To: L.ZETTEL Refer#: 2928 From: PETE KOZIAR Read: NO Subj: LIBRARIES Status: PUBLIC MESSAGE I agree -- the control systems that we have in place here all compile themselves upon start-up. It only takes a minute or two for a large system. Another approach, if the system allows saving itself, is to load in the "libraries" that you would need, then save the system at that point and do your development with the saved system. --- * Via Qwikmail 2.01 The Baltimore Sun ----- 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.pgh.pa.us (ForthNet articles from GEnie) (10/05/90)
Date: 09-21-90 (12:02) Number: 3814 (Echo) To: CHARLIE HITSELBERGER Refer#: 3809 From: PETE KOZIAR Read: 09-21-90 (12:09) Subj: HASHED VOCABULARIES Status: PUBLIC MESSAGE F83 and its derivatives use hashing to separate the dictionary into multiple threads based on hash key. The hashing used in what I'm familiar with is sum of the ASCII of the characters mod something. I've also seen first character plus lenngth, I believe. --- * Via Qwikmail 2.01 The Baltimore Sun ----- 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/05/90)
Date: 09-24-90 (16:31) Number: 3858 (Echo) To: CHARLIE HITSELBERGER Refer#: NONE From: IAN WATTERS Read: 09-27-90 (12:24) Subj: HASHING THE DICTIONARY Status: PUBLIC MESSAGE CHpAnyway, I was thinking of doing something major league to the dictionary. CHpThe bigger the dictionary gets, the longer the average search takes. CHpThis slows down compiles. What if the FIND word were to Xor together CHpall of the bytes of the word being searched for, then Xor the two CHpnybbles of that, to get out a four-bit hash key. Then it starts in that CHp"thread" and searches backwards. The hashing algorithm is very simple CHpand could be easily implemented as a code word. Anybody out there have CHpany thoughts on this? Many Forths have hashed dictionaries. The one I wrote for a CP/M machine used 16 threads too, but a much simpler hashing function (length of string XOR first character from memory). I wanted to use words like $____, so that limited me to these two and I tried as many functions as I could until I found one that gave the most even distribution of results with the kernel and sample applications. You really notice the improvement in compile speed, especially if you don't use the fig-Forth directory structure. Ian --- ~ EZ 1.33 ~ I've a wonderful tagline, but this isn't it! PCRelay:IBBSNET -> #143 RelayNet (tm) 4.10a15 <Islington BBS> London UK +44 71 704 0760 NET/Mail : DC Information Exchange, MetroLink Int'l Hub. (202)433-6639 ----- 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/05/90)
Date: 09-27-90 (12:24) Number: 3860 (Echo)
To: IAN WATTERS Refer#: 3858
From: CHARLIE HITSELBERGER Read: NO
Subj: HASHING THE DICTIONARY Status: PUBLIC MESSAGE
Here's my function to hash the dictionary. It's go [garbage in
message elided. -dwp]
eal thing, but for all you deprived souls without a 6502, here's
the high-level def.
: HASH ( ADDR -- N ; assume a counted string address )
0 OVER C@ 127 AND 1+ 0
DO
OVER I +
C@ XOR
LOOP
SWAP DROP
16 /MOD XOR ;
Now, for my next trick, I'll create a table of 16 words at the very
bottom of the dictionary. These words will point to the last word in
the dictionary for that particular hash-thread. All hash threads will
wind up by pointing to the lowest word in the dictionary, which in turn
will link to a "0000" (end of linked list). I figured that was cleaner
to link everything into one tail, rather than to have 16 vocabulary
tails. Please, somebody, stop me if I am a fool. I have never rolled a
compiler before, and I go to sleep every night with the nagging feeling
that somehow I am really messing this up and will regret it later.
-----
This message came from GEnie via willett through a semi-automated process.
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/05/90)
Date: 09-27-90 (08:57) Number: 3865 (Echo) To: IAN WATTERS Refer#: NONE From: JONAH THOMAS Read: NO Subj: HASHING THE DICTIONARY Status: PUBLIC MESSAGE -> CH"thread" and searches backwards. The hashing algorithm is very -> simple and could be easily implemented as a code word. Anybody out -> there have any thoughts on this? -> Many Forths have hashed dictionaries. The one I wrote for a CP/M -> machine used 16 threads too, but a much simpler hashing function I wondered about using a binary tree for the dictionary structure. You could do a string comparison to get each place in the tree. With N words in the dictionary, you'd average log2 (N) misses before the hit. It would take double the space for the links, though, in a 16 bit Forth that would be 4N bytes instead of 2N bytes. It looked like it would be really fast, but I never actually tried it, my projects aren't big enough to worry about compile time, and if it starts looking like a problem I save a version of the system with the modules that are debugged already included. --- ~ NET/Mail : The MATRIX (5 Nodes/1.2 Gig) Birmingham, AL (205) 323-2016 ~ RNet 1.05M:* Metrolink - Front Porch BBS 404-695-1889 HST -Regional HUB ----- 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/05/90)
Date: 10-01-90 (11:34) Number: 3946 (Echo) To: JONAH THOMAS Refer#: 3865 From: RAY DUNCAN Read: NO Subj: HASHING THE DICTIONARY Status: PUBLIC MESSAGE LMI's UR/FORTH has had totally hashed dictionary for several years. We use a 4 KB hash table and chain the collisions. We have found that even with several thousand words in the dictionary, FIND only requires an average of <2 name comparisons. 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/15/90)
Date: 10-09-90 (09:26) Number: 4 of 10 To: RAY DUNCAN Refer#: NONE From: JONAH THOMAS Read: NO Subj: HASHING THE DICTIONARY Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) > use a 4 KB hash table and chain the collisions. We have found that > even with several thousand words in the dictionary, FIND only > requires an average of <2 name comparisons. OK! I was thinking about using a sort of binary tree and a comparison to cut the search time down to o[log2(n)] from o[n]. But it doubled the size of the links. With a 4K hash table you'd break even on size at about 2000 words, and it only gets better from there. With <2 comparisons you do better on time as soon as the dictionary gets big enough that a lot of string comparisons take longer than <2 hash compares. That might be fairly small. The only advantages left for the tree are the ease of thinking (which is a one-time thing) and re-use of the code (which is trivial). Thanks for stopping me before I actually wasted time getting it working! 8-) --- ~ NET/Mail : The MATRIX (5 Nodes/1.2 Gig) Birmingham, AL (205) 323-2016 ~ RNet 1.05M:* Metrolink - Front Porch BBS 404-695-1889 HST -Regional HUB PCRelay:DCINFO -> #16 MetroLink (tm) International Network 4.10 DC Info Exchange MetroLink International Hub ----- 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/16/90)
Date: 10-02-90 (18:55) Number: 3952 (Echo) To: JONAH THOMAS Refer#: NONE From: IAN WATTERS Read: NO Subj: HASHING THE DICTIONARY Status: PUBLIC MESSAGE JT-> I wondered about using a binary tree for the dictionary structure. Don't forget to have some way to distinguish between words with the same name in different vocabularies. I forgot to mention an XOR with the vocabulary number in my orginal post's hashing function... Blush! Ian --- ~ SLMR 1.0 ~ It's noisy next door. A Dr Herbert West lives there... PCRelay:IBBSNET -> #143 RelayNet (tm) 4.10a15 <Islington BBS> London UK +44 71 704 0760 NET/Mail : DC Information Exchange, MetroLink Int'l Hub. (202)433-6639 ----- 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)
Date: 10-09-90 (10:26) Number: 4037 (Echo) To: RAY DUNCAN Refer#: NONE From: JONAH THOMAS Read: NO Subj: HASHING THE DICTIONARY Status: PUBLIC MESSAGE > use a 4 KB hash table and chain the collisions. We have found that > even with several thousand words in the dictionary, FIND only > requires an average of <2 name comparisons. OK! I was thinking about using a sort of binary tree and a comparison to cut the search time down to o[log2(n)] from o[n]. But it doubled the size of the links. With a 4K hash table you'd break even on size at about 2000 words, and it only gets better from there. With <2 comparisons you do better on time as soon as the dictionary gets big enough that a lot of string comparisons take longer than <2 hash compares. That might be fairly small. The only advantages left for the tree are the ease of thinking (which is a one-time thing) and re-use of the code (which is trivial). Thanks for stopping me before I actually wasted time getting it working! 8-) --- ~ NET/Mail : The MATRIX (5 Nodes/1.2 Gig) Birmingham, AL (205) 323-2016 ~ RNet 1.05M:* Metrolink - Front Porch BBS 404-695-1889 HST -Regional HUB ----- 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)
Date: 10-13-90 (13:58) Number: 4048 (Echo) To: GARY SMITH Refer#: 4038 From: RAY DUNCAN Read: NO Subj: CONVENTIONS AND "TRICKS" Status: PUBLIC MESSAGE The hash-cache strategy that Mitch describes is quite effective. LMI has had this in its older-generation PC/FORTH, PC/FORTH+, and Z-80 FORTH products for about 5 years; Micromotion also had it in its last line of Forth-83 products before they disappeared. We found that we could just about double the compilation speed with a 256-slot hash cache. We got an additional 2-3X improvement in compilation speed when we went to the totally hashed dictionary in the newer UR/FORTH implementations. The biggest problem with the hash-cache approach is in interpreting numbers; you must probe the cache AND exhaustively search the linked dictionary before you can conclude that the token is a number and not a Forth "word." The completely hashed dictionary eliminates this problem. 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/25/90)
Date: 10-19-90 (10:08) Number: 4082 (Echo) To: RAY DUNCAN Refer#: 4048 From: ELLIOTT CHAPIN Read: NO Subj: CONVENTIONS AND "TRICKS" Status: PUBLIC MESSAGE RD>The biggest problem with the hash-cache approach is in interpreting RD>numbers; you must probe the cache AND exhaustively search the linked RD>dictionary before you can conclude that the token is a number and not a RD>Forth "word." The completely hashed dictionary eliminates this problem. I have wondered for a long time why one doesn't hear of checking for numbers before words. Elliott Chapin --- ~ DeLuxe} #4315 ~ PCRelay:CRS -> RelayNet (tm) 4.10a14 Canada Remote Systems * Toronto, Ontario ----- 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 (10/26/90)
> I have wondered for a long time why one doesn't hear of checking for > numbers before words. bad feed , dead beef bed babe ? dad faced a deaf cafe The point is that there is no syntactic way in Forth to distinguish a number from a word, given that the number input base can be hex. Checking for numbers first would remove some plausible words from the name space. In fact, the common word CFA , found in many pre-Forth-83 systems, parses as a valid hex number. Mitch Bradley, wmb@Eng.Sun.COM
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (10/27/90)
Date: 10-23-90 (15:05) Number: 4094 (Echo) To: RAY DUNCAN Refer#: NONE From: IAN WATTERS Read: NO Subj: CONVENTIONS AND "TRICKS" Status: PUBLIC MESSAGE =>RD> The completely hashed dictionary eliminates this problem. How easily does your system forget words? Removing items from hash tables tends to be messy... except when using linked lists for clashes. Do you end up with 1024 linked lists with a 2K hash table? / /\ /\/ --- ~ SLMR 1.0 ~ *** Note "address change" *** Islington RIP, viva OLEF! PCRelay:OLEF -> #181 RelayNet (tm) 4.10a15 The Node is OLEF, HUB is HUBOLEF1 in the UK NET/Mail : DC Information Exchange, MetroLink Int'l Hub. (202)433-6639 ----- 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/29/90)
To: IAN WATTERS Refer#: 4094 From: RAY DUNCAN Read: NO Subj: CONVENTIONS AND "TRICKS" Status: PUBLIC MESSAGE Forgetting is no problem. To FORGET a word, we find it via the hash table, truncate the header segment at that point (thereby also discarding all subsequently defined words), then rebuild the hash table from scratch. The routine which builds the hash table is all in assembler and very tightly coded, so the user never notices any delay after FORGET; the only other time you have to build the whole hash table is at boot, and that delay is hidden inside the Forth system's load time. Collisions are chained, but the chains tend to be very short; even with a couple thousand words in the dictionary, the average chain length is less than 2. In a way this is the extreme case of the multithreaded dictionary! 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
tom@garth.UUCP (Tom Granvold) (11/02/90)
In article <9010261354.AA01446@ucbvax.Berkeley.EDU> wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV writes: >> I have wondered for a long time why one doesn't hear of checking for >> numbers before words. examples removed. >The point is that there is no syntactic way in Forth to distinguish a number >from a word, given that the number input base can be hex. Checking for >numbers first would remove some plausible words from the name space. In >fact, the common word CFA , found in many pre-Forth-83 systems, parses as >a valid hex number. > >Mitch Bradley, wmb@Eng.Sun.COM Yes, but doesn't checking for words first remove some plausible values from the numbers that can be used :-) ------------------------------------------------------ Name: Tom Granvold Mail: 2400 Geng Rd., Palo Alto, Calif., 94303 UUCP: ucbvax!decvax!decwrl!pyramid!garth!tom ------------------------------------------------------
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (11/07/90)
Date: 11-05-90 (14:13) Number: 109 of 110 (Echo) To: JONAH THOMAS Refer#: 4 From: RAY DUNCAN Read: NO Subj: HASHING THE DICTIONARY Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) With a hash table the payoff is immediate; the code to hash the name being looked up, probe the hash table, and compare to the actual header is all in assembly language and very fast. This turns out to ALWAYS be more efficient than the traditional linear search of a linked dictionary, when the dictionary is of any USEFUL size. When the dictionary gets large, the difference in lookup speed is enormous, and you have the additional advantage that interpretation of numbers is also speeded up drastically --- FIND typically knows immediately (with a couple of probes of the hash table) that the token is not a Forth word, instead of being required to exhaustively compare the token against every name in the current search order before attempting conversion to a number. On the other hand, this kind of dictionary management doesn't lend itself to quick ports of the language or to ROMing; for these situations (where compilation speed is unimportant compared to the benefits of having a small, interactive system) we still use (or at least start with) the more traditional linked dictionary (sometimes adding a lookup cache later if we don't feel like going the whole distance to the hashed dictionary). <<<>>> ----- 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) (12/03/90)
Date: 11-28-90 (23:37) Number: 330 of 331 To: B.RODRIGUEZ2 [BRAD] Refer#: NONE From: JERRY SHIFRIN Read: NO Subj: ATARI ST PUBLIC DOMAIN L& Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) BB>(I'm implementing the BB>functions of SNOBOL under Forth.) Among other things, I'm planning to add BB>list processing a la Alexander Sakharov. You may want to check out Martin Tracy's nice set of list processing routines in the FIG model library ($40). Unless you're doing it for fun, it's probably worth the investment. --- ~ EZ 1.32 ~ ~ MetroLink: Data Bit NETWork * Alexandria, VA * (703) 719-9648 PCRelay:DCINFO -> #16 MetroLink (tm) International Network 4.10 DC Info Exchange MetroLink International Hub <<<>>> ----- 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) (12/03/90)
Category 3, Topic 1 Message 89 Sun Dec 02, 1990 B.RODRIGUEZ2 [Brad] at 10:56 EST > You may want to check out Martin Tracy's nice set of list > processing routines in the FIG model library ($40). Unless you're > doing it for fun... Thanks. I have 'em, but I've been slow to read 'em. Whereas Dr. Sakharov asked me to review his list processing article before publication, which pushed me over my "hump." I liked his word set. And yes, I am doing this for fun. - Brad ----- 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) (12/29/90)
Date: 12-26-90 (11:33) Number: 690 of 698
To: STEVE PALINCSAR Refer#: NONE
From: IAN WATTERS Read: NO
Subj: SHELLING TO DOS Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
SP] ^I keep reading about menuing systems that let you shell out while
] ^leaving only an 80-byte "tail" in memory so you can return to the
] ^calling program when the child finishes running. Does anybody have
] ^any idea exactly how this is done? Is it something that could be
] ^done with forth?
Two ways spring to mind...
(a) You call your Forth program with a batch file eg "FP.Bat" of the
form:
ForthPro
ANOther
The Forth program then writes the batch file "ANOther" eg
ShellTo
FP
So to run another program, you do a normal exit and the newly
written batch program gets executed. This runs the other program
and returns to ForthPro etc etc
To break out of the loop, you write an empty ANOther.Bat file.
This is how several menu programs do it. The problem is that
you have to restart the Forth program everytime, having lost
everything you didn't save to disk.
(b) So the alternative is to save piles of memory containing the
Forth program and data to disk or EMS, leaving only a small
section of code to reload it all. Several TSR libraries have
got this down to a fine art, but it's more complex than (a).
//\/\/
---
~ SLMR 1.05 #109 ~ He who laughs last probably FLUSHed.
PCRelay:OLEF -> #181 RelayNet (tm)
4.10a15 The Node is OLEF, HUB is HUBOLEF1 in the UK
<<<>>>
-----
This message came from GEnie via willett. You cannot Reply to the author
using email. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, whatever).
Report problems to: dwp@willett.pgh.pa.us or uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/08/91)
Date: 03-04-91 (18:48) Number: 1406 of 1406
To: CHARLIE HITSELBERGER Refer#: NONE
From: IAN WATTERS Read: NO
Subj: AUTO-INCREMENTING Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
CH>Another question: I'm using hardware with a 40*25 video display, and
CH>forth blocks are 64*16 by convention.
On a machine with a 40 column display, it's easiest to make blocks 512 bytes
long and display them as 32x16... The only layout problems I had using this
arrangement were with long code words which often overflowed onto the next
block.
One system (rqFORTH on the BBC Micro) had the following word:
: ->> (S -- )
2 BLK +! 0 >IN ! ; IMMEDIATE
ie just like --> except that you skip a screen. The skipped screens could
then be used for comments, so when they were printed out it looked like:
----------------------------------------------
Screen 6 Screen 7
code comments on
more code screen 6
etc ->>
Screen 8 Screen 9
code comments on
more code screen 8
etc ->>
Screen 10 Screen 11
code comments on
more code screen 10
etc ->>
----------------------------------------------
This worked well and 32x16 *does* encourage short definitions!
//\/\/
---
~ SLMR 1.05 #109 ~ My tagline's s
lipped !
PCRelay:OLEF -> #181 RelayNet (tm)
4.10 O.L.E.F.1. London ->OLEF (+44) 81-882-9808
<<<>>>
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/24/91)
Category 3, Topic 1 Message 98 Wed May 22, 1991 D.RUFFER [Dennis] at 23:42 EDT Re: Daniel C. Sobral > UPPERCASE only: not defined in this module Doesn't this mean that you define a word in a different case from what you use it (in another module)? I've seen that before, and I find it confusing. Re: Mitch.Bradley > For example, according to the rules, "FORTH" is incorrect. I think that is why Marlin "changed" it when he came in as Forth Dimensions' editor. At least that is the "story" he told me. :) However, you point is well taken. > "Cuteness" contributes to Forth's reputation as a difficult-to- > read language. I couldn't agree more. JOT sounds like one of those "cute" three letter words that people come up with so that the source code is "shorter". However, NUMBER-BUF is not much better (IMHO), because of my aversion to hyphenated words. Now #BUFFER might work if you don't have a preconceived notion about the # sign, but I'm sure someone else would dislike it also. The important thing, I guess, is that it makes sense to the author. Likely, Martin "understands" what JOT means and within the context of ZEN, it is probably appropriate. Re: Nicolas Tamburri > Some systems honor case sensitivity, others don't Good point Nick! I try to use only UPPER case for word I expect the user to use. I should probably try to keep case in-sensitive systems in mind as I write code, but my system is case sensitive so it is difficult at times. DaR ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/25/91)
Category 3, Topic 1
Message 104 Thu May 23, 1991
D.RUFFER [Dennis] at 22:36 EDT
Re: Mitch.Bradley@ENG.SUN.COM
> I believe that Glen got the idea from Jef Raskin.
Depending on when Glen told you about it, it may have come from Jef. He was
the guest speaker at the Real-Time Programming Convention held in Anaheim in
1988. If my memory serves me correctly the quote was:
"The only thing that Chuck did wrong in Forth was the
curvature of the ellipsis."
He would have rather your example was like this:
( DUP ROT . )
Now wouldn't that be interesting! :) DaR
-----
This message came from GEnie via willett. You *cannot* reply to the author
using e-mail. Please post a follow-up article, or use any instructions
the author may have included (USMail addresses, telephone #, etc.).
Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwpForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/28/91)
Category 3, Topic 1 Message 108 Mon May 27, 1991 D.RUFFER [Dennis] at 03:04 EDT Re: Mitch.Bradley@ENG.SUN.COM (Mitch Bradley) > What are the reasons for your aversion to hyphenated words? To me, a hyphen tends to imply that a word is doing two things. Your example of READ-FILE is doing exactly that. It is selecting the FILE device and doing a READ on it. READ-LINE is doing the same thing from the LINE device (:whatever that is:). I realize that this line of thinking is difficult to accomplish in "standard" Forth, but it works quite nicely with oop extensions or even with vocabularies (if you have enough of them). Your point about hyphenated words is well taken though. In general, they are well understood. I just also believe that information hiding can be used very effectively. You are right about #BUFFER being mistaken for the size of the buffer. I had forgotten about the previous usages of #. >> Likely, Martin "understands" what JOT means and within the >> context of ZEN, it is probably appropriate. > > I disagree. I think the important thing is that it makes sense > to somebody else picking up the code for the first time. It is ok for us to disagree, and I can see where you are coming from. However, on all the _large_ project I've been on, I ended up making a "new language" anyways. The systems had their own vocabularies and naming conventions. Within one line of applications (i.e. programming team) the conventions would be pretty consistant, but outside of that "environment" the conventions may be quite different. If a someone (Forth guru or novice) wants to understand the application, they had better start with learning the conventions. Hopefully, they will be documented, but my experience has been that they never are. :( IMHO, this is true in _any_ language. {B-{)> DaR ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (05/31/91)
Category 3, Topic 1 Message 110 Wed May 29, 1991 D.RUFFER [Dennis] at 22:50 EDT Re: hnridder@cs.ruu.nl (Ernst de Ridder) > What (different) naming conventions are there? Well, I certainly haven't seen all the possiblities, but here are a few that I've used: !name @name .name -> These are clear (I think). #name -> Can mean "size of" or "number of" depending on context. +name -name -> Turn on and turn off name. -name -> Inverse truth value returned by name. /name -> Initialize name. >name -> "Into" or "pointer to" name, but can also be "translate to". 'name -> Vector for name. (name) -> Low level subset of name. ?name -> Takes a truth value. name? -> Returns a truth value. These are just a few of what I've used and seen, but I'm sure there are many more, and this doesn't include the case-sensitive ones mentioned earlier. DaR ----- This message came from GEnie via willett. You *cannot* reply to the author using e-mail. Please post a follow-up article, or use any instructions the author may have included (USMail addresses, telephone #, etc.). Report problems to: dwp@willett.pgh.pa.us _or_ uunet!willett!dwp