wmb@MITCH.ENG.SUN.COM (02/14/91)
> What about the simpler methods of > conditional compiliation. Have these all been rejected? Why do we have > to have the huge overhead of IFTRUE and such, rather than something > simple and elegant, such as query-paren. The trouble with query paren is that it doesn't nest, and it's a royal pain to use if the stuff you are enclosing contains embedded right parens. Another alternative is "conditional backslash". It has problems too; it doesn't nest, you need it at the start of every line, and it's inconvenient to specify the equivalent of an "otherwise" clause with this technique. Are there some other commonly-used techniques I don't know about? The overhead isn't huge; it can be implemented in about 150 bytes in ANS Forth. It's optional, too; it's in the extension portion of the optional files wordset. So, even if you implement the file wordset, you don't have to have these words. I can't think of any good reason for a vendor not to supply them at least in source form though. Interestingly, within hours of announcing their existence, I received an enthusiastic personal email reply from a person who was very glad to have them. I guess its just a matter of personal taste. Mitch Bradley, wmb@Eng.Sun.COM
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (02/24/91)
> And I don't relish IFTRUE either. > If a clumsy mechanism of this type must be used (and, sigh, I suppose it > must) at least let there be a contest or something for BETTER NAMES! > > To kick off the contest, I will propose [IF] [ELSE] [THEN]. <grin> The conditional compilation proposal that the ANS committee is currently voting on via letter ballot uses the names .IF .ELSE .THEN 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). The disadvantage is that OTHERWISE is a bona fide English word, and its appearance in text enclosed by IFTRUE IFEND could be construed as an operator. .IF .ELSE .THEN are nice names. Personally, I agree that [IF] etc are more obvious, and also "[]" has less of a tendency to "get lost" visually than does "." . However, the "dotted" names are in common use; LMI Forth uses those names, and LMI Forth is a very successful system. Another good set of names would be #IF #ELSE #ENDIF , just like C uses. I don't subscribe to the philosophy that Forth always has to do things differently from C on general priciples, and the C names are certainly widely known in the programming community at large. However, all this is pretty much moot; the concrete proposal says .IF .ELSE .THEN , and I doubt that there will be another opportunity to tune the names before Basis goes to dpANS. That is fine with me; the function is much more important than the names, and I think the proposed names are good enough for all practical purposes. Mitch
mburke@eecs.wsu.edu (Matthew Burke - grad student) (02/27/91)
From what I've seen, I thought there was some (tacit) convention that
words beginning with a dot were ones responsible for printing certain
values (such as . .U R.U .FILES {in PYGMY} etc.). I have done my
best to follow this in my own programming as there is, IMO, a lot
going for common conventions.
Personally, my preference would be for #IF etc.
Matt
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Matthew M. Burke mburke@cs2.wsu.edu %
% Where am I and what am I doing in this handbasket? %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%dwp@willett.pgh.pa.us (Doug Philips) (02/28/91)
In article <9102250350.AA26430@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes: > .IF .ELSE .THEN are nice names. Personally, I agree that [IF] etc are > more obvious, and also "[]" has less of a tendency to "get lost" visually > than does "." . However, the "dotted" names are in common use; LMI Forth > uses those names, and LMI Forth is a very successful system. > > Another good set of names would be #IF #ELSE #ENDIF , just like C uses. > I don't subscribe to the philosophy that Forth always has to do things > differently from C on general priciples, and the C names are certainly > widely known in the programming community at large. According to the docs I have on Upper Deck Systems Forth, they use the #if ... #endif nestable forms. Do they have anyone on the TC (or did they?)? > However, all this is pretty much moot; the concrete proposal says > .IF .ELSE .THEN , and I doubt that there will be another opportunity > to tune the names before Basis goes to dpANS. That is fine with me; > the function is much more important than the names, and I think the > proposed names are good enough for all practical purposes. I was almost ready to agree with you about "more important than the names." I think that a consistency in naming conventions is at the same level of importance as the function(s) being added. As someone else already pointed out, the tradition of a . (dot) prefix meaning "print" is being violated. I'm curious to know if "common use" is isomorphic with "LMI does it" in this case or if there really are other users. (As I pointed out, Upper Deck Systems does it differently). -Doug --- Preferred: dwp@willett.pgh.pa.us Ok: {pitt,sei,uunet}!willett!dwp
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (02/28/91)
> I'm curious to know if "common use" is isomorphic with "LMI does it" in this > case or if there really are other users. (As I pointed out, Upper Deck > Systems does it differently). I don't know of any systems other than LMI using the names ".IF .ELSE .THEN". In fact, I don't know of any two systems that agree on ANY set of names. The only set of names that has much chance of multi-system use is IFTRUE .. OTHERWISE .. IFEND , and that set has the unfortunate property that OTHERWISE is a well-formed English word, and thus tends to appear in text comments, confusing the IFTRUE parser. Everything else being equal, I would go with LMI over Upper Deck Systems, since I suspect that LMI has at least 10 times as many users as Upper Deck Systems (this is not intended as a criticism of UDS). I think that naming consistency is important, but I don't think it is as important as having the functions you need. The naming thing is an annoyance, but lack of functionality can keep you from doing something you need to do. If a convenient opportunity arises, I will propose a name change, but I am worried that raising the issue will open the door for the minimalists to propose deleting the functions entirely. I don't want that to happen. Mitch
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (03/05/91)
> Is it the policy of the TC to put stuff in at the last minute so as > to avoid discussion. No, it just happened that nobody bothered to propose them until the last meeting. As a group, the TC is definitely not trying to "railroad" this. Evidence: at least 2 TC members have voted against the proposal in the letter ballot, and their reasons for voting no were both "too late, insufficient discussion". Personally, I am confident that these words are well-understood and important (based on their existence in numerous systems for many years). > BTW, since I haven't seen this proposal: > 1. are these words nestable? > 2. can these words range across multiple screens linked with --> ? > 3. can these be used both in compile and interpret "state"? Yes on all counts. Mitch
cychao@csun11.cs.uh.edu (Chih-Yu Chao (Dr. S. Huang)) (03/12/91)
Now that backslash (\) is standard word for line comment, how about use \IF, \ELSE, and \THEN for conditional compilation. Well, just suggestion. CY Chao U. of Houston, Texas InterNet: cychao@cs.uh.edu
wmb@MITCH.ENG.SUN.COM (03/15/91)
Comparison of different names for conditional compilation:
IFTRUE OTHERWISE IFEND
+ Mentioned in Forth-83
+ Used in some existing implementations
- OTHERWISE is an English word that often appears in comments
.IF .ELSE .THEN
+ Used in LMI Forth and in at least one other implementation
- "." conventionally signifies an output function
#IF #ELSE #THEN
+ Many programmers know these name
+ Used in at least one implementation
- "#" has other conventional meanings in Forth (number
conversion, in #TIB, etc)
[IF] [ELSE] [THEN]
+ Mnemonically consistent with ['], etc.
- They look "ugly" to some people
IF( )ELSE( )THEN
+ The bracketing is explicit
- Potential for confusion about where the flag goes
Mitch Bradley, wmb@Eng.Sun.COMwmb@MITCH.ENG.SUN.COM (03/15/91)
> 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] ] Since [IF] is immediate, the correct usage would be: [ condition ] [IF] If you put [IF] inside [ ] , then the right bracket (]) would be skipped. Mitch Bradley, wmb@Eng.Sun.COM