Re: Current Standings: Number Prefixes

The Beez' <hansoft@xxxxxxxxxxx> writes:
- Second, Forth seems to be moving in a direction (LOCALS, escaped
strings, constants) where it doesn't seem to matter whether I'm using
C or Forth. Forth EXPOSES its internals and those proposals do every
effort to HIDE them again.

That seems a curious claim to make wrt escaped strings and number
prefixes (I guess that's what you mean with constants). How do these
proposals hide anything?

- Third, every effort was taken to make sure that parts of Forth are
optional. This proposal violates that by embedding it in the text
interpreter.

I see two views of "optional" at work here (conveniently clouded by
the use of passive voice):

1) The standard text makes lots of things optional, in particular all
the extension word sets; i.e., a system may or may not implement the
extension and may still claim to be standard. The present proposal
follows this tradition and also proposes number prefixes as an
optional extension. I.e., even if it gets into the Forth200x
document, you can still have a Forth 200x system that does not
implement number prefixes.

2) Some systems make extensions optional in the sense that they can be
loaded in the system or not. This may be a little more difficult with
an extension that extends text interpreter number conversion than with
an extension that just provides additional words, but it is possible
(actually one way to achieve this was recently discussed in the thread
on "number parsing hooks":
<2007Aug4.093801@xxxxxxxxxxxxxxxxxxxxxxxxxx> ff.).

Note that the double-number and Floating-Point wordsets also "embed"
themselves in the text interpreter. In Gforth the FP conversion is
not there from the start, it embeds itself later.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2007: http://www.complang.tuwien.ac.at/anton/euroforth2007/
.

Relevant Pages

  • Re: Improved Extension Process Proposal
    ... but differing in how reports become final, and what finalization means not just to the proposed extension, but to actual users. ... popularity contests independently of the SRFI process? ... 'unwashed masses' of c.l.s as you seem to view them, ... ensuring that extensions proposals become truely avaiable, ...
    (comp.lang.scheme)
  • Re: IN: Governor Daniels Proposes Indianapolis Outer Belt
    ... They probably are referring to: ... widening OR-217 to 6 through lanes. ... There are a number of proposals ... signed as an extension of OR 18. ...
    (misc.transport.road)
  • Re: Lcc win overflow handling
    ... 'standard C' versions of the checking code. ... If he wants the best overflow ... then seeing alternative proposals might be ... If he is sure that he already has the best possible design, ...
    (comp.lang.c)
  • Re: gets() is dead
    ... of nested exception handling packages in Standard C. ... With undefined behavior, you typically get a random crash leaving ... When submitted appropriately within the process, proposals are taken ... you people just don't care about important capability issues. ...
    (comp.lang.c)
  • Re: 200x wish list
    ... suggestions for improvement to ANS that aren't covered by the 200x ... If you want your suggestions to be considered for a future standard, ... your proposals, ... to the compiler. ...
    (comp.lang.forth)