From:	Andreas Kochenburger
Subject:	Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	Mon, 17 Jan 2005 18:40:37 +0100

Just for fun (and perhaps useful for Forth-200x):

Extracts from the current standard docs say:

8.3.2 Text interpreter input number conversion
When the text interpreter processes a number that is immediately
followed by a decimal point and is not found as a definition name, the
text interpreter shall convert it to a double-cell number.

A.12.3.7 Text interpreter input number conversion
The Technical Committee has more than once received the suggestion
that the text interpreter in Standard Forth systems should treat
numbers that have an embedded decimal point, but no exponent, as
floating-point numbers rather than double cell numbers. This
suggestion, although it has merit, has always been voted down because
it would break too much existing code; many existing implementations
put the full digit string on the stack as a double number and use
other means to inform the application of the location of the decimal
point.

My common sense says:

This was and is nostalgic nonsense. When a Forth system "has"
fp-numbers, the default behavior must be to interpret all numbers with
a decimal point as fp-number. FLOATS outrule DOUBLES.
(Switching the default interpretation can be trivially implemented by
a single system variable)

Your vote?

Cheers, Andreas

http://www.minforth.net.ms/

From:	Jorge Acereda
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE,
Date:	Wed, 19 Jan 2005 15:58:02 +0100

On 19 Jan 2005 13:46:50 GMT, Albert van der Horst
wrote:
> In article ,
> Jorge Acereda wrote:
> >Agreed. We wouldn't be discussing here what 1.0 means if we had such
> >mechanism visible to the user. There's no point in spending effort
> >solving a problem that you can easily avoid. Just let it be what the
> >user wants. When you add to that the fact that vectoring that word
> >opens lots of new possibilies, I just can wonder this mechanism wasn't
> >specified in the previous standard.
>
> See above. A standard specifying it would become an implementation
> standard rather than a language standard.

I fail to see why. What freedom are you taking from the implementor?
What implementation decisions would be ruled out by such decision? You
are just providing a hook (and a very useful one, IMHO), I don't see
how can that limit the implementor or complicate things on his side.

See you,
Jorge Acereda

From:	Elizabeth D. Rather
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE,not double-number TEN
Date:	Wed, 19 Jan 2005 10:29:28 -0800

"Jorge Acereda" wrote in message
news:mailman.72.1106146698.527.comp.lang.forth@ada-france.org...
> > ...
> > See above. A standard specifying it would become an implementation
> > standard rather than a language standard.
>
> I fail to see why. What freedom are you taking from the implementor?
> What implementation decisions would be ruled out by such decision? You
> are just providing a hook (and a very useful one, IMHO), I don't see
> how can that limit the implementor or complicate things on his side.

This requires number conversion to be a vectored function, which has a lot
of implications about how the text interpreter and compiler are factored. I
have nothing personally against number conversion being vectored, but don't
think the standard should mandate such things.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

From:	Albert van der Horst
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE,not double-number TEN
Date:	19 Jan 2005 20:21:09 GMT

In article <10ut9oed0qm8f05@news.supernews.com>,
Elizabeth D. Rather wrote:
>
>This requires number conversion to be a vectored function, which has a lot
>of implications about how the text interpreter and compiler are factored. I
>have nothing personally against number conversion being vectored, but don't
>think the standard should mandate such things.

In particular ciforth would have to be completely redesigned.
( 314 is interpreted by finding 3 in the ONLY vocabulary.)

I hesitate to propose the PREFIX keyword,
because it would have a comparable impact on implementations.
Still I think it is at least about function, not implementation.

PREFIX : specify that the latest word defined is found in the
search order, even if it is not followed by white space.
It will typically set a flag in a header. Compare with IMMEDIATE.

>
>Cheers,
>Elizabeth

>
>
>--
>==================================================
>Elizabeth D. Rather (US & Canada) 800-55-FORTH
>FORTH Inc. +1 310-491-3356
>5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
>Hawthorne, CA 90250
>http://www.forth.com
>
>"Forth-based products and Services for real-time
>applications since 1973."
>==================================================
>
>

--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

From:	Anton Ertl
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	Tue, 18 Jan 2005 16:33:17 GMT

Andreas Kochenburger writes:
>Just for fun (and perhaps useful for Forth-200x):
>
>Extracts from the current standard docs say:
>
>8.3.2 Text interpreter input number conversion
>When the text interpreter processes a number that is immediately
>followed by a decimal point and is not found as a definition name, the
>text interpreter shall convert it to a double-cell number.
>
>A.12.3.7 Text interpreter input number conversion
>The Technical Committee has more than once received the suggestion
>that the text interpreter in Standard Forth systems should treat
>numbers that have an embedded decimal point, but no exponent, as
>floating-point numbers rather than double cell numbers. This
>suggestion, although it has merit, has always been voted down because
>it would break too much existing code; many existing implementations
>put the full digit string on the stack as a double number and use
>other means to inform the application of the location of the decimal
>point.
>
>My common sense says:
>
>This was and is nostalgic nonsense. When a Forth system "has"
>fp-numbers, the default behavior must be to interpret all numbers with
>a decimal point as fp-number.

ANS Forth says different, therefore ANS Forth systems behave
differently and ANS Forth programs rely on that behaviour. Breaking
existing standard programs is a big no-no. Therefore, you have no
chance that there will be a consensus in the direction you wish.

>Your vote?

No.

What might be doable is to have a word (or a set of words that change
the behaviour). Maybe something like:

|set-dotted-number-input ( n1 -- n2 )
|
|If n1 is 0, numbers containing a . will be interpreted as doubles
|(default). If n1 is 1, numbers containing a . will be interpreted as
|floats. Passing other numbers is ambiguous. n2 represents the
|previous behaviour (if you pass it to set-dotted-number, the previous
|behaviour will be restored).

The downside of such a proposal is that we get another case of text
interpretation state, like BASE (which we may make mostly unnecessary
using prefixes (or, as Albert calls them, denotations)). For floats
it is relatively easy to be independent of this state, by always using
the "1e" style. But for doubles, we would need another way of writing
them.

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	Andreas Kochenburger
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	Wed, 19 Jan 2005 10:50:17 +0100

On Tue, 18 Jan 2005 16:33:17 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:
>The downside of such a proposal is that we get another case of text
>interpretation state, like BASE (which we may make mostly unnecessary
>using prefixes (or, as Albert calls them, denotations)). For floats
>it is relatively easy to be independent of this state, by always using
>the "1e" style. But for doubles, we would need another way of writing
>them.

Another ambiguity of the 1E-style (I like that one ;-) is

1e -> fp 1
1.e -> fp 1
1.e0 -> fp 1
hex 1e -> single 30
hex 1.e -> double 30
hex 1.e0 -> double 480

So far for not breaking exisiting code which relies on that mess.

Cheers, Andreas

http://www.minforth.net.ms/

From:	Albert van der Horst
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	19 Jan 2005 14:47:32 GMT

In article <2005Jan18.173317@mips.complang.tuwien.ac.at>,
Anton Ertl wrote:
>
>The downside of such a proposal is that we get another case of text
>interpretation state, like BASE (which we may make mostly unnecessary
>using prefixes (or, as Albert calls them, denotations)). For floats

To be precise any notation that generates a nameless object is
a denotation (this is just compiler theory terminology):
123.0 (in forth)
S" aap noot" (in forth)
"aap noot" (in c)
( red ==> 0xff0000 , green ==> 0x00ff00, blue ==> 0x0000ff ) (in perl)
And, strictly speaking
:NONAME ... ; (in Forth)

Some Forth's understand $12345
It is an anonymous object generated on the stack.
So it is a denotation.
Most Forth denotations (notable exception: floating point numbers)
consists of a prefix (here $) and the data.

An important class of denotations can be implemented using prefixes,
and indeed adding a prefix mechanism to Forth would go a long
way to allow user-extensibility in this area.

If we write $12345 as ``$ 12345'' we have a situation that can
handled by a portable extension: a word named ``$'' that scans the
input stream. So in fact a general denotation mechanism is already
present in Forth, if we accept that a denotation can be several words.

Now there is this little bit of syntactic sugar. Making $ a
prefix would allow to find it in the dictionary even if the space
were omitted. The rest remains the same, i.e. the interpreter pointer
sits directly after $, ready to interpret the input stream, forcibly
as a hex number, irrespective of BASE.
So prefixes are a general mechanism to add a certain class of
denotations to Forth. It could be argued that suffixes have no
advantage over prefixes ( 019AH versus $019A ) and are unforthish.

$12345 is a denotation , and so is HEX: 12345 in fact

$ is a prefix , and it makes sense to call the above HEX: a prefix.

Prefixes makes one painfully aware that "numbers are state-smart".
There is no salvation from this, or you must use colorforth,
where you have to pick the right color for
your number. But running the prefixes together with the
characters-to-be-parsed alleviates this a bit. It is rather
unexpected that ' or $ should get a word from the console
then execute or compile oeps in 'oeps and $oeps .
A denotation like 'FIND makes it acceptable to think of it
as "just a number" the execution token of FIND, instead of
being aware of all what is going underneath.

ciforth contains the word prefix that is like immediate,
changing the way a word is treated by the interpreter/compiler.
Furthermore ONLY is a vocabulary. It is appropriate that all
number denotations belong in ONLY, which is the minimum search order.
This vocabulary contains every way to start a denotation, including
the digits 0 ...9 that start a regular number.
I want to stress that this is only an implementation method,
and results in ISO compliant behaviour.

In this context adding a $ notation can be done in this way
'ONLY >WID CURRENT !
: $ ; IMMEDIATE PREFIX
DEFINITIONS

(The word PREFIX will be added to ciforth 4.0.6. Up till now
this mechanism was present under the hood, only.)

>the "1e" style. But for doubles, we would need another way of writing
>them.

I hate the confusion caused by this E being a hex number too.
Would a proposal to at least allow an alternative character
stand a chance?
Like allowing 1234.5_4 besides 1234.5E4.

(If I had my way I would have the simple rule:
if it contains a _ , it is fp,
else if it contains a . , it is double,
else a single.
At least this doesn't break existing code.)

>
>- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

From:	Anton Ertl
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	Wed, 19 Jan 2005 21:36:47 GMT

Albert van der Horst writes:
>>the "1e" style. But for doubles, we would need another way of writing
>>them.
>
>I hate the confusion caused by this E being a hex number too.

Not really a confusion, as the hex number tends to be written $1e or
01e, which you probably won't do with an fp number.

>Would a proposal to at least allow an alternative character
>stand a chance?

Not with me. "E" is used for specifying exponents in most other
languages. The problem we have with "." is because we deviated from
usage in other languages.

>Like allowing 1234.5_4 besides 1234.5E4.

I have seen _ used for grouping (e.g. 100_000_000), so this appears to
be a particularly bad choice.

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	Andreas Kochenburger
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	Tue, 18 Jan 2005 19:10:18 +0100

On Tue, 18 Jan 2005 16:33:17 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>ANS Forth says different, therefore ANS Forth systems behave
>differently and ANS Forth programs rely on that behaviour. Breaking
>existing standard programs is a big no-no.

In other words, Forth-200x will continue "dogmatically" with every
aspect of the current ANS behavior?

Cheers, Andreas

http://www.minforth.net.ms/

From:	Jerry Avins
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number
Date:	Tue, 18 Jan 2005 13:30:34 -0500

Andreas Kochenburger wrote:

> On Tue, 18 Jan 2005 16:33:17 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
>
>>ANS Forth says different, therefore ANS Forth systems behave
>>differently and ANS Forth programs rely on that behaviour. Breaking
>>existing standard programs is a big no-no.
>
>
> In other words, Forth-200x will continue "dogmatically" with every
> aspect of the current ANS behavior?
>
>
> Cheers, Andreas
>
> http://www.minforth.net.ms/

I hope so.

Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

From:	Anton Ertl
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	Tue, 18 Jan 2005 18:58:35 GMT

Andreas Kochenburger writes:
>On Tue, 18 Jan 2005 16:33:17 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>ANS Forth says different, therefore ANS Forth systems behave
>>differently and ANS Forth programs rely on that behaviour. Breaking
>>existing standard programs is a big no-no.
>
>In other words, Forth-200x will continue "dogmatically" with every
>aspect of the current ANS behavior?

The plan is certainly to be a compatible extension, i.e., Forth-94
programs should run in Forth-200x. Defined behaviour will stay.
Extensions are done by defining currently-undefined behaviour.

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	John Doty
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number
Date:	Wed, 19 Jan 2005 03:53:59 -0700

Anton Ertl wrote:

> ANS Forth says different, therefore ANS Forth systems behave
> differently and ANS Forth programs rely on that behaviour. Breaking
> existing standard programs is a big no-no. Therefore, you have no
> chance that there will be a consensus in the direction you wish.

So the purpose of this process isn't to clean up the mess, but merely
pile *additional* kludges atop an already excessively complex standard?

-jpd

From:	Brad Eckert
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE,not double-number TEN
Date:	19 Jan 2005 15:45:03 -0800

I see the value of a language standard as opposed to an implementation
standard when it comes to code size and efficiency. But parsing numbers
isn't one of those areas where speed or compiler optimizations are
important.

The problem I run into is that all of the Forths I use implement the
interpreter in different ways so changing the interpreter in a portable
way is very hard. Even making such code portable among a set of
commonly used Forths is a pain. I could redefine QUIT and all of the
words it uses. That would be portable but then maybe it throws away the
efficiency ANS was supposed to give me.

A redirectable INTERPRET would be very nice to have. Forth Inc factors
its INTERPRET differently than the FIG descendants so you know a lot
more about it than I do. You can't change it without breaking
somebody's code, but I think you can make it a defered word without
breaking any code. AFAIK, ANS provides all the words the user needs to
make her own interpreter: WORD, FIND, STATE, POSTPONE LITERAL, etc. If
some code has a special parsing need, it should be able to add it to
the interpreter somehow.

Shooting for a language standard may be ideologically pure, but it hits
me where it hurts for no good reason. Where code generation is not
affected, why not introduce a wee bit of implementation detail?
--
Brad

From:	Brad Eckert
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	20 Jan 2005 08:07:31 -0800

I think UNKNOWN would be more valuable than INTERPRET. It's sort of an
escape hatch. ENVIRONMENT tells you the hatch is available.

But pure ANS locks me out of the interpreter, which I think it
shouldn't do.

--
Brad

From:	rickman
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number
Date:	Mon, 17 Jan 2005 16:27:00 -0500

Andreas Kochenburger wrote:
> Just for fun (and perhaps useful for Forth-200x):
>
> Extracts from the current standard docs say:
>
> 8.3.2 Text interpreter input number conversion
> When the text interpreter processes a number that is immediately
> followed by a decimal point and is not found as a definition name, the
> text interpreter shall convert it to a double-cell number.
>
> A.12.3.7 Text interpreter input number conversion
> The Technical Committee has more than once received the suggestion
> that the text interpreter in Standard Forth systems should treat
> numbers that have an embedded decimal point, but no exponent, as
> floating-point numbers rather than double cell numbers. This
> suggestion, although it has merit, has always been voted down because
> it would break too much existing code; many existing implementations
> put the full digit string on the stack as a double number and use
> other means to inform the application of the location of the decimal
> point.
>
> My common sense says:
>
> This was and is nostalgic nonsense. When a Forth system "has"
> fp-numbers, the default behavior must be to interpret all numbers with
> a decimal point as fp-number. FLOATS outrule DOUBLES.
> (Switching the default interpretation can be trivially implemented by
> a single system variable)
>
> Your vote?

Even if a vote says changing this is supported, this is not a complete
change as there is no proposal to replace the current functionality of a
double number input. What will replace the trailing decimal point?

--

Rick Collins

rick.collins@XYarius.com

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design http://www.arius.com
4 King Ave. 301-682-7772 Voice
Frederick, MD 21701-3110 GNU tools for the ARM http://www.gnuarm.com

From:	Andreas Kochenburger
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	Tue, 18 Jan 2005 12:38:04 +0100

On Mon, 17 Jan 2005 16:27:00 -0500, rickman
wrote:
>
>Even if a vote says changing this is supported, this is not a complete
>change as there is no proposal to replace the current functionality of a
>double number input. What will replace the trailing decimal point?

How about
..01 -> fp 0.01
0.1 -> fp 0.1
01. -> double 1
1. -> double one
1.0 -> fp 1
10. -> double ten ?

IIRC older Forths had a variable called DPL which indicated the
decimal point location after number conversion, I guess mostly to
support fixed point arithmetics eg. for financial arithmetics.

Since DPL is not in the current standard, IMO it is pretty annoying to
have to enter or read-in-&-convert 1.0 to 1E or such.

Cheers, Andreas

http://www.minforth.net.ms/

From:	Brad Eckert
Subject:	Re: denotations Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	19 Jan 2005 15:01:30 -0800

Extensible denotation handling also allows the user to add things like
a dot parser. A dot parser handles XXX.YYY by searching wordlist XXX
for word YYY and compiling/interpreting as required.

The notation should make clear what kind of number it is because
ambiguity may break library code. But if we can't agree on which
formats are acceptable, we should at least provide a standard way for a
library to plug in its own number parser.

Brad

From:	Guido Draheim
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number
Date:	Tue, 18 Jan 2005 09:32:38 +0100

Andreas Kochenburger wrote:
> Just for fun (and perhaps useful for Forth-200x):
>
> [...]
> My common sense says:
>
> This was and is nostalgic nonsense. When a Forth system "has"
> fp-numbers, the default behavior must be to interpret all numbers with
> a decimal point as fp-number. FLOATS outrule DOUBLES.
> (Switching the default interpretation can be trivially implemented by
> a single system variable)
>

Btw, we should have a common understanding of specifying
hex numbers without BASE - it's used so often that I feel
all systems do have some kind of number prefix for that.
We had a discussion about base-prefixes a while back but
it was not proposed for standardization so far. -- guidod

From:	Jorge Acereda
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE,
Date:	Tue, 18 Jan 2005 23:29:17 +0100

On 17 Jan 2005 10:00:25 -0800, Brad Eckert wrote:
> The interpreter's number handler should be a defered word or vector.
>
> The ANS standard specifies very few variables, like STATE and BASE. It
> could specify a variable to hold the xt of the number handler.
> ENVIRONMENT would tell you if the system allows you to re-vector it.
> Brad

Agreed. We wouldn't be discussing here what 1.0 means if we had such
mechanism visible to the user. There's no point in spending effort
solving a problem that you can easily avoid. Just let it be what the
user wants. When you add to that the fact that vectoring that word
opens lots of new possibilies, I just can wonder this mechanism wasn't
specified in the previous standard.

Jorge Acereda

From:	Albert van der Horst
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	19 Jan 2005 13:46:50 GMT

In article ,
Jorge Acereda wrote:
>> The ANS standard specifies very few variables, like STATE and BASE. It
>> could specify a variable to hold the xt of the number handler.

When was the last time you beat your wife? Your proposal
assumes there is such a thing in a system like the xt of the
number handler. In some implementations there just isn't.
You are not able to understand that there are guys who just
don't beat their wife, because they ain't got one.

If anything a standard should keep away from imposing implementation
restrictions on standard systems.

>> ENVIRONMENT would tell you if the system allows you to re-vector it.
>> Brad
>
>Agreed. We wouldn't be discussing here what 1.0 means if we had such
>mechanism visible to the user. There's no point in spending effort
>solving a problem that you can easily avoid. Just let it be what the
>user wants. When you add to that the fact that vectoring that word
>opens lots of new possibilies, I just can wonder this mechanism wasn't
>specified in the previous standard.

See above. A standard specifying it would become an implementation
standard rather than a language standard.

>
> Jorge Acereda

--

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

From:	Elizabeth D. Rather
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE,not double-number TEN
Date:	Tue, 18 Jan 2005 16:57:54 -0800

"Jorge Acereda" wrote in message
news:mailman.70.1106087372.527.comp.lang.forth@ada-france.org...
> On 17 Jan 2005 10:00:25 -0800, Brad Eckert
wrote:
> > The interpreter's number handler should be a defered word or vector.
> >
> > The ANS standard specifies very few variables, like STATE and BASE. It
> > could specify a variable to hold the xt of the number handler.
> > ENVIRONMENT would tell you if the system allows you to re-vector it.
> > Brad
>
> Agreed. We wouldn't be discussing here what 1.0 means if we had such
> mechanism visible to the user. There's no point in spending effort
> solving a problem that you can easily avoid. Just let it be what the
> user wants. When you add to that the fact that vectoring that word
> opens lots of new possibilies, I just can wonder this mechanism wasn't
> specified in the previous standard.

ANS Forth didn't specify a vectored number conversion mechanism because that
is an implementation issue, not a semantics issue. We were attempting to
specify Forth semantically and avoid implementation specification as much as
possible. AFAIK nothing is required to be vectored. That said, many Forths
do vector it, especially those with an optional FP package (because that's
the only way that makes sense to add an optional FP).

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

From:	Jorge Acereda
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE,
Date:	Thu, 20 Jan 2005 01:14:10 +0100

On 19 Jan 2005 15:45:03 -0800, Brad Eckert wrote:
>
> A redirectable INTERPRET would be very nice to have. Forth Inc factors
> its INTERPRET differently than the FIG descendants so you know a lot
> more about it than I do. You can't change it without breaking
> somebody's code, but I think you can make it a defered word without
> breaking any code. AFAIK, ANS provides all the words the user needs to
> make her own interpreter: WORD, FIND, STATE, POSTPONE LITERAL, etc. If
> some code has a special parsing need, it should be able to add it to
> the interpreter somehow.

In my ideal word, I would be happy with a vectored UNKNOWN ( addr len
-- ) word (called when the dictionary search fails). And given that it
would be easy to extend the interpreter (and we are in my ideal world
where there's no legacy code), I would remove the fat, ugly and slow
>NUMBER from core and leave just a single-cell version.

Would INTERPRET be more flexible than this UNKNOWN?

Greetings,
Jorge Acereda

From:	Brad Eckert
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	17 Jan 2005 10:00:25 -0800

The interpreter's number handler should be a defered word or vector.

The ANS standard specifies very few variables, like STATE and BASE. It
could specify a variable to hold the xt of the number handler.
ENVIRONMENT would tell you if the system allows you to re-vector it.
Brad

From:	Albert van der Horst
Subject:	denotations Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	18 Jan 2005 13:58:14 GMT

In article <1105984825.255239.66590@z14g2000cwz.googlegroups.com>,
Brad Eckert wrote:
>The interpreter's number handler should be a defered word or vector.
>
>The ANS standard specifies very few variables, like STATE and BASE. It
>could specify a variable to hold the xt of the number handler.
>ENVIRONMENT would tell you if the system allows you to re-vector it.

As you all know by now, I am of the opinion that
the "number" handler should be extensible and modular
extending number handling should be oblivious to current number
handling 1)
number handler is a bad name, because it handles strings and
application dependant denotations, such as labels in an assembler.
So lets talk about denotation handling.

1) This is as far as it goes. you are right that some numbers
could be double as well as floating. But in Forth there is no
floating context (I am doing perl at the moment, they are talking
about scalar and array context. It makes me appreciate the
context free ness of Forth.) So the notation shoudl make clear
what kind of number it is. We can't have it any other way in
Forth.

>Brad
>

Groetjes Albert

--
--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

From:	Stephen Pelc
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	Wed, 19 Jan 2005 10:50:23 GMT

On Mon, 17 Jan 2005 18:40:37 +0100, Andreas Kochenburger
wrote:

>My common sense says:
>
>This was and is nostalgic nonsense. When a Forth system "has"
>fp-numbers, the default behavior must be to interpret all numbers with
>a decimal point as fp-number. FLOATS outrule DOUBLES.
>(Switching the default interpretation can be trivially implemented by
>a single system variable)
>
>Your vote?

Breaking existing code is a no-no for acceptability.

The existing functionality is not good enough.

The root cause is that the same character is used as a
double number indicator and a floating point indicator.
The solution is to let the user change this.

Assume the existence of two variables.

VARIABLE DP-CHAR CHAR . DP_CHAR !
\ *G Holds the character used to specify double numbers.
VARIABLE FP-CHAR CHAR . DP_CHAR !
\ *G Holds the character used to specify floating point numbers.

: FpDutch \ --
\ *G Specify the double and float indicators for Dutch.
[char] , fp-char ! [char] . dp-char !
;

: FpUK \ --
\ *G Specify the double and float indicators for UK English.
[char] . fp-char ! [char] , dp-char !
;

: FpAns \ --
\ *G Specify the double and float indicators for ANS Forth.
[char] . fp-char ! [char] . dp-char !
;

The advantages of this scheme are
1) By making FpAns the default, the system is ANS compliant
"out of the box".
2) Users can do whatever they want.

MPE has used this scheme for a number of years and had no
complaints about it from users.

As a side note, we have also introduced a variable IGN-CHAR
(by default set to ':') to specify a character that is ignored
during number input. This allows us to use
1234:ABCD
to improve readability of 32 bit hexadecimal or binary
numbers.

Stephen

--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

From:	Anton Ertl
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	Wed, 19 Jan 2005 12:36:44 GMT

stephenXXX@INVALID.mpeltd.demon.co.uk (Stephen Pelc) writes:
>The existing functionality is not good enough.
>
>The root cause is that the same character is used as a
>double number indicator and a floating point indicator.

Not in AnS Forth. The root cause is that the FP number input syntax
in ANS Forth is significantly different from that in other languages,
and also from the F. output syntax.

>The solution is to let the user change this.
>
>Assume the existence of two variables.
>
>VARIABLE DP-CHAR CHAR . DP_CHAR !
>\ *G Holds the character used to specify double numbers.
>VARIABLE FP-CHAR CHAR . DP_CHAR !
>\ *G Holds the character used to specify floating point numbers.
>
>: FpDutch \ --
>\ *G Specify the double and float indicators for Dutch.
> [char] , fp-char ! [char] . dp-char !
>;
>
>: FpUK \ --
>\ *G Specify the double and float indicators for UK English.
> [char] . fp-char ! [char] , dp-char !
>;
>
>: FpAns \ --
>\ *G Specify the double and float indicators for ANS Forth.
> [char] . fp-char ! [char] . dp-char !
>;
>
>The advantages of this scheme are
>1) By making FpAns the default, the system is ANS compliant
>"out of the box".
>2) Users can do whatever they want.

Disadvantage: Every piece of code has to save and restore these
variables, or you have to set them again after any use (and libraries
using these conventions are not compatible with each other).

To alleviate this disadvantage, while we may want to give the users a
way to switch the interpretation of "1.1" between double and float, we
also want to have a syntax for which the interpretation does not
switch. For floats we have it: "1.1e". For doubles we don't have it.
Maybe we could let the base-prefix serve double duty here: "&1.1"
would be the double with the decimal value 11. What do you think?

>As a side note, we have also introduced a variable IGN-CHAR
>(by default set to ':') to specify a character that is ignored
>during number input. This allows us to use
> 1234:ABCD
>to improve readability of 32 bit hexadecimal or binary
>numbers.

For the reasons above, I would prefer a fixed set of ignored
characters; I don't see a point in making that switchable, at least
for source code (>NUMBER/CONVERT is a different issue).

- 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.complang.tuwien.ac.at/forth/ansforth/forth200x.html

From:	Stephen Pelc
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	Thu, 20 Jan 2005 09:53:24 GMT

On Wed, 19 Jan 2005 12:36:44 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>stephenXXX@INVALID.mpeltd.demon.co.uk (Stephen Pelc) writes:
>>The existing functionality is not good enough.
>>
>>The root cause is that the same character is used as a
>>double number indicator and a floating point indicator.
>
>Not in AnS Forth. The root cause is that the FP number input syntax
>in ANS Forth is significantly different from that in other languages,
>and also from the F. output syntax.

After some reflection, I concede that you are right in terms
of the ANS standard. However, Forth is an extensible interactive
language. The common input and output words should be useful
for applications. Requiring application entry of floating
point numbers to include an E, e.g. 0.001e0 is simply shooting
yourself in the foot. Vendors modify their systems to provide
facilities that application developers want and need. If the
need is demanding enough, MPE will do it at the expense of
standards compliance and complexity.

The system I proposed allows you to use different indicators
for floats and double integers while being easy to revert to
standards compliance.

>Disadvantage: Every piece of code has to save and restore these
>variables, or you have to set them again after any use (and libraries
>using these conventions are not compatible with each other).

This leads to the question of how to revert to compliance,
which is just a question of defining a name, e.g.
ANS-COMPLIANT ( -- )

A contibution to the MPE benchmark suite gives us a clue as
to how to identify the system you are running on:

: start \ --
S" FORTH-SYS" ENVIRONMENT? IF
S" SP-FORTH" COMPARE 0= IF
S" lib\include\tools.f" INCLUDED
THEN
THEN
;
start

>For the reasons above, I would prefer a fixed set of ignored
>characters; I don't see a point in making that switchable, at least
>for source code (>NUMBER/CONVERT is a different issue).

We used variables for simplicity. Specifying a buffer of minimum
size one cell with zeros meaning no contents is adequate for most
purposes. However, there *will* be an application domain that
requires a separator you haven't included in the list or
requires an indicator that is in the list.

Stephen

--
Stephen Pelc, stephenXXX@INVALID.mpeltd.demon.co.uk
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads

From:	Albert van der Horst
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number TEN
Date:	18 Jan 2005 13:49:04 GMT

In article ,
Andreas Kochenburger wrote:
>My common sense says:
>
>This was and is nostalgic nonsense. When a Forth system "has"
>fp-numbers, the default behavior must be to interpret all numbers with
>a decimal point as fp-number. FLOATS outrule DOUBLES.
>(Switching the default interpretation can be trivially implemented by
>a single system variable)

If you gonna change that, you must take into account national conventions.
We (=Dutch) say
the US deficit is approximately 1.000.000.000.000 euro.
And
my 0,02 euro (two eurocent)

>
>Your vote?

Against. Flat out. Because you can't come up with such a proposal
without at least consider how the denotation for a double should
be. So the proposal is dismissed on formal grounds: incomplete,
hence unusable.

>Cheers, Andreas
>
>http://www.minforth.net.ms/

--

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
One man-hour to invent,
One man-week to implement,
One lawyer-year to patent.

From:	Krishna Myneni
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number
Date:	Mon, 17 Jan 2005 18:21:27 -0800

Andreas Kochenburger wrote:
> ... When a Forth system "has"
> fp-numbers, the default behavior must be to interpret all numbers with
> a decimal point as fp-number. ...

I sympathize with your feeling on this, but sadly I must
disagree. The potential to break code unknowingly is pretty
much of a certainty. My solution in kForth has been for the
number interpreter not to recognize numbers with a sole
trailing point decimal. This does not mean that double numbers
are not supported, just their method of entry is not direct.
In this way, the interpreter will fail to load legacy code
that uses the conventional double number format and force
the user to update the code. It also provides me with a safety
feature if I mistakenly enter a number with a trailing decimal
point, intending to have entered an fp number --- almost
a certainty from having programmed for many years in other
languages. Floating point numbers are entered in their conventional
format in kForth, and I strongly support that this be upheld.

The double number convention was just a bad choice from the
start. I would support an alternative entry format for double
numbers so that interpreters can implement the new form and
simply not recognize the older form. Any interpreter which
chooses to recognize the older format should not reinterpret
the number as an fp number or something else.

Krishna

From:	Guido Draheim
Subject:	Re: Test vote 2005: 1.0 shall mean fp-number ONE, not double-number
Date:	Tue, 18 Jan 2005 09:26:31 +0100

Krishna Myneni wrote:
> Andreas Kochenburger wrote:
>
>> ... When a Forth system "has"
>> fp-numbers, the default behavior must be to interpret all numbers with
>> a decimal point as fp-number. ...
>
>
> I sympathize with your feeling on this, but sadly I must
> disagree. The potential to break code unknowingly is pretty
> much of a certainty. My solution in kForth has been for the
> number interpreter not to recognize numbers with a sole
> trailing point decimal. This does not mean that double numbers
> are not supported, just their method of entry is not direct.
> In this way, the interpreter will fail to load legacy code
> that uses the conventional double number format and force
> the user to update the code. It also provides me with a safety
> feature if I mistakenly enter a number with a trailing decimal
> point, intending to have entered an fp number --- almost
> a certainty from having programmed for many years in other
> languages. Floating point numbers are entered in their conventional
> format in kForth, and I strongly support that this be upheld.
>
> The double number convention was just a bad choice from the
> start. I would support an alternative entry format for double
> numbers so that interpreters can implement the new form and
> simply not recognize the older form. Any interpreter which
> chooses to recognize the older format should not reinterpret
> the number as an fp number or something else.
>

You are right (a) we specify a new suffix (b) depracate the
old dot-suffix (c) system makers create warning messages
about the old style (d) wait ten years ;-) ...