32/64-bit machines have increased the risk of entering numbers incorrectly.
Should the Forth interpreter be allowed to ignore certain punctuation e.g.
underscore in numbers? What would be the issues?

Usual suspects pre-answered.

Q. Why the underscore character?
A. It's not one of the characters Forth Inc uses to denote a double number.
It's increasingly used in programming languages for this purpose. Even
XPL0 has it.

A. ANS didn't see the need for it.
Q. Are you married?

Q. Should >NUMBER process the underscore?
A. No - for the same reason SCAN shouldn't handle TABs - it makes it weaker.

Q. Then you'll need a routine to strip the underscores and a temporary buffer
to hold the result. What do you suggest?
A. The HOLD buffer.

Q. Won't it interfere with numeric output?
A. Input/output are usually mutually exclusive.

Q. Won't the HOLD buffer need to be larger to hold the punctuation?
A. Assuming worst case and one underscore per 4 characters, 20% larger.

Q. Is all this just c.l.f. speculation - or have you implemented it?
A. Implemented

Q. Has it broken anything?
A. Not AFAIK

Q. What did it cost?
A. 34 bytes on 8086, 39 bytes on 8080

Q. Can't it be done using recognizers?
A. If so, probably at more cost.

Q. Will you keep it?
A. Good question. For 16-bit integers its value may be marginal. How often
do you enter values in binary?

On 23/07/2022 16:24, dxforth wrote:
>
> Q. Won't the HOLD buffer need to be larger to hold the punctuation?
> A. Assuming worst case and one underscore per 4 characters, 20% larger.

Q. Hang on - doesn't the buffer hold the _converted_ string?
A. Correct. The HOLD buffer doesn't need to be larger.

On Saturday, July 23, 2022 at 8:24:09 AM UTC+2, dxforth wrote:
> 32/64-bit machines have increased the risk of entering numbers incorrectly.
> Should the Forth interpreter be allowed to ignore certain punctuation e.g.
> underscore in numbers? What would be the issues?
>
> Usual suspects pre-answered.
>
> Q. Why the underscore character?
> A. It's not one of the characters Forth Inc uses to denote a double number.
> It's increasingly used in programming languages for this purpose. Even
> XPL0 has it.
>
> Q. Should >NUMBER process the underscore?
> A. No - for the same reason SCAN shouldn't handle TABs - it makes it weaker.
>
[..]
> Q. Has it broken anything?
> A. Not AFAIK
[..]

What exactly is your idea?

"... certain punctuation e.g. underscore ... "

I guess you are talking about integer single precision, i.e. you want
_1000, 1_000, 10_00, 100_0, 1000_, _1__0_0_0____ all to map to 1000
in the current BASE? This_is_dead_beef ?

When >NUMBER doesn't handle it, how does it get recognized as an
integer by the rest of the system? Why not have the application filter
it when it wants to support this?

-marcel

In article <7ac8f1a1-c173-4dff-930f-2e29aa5990ccn@googlegroups.com>,
Marcel Hendrix <mhx@iae.nl> wrote:
>On Saturday, July 23, 2022 at 8:24:09 AM UTC+2, dxforth wrote:
>> 32/64-bit machines have increased the risk of entering numbers incorrectly.
>> Should the Forth interpreter be allowed to ignore certain punctuation e.g.
>> underscore in numbers? What would be the issues?
>>
>> Usual suspects pre-answered.
>>
>> Q. Why the underscore character?
>> A. It's not one of the characters Forth Inc uses to denote a double number.
>> It's increasingly used in programming languages for this purpose. Even
>> XPL0 has it.
>>
>> Q. Should >NUMBER process the underscore?
>> A. No - for the same reason SCAN shouldn't handle TABs - it makes it weaker.
>>
>[..]
>> Q. Has it broken anything?
>> A. Not AFAIK
>[..]
>
>What exactly is your idea?
>
>"... certain punctuation e.g. underscore ... "
>
>I guess you are talking about integer single precision, i.e. you want
>_1000, 1_000, 10_00, 100_0, 1000_, _1__0_0_0____ all to map to 1000
>in the current BASE? This_is_dead_beef ?
>
>When >NUMBER doesn't handle it, how does it get recognized as an
>integer by the rest of the system? Why not have the application filter
>it when it wants to support this?

>NUMBER is carefully designed to be interruptable.
It could handle extra characters, e.g. a traditional use of
finding the place of the decimal point (for fixed point numbers).

0. "1111.1111" >NUMBER OVER C@ &. = IF OVER DPL ! /STRING THEN >NUMBER

Handling _ without changing >NUMBER, but yet using is, is left as an
exercise for the reader.

I admit that >NUMBER is a reasonable factor, but I don't care a bit
about the suggestion to use in a Forth kernel (political correct Forth).
So it is not used in ciforth, and could be relegated to a loadable extension.

>
>-marcel

&. is a notation that replace '.' in
A decimal point in the middle of a word is non-standard.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

dxforth <dxforth@gmail.com> writes:
>32/64-bit machines have increased the risk of entering numbers incorrectly.

And reading the entered numbers. Who can tell quickly what order of
magnitude 1000000000000 has?

It's also about outputted numbers. Yes, I can write an output routine
that outputs 8_888_888_888_888 for readability, but if I cannot cut
that number and paste it back in (which I occasionally have to do), I
shy away from that.

>Should the Forth interpreter be allowed to ignore certain punctuation e.g.
>underscore in numbers?

It is allowed that already.

>Usual suspects pre-answered.
>
>Q. Why the underscore character?
>A. It's not one of the characters Forth Inc uses to denote a double number.
> It's increasingly used in programming languages for this purpose. Even
> XPL0 has it.

Very sensible. Who are you and what have you done to dxforth:-)

>Q. Should >NUMBER process the underscore?
>A. No - for the same reason SCAN shouldn't handle TABs - it makes it weaker.

I don't see strong reasons either way.

>Q. Then you'll need a routine to strip the underscores and a temporary buffer
> to hold the result. What do you suggest?
>A. The HOLD buffer.

No such buffer is needed. That's the beauty of >NUMBER, which has
been designed for a very similar use case:

: >number_ ( ud1 c-addr1 u1 -- ud2 c-addr2 u2 )
\ like >number, but ignores _
begin
>number
dup 0> while
over c@ '_' = while
1 /string
repeat then ;

Whould the buffer option be smaller?

: >number_ ( ud1 c-addr1 u1 -- ud2 c-addr2 u2 )
\ not tested or debugged
holdbuf >r
begin
over c@ dup digit? if
drop r> c!+ r>
else
'_' <> if
holdbuf r> over - 2swap 2>r >number 2drop 2r> exit then
again ;

Do you manage any better?

>Q. Won't it interfere with numeric output?
>A. Input/output are usually mutually exclusive.

Says who?

>Q. Can't it be done using recognizers?
>A. If so, probably at more cost.

What makes you think so?

>Q. Will you keep it?
>A. Good question. For 16-bit integers its value may be marginal. How often
> do you enter values in binary?

I have been thinking about adding this feature for a while. I expect
that I will do so at some point in the future.

- 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: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

On 23/07/2022 18:02, Marcel Hendrix wrote:
>
> What exactly is your idea?
>
> "... certain punctuation e.g. underscore ... "
>
> I guess you are talking about integer single precision, i.e. you want
> _1000, 1_000, 10_00, 100_0, 1000_, _1__0_0_0____ all to map to 1000
> in the current BASE? This_is_dead_beef ?

Any character string representing a number sent to the forth interpreter.
The idea is to strip the underscores just before forth tries to convert
the string to a number. The catch is it mustn't be found in the dictionary
which is classically searched first. This effectively means you can't
use underscore in a word name - or risk your number being found.

> 32/64-bit machines have increased the risk of entering numbers incorrectly.
> Should the Forth interpreter be allowed to ignore certain punctuation e.g..
> underscore in numbers? What would be the issues?

No such risk in case of underscore; to enter underscore character one has
to press Shift-Minus — it can be done only on purpose.
I believe one character that could be ignored the way you propose is space.
When entering long numbers it may be comfortable to, for example, separate
thousands by adding single space among them. It's easier to check the input
before final Enter-press.

Zbig schrieb am Samstag, 23. Juli 2022 um 16:28:34 UTC+2:
> > 32/64-bit machines have increased the risk of entering numbers incorrectly.
> > Should the Forth interpreter be allowed to ignore certain punctuation e..g.
> > underscore in numbers? What would be the issues?
> No such risk in case of underscore; to enter underscore character one has
> to press Shift-Minus — it can be done only on purpose.
> I believe one character that could be ignored the way you propose is space.
> When entering long numbers it may be comfortable to, for example, separate
> thousands by adding single space among them. It's easier to check the input
> before final Enter-press.

You are timidly entering the gritty realm of locales ... ;-)

> > > 32/64-bit machines have increased the risk of entering numbers incorrectly.
> > > Should the Forth interpreter be allowed to ignore certain punctuation e.g.
> > > underscore in numbers? What would be the issues?
> > No such risk in case of underscore; to enter underscore character one has
> > to press Shift-Minus — it can be done only on purpose.
> > I believe one character that could be ignored the way you propose is space.
> > When entering long numbers it may be comfortable to, for example, separate
> > thousands by adding single space among them. It's easier to check the input
> > before final Enter-press.
> You are timidly entering the gritty realm of locales ... ;-)

Not quite. I'm of course aware, that some countries use comma and dot for said
"thousand separators", but both comma and dot characters are usually interpreted
as "double" mark in Forth. So only the space can be used as "separator".

On 23/07/2022 21:50, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
> ...
>>Q. Then you'll need a routine to strip the underscores and a temporary buffer
>> to hold the result. What do you suggest?
>>A. The HOLD buffer.
>
> No such buffer is needed. That's the beauty of >NUMBER, which has
> been designed for a very similar use case:
>
> : >number_ ( ud1 c-addr1 u1 -- ud2 c-addr2 u2 )
> \ like >number, but ignores _
> begin
> >number
> dup 0> while
> over c@ '_' = while
> 1 /string
> repeat then ;

The idea was to avoid separate number converters.

>>Q. Won't it interfere with numeric output?
>>A. Input/output are usually mutually exclusive.
>
> Says who?

Humans - who use the same mouth to eat and speak.

>
>>Q. Can't it be done using recognizers?
>>A. If so, probably at more cost.
>
> What makes you think so?

The 30 odd bytes I spent would be hard to beat.

My implementation is sound enough. It's the potential for underscored
numbers to collide with dictionary entries that's the problem. 200x
character literals have the same issue but there the risk is manageable
since it involves strings of 3 characters only one of which is variable.
What comes from trying to import foreign ideas into Forth.

On 24/07/2022 13:22, dxforth wrote:
>
> It's the potential for underscored
> numbers to collide with dictionary entries that's the problem.

Collisions might be reduced sufficiently by requiring underscored
numbers begin with an underscore. Not fool-proof but then neither
were 200x character literals.

On 23/07/2022 9:24, dxforth wrote:
> 32/64-bit machines have increased the risk of entering numbers incorrectly.
> Should the Forth interpreter be allowed to ignore certain punctuation e.g.
> underscore in numbers? What would be the issues?

I implemented underscores-in-numbers a while back in 8th, at no
perceivable cost. Makes large numbers much easier to understand.

On 24/07/2022 14:26, Ron AARON wrote:
>
>
> On 23/07/2022 9:24, dxforth wrote:
>> 32/64-bit machines have increased the risk of entering numbers incorrectly.
>> Should the Forth interpreter be allowed to ignore certain punctuation e.g.
>> underscore in numbers? What would be the issues?
>
> I implemented underscores-in-numbers a while back in 8th, at no
> perceivable cost. Makes large numbers much easier to understand.

What about dictionary collisions - or does 8th handle numbers differently?
Any class of number or just integers?

On 24/07/2022 7:42, dxforth wrote:
> On 24/07/2022 14:26, Ron AARON wrote:
>>
>>
>> On 23/07/2022 9:24, dxforth wrote:
>>> 32/64-bit machines have increased the risk of entering numbers incorrectly.
>>> Should the Forth interpreter be allowed to ignore certain punctuation e.g.
>>> underscore in numbers? What would be the issues?
>>
>> I implemented underscores-in-numbers a while back in 8th, at no
>> perceivable cost. Makes large numbers much easier to understand.
>
> What about dictionary collisions - or does 8th handle numbers differently?
> Any class of number or just integers?

The dictionary is searched first, so : 123_456 ; will be found if
"123_456" is entered. Numbers are attempted to be parsed after words, so
it's possible to override e.g. "8" if you wanted to.

Any kind of number allows the underscore, including "big integers" and
"big floats". The underscore is simply ignored inside number parsing.

On 24 Jul 2022 at 06:42:32 CEST, "dxforth" <dxforth@gmail.com> wrote:

>> I implemented underscores-in-numbers a while back in 8th, at no
>> perceivable cost. Makes large numbers much easier to understand.
>
> What about dictionary collisions - or does 8th handle numbers differently?
> Any class of number or just integers?

Once you have decided that numbers should have an ignoreable character
you might as well replace all occurrences of that literal by a variable. Once
you have a variable, you can now choose the ignoreable character at
run-time, e.g.
':' ign-char !

You can use a similar mechanism for the DP and FP separators. Since
a variable is larger than a byte, you can treat the variables as n-char
arrays in which any match satisfies. VFX has used this mechanism for
decades to allow users to have locale-sensitive DP and FP numbers.
Since we made this change there have been no whines from the
standards lawyers and no technical support issues.

Stephen
--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

dxforth <dxforth@gmail.com> writes:
>On 23/07/2022 21:50, Anton Ertl wrote:
>> dxforth <dxforth@gmail.com> writes:
>> ...
>>>Q. Then you'll need a routine to strip the underscores and a temporary buffer
>>> to hold the result. What do you suggest?
>>>A. The HOLD buffer.
>>
>> No such buffer is needed. That's the beauty of >NUMBER, which has
>> been designed for a very similar use case:
>>
>> : >number_ ( ud1 c-addr1 u1 -- ud2 c-addr2 u2 )
>> \ like >number, but ignores _
>> begin
>> >number
>> dup 0> while
>> over c@ '_' = while
>> 1 /string
>> repeat then ;
>
>The idea was to avoid separate number converters.

I have no idea what you mean with that.

>>>Q. Won't it interfere with numeric output?
>>>A. Input/output are usually mutually exclusive.
>>
>> Says who?
>
>Humans - who use the same mouth to eat and speak.

And the relevance to conversion from strings to numbers and numbers to
strings is?

>>>Q. Can't it be done using recognizers?
>>>A. If so, probably at more cost.
>>
>> What makes you think so?
>
>The 30 odd bytes I spent would be hard to beat.

Moving the goalposts? I did not ask about beating.

Why makes you think that the cost would be higher rather than just the
same if one applies the same change to a pluggable number recognizer
rather than a hardwired one?

>It's the potential for underscored
>numbers to collide with dictionary entries that's the problem.

That's no problem, just like the potential for other numbers to
collide with dictionary entries is no problem:

Dictionary entries are searched first, so if you have a word _ or __
or _1 or 1_ etc., it will be found before the number recognizer tries
to convert it into a number. The conventional way to avoid a number
being shadowed by a dictionary entry is to start the number with one
of the digits 0-9 (and avoiding dictionary entries that start with
these digits, albeit there are some exceptions that prove this rule).

>200x character literals have the same issue

It's the same non-issue for the same reason. And, guess what, no
problems have been reported to us, neither for the Forth-2012
character literals ('a', implemented in Gforth since 0.7 (2008)), nor
for Gforth's older syntax ('a, implemented in Gforth since the first
public release (1996)).

- 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: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

Stephen Pelc <stephen@vfxforth.com> writes:
>Once you have decided that numbers should have an ignoreable character
>you might as well replace all occurrences of that literal by a variable. Once
>you have a variable, you can now choose the ignoreable character at
>run-time, e.g.
> ':' ign-char !

That may be a way for vendors to placate their customers if they all
want some different ignore-character, but if you want a common
language for exchanging libraries, studying programs etc, it's a bad
idea. And given that no other viable ignore-characters apart from _
has been proposed (I don't consider space, comma, and dot to be a
viable ignore-characters in Forth) despite the frequent urge to
bike-shed such small changes to death, why propose this misfeature in
your first posting on this topic?

Your example is especially nasty because ':' is a double indicator in
SwiftForth. So someone following your suggestion would produce
programs that behave quite differently in SwiftForth.

>You can use a similar mechanism for the DP and FP separators.

Also bad ideas for language commonality. If you want to accept
decimal comma, accept it in addition to the decimal point. No need
for variables.

>Since we made this change there have been [...] no technical support issues.

If library authors made use of this misfeature, and an application
author would trip over that, would you get a support call? I guess,
though, that library authors are smart enough to stay clear of it.
But if a "feature" is best avoided, why provide it at all?

- 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: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

In article <034d9af5-154a-431d-a469-f7054b9c0bb1n@googlegroups.com>,
Zbig <zbigniew2011@gmail.com> wrote:
>> 32/64-bit machines have increased the risk of entering numbers incorrectly.
>> Should the Forth interpreter be allowed to ignore certain punctuation e.g.
>> underscore in numbers? What would be the issues?
>
>No such risk in case of underscore; to enter underscore character one has
>to press Shift-Minus — it can be done only on purpose.
>I believe one character that could be ignored the way you propose is space.
>When entering long numbers it may be comfortable to, for example, separate
>thousands by adding single space among them. It's easier to check the input
>before final Enter-press.

Using spaces in numbers? In Forth this is a bad idea.
Underscores, yes.

Groetjes Albert
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

> Using spaces in numbers? In Forth this is a bad idea.
> Underscores, yes.

Who, apart of Forth programmer, will use underscore when entering
any number?

Zbig <zbigniew2011@gmail.com> writes:
>Who, apart of Forth programmer, will use underscore when entering
>any number?

Accoding to
<https://en.wikipedia.org/wiki/Decimal_separator#Digit_grouping>:

|maritime "21_450"

and (more relevant):

|Ada, C# (from version 7.0[34]), D, Haskell (from GHC version 8.6.1),
|Java, Kotlin,[35] OCaml, Perl, Python (from version 3.6), PHP (from
|version 7.4[36]), Ruby, Go (from version 1.13), Rust, Julia, and
|Swift use the underscore (_) character for this purpose

- 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: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

> >Who, apart of Forth programmer, will use underscore when entering
> >any number?
> Accoding to
> <https://en.wikipedia.org/wiki/Decimal_separator#Digit_grouping>:
>
> |maritime "21_450"

Correction: apart of Forth programmer and a sailor.

> and (more relevant):
>
> |Ada, C# (from version 7.0[34]), D, Haskell (from GHC version 8.6.1),
> |Java, Kotlin,[35] OCaml, Perl, Python (from version 3.6), PHP (from
> |version 7.4[36]), Ruby, Go (from version 1.13), Rust, Julia, and
> |Swift use the underscore (_) character for this purpose

OK, so I'm asking the same question to creators of Ada, C# (from version
7.0[34]), D, Haskell (from GHC version 8.6.1), Java, Kotlin,[35] OCaml, Perl,
Python (from version 3.6), PHP (from version 7.4[36]), Ruby, Go (from
version 1.13), Rust, Julia, and Swift: who, apart of the sailors and apart
of the programmers, that were told "use underscore" — indeed uses
underscore when entering any numbers?

The question is serious; I never saw anyone, who was using underscore
to enter number — well, maybe indeed it's commonly used somewhere
for that purpose (like I had no idea some sailors use that).

On 24/07/2022 15:53, Anton Ertl wrote:
> Zbig <zbigniew2011@gmail.com> writes:
>> Who, apart of Forth programmer, will use underscore when entering
>> any number?
>
> Accoding to
> <https://en.wikipedia.org/wiki/Decimal_separator#Digit_grouping>:
>
> |maritime "21_450"
>
> and (more relevant):
>
> |Ada, C# (from version 7.0[34]), D, Haskell (from GHC version 8.6.1),
> |Java, Kotlin,[35] OCaml, Perl, Python (from version 3.6), PHP (from
> |version 7.4[36]), Ruby, Go (from version 1.13), Rust, Julia, and
> |Swift use the underscore (_) character for this purpose
>
> - anton

Indeed; it was because someone asked for it based on Python's example,
that I did eventually add it into 8th.

On 24/07/2022 19:35, Anton Ertl wrote:
> dxforth <dxforth@gmail.com> writes:
>>On 23/07/2022 21:50, Anton Ertl wrote:
>>> dxforth <dxforth@gmail.com> writes:
>>> ...
>>>>Q. Then you'll need a routine to strip the underscores and a temporary buffer
>>>> to hold the result. What do you suggest?
>>>>A. The HOLD buffer.
>>>
>>> No such buffer is needed. That's the beauty of >NUMBER, which has
>>> been designed for a very similar use case:
>>>
>>> : >number_ ( ud1 c-addr1 u1 -- ud2 c-addr2 u2 )
>>> \ like >number, but ignores _
>>> begin
>>> >number
>>> dup 0> while
>>> over c@ '_' = while
>>> 1 /string
>>> repeat then ;
>>
>>The idea was to avoid separate number converters.
>
> I have no idea what you mean with that.

You just created one. Will you create another for floats?

>
>>>>Q. Won't it interfere with numeric output?
>>>>A. Input/output are usually mutually exclusive.
>>>
>>> Says who?
>>
>>Humans - who use the same mouth to eat and speak.
>
> And the relevance to conversion from strings to numbers and numbers to
> strings is?

I see no reason for them to collide.

>
>>>>Q. Can't it be done using recognizers?
>>>>A. If so, probably at more cost.
>>>
>>> What makes you think so?
>>
>>The 30 odd bytes I spent would be hard to beat.
>
> Moving the goalposts? I did not ask about beating.
>
> Why makes you think that the cost would be higher rather than just the
> same if one applies the same change to a pluggable number recognizer
> rather than a hardwired one?

Feel free to show the code for the plug-in.

>>It's the potential for underscored
>>numbers to collide with dictionary entries that's the problem.
>
> That's no problem, just like the potential for other numbers to
> collide with dictionary entries is no problem:
>
> Dictionary entries are searched first, so if you have a word _ or __
> or _1 or 1_ etc., it will be found before the number recognizer tries
> to convert it into a number. The conventional way to avoid a number
> being shadowed by a dictionary entry is to start the number with one
> of the digits 0-9 (and avoiding dictionary entries that start with
> these digits, albeit there are some exceptions that prove this rule).

Fair enough

>
>>200x character literals have the same issue
>
> It's the same non-issue for the same reason. And, guess what, no
> problems have been reported to us, neither for the Forth-2012
> character literals ('a', implemented in Gforth since 0.7 (2008)), nor
> for Gforth's older syntax ('a, implemented in Gforth since the first
> public release (1996)).
>
> - anton

> |Swift use the underscore (_) character for this purpose

BTW: I think if „space” is too difficult to use it as „thousand separator”,
ignored by Forth, I got a better „candidate”: Vertical Tab (0Bh):
— it's practically unused anywhere
— it could be entered with, say, Shift-Space
— it could be displayed as, guess what, just a single space

On 24 Jul 2022 at 12:05:23 CEST, "Anton Ertl" <Anton Ertl> wrote:

Your response is a typical "not invented here" response.

The DP and FP character definitions solve a *real* issue in that the
Forth standard approach cannot be used for real-world data entry.
The DP and FP char solution allows the double and FP data entry
routines to be used for data entry in various locales.

> Your example is especially nasty because ':' is a double indicator in
> SwiftForth. So someone following your suggestion would produce
> programs that behave quite differently in SwiftForth.

I have a dispute resolution protocol in a contract (yes, really) that includes
the line:
"Dispute resolution processes include the consumption of alcoholic
beverages, food and laughter."
Leon at Forth Inc and I are perfectly capable of finding a resolution.

> Also bad ideas for language commonality. If you want to accept
> decimal comma, accept it in addition to the decimal point. No need
> for variables.

I think that you do not understand locales.

Stephen

--
Stephen Pelc, stephen@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads