ForthNet@willett.UUCP (ForthNet articles from GEnie) (01/14/90)
Category 10, Topic 24
Message 5 Sat Jan 13, 1990
R.BERKEY [Robert] at 17:29 PST
To: Mitch Bradley
Re: Context-Free Numeral Syntax
MB> Of course, Forth really ought to have some way of explicitly
MB> declaring the radix of an individual number.
So far, so good. One of the single biggest annoyances I've encountered
recently is being unable to read code because of the context sensitivity of
BASE .
MB> The consensus was that I should amend the proposal to instead
MB> define Forth words H# and D# , which would be followed by a
MB> space and the number. We'll see how this amended proposal
MB> fares.
As for H# and D# as prefix words, I can't tell that the committee isn't just
putting you off:
(1) These can easily enough be defined.
(2) The association of 'D' with "double" compounds problematically its use for
decimal. Precisely the name D# is used for interpreting the following string
as a double number, and the FST standards offer no other way but prefix
operators for double numbers in source code. I've come up with the Roman
numeral 'X' for the ten of DECIMAL as a fix (only to discover other's using
'X' for hex!).
(3) I've known about these prefix operators for some nine years now, but I've
_never_ used them.
(4) Did they agree that these words would be state smart? ;-)
: H#12a4 ( -- $12A4 ) \ Define a constant a hard way
STATE @ IF [H#] 12A4 POSTPONE LITERAL
ELSE [ H# 12A4 ] LITERAL
THEN ; IMMEDIATE
MB> At the last ANSI meeting, I proposed that number syntax
MB> should allow the prefixes H# , D# , O# , and B# ...
MB> Thus you could write H#12a4 or D#5478 ...
Back to standardizing H# and D# and B# and O# as a part of the number: Part
of my negative response to this syntax would have to be that I haven't seen it
before, but I think there is more to it. Are you claiming you use these? Can
you say you like them?
--- Single character syntax ---
Indeed, do you know of more than one character ever having been used in any
assembler, language, etc. It seems that any of the single characters " # % &
or ' would suffice.
For my own solution with F-PC I've not resisted the culturally-biased '$' for
hex, and adopted '#' for decimal, i.e., $12A4 and #32 . It was work to go
through and mark each number, but the effort was well worth it. In short,
I've eliminated HEX and DECIMAL from application code.
Guy Kelly's PC83 uses a logical relationship of "'" for octal and '"' for hex.
I've heard that single character syntax has been in the San Diego systems
since pre-FIG days (and there was such in the SuperForth/polyFORTH I used
there). They wonder why the rest of us haven't caught on yet!
Robert Berkey
-----
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) (01/14/90)
Category 10, Topic 24
Message 6 Sat Jan 13, 1990
R.BERKEY [Robert] at 17:34 PST
To: Mitch Bradley
Re: Numeral Case-sensitivity in Case-insensitive Forths
Case Sensitivity Considerations for User Defined Numeral Syntax
Related to the previous message on numeral syntax are prior comments by Gene
LeFave and Roedy Green encouraging user defined extensions to the numeral
syntax.
In that same area, there is currently a dispute brewing with case insensitive
Forth's not being case sensitive for number interpretation. Might rub C
programmer's expectations raw for hexadecimal 12a4 getting aborted, I don't
know the answer. But I recall having a problem with ForthMacs because it
didn't understand hexadecimal 12A4 . Yet everyone would agree that 'A' and
'a' should be different (unlike F-PC interpretation).
Robert Berkey
-----
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) (01/16/90)
Category 10, Topic 24 Message 7 Sun Jan 14, 1990 F.SERGEANT [Frank] at 22:44 CST re: temporary base changes I loved Wil Baden's words on the order of $XX and $XXXX for forcing the base for that one number to hex. His trick relied on setting WIDTH to 3 and 5 respectively for their definitions. That way, $12 $FF $7E etc would all match to $XX and $1234 $FFEE etc would match to $XXXX. I think this can be done in any Forth that has WIDTH, and without changing NUMBER or anything in the kernel. Pygmy does not have WIDTH. It saves the full name (up to 31 characters) and does not need to do set any other bits in the header. (This may save some time. It certainly makes browsing the dictionary with DUMP and DU more pleasant as the names are easily readable.) In version 1.2 of Pygmy I changed NUMBER to recognize the prefix $ as indicating HEX for that one number (and the prefix ' for indicating an ascii character. LOAD in all versions of Pygmy restores the base to decimal before returning, so you always know what base the screen starts off in. So often I want just one number to be in hex, usually to set or test a bit pattern, and would prefer the rest of the numbers in decimal. So, yes, I am using this and I like it. I hate the clutter of saying something like DECIMAL ....... HEX FC DECIMAL ........ and can now say just ........ $FC ............. I am enjoying this new convenience in new code that I write. Gee, saying something like H#1234 sure is ugly! I'm used to the dollar sign from many years of Motorola processor exposure, and also to an X from IBM 360/370 assembler work (eg X'1234'). Of the two I think the dollar sign is at least as pretty, and since it is simpler, it wins. For my double numbers I use D' 1234 as I haven't built any other mechanism into the kernel. This has been satisfactory so far. Sometimes I might want to express a bit pattern in binary. I don't, however. I just use hex. I think I wouldn't bother changing NUMBER to recognize either a forced octal or binary. If I had to use octal or binary and 2 BASE ! or 8 BASE ! wouldn't do, I suppose I would define something like B' or O' ( eg B' 01100011 or O' 137 ). -- Frank ----- 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@SUN.COM (01/17/90)
> ... discussion about various ways to specify explicit number base ... > MB: H# D# > RB: %, etc > FS: $, h', etc The trouble with this topic is that everybody in the whole world has a different idea about what "looks" good. Everybody is "used" to something from exposure to some random assembly language. The only ways that I know to resolve such issues: 1) by fiat 2) give up and do nothing A couple of objective comments: A lot of Forth systems use "$" as a prefix for string operators (as in BASIC). RB notes the difficulty with "D#" also being a plausible operator for entry of double numbers. Whatever scheme is chosen should treat the "double/single" and "hex/decimal" choices orthogonally, since the choices are independent of one another. Mitch
dunn@uhccux.uhcc.hawaii.edu (John Dunn) (01/18/90)
In article <9001172005.AA21025@jade.berkeley.edu> Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu> writes: >> ... discussion about various ways to specify explicit number base ... >> MB: H# D# >> RB: %, etc >> FS: $, h', etc > >The trouble with this topic is that everybody in the whole world has >a different idea about what "looks" good. Everybody is "used" to something >from exposure to some random assembly language. > I'm not sure what the fuss is about here. For years, over several different Forths, I have simply trapped the string before it gets to NUMBER, and look for an appended character that designates a specified base. My preference happens to be "H" for hex, and the default is decimal, but so what - the character can be any non-numeric you pick. The trap routine looks at the string, and if the character is detected as the last character of the string (could be the first character, but my preference is to use the last), the current base is pushed to the stack, BASE is changed, the character is stripped from the string, and NUMBER is called. Then the BASE is restored. Simple, and works just fine. Forths that vector NUMBER make this especially easy, but I have never had much trouble finding a way to redefine low level words regardless of the implementation. One of the nicer features of Forth. -John Dunn
hacker@isadora.ikp.liu.se (Goran Larsson [Hacker of Hackefors]) (01/20/90)
In article <9001172005.AA21025@jade.berkeley.edu> Forth Interest Group International List <FIGI-L%SCFVM.bitnet@jade.berkeley.edu> writes: >> ... discussion about various ways to specify explicit number base ... >> MB: H# D# >> RB: %, etc >> FS: $, h', etc >RB notes the difficulty with "D#" also being a plausible operator for >entry of double numbers. Whatever scheme is chosen should treat the >"double/single" and "hex/decimal" choices orthogonally, since the >choices are independent of one another. In my own forth system designed five years ago I used the base#number syntax. Normal numbers: 16#7F 8#33 10#100 2#10010110 30#HIGH Double numbers: 16#FFFFFFFF. 10#100000. The number representing the base is always interpreted as a decimal number. The whole thing was implemented inside NUMBER. ! _ ! ! Goran Larsson [The Hacker of Hackefors] --+-+ Hackefors, Linkoping, SWEDEN (See) +46 13-155535 (Hear) +-+-- ...!uunet!sunic!unilog!isadora!hacker (Bang!) ! ! hacker@isadora.sypro.se (at'n'dots) ! Mmh, Yes
ForthNet@willett.UUCP (ForthNet articles from GEnie) (03/03/90)
Date: 03-01-90 (11:46) Number: 2988 (Echo) To: PETE KOZIAR Refer#: 2967 From: DAVID ALBERT Read: NO Subj: INNER INTERPRETER Status: PUBLIC MESSAGE I would have thought that the return stack gets more use than any other (the paramter) stacks. You are quite right about the extra byte in the instruction prefix though. However, since memory is cheap and plentiful in almost any machine these days (particularly on 80x86 types) that is not of concern. One particularly nice feature of the subroutine threading is that it greatly facilitates expansion to larger memory models without brutally slowing the inner interpreter. (Memory models...yuk!) ----- 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 10, Topic 24
Message 9 Sun Mar 18, 1990
R.BERKEY [Robert] at 01:27 PST
-------------------------------------------------------------------------
ANSI X3J14 Forth Technical Proposal Page 1 of 1
-------------------------------------------------------------------------
Title: [COMPILE]
Related Proposals:
Keyword(s): syntax, interpreters Proposal (X)
Forth Word(s): POSTPONE Comment ( )
-------------------------------------------------------------------------
Abstract:
POSTPONE is not a substitute for [COMPILE] .
-------------------
Discussion:
The definition of POSTPONE states:
Syntax:
: <name2> ... POSTPONE <name> ... ;
Compilation semantics:
Append the compilation semantics of <name> to the
interpretation semantics of <name2>.
[COMPILE] is needed in order to append the interpretation semantics
of <name2>.
For example:
A word defined using POSTPONE POSTPONE , when executed, compiles
the action of <name> as it behaves when compiled.
POSTPONE [COMPILE] is necessary to compile the action of <name> as
it behaves when text interpreted.
-------------------
Proposal:
Move [COMPILE] from EXT CORE to CORE. Remove the "Note:" that the
word is obsolescent.
Remove [COMPILE] from 5.7.1 Obsolescent features.
-------------------------------------------------------------------------
Submitted by: Robert Berkey Date: 90-03-17
Address: 47000 Warm Springs Blvd. #253 Ph: (415) 659-1334 x352
Fremont, CA 94539 Msgs: GEnie R.BERKEY
ANSI X3J14 Forth Standards Committee
111 N. Sepulveda Blvd., Suite 300, Manhattan Beach, CA 90266
-------------------------------------------------------------------------
-----
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) (04/07/90)
Category 10, Topic 24
Message 11 Sat Apr 07, 1990
R.BERKEY [Robert] at 02:27 PDT
To: Jan Stout, et. al.
Re: COMPILE , POSTPONE's rationale note, and threading terminology
Jan Stout writes, 900321:
> 4. COMPILE
[ re: an implementation of COMPILE for subroutine threaders. ]
I infer that the reference is to the rationale note for POSTPONE .
There is a valid standard's issue involved, but I think the rationale note
needs work. Based on a couple of experiences, though, getting these things
adjusted is not so easy, so you might consider sending proposals, or
opinions/concerns, to the committee.
The issue that the (indicated) implementation of COMPILE won't work with
native code compilations is an implementation problem of the tradeoffs in
selecting native code compilation, as well as a standard's issue also
involving Forth hardware; as opposed to the validity of this implementation of
COMPILE for "jsr threading", "subroutine threading without inline code
expansion or peephole optimization".
We need concensus about what these terms mean, else these confusions will
continue. To Tom Almy: As far as I know "native code compilation" is
terminology of your origin. To all: Forth programmers in the San Diego area,
as via Guy Kelly, were using "jsr threaded" implementations since before the
days of fig-FORTH--the reference here and above to "jsr thread" is as I have
understood Kelly to use the term. I don't recall having heard "subroutine
threaded code", in the sense used in BASIS 11, prior to the X3.J14
deliberations. My impression is that the BASIS 11 terminology serves no
technical purpose.
-----
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'toma@tekgvs.LABS.TEK.COM (Tom Almy) (04/09/90)
In article <750.UUL1.3#5129@willett.UUCP> ForthNet@willett.UUCP (ForthNet articles from GEnie) writes: >The issue that the (indicated) implementation of COMPILE won't work with >native code compilations is an implementation problem of the tradeoffs in >selecting native code compilation. Well, you can put the blame anywhere you want. My native code compilers don't support COMPILE because there is no following token to compile. But I could make it work by taking COMPILE and the following token and generating code which would compile that token (either in a threaded or native code fashion). Frankly, since all the systems my NCC is on use a threaded code interpreter at compile time, there is no need for me to be concerned with this -- COMPILE can still be used in a threaded colon definition. >We need concensus about what these terms mean, else these confusions will >continue. To Tom Almy: As far as I know "native code compilation" is >terminology of your origin. Nope, I did not invent that term, it's been around for many years but not in the Forth community which has tended to be stuck on threaded code compilation -- a simpler, memory efficient, and portable technique. >To all: Forth programmers [...] were using "jsr threaded" implementations >since before the days of fig-FORTH [...] >I don't recall having heard "subroutine threaded code", in the sense used >in BASIS 11, prior to the X3.J14 deliberations. You were probably calling it "jsr threaded" because the machines you were using called the instruction "jsr"! But the real problem is that it shouldn't be called "threaded code" at all. It's really a simply generated native code. Once you've added the obvious in-line literal and control structure code it starts to look more and more like a true native code compiler (portability and decompilability* start to go away). Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply * There's a word of my own invention!
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (08/30/90)
Category 10, Topic 24
Message 12 Wed Aug 29, 1990
R.BERKEY [Robert] at 04:16 PDT
Subject: BASIS12 input-stream definitions
Mitch,
Thanks for looking at the code I wrote for <NAME> using BASIS, and opining
that the basic axioms are satisfied. That led me to get out BASIS12 to check
out my impression that "it's not clear how to set >IN in BASIS."
I do see some problems here. BASIS12 simultaneously explores three
descriptions of the input stream associated with the "text input buffer". One
of these descriptions follows along Forth-83 lines, for the buffer area that
Forth-79 called the "terminal input buffer". The second description is a
concept with a stable TIB , with >IN and #TIB each relative to TIB . And the
third description is a concept in which TIB is mutable.
(1) The address-offset calculations in the coding for <NAME> are
using address units. So CHARS must be added to the definition of
<NAME> .
(While I'm on this point, the text for the definition of "input
stream" has the same problem.) (Note that >IN was changed from
"address units" to "character" units in Vancouver.)
(2) How does a program know what values go into >IN ?
>IN itself doesn't say, but an inference can be drawn from other
text. The glossary entry for #TIB gives specific values that can be
stored into #TIB . And the definition of "input stream" makes it
clear that the values in >IN parallel those in #TIB .
However, the values that can be stored in #TIB are
{0..capacity of the input buffer}. This, of course, invalidates
the <NAME> implementation. An editor's box below #TIB notes
that #TIB needs work, "Problem similar to one just fixed for >IN
...At the very least, the range specification must be deleted."
But making the text of #TIB similar to that in >IN would remove
the inference that determines valid values for >IN .
(3) The original source of my concern about setting >IN stemmed from
the rationale note that says, "Re-reading the input stream by
setting the contents of >IN to some arbitrary value, such as zero,
is incorrect." This seemed to imply that it's a system perogative
as to what goes into >IN .
Maybe that's just my misinterpretation, but the text of >IN doesn't
help things. (a) It does not identify the values that a program can
store there. (b) It uses the concept "start of the current input
stream". And the definition of "input stream" doesn't clearly
identify "start of the current input stream".
(4) What is TIB ?
It returns the address of something called the "text input buffer".
But "text input buffer" isn't further described.
The intent is presumably that systems can change the value returned
by TIB . If so, when does it change?
Without this information, programs cannot use TIB .
(5) The word SOURCE-FILE doesn't exist in BASIS12.
Robert
-----
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/30/90)
Subject: BASIS12 input-stream definitions Robert Berkey writes: > ... a careful and detailed analysis of the input stream definition, > exposing some inconsistencies. Robert, Based on your analysis, I suppose that it is incumbent on someone to take a shot at rewording this section of Basis to make it clear. I guess it might as well be me. Wanna help? According to my understanding of the way it is *intended* to work, your QUOTE-TO could should be perfectly correct. We need to make sure that the words indeed say that. > (3) The original source of my concern about setting >IN stemmed from > the rationale note that says, "Re-reading the input stream by > setting the contents of >IN to some arbitrary value, such as zero, > is incorrect." This seemed to imply that it's a system perogative > as to what goes into >IN . The intention of this rationale was to emphasize that you cannot assume that the current input stream began at TIB + 0. Note that it says "re-read". It is my understanding that it is fair game to set >IN to the value "adr TIB -" to begin reading at "adr". Let's take a shot at fixing the language. > The intent is presumably that systems can change the value returned > by TIB . If so, when does it change? My understanding is that it changes only when the system switches from one line-oriented input stream source to another, as with EVALUATE . When a nested interpreter (e.g. EVALUATE , LOAD) exits, the previous value of TIB is supposed to be restored. > Without this information, programs cannot use TIB . You can use it within the context of one input stream source. > (5) The word SOURCE-FILE doesn't exist in BASIS12. That was an editing mistake. I hope you guys fixed it at Vancouver? Please say yes. In my letter to Elizabeth, recording my votes, I stated 2 times that the effects of TP-641 (SOURCE-FILE, etc) did not appear in either Basis 11 or Basis 12. If this didn't get fixed, then I am depressed, and all that trouble that I went to to FAX my comments was wasted. Mitch
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/11/91)
Category 10, Topic 24 Message 18 Sat Feb 09, 1991 B.RODRIGUEZ2 [Brad] at 13:51 EST > ...when you <BUILDS things, you need to align it. And, if the word > DOES> nothing, the user will have to use ALIGN before @ and ! too. Actually, that's not true, if the system implementor did things right. The last word-aligned system I used automatically ALIGNed before every CREATE. This forced the parameter field to an even address (which was required for the thread of a colon definition). So, DOES> always returned an aligned address, and the user didn't have to worry about it. Strings compiled in-line were always padded to an even number of bytes; this required a small bit of additional logic in the run time code which advances the IP over the string, but it was invisible to the user. (In-line byte parameters were forbidden, no great loss.) Brad Rodriguez | brad%candice@maccs.uucp (God willing) B.RODRIGUEZ2 on GEnie | brad%candice@maccs.dcss.mcmaster.ca | bradford@maccs.dcss.mcmaster.ca (archaic) ----- 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!dwp
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (02/22/91)
Date: 02-21-91 (05:11) Number: 1273 of 1274 To: GARY SMITH Refer#: 1230 From: CHRIS WATERS Read: NO Subj: Ans Tc Magnet For Interpr Status: PUBLIC MESSAGE Conf: FORTH (58) Read Type: GENERAL (+) Reply To: wmb@MITCH.ENG.SUN.COM Subject: Conditional compilation > 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. This is true, though the same argument could be leveled against using paren as a comment character!! Personally, I don't relish the idea of using BEGINCOMMENT ... ENDCOMMENT. 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> Some may argue that this goes against hysterical (er, historical) usage. To this I reply, I can show you at least one commercial Forth (albeit a discontinued one) that uses IFTRUE as an alias for IF (to correspond to the IFFALSE, which compiled a -?BRANCH). And the Forth may be discontinued, but I believe there is still one company (Rolodex, no less) that still uses it as the basis for a couple of their products. Also, I think the names [IF] [ELSE] [THEN] are more consistent with standard Forth usage, and easier to understand. Comments anyone? >Interestingly, within hours of announcing their existence, I >received an enthusiastic personal email reply from a person who >was very glad to have them. Certainly, having conditional compilation (conditional interpretation?) is better than not having it. Did you offer this person a choice between IFTRUE and query-paren? ;) --- Tag1.2 * And just why _do_ we need more lerts, anyway? --- * 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