Re: Current Standings: Number Prefixes

The Beez' wrote:
[ ] conforms to ANS Forth.
[ ] already implements the proposal in full since release [ ].
[ ] implements the proposal in full in a development version.
[ ] will implement the proposal in full in release [ ].
[ ] will implement the proposal in full in some future release.
There are no plans to implement the proposal in full in [ ].
[X] will never implement the proposal in full.

...
Sorry, I've not discussed these features for some time, but I had
other priorities. Still, I'd like to make my stand. In short: you
shouldn't burden the text interpreter with stuff like this. It's so
unForth-like. It makes fat Forths - or worse - forces people to make
fat Forths, just to be compliant. If it had been an extra word - like
CHAR - I'd feel a lot better. This is an ugly kludge IHMO. I respect
the people who designed and used it and I don't want to appear lacking
respect, but this is a thing I cannot support.

I never liked the double word number (with the embedded dot) as well.
See "my" implementation of the double word set.

So far the voting where 4tH is concerned.

Hans Bezemer




Hans,

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. 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

: someword ( u1 -- u2) 256 * hc1 + ;


The alternative appears even more kludgey (sp?):

: someword ( u1 -- u2) 256 * [ hex 0EC decimal ] literal + ;

So, in my mind, the sacrifice of elegance in the compiler for the sake of
programmer's ease, in this instance, is somewhat justifiable:

: someword ( u1 -- u2) 256 * $0EC + ;



Regards,
Krishna
.