Re: Current Standings: Number Prefixes

I have a great deal of sympathy with your position on this matter, and I, like
you, have given some thought to whether or not to implement number prefixes. It
is most certainly an inelegant kludge to the interpreter/compiler. However, my
intent to back this proposal is based on my experience trying to port programs,
written for other Forths, which used number prefixes. It wasn't worth the effort
to try to replace every instance of something like "$0EC" with something like
"H# 0EC", where "H#" is a parsing word.

Krishna,

Like you, I do have a great deal of understanding for your position or
any other programmer who has to deal with Forth on a professional
basis. I have the luxury of using Forth and designing 4tH for other
purposes, although there is a major bank in Holland who would not like
to do with out their 4tH batch jobs. Due to the hour I did not have
the time to motivate my position, which I will do here:

- First, 4tH was designed to be small, simple and elegant. This
proposal is not.
- 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.
- 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 know there are forces that say "that a standard system
is a system that supports anything, so I don't have to wonder whether
it is there". Note that this minimizes the number of possible
implementations and designs, something that Forth was once known for.
A lot of "inventions" and diversity came from the ability to do that.
Instead of joining all different implementations, this direction (and
this proposal) diverts them. "Hell, why should I bother even to look
at ANS. I don't want to make my compiler like that, so let's ignore it
completely". Note even Reva and RetroForth give ANS a thought (an
interface, but anyway).
- Fourth, I'm sure Chuck doesn't like it ;-)

Also, from the programmer's perspective,
it is not reasonable to have to do something like the following, when we have a
mixed base calculation, which is a common occurrence:

HEX
0EC CONSTANT hc1
DECIMAL

My proposal (a separate word) fixes that too. No need to change the
interpreter.

Hope this will clarify my point of view. Krishna, thank you very much
for your reaction.

Hans Bezemer


.