ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/04/91)
Category 10, Topic 4 Message 3 Sun Mar 03, 1991 B.RODRIGUEZ2 [Brad] at 10:22 EST > I don't know of any systems other than LMI using the names > ".IF .ELSE .THEN". Klaus Schleisiek-Kern of DELTA t uses these names. > I am worried that raising the issue will open the door for the > minimalists to propose deleting the functions entirely. And I am worried about functions being railroaded into the BASIS. Is it the TC's policy to put things in at the last minute so as to avoid discussion of their removal? - Brad ----- 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) (03/05/91)
Date: 03-02-91 (17:49) Number: 1401 of 1401 To: GARY SMITH Refer#: 1361 From: CHRIS WATERS Read: 03-04-91 (05:30) Subj: Operating Systems Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Reply to: wmb@MITCH.ENG.SUN.COM (Mitch Bradley) Subject: Re: Conditional compilation > The conditional compilation proposal that the ANS committee is >currently voting on via letter ballot uses the names .IF .ELSE >.THEN A very acceptable choice. Much better than IFTRUE, etc. I can easily live with, and even approve of those names. I still think [IF] was a slightly better choice, but since I came up with that off the top of my head while composing that last mesage, I'm not surprised that it was too late to submit to the committee. :) > The advantage of IFTRUE OTHERWISE IFEND is that those names are >mentioned in the Forth-83 document (which is why my Forth >systems use those names). I'm not sure that being in the 83-standard is something that could really be called an "advantage". :) And as I pointed out, END and ;: are mentioned in the 83-standard as well. I saw no reason to include these in my Forth either. None of these were required words. Despite the fact that I fought for several features in the 83-standard, through the offices of my good friend John James, I cannot say I was ever pleased with the result. I'm beginning to think I may find myself pleased with ANSI-Forth, though. But only time (and a copy of BASIS that I can actually READ) will tell. regards, Chris (email only to spelunky@darkside.com) --- Tag1.3 * Maybe I should have asked for my Neutron Bomb in PAISLEY! --- * SFUTI 3.01 / The Cave BBS -- Unix/Xenix/Anime/Forth/C/Madness.. PCRelay:THECAVE -> #559 RelayNet (tm) 4.10 The Cave (408)259-8098 12/24/96/19.2 HST/DS <<<>>> ----- 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
cychao@csun10.cs.uh.edu (Chih-Yu Chao (Dr. S. Huang)) (03/06/91)
I have been learning FPC V3.53 recently, and had a technical reference manual written by Dr. C.H. Ting. In the manual some words' definition is implemented by target compile (?) words, such as T:, T;, [TARGET], [META], TRANSITION, ... etc. Is there anybody know what are these words' real meaning ( I know it's target compiling.), or tell me where can I find a manual to learn these strange words. My E-mail address is: cychao@cs.uh.edu.
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/07/91)
To: GARY SMITH Refer#: 1387
From: RAY DUNCAN Read: NO
Subj: CONDITIONALS ! Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
>I'm curious to know if "common use" is isomorphic with "LMI Does It"
LMI didn't have any part in the addition of .IF .ELSE .THEN to the
BASIS; we haven't been part of X3J14 for some time. I can't speak for
whether these words are in "common use" or not, and I don't claim that
they are.
For our own part, we picked the ".IF" notation by analogy to some
assemblers which use a dot to prefix things that are assembler
directives rather than actually generating code. It's true that this
conflicts somewhat with the Forth naming convention of dot indicating
that something will be printed. I don't have any preference on this
issue one way or the other. I do fail to see how #IF is any more
"Forth-like" than ".IF" since the only use I know of for # in Forth is
to convert binary to ASCII.
Ray Duncan, LMI
-----
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) (03/07/91)
To: B.RODRIGUEZ2 [BRAD] Refer#: 1389 From: RAY DUNCAN Read: NO Subj: OPERATING SYSTEMS Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Brad writes: >If I were voting, I'd go with [IF] [ELSE] [THEN] >Are these words nestable >Can these words range across multiple screens linked with --> >Can these words be used both in compile and interpret state 1. I support this, it seems reasonable. LMI isn't going to draw a line in the sand over the naming ".IF" etc. 2. They are nestable in the current version of LMI systems, but they weren't nestable in their first incarnations, so a lot of users don't take advantage of the nesting. 3. They don't span screens linked by --> in LMI systems, but they will work for collections of screens loaded with THRU (the implementation of .IF in our systems is basically to call WORD repeatedly looking for .ELSE or .THEN, with a little extra logic to support recursion). 4. .IF etc. are immediate and work in either interpreting or compiling mode. However if you want to control compilation with a flag you have to make that flag IMMEDIATE, obviously, e.g. TRUE CONSTANT DEBUG? IMMEDIATE ... : FOOBAR ... DEBUG? .IF ... .THEN ... ; Ray Duncan, LMI NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 ----- 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) (03/11/91)
Date: 03-07-91 (14:01) Number: 1445 of 1453
To: RAY DUNCAN Refer#: NONE
From: CHRIS WATERS Read: NO
Subj: Conditionals ! Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
RD>issue one way or the other. I do fail to see how #IF is any
RD>more "Forth-like" than ".IF" since the only use I know of for #
RD>in Forth is to convert binary to ASCII.
I think Mitch was saying that #IF is no WORSE than .IF, and shouldn't be
rejected just because it's 'C-like'. I'd have to agree with him about
that. Neither .IF nor #IF strike ME as particularly 'Forth-like'. :)
Personally, I think my suggested [IF] is the only suggestion I've heard
that is at all Forthlike. It has one drawback that I can think of--the
braces usually indicate a immediate word that should be used inside a
colon definition, whereas [IF] (or .IF or #IF) is probably used outside
of colon definitions more often than not. But it IS an immediate word,
and CAN be used inside colon defs, and I do think it's a better choice
of name than either of the other two.
Another possibility is (IF), by analogy with paren and dot-paren, the
only words I can think of which act the same inside or outside of a
definition. But this would conflict with paren, the same objection that
was raised to query-paren.
I'd much prefer to see a syntax that is consistent with other Forth
words, rather than one borrowed from another language without
consideration for what the name implies in Forth. Both .IF and #IF
imply (to me at least) a word that has something to do with output.
I could live with either if accepted into the standard, but from my
point-of-view, this would be a flaw in the standard.
I'm not inseparably attached to [IF]. It was something I came up with
off the top of my head, a week or two ago, and I confess I've never used
it in any code (I'm a query-paren man, myself; been using qp since about
'79) but I do think it's a good suggestion, and would not mind seeing it
given equal consideration.
Chris R:-{O}
p.s. I used LMI-Forth at my last job about four years ago (an excellent
product, BTW), but I don't remember .IF. Is this a new addition to LMI?
---
Tag 1.3 * Do not disturb! Asleep at computer
---
* SFUTI 3.01 / The Cave BBS -- Unix/Xenix/Anime/Forth/C/Madness..
PCRelay:THECAVE -> #559 RelayNet (tm)
4.10 The Cave (408)259-8098 12/24/96/19.2 HST/DS
<<<>>>
-----
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!dwpdcp@world.std.com (David C. Petty) (03/11/91)
In article <2458.UUL1.3#5129@willett.pgh.pa.us>, Brad Rodriguez writes: ``Is it the TC's policy to put things in at the last minute so as to ``avoid discussion of their removal? Brad, how could you even _suggest_ such a thing. We both know that could _never_ be in the back of the minds of _any_ TC members, don't we? (If I knew what the usenet smiley-face symbol for oozing sarcasm was -- and if I used usenet simley-face symbols -- I would use it here.) I am reminded of a quote (though I cannot remember the attribution) that goes something like, ``As I get older I find that I just don't have enough synicism.'' -- David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\ POBox Two | CIS: 73607,1646 | BIX, Delphi, MCIMail: dcp / \ Cambridge, MA | `It must've been some-other-body, / \ 02140-0001 USA | uh uh babe it wasn't me...' /______\
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/13/91)
Date: 03-09-91 (11:00) Number: 1464 of 1465 (Echo) To: CHRIS WATERS Refer#: 1445 From: RAY DUNCAN Read: NO Subj: CONDITIONALS ! Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) >I used LMI Forth at my last job about 4 years ago but I don't >remember .IF. Is this a new addition to LMI? It was introduced in the UR/FORTH implementations ca. 1986 then moved into PC/FORTH and PC/FORTH+ when they were overhauled for high-level compatibility with UR/FORTH in 1988. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- 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) (03/18/91)
Date: 03-13-91 (08:13) Number: 1502 of 1502 (Echo)
To: GARY SMITH Refer#: 1487
From: JACK WOEHR Read: NO
Subj: CONDITIONALS ! Status: PUBLIC MESSAGE
Conf: FORTH (58) Read Type: GENERAL (+)
-> (David C. Petty) Organization: The World @ Software Tool & Die
-> In article <2458.UUL1.3#5129@willett.pgh.pa.us>, Brad Rodriguez
-> writes:
-> ``Is it the TC's policy to put things in at the last minute so as to
-> ``avoid discussion of their removal?
-> Brad, how could you even _suggest_ such a thing. We both know that
-> could _never_ be in the back of the minds of _any_ TC members, don't
-> we? (If I knew what the usenet smiley-face symbol for oozing sarcasm
-> was -- and if I used usenet simley-face symbols -- I would use it
-> here.)
David, that is ridiculous. Nothing except the arrival of
our nightly pizza order stifles discussion @ X3J14.
The last meeing was dedicated to TAKING THINGS OUT of the
Standard as much as possible.
EVERY member of the TC wants things REMOVED ... it's just
that, like the user community at large, we all disagree on what
is to go!
By and large, as an implementor of the BASIS, I believe that
we have done a good job at tailoring a Forth that will be PORTABLE
and AS COMPATIBLE AS POSSIBLE in syntax with what went before. We
coulda done better, but we coulda done a whole lot worse!
=jax=
NET/Mail : RCFB Golden, CO (303) 278-0364 VESTA & Denver FIG for Forth!
<<<>>>
-----
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) (03/18/91)
Category 10, Topic 4 Message 16 Sun Mar 17, 1991 B.RODRIGUEZ2 [Brad] at 10:50 EST Charles Eaker writes: > I don't like [IF] because it puts the brackets in what will > sometimes be the wrong place. In a definition would would have to > use > [ condition [IF] ] Someone correct me if I'm wrong, but my understanding is that you'd have to use [ condition ] [IF] and that the construct posted by Charles Eaker would actually have dangerous side effects, since if the condition is true, ']' is skipped and the system remains in interpret state. E.g., [ condition [IF] ] blah blah blah [ELSE] R> DROP [THEN] would go boom. Come to think of it, this is an argument for the [IF] name, since it provides a visual reminder -- the nested brackets, which certainly caught Charles' eye! --of a dangerous usage. Also, has the TC adequately documented risks such as these? Jack Woehr writes: > The last meeting was dedicated to TAKING THINGS OUT of the Standard > as much as possible. ... EVERY member of the TC wants things > REMOVED. Hmmm. Every member wants things removed, but with every meeting, it gets bigger and bigger. What's wrong with this picture? Re. the last meeting, all I've heard from it so far (I'm still waiting to download the BASIS) is these new conditionals, and the new search order words. Hardly "taking things out." Maybe if everyone started agitating to put things in, the BASIS would get smaller? :-) - Brad Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca "Shoes for industry!" | bradford@maccs.dcss.mcmaster.ca (archaic) ----- 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
eaker@sunbelt.crd.ge.com (Charles E Eaker) (03/21/91)
> > [ condition [IF] ] > >Someone correct me if I'm wrong, but my understanding is that you'd have to >use > [ condition ] [IF] > >and that the construct posted by Charles Eaker would actually have dangerous >side effects, since if the condition is true, ']' is skipped and the system >remains in interpret state. Oops! Blush! Duh! I just put a huge dent into my forehead. However, thinking quickly, I miraculously turn this into an argument for my IF( )ELSE( )THEN naming proposal in which the parentheses clearly indicate the scope of what is, and what is not, skipped in the input stream. Consequently, the construction [ condition IF( ] T-stuff )ELSE( F-stuff )THEN clearly *looks* wrong because the over-lapping scopes are quite evident especially when compared to the correct [ condition ] IF( T-stuff )ELSE( F-stuff )THEN If I had recast the example in terms of these names, I would have seen, literally, the error immediately. In the original example, [ condition [IF] ] the brackets appear to be "properly" nested in some way. This is another reason, I think, against the [IF] set of names, and must be what I *really* had in mind when I said the brackets are mis-leading. The [IF] word only opens a scope. It does not represent, as the brackets strongly imply, a fully self-contained, interpreted scope in the same way that ['] does. -- Chuck Eaker / P.O. Box 8, K-1 3C12 / Schenectady, NY 12301 USA eaker@crd.ge.com eaker@crdgw1.UUCP (518) 387-5964
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/30/91)
Date: 03-15-91 (20:57) Number: 1504 of 1557 To: GARY SMITH Refer#: NONE From: CHRIS WATERS Read: NO Subj: CONDITIONALS ! Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Reply to: eaker sunbelt.crd.ge.com (Charles E Eaker) Subject: Names for conditional compilation. > I don't like [IF] because it puts the brackets in what will sometimes > be the wrong place. In a definition one would have to use > [ condition [IF] ] Well, if you dislike that, you could use: [ condition ] [IF] Which is more like the syntax I usually use with query-paren in any case. I don't really have a problem with either .IF or #IF, except that both of those names seem to imply that the word has something to do with output. > #IF is ok with me. When tens of thousands of programmers look at it for > the first time, their gut reaction will be nearly correct. I don't mind > porting C-isms to Forth as long as they aren't contrary to Forth > custom. This usage of '#' doesn't conflict with its traditional one. It doesn't conflict with the use of '#' in pictured numeric output? I have to disagree with you here. Moreover, I sometimes use my C pre- processor on my Forth code, and this would conflict with THAT! You also suggested: [ condition ] IF( But I think it's a little too easy to miss the lone parenthesis there. (And I notice you didn't misplace the braces in the example for YOUR suggestion! <grin>) Still, I think it's a good counter-proposal. [IF] was made up off the top of my head. I'd prefer either of these to .IF or #IF. regards, Chris --- Tag 1.3 * this tagline was supposed to be written in Hindustani PCRelay:IDCBBS -> #918 4.10 IDC BBS ~ Alameda, CA ~ (415) 865-7115 ~ HST <<<>>> ----- 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) (03/30/91)
Date: 03-26-91 (14:17) Number: 1601 of 1601 (Echo) To: GARY SMITH Refer#: 1569 From: RAY DUNCAN Read: NO Subj: CONDITIONALS ! Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) The problem I see with IF( )ELSE )THEN is that it makes things more difficult to "comment out" -- all the implementations of ( that I know about would incorrectly identify )ELSE or )THEN as the end of the comment. NET/Mail : LMI Forth Board, Los Angeles, CA (213) 306-3530 <<<>>> ----- 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
wmb@ENG.SUN.COM (Mitch Bradley) (03/31/91)
> The problem I see with IF( )ELSE )THEN is that it makes things more > difficult to "comment out" -- all the implementations of ( that I know > about would incorrectly identify )ELSE or )THEN as the end of the > comment. The use of "( ... )" to comment-out large blocks of code is fairly dubious anyway, since most code has interspersed comments, and most implementations of "(" do not nest. On the other hand, "( .. )" could be entirely enclosed inside "IF( .. )THEN" with no ill effects, e.g. IF( OVER + ( n1 n2 ) )THEN Mitch
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (03/31/91)
Category 10, Topic 4 Message 22 Sat Mar 30, 1991 B.RODRIGUEZ2 [Brad] at 20:00 EST Thanks for the comparison chart, Mitch; it's quite useful. BTW, at least one implementation (MicroProcessor Engineering, U.K.) uses the names IF( )ELSE( )THEN . I could probably live with this, although Ray's observation about parenthesis comments is a concern. - Brad ----- 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) (04/06/91)
Date: 04-01-91 (18:07) Number: 1717 of 1724 To: GARY SMITH Refer#: NONE From: CHRIS WATERS Read: NO Subj: CONDITIONALS ! Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Reply to: eaker sunbelt.crd.ge.com (Charles E Eaker) Subject: Re: Conditionals ! > However, thinking quickly, I miraculously turn this into an argument > for my > > IF( )ELSE( )THEN If you're going to name it something like that, why not: (IF (ELSE) THEN) Which would allow you to use the standard names in minimal memory conditions, as long as you didn't have any nested comments or conditionals, simply by substituting the (admittedly non-standard) definitions for query-paren. Otherwise, I think it's too easy to accidentally leave out a space, and end up with "IF(" when what you really meant was "IF (". That's my main objection to your proposal, which I otherwise think is very good. --- Tag 1.3 * If this had been a real emergency, you would be dust! PCRelay:IDCBBS -> #918 4.10 IDC BBS ~ Alameda, CA ~ (415) 865-7115 ~ HST <<<>>> ----- 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