wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (02/14/91)
> The challenge I proposed was to find _one_ non-Forth book > (English or not) in which embedding a decimal point in a number implied > it was double precision integer How many non-C books imply that the presence of an "L" implies a 32-bit number? How about "0x" for hexadecimal? ANS Forth has a function >FLOAT that a program may call to parse a floating point number. The syntax that >FLOAT will accept is not necessarily the same as the syntax that the text interpreter will accept. >FLOAT may be used to import externally-generated ASCII floating point numbers. Similarly, in C, the number syntax that the C compiler accepts is not necessarily the same as the syntax that scanf() accepts. Mitch
warnock@stars.gsfc.nasa.gov (ARCHIE WARNOCK) (02/14/91)
In article <9102131829.AA12430@ucbvax.Berkeley.EDU>, wmb@MITCH.ENG.SUN.COM (Mitch Bradley) writes... >How many non-C books imply that the presence of an "L" implies a 32-bit >number? How about "0x" for hexadecimal? I passed this by and almost didn't bother to post a reply and later realized that some people might not have realized you were joking. Certainly, I have far too much respect for your intelligence and for what you've contributed to the Forth community to believe you'd offer such a specious argument with a straight face. For those who may not get the joke, the distinction is that 0x15 or 15L don't have other interpretations in common usage, while 1.5 does. I could post you screen dumps from a spreadsheet, from a database, from ASCII output from _any_ other computer languages, from prompts for user input and from a vast, vast majority of book, magazines and other common sources of information. All of them would interpret 1.5 as a decimal number. Some might interpret 1,5 as a decimal number instead but none would interpret it as an integer (long or otherwise). Archie
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (02/15/91)
> (Mitch Bradley) writes... > >How many non-C books imply that the presence of an "L" implies a 32-bit > >number? How about "0x" for hexadecimal? > I passed this by and almost didn't bother to post a reply and later > realized that some people might not have realized you were joking. > Certainly, I have far too much respect for your intelligence and for > what you've contributed to the Forth community to believe you'd offer > such a specious argument with a straight face. I appreciate your being willing to give me the benefit of the doubt, but I wasn't joking. In my opinion, the distinction between the syntax that a programming language chooses for its own source code and the syntax that it accepts for external data is an important one. I completely agree that Forth's historical use of a decimal point to signify a double precision number *within Forth source code* is entirely stupid. However, I don't agree that said stupidity *within the context of source code* is a fatal flaw. All languages have their syntactic idiosyncracies. This is one of Forth's syntactic idiosyncracies. Dumb as it is, I remain philosophical about it. The requirement for accepting external data is satisfied by the ANS Forth word ">FLOAT" (Basis 15), which accepts most popular floating point number formats. > the distinction is that 0x15 or 15L don't have other interpretations in > common usage, while 1.5 does. This point is entirely valid, and that's precisely why I think that "decimal point => double number" is stupid. However, I don't agree that this issue is of critical importantance. It doesn't keep you from doing anything important, it just means that numbers look a little funny. Everything about Forth looks funny, and this is just one more thing. The application programmer has all the tools he needs to do the "right thing" for the user, and if the programmer has to use funny "spelling" of certain words and numbers within his source code, I can live with that. By the way, if someone can suggest a good solution to the whole number syntax problem *that does not break existing Forth code*, I will happily champion the propsal to the committee. I suppose we could make the presence of a decimal point an ambiguous condition (weasel words meaning that the implementation can do whatever it wants), and suggest that it "ought to" mean a floating point number. A Standard Program would still have to use the "E" notation for its floating point numbers to guarantee an unambiguous interpretation. This would create another problem though: What notation does a standard program use for a double number? (Entering it as 2 single numbers is not portable; it depends on the internal number representation and on the cell size). Mitch Bradley