ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/04/91)
Category 10, Topic 23 Message 1 Sun Jun 02, 1991 R.BERKEY [Robert] at 22:19 PDT Daniel C. Sobral writes, 28 May 91, > => Category 10, Topic 15 > => Message 21 Sat May 25, 1991 > => R.BERKEY [Robert] at 20:45 PDT ... > => KEY can't input a <RETURN>? In my opinion, the committee > => decision here lacks serious commitment to standardization. > Key accepts anything with 7 bits. I don't agree. The new limitation is in Appendix C, and applies to EKEY as well as KEY: Only the range hex 20-7E is pertinent to this standard, and the semantics of character values outside this range is implementation-defined. Use of the graphic hex 24 (the currency sign) is an environmental dependency. A "Normative Annex", in case that isn't clear, means that the text is part of the Standard, as opposed to being supplementary material. This thing about characters can get confusing real quick. In Forth-83, a "character" was the set of 128 ASCII characters, including both control and graphic characters. In BASIS, a "character" as used for I/O is the set of 95 ASCII graphic characters, {20-7E}, and if the character is visible, i.e., in source code or being displayed with TYPE or EMIT, the currency graphic, '$', or hex 24, cannot be used. A "char" is decimal {32-127}. This value limits inputs to C! FILL and C, among others. By the way, "char" as defined in BASIS15 was changed from {0- 127} to {32-127} _during_ the dpANS vote, which shouldn't have happened. Also, I think it is routine to see 0 <address> C! in Forth. Another common practice which had already been disallowed is: <true-flag> <address> C! In BASIS, a "character" is also a unit of data storage known to be at least 8 bits, although there is no way to store 8-bit data in a "character". These X3.J14 proposals for KEY C! and FILL are the most severe form of change for a language committee, when conversion of previously conforming code is not possible and the syntax is left unchanged. Robert ----- 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
UNBCIC@BRFAPESP.BITNET (06/05/91)
I don't think that the range of input accepted by CHAR or by KEY or by
EKEY have something to do with values that can be C!.... Well, I bet
Mitch will (probably already have) comment on this later.
(8-DCS)
Daniel C. Sobral
UNBCIC@BRFAPESP.BITNETMitch.Bradley@ENG.SUN.COM (06/05/91)
> I don't think that the range of input accepted by CHAR or by KEY or by > EKEY have something to do with values that can be C!.... Well, I bet > Mitch will (probably already have) comment on this later. Here is my sense of what the committee means to say. If a careful reading of Basis implies something else, then we need to fix it. The numerical references are from Basis 15. a) The "character" *data type* is capable of representing numbers from 0 to at least 255. (because: 4.0120 says at least 8 bits, 5.1 says char is a subrange of positive numbers, and all the allowed number representations can (and do) represent 0-255 with the low order 8 bits). b) The "implementation-defined character set" tells how that data type is used to represent the symbols in a human-readable character set. That information includes which subset of the possible values representable by the character data type are actually supported, and the correspondence between their numerical values and graphical representations. c) In the absense of any explicit specification to the contrary, the default specification of (b) includes at least the printable ASCII characters with their usual encodings. Item (a) says what you can put in the character data type. Item (b) says what you get from the outside world through KEY and EMIT . > Another common practice which had already been disallowed is: > > <true-flag> <address> C! CREATE FOO TRUE FOO C! FOO C@ ( n ) On all existing systems I know, the number left on the stack is not a well-formed true flag, and "TRUE =" returns false. What is this example supposed to mean? Mitch.Bradley@Eng.Sun.COM
dcp@world.std.com (David C. Petty) (06/23/91)
In article <676362431.6@egsgate.FidoNet.Org>, Mitch Bradley writes: `> Another common practice which had already been disallowed is: `> `> <true-flag> <address> C! ` `CREATE FOO `TRUE FOO C! FOO C@ ( n ) ` `On all existing systems I know, the number left on the stack is not `a well-formed true flag, and "TRUE =" returns false. ` `What is this example supposed to mean? Well, Mitch, In BASIS 16, section 5.10.1 General Ambiguous Conditions we find: ``Argument type incompatible with specific input parameters.'' While section 5.3 Data Type Compatibility does not list flag as a subrange of char. Since C! takes ( char c-addr -- ) I think it is precisely your example that results in an ``ambiguous condition.'' What is clearly _not_ ambiguous is what all Forth systems do in your example: only store the lower byte of TRUE. Could you comment on this and prehaps discuss the last minute resolution of the EKEY, EKEY?, KEY, KEY? situation as it relates to the char data type? Also I am _sure_ that everyone on the net would appreciate the lyrics to your _Flintstone's Theme_ sing-along at Rochester. -- David C. Petty | dcp@world.std.com | ...!{uunet,bu.edu}!world!dcp /\ POBox Two | CIS: 73607,1646 | BIX, MCIMail: dcp / \ Cambridge, MA | `Whatsoever thou doest to the tip, / \ 02140-0001 USA | doest thou likewise to the ring.' - RAG /______\
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (06/25/91)
Category 10, Topic 23 Message 9 Mon Jun 24, 1991 D.RUFFER [Dennis] at 00:22 EDT Re: B.RODRIGUEZ2 [Brad] > Obviously BCD is not allowed Why not? Do not two BCD digits "fit" into a byte and doesn't that combination become a number that's less than 255? I don't understand how you conclude that BCD is "not allowed". > My understanding was that the ISO character set (ASCII with some > international tweaks) was mandated by the BASIS. Is this > incorrect? BASIS uses the ... (can't remember the name right now) character set, but I do not think it precludes a standard system from using some other character set. > Those of us who (by choice or necessity) are stingy with our > memory often store boolean flags in byte variables. Is this > practice disallowed by ANS Forth? This has never been portable or "allowed" by any standard. The BASIS does not make it any more acceptable than it ever was. However, since there is not typing in Forth, there is nothing to stop you from doing it. Since a true flag is non-zero and a false flag is zero, it will probably even work. {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) (07/01/91)
Category 10, Topic 23
Message 11 Sat Jun 29, 1991
L.ZETTEL at 21:25 EDT
This is one committee member's private, unofficial assesment of where BASIS17
stands with regard to the material in message 8:
BCD has been specifically disallowed. The relevant section of 5.3.1 now
reads:
" This standard allows one's complement, two's complement, or sign-magnitude
representations. In these systems arithmetic zero is represented as the
value of a single cell with all bits clear. This enumeration of allowed
number representations specifies a correspondence between numbers and bit
masks."
And that is why it was done. The problem is that in twos complement the
binary representation of ten is ... 0000 1010 . In BCD it is (I believe)
... 0001 0000 . There is NO WAY the customary hacks for constructing masks
with arithmetic could work the same way in both systems. They _will_ work in
one's complement as long as the sign bit is not set (i. e., arithmetic is
done on positive values only). Nobody seems to be sure about signed-
magnitude, but that is looked on as pretty much only of academic interest.
-LenZ-
-----
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) (07/01/91)
Category 10, Topic 23
Message 12 Sat Jun 29, 1991
L.ZETTEL at 21:56 EDT
The subject of character set is still a little fuzzy around the edges (in my
opinion). The character set specification is now in section 6.3 Standard
Character Set. Above the table of characters we have the following
paragraph:
"The following defines the value assignments and graphic forms for standard
characters. These values and graphics are taken directly from ANS X3.4-1974
(ASCII) and ISO-646-1983, International Reference Version. Only the range
hex 20-7E is pertinent to this standard, and the semantics of character
values outside this range is implementation-defined. Use of the graphic hex
24 (the currency sign) is an environmental dependency."
The following is clear: If your system handles a character specified in ASCII
as a number from hex 20 to hex 7E, the number has to correspond to the
character in the table. A standard system can handle a number outside that
range as a character and call it anything it wants.
Not so clear: whether a system that can handle ONLY the characters used in
the CORE words (no lower case, for instance) can claim to be a standard
system. Similarly not clear: what characters a system MUST enable a user to
enter from the standard input device.
-LenZ-
-----
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) (07/01/91)
Category 10, Topic 23
Message 13 Sat Jun 29, 1991
L.ZETTEL at 21:58 EDT
WIth regard to TRUE FOO C! FOO C@ : The value on the stack at the end of the
sequence will not be a well-formed flag unless the size of a character and
the size of a cell are the same (odd, but legal). On any ASCII Standard
system (assuming we get there) the result would be treated by IF as true.
Citing 4.0790 true : " A 'true' flag returned by a standard word is a single-
cell value with all bits set." The above construct therefore can not be
used by itself to leave a flag after a system word. It _would_ be legal in a
standard _program_.
-LenZ-
-----
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) (07/01/91)
Category 10, Topic 23 Message 14 Sun Jun 30, 1991 B.RODRIGUEZ2 [Brad] at 12:11 EDT To Dennis Ruffer: a) the paragraph I was responding to said > the 'character' *data type* is capable of representing numbers > from 0 to at least 255. (because: 4.0120 says at least 8 bits, > 5.1 says char is a subrange of positive numbers, and all the > allowed number representations can (and do) represent 0-255 with > the low order 8 bits). It was this phrase "the allowed number representations" that caught my eye. I was not aware that such a list existed, but IF it does, and IF the above paragraph is a corrrect interpretation of the BASIS, then BCD must not be allowed (because BCD cannot represent numbers "from 0 to at least 255" in a byte). Or was the above paragraph wrong? Upon second reading, however, I see that BCD can meet these requirements, as long as a "character" is three BCD digits. Is this the intent of the committee? Clarification please. b) I'll need to print out BASIS17 to quote applicable sections, but I seem to recall several paragraphs (e.g. EMIT) which to all intents would mandate the ASCII/ISO character set. (At least, Baudot and EBCDIC would not satisfy the requirements!) And I believe that the character set was made a "normative" annex -- but I'm not sure, which is why I asked the question. c) Actually, storing flags in character variables was portable in the 79 Standard. The 83 Standard invalidated the practice. - 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
ForthNet@willett.pgh.pa.us (ForthNet articles from GEnie) (07/01/91)
Category 10, Topic 23 Message 15 Sun Jun 30, 1991 B.RODRIGUEZ2 [Brad] at 12:31 EDT Obviously Len Zettel's reply and mine have "crossed in the email." Many thanks, Len, for the commentary, and I hope that if your understanding of BASIS17 is incorrect (which I doubt), some other TC member will jump in here. a) You've answered all my number-representation questions. (Except one: who uses ones-complement these days?) b) I found your comment re. character sets a bit confusing: > If your system handles a character specified in ASCII as a number > from hex 20 to hex 7E, the number has to correspond to the > character in the [ISO-646] table. Does this mean that a) if your system uses ASCII, it has to use ISO ASCII, or that b) if your system uses any characters which can be represented in ASCII, it has to use the ASCII coding? Put another way: must the letter "A" be represented as 41 hex in a standard system? Or can I use EBCDIC coding, as long as I don't use character codes in the range 20-7E hex? c) As I understand your remarks, the phrase TRUE FOO C! FOO C@ would not return a well-formed flag, and could not be used in the ANSI standard for the kernel, but it _would_ conform to the ANSI standards for programs. That is, standard _programs_ can be written using character variables for flags. Is this correct? - 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