hello,

I would reuse some external data to do something with

My idea was to :
1.capture data (get some string)
2. display
3. convertit to number
4. dostuff
5. display results

So I defined some

create buffer 1024 allot
5 constant SIZE
variable out
create outputgraph SIZE cells allot
: commandout ( "cmd" -- variable out as string )
r/o open-pipe throw dup buffer swap 256 swap read-file throw swap
close-pipe throw drop buffer swap out 2!
; : [] ( n addr -- addr[n] ) swap cells + ; \ if i understood correctly the array model

here I can now test the capture

s\" psql -c \qselect sum(exp) from experience where champs ilike 'langues' ;\q | sed '3!d' " commandout
out 2@ type \ should be 40 40
ok

now the goal is to convert it as an int inside my array
so I thouthg I could just

out 2@ s>number drop 0 outputgraph [] ! \ may be

but before that even the out 2@ s>number just output 0 0 to the stack & not a number ...

Ideas to fit my goal to capture the "40" value from that example ?

regards

In article <ce094d5f-a29f-4a1e-ad61-7e7d156f2e35n@googlegroups.com>,
gobli...@gmail.com <goblinrieur@gmail.com> wrote:
>hello,
>
>I would reuse some external data to do something with
>
>My idea was to :
>1.capture data (get some string)
>2. display
>3. convertit to number
>4. dostuff
>5. display results
>
>So I defined some
>
>create buffer 1024 allot
>5 constant SIZE
>variable out
> create outputgraph SIZE cells allot
>: commandout ( "cmd" -- variable out as string )
> r/o open-pipe throw dup buffer swap 256 swap read-file throw swap

I know no Forth that know "open-pipe" like that

<SNIP>

>
>regards
>
Groetjes Albert
>
>
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

Le lundi 12 juin 2023 à 21:51:20 UTC+2, none albert a écrit :
> In article <ce094d5f-a29f-4a1e...@googlegroups.com>,
> gobli...@gmail.com <gobli...@gmail.com> wrote:
> >hello,
> >
> >I would reuse some external data to do something with
> >
> >My idea was to :
> >1.capture data (get some string)
> >2. display
> >3. convertit to number
> >4. dostuff
> >5. display results
> >
> >So I defined some
> >
> >create buffer 1024 allot
> >5 constant SIZE
> >variable out
> > create outputgraph SIZE cells allot
> >: commandout ( "cmd" -- variable out as string )
> > r/o open-pipe throw dup buffer swap 256 swap read-file throw swap
> I know no Forth that know "open-pipe" like that
>
> <SNIP>
>
> >
> >regards
> >
> Groetjes Albert
> >
> >
> --
> Don't praise the day before the evening. One swallow doesn't make spring.
> You must not say "hey" before you have crossed the bridge. Don't sell the
> hide of the bear until you shot it. Better one bird in the hand than ten in
> the air. First gain is a cat spinning. - the Wise from Antrim -

this is just a part of code that works perfectly the issue is on number conversion

gobli...@gmail.com schrieb am Montag, 12. Juni 2023 um 21:36:46 UTC+2:
> so I thouthg I could just
> out 2@ s>number drop 0 outputgraph [] ! \ may be

Standard with stack diagram:
>NUMBER ( ud1 c-addr1 u1 – – ud2 c-addr2 u2 )
So it expects and returns 4 stack items.

What is the stack diagram of your s>number?

On Monday, June 12, 2023 at 3:55:13 PM UTC-4, gobli...@gmail.com wrote:

gForth seems to have NUMBER? .
It takes a byte counted string and returns the number and flag

S" 9999" PAD PLACE ok
ok
ok
PAD NUMBER? ok
..S <2> 9999 -1 ok

On Monday, June 12, 2023 at 4:24:08 PM UTC-4, Brian Fox wrote:
> On Monday, June 12, 2023 at 3:55:13 PM UTC-4, gobli...@gmail.com wrote:
>
> gForth seems to have NUMBER? .
> It takes a byte counted string and returns the number and flag
>
> S" 9999" PAD PLACE ok
> ok
> ok
> PAD NUMBER? ok
> .S <2> 9999 -1 ok

If you can tolerate single precision I wrote this one for Camel Forth
It's weird because zero means a good conversion but that was
more consistent with ABORT" in my system.

: NUMBER? ( addr len -- n ?) \ ?=0 is good conversion
( -- addr len) \ bad conversion
OVER C@ [CHAR] - = DUP >R \ save flag for later
IF 1 /STRING THEN \ remove minus sign
0 0 2SWAP >NUMBER NIP NIP \ convert the number
R> IF SWAP NEGATE SWAP THEN \ negate if needed
;

Le lundi 12 juin 2023 à 22:27:12 UTC+2, Brian Fox a écrit :
> On Monday, June 12, 2023 at 4:24:08 PM UTC-4, Brian Fox wrote:
> > On Monday, June 12, 2023 at 3:55:13 PM UTC-4, gobli...@gmail.com wrote:
> >
> > gForth seems to have NUMBER? .
> > It takes a byte counted string and returns the number and flag
> >
> > S" 9999" PAD PLACE ok
> > ok
> > ok
> > PAD NUMBER? ok
> > .S <2> 9999 -1 ok
> If you can tolerate single precision I wrote this one for Camel Forth
> It's weird because zero means a good conversion but that was
> more consistent with ABORT" in my system.
>
> : NUMBER? ( addr len -- n ?) \ ?=0 is good conversion
> ( -- addr len) \ bad conversion
> OVER C@ [CHAR] - = DUP >R \ save flag for later
> IF 1 /STRING THEN \ remove minus sign
> 0 0 2SWAP >NUMBER NIP NIP \ convert the number
> R> IF SWAP NEGATE SWAP THEN \ negate if needed
> ;
thanks you all
il gnuforth there is an internal "evaluate" word that does it well :) but I didn't knew it
all solution around your versions of number? might have worked too I think ..

now

s\" psql -c \qselect sum(exp) from experience where champs ilike 'langues' ;\q | sed '3!d' " commandout
34 17 at-xy 33 colorize out 2@ type 0 colorize
out 2@ evaluate 1000 / 0 outputgraph [] !

works fine now , so
0 outputgraph [] @

now displays the numbers & I could test a loop over 3 values of index
like
[##########]
[###############################################]
[#########################]

using each of
[....]
.." ["
i outputgraph [] @ 0 do
." #"
loop
.." ]"
[...]

albert@cherry.(none) (albert) writes:
>I know no Forth that know "open-pipe" like that

Maybe Gforth: <https://gforth.org/manual/Pipes.html>

- 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 proceedings: http://www.euroforth.org/ef22/papers/

On Monday, June 12, 2023 at 9:51:20 PM UTC+2, none albert wrote:
> In article <ce094d5f-a29f-4a1e...@googlegroups.com>,
> gobli...@gmail.com <gobli...@gmail.com> wrote:
> >hello,
> >
> >I would reuse some external data to do something with
> >
> >My idea was to :
> >1.capture data (get some string)
> >2. display
> >3. convertit to number
> >4. dostuff
> >5. display results
> >
> >So I defined some
> >
> >create buffer 1024 allot
> >5 constant SIZE
> >variable out
> > create outputgraph SIZE cells allot
> >: commandout ( "cmd" -- variable out as string )
> > r/o open-pipe throw dup buffer swap 256 swap read-file throw swap
> I know no Forth that know "open-pipe" like that
>
> <SNIP>
>
> >
> >regards
> >
> Groetjes Albert
> >
> >
> --
> Don't praise the day before the evening. One swallow doesn't make spring.
> You must not say "hey" before you have crossed the bridge. Don't sell the
> hide of the bear until you shot it. Better one bird in the hand than ten in
> the air. First gain is a cat spinning. - the Wise from Antrim -

4tH can as well:

s" ls" input pipe + open error? abort" Cannot open pipe"
dup use begin refill while 0 parse type cr repeat close

Hans Bezemer

On 13/06/2023 1:26, Hans Bezemer wrote:
> On Monday, June 12, 2023 at 9:51:20 PM UTC+2, none albert wrote:
>> In article <ce094d5f-a29f-4a1e...@googlegroups.com>,
>> gobli...@gmail.com <gobli...@gmail.com> wrote:
>>> hello,
>>>
>>> I would reuse some external data to do something with
>>>
>>> My idea was to :
>>> 1.capture data (get some string)
>>> 2. display
>>> 3. convertit to number
>>> 4. dostuff
>>> 5. display results
>>>
>>> So I defined some
>>>
>>> create buffer 1024 allot
>>> 5 constant SIZE
>>> variable out
>>> create outputgraph SIZE cells allot
>>> : commandout ( "cmd" -- variable out as string )
>>> r/o open-pipe throw dup buffer swap 256 swap read-file throw swap
>> I know no Forth that know "open-pipe" like that
>>
>> <SNIP>
>>
>>>
>>> regards
>>>
>> Groetjes Albert
>>>
>>>
>> --
>> Don't praise the day before the evening. One swallow doesn't make spring.
>> You must not say "hey" before you have crossed the bridge. Don't sell the
>> hide of the bear until you shot it. Better one bird in the hand than ten in
>> the air. First gain is a cat spinning. - the Wise from Antrim -
>
> 4tH can as well:
>
> s" ls" input pipe + open error? abort" Cannot open pipe"
> dup use begin refill while 0 parse type cr repeat close
>
> Hans Bezemer

So can 8th, of course, using "f:popen" or (in the about to be released
version) "f:popen3".

On 12/06/2023 22:36, gobli...@gmail.com wrote:
> hello,
>
> I would reuse some external data to do something with
>
> My idea was to :
> 1.capture data (get some string)
> 2. display
> 3. convertit to number
> 4. dostuff
> 5. display results
>
> So I defined some
>
> create buffer 1024 allot
> 5 constant SIZE
> variable out
> create outputgraph SIZE cells allot
> : commandout ( "cmd" -- variable out as string )
> r/o open-pipe throw dup buffer swap 256 swap read-file throw swap
> close-pipe throw drop buffer swap out 2!
> ;
> : [] ( n addr -- addr[n] ) swap cells + ; \ if i understood correctly the array model
>
> here I can now test the capture
>
> s\" psql -c \qselect sum(exp) from experience where champs ilike 'langues' ;\q | sed '3!d' " commandout
> out 2@ type \ should be 40 40
> ok
>
> now the goal is to convert it as an int inside my array
> so I thouthg I could just
>
> out 2@ s>number drop 0 outputgraph [] ! \ may be
>
> but before that even the out 2@ s>number just output 0 0 to the stack & not a number ...
>
> Ideas to fit my goal to capture the "40" value from that example ?
>
> regards

In 8th you would use "sh$" to (easily) capture the output of the shelled
command, though the command is run in another thread:

: cmd \ s -- s
( nip t:parent swap t:push! ) sh$
-1 sleep t:pop ;

Converting the string to a number is simple, though you probably want to
ensure no whitespace surrounds it:

s:trim >n

Putting that into a new array:

1 a:close

The end result would be [40] (assuming that's what you're looking for).

Brian Fox <brian.fox@brianfox.ca> writes:
>On Monday, June 12, 2023 at 3:55:13=E2=80=AFPM UTC-4, gobli...@gmail.com wr=
>ote:
>
>gForth seems to have NUMBER? .

Not in the development version. As for S>NUMBER (mentioned also in
this thread), the source code says:

\ don't use this, there is no way to tell success

The current recommendation is

'rec-num' ( addr u -- n/d table | notfound ) gforth-experimental "rec-num"
converts a number to a single/double integer

where table is the xt of TRANSLATE-NUM (and n below table) or
TRANSLATE-DNUM (and d below table); or the top of stack ist the xt of
NOTFOUND.

I find the combination of single- and double-cell numbers in one
recognizer suboptimal as an interface, but it actally simplifies the
implemetation compared to a variant that has separate recognizers for
singles and doubles and only combines them at the recognizer level.

- 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 proceedings: http://www.euroforth.org/ef22/papers/

In article <2023Jun12.224343@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.(none) (albert) writes:
>>I know no Forth that know "open-pipe" like that
>
>Maybe Gforth: <https://gforth.org/manual/Pipes.html>

I intended to provoke an introductory remark:
"using a bleeding edge version of Gforth." /
"using a Ubuntu installed version of Gforth." /
"using a 2010 version of winforth"

I didn't realize that the open-pipe had nothing to do
with the question he asked.

I wasn't aware of the online documentation of gforth.
Nothing about "pipe" is to be found in the info docs of
gforth installed by Ubuntu.

>
>- anton

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

Anton Ertl schrieb am Dienstag, 13. Juni 2023 um 09:48:28 UTC+2:
> Brian Fox <bria...@brianfox.ca> writes:
> >On Monday, June 12, 2023 at 3:55:13=E2=80=AFPM UTC-4, gobli...@gmail.com wr=
> >ote:
> >
> >gForth seems to have NUMBER? .
> Not in the development version. As for S>NUMBER (mentioned also in
> this thread), the source code says:
>
> \ don't use this, there is no way to tell success
>
> The current recommendation is
>
> 'rec-num' ( addr u -- n/d table | notfound ) gforth-experimental "rec-num"
> converts a number to a single/double integer
>
> where table is the xt of TRANSLATE-NUM (and n below table) or
> TRANSLATE-DNUM (and d below table); or the top of stack ist the xt of
> NOTFOUND.
>
> I find the combination of single- and double-cell numbers in one
> recognizer suboptimal as an interface, but it actally simplifies the
> implemetation compared to a variant that has separate recognizers for
> singles and doubles and only combines them at the recognizer level.

I use a non-standard
NUMBER? \ ( a u -- 0 | n 1 | d 2 ) convert to single or double number
that handles prefixes, 'c' chars, and the classic dpl. So no surprises here.
Okay for interpreting legacy code.

I use recognizers to differentiate
- when 12. and 1.2 shall be treated differently (for fixed point math)
- when 12. and 1.2 shall be recognized as fp-numbers
- when to be "half-standard": 12. is a double, 1.2 is a float

Somewhat convoluted due to old Forth code heritage, but works well
so far.

albert@cherry.(none) (albert) writes:
>In article <2023Jun12.224343@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@cherry.(none) (albert) writes:
>>>I know no Forth that know "open-pipe" like that
>>
>>Maybe Gforth: <https://gforth.org/manual/Pipes.html>
>
>I intended to provoke an introductory remark:
>"using a bleeding edge version of Gforth."

Bleeding edge since at least gforth-0.2 (1996).

>Nothing about "pipe" is to be found in the info docs of
>gforth installed by Ubuntu.

That's not surprising given that Ubuntu follows Debian in not
installing the Gforth documentation (not even as a "non-free"
package).

What "info docs of gforth installed by Ubuntu" are you referring to?
There are no info docs of Gforth on my Ubuntu 22.04 laptop except
those that I installed myself.

- 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 proceedings: http://www.euroforth.org/ef22/papers/

In article <2023Jun13.185532@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@cherry.(none) (albert) writes:
>>In article <2023Jun12.224343@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>albert@cherry.(none) (albert) writes:
>>>>I know no Forth that know "open-pipe" like that
>>>
>>>Maybe Gforth: <https://gforth.org/manual/Pipes.html>
>>
>>I intended to provoke an introductory remark:
>>"using a bleeding edge version of Gforth."
>
>Bleeding edge since at least gforth-0.2 (1996).

The goal of this remark is that we can help better,
if we know what Forth is used. Where open-pipe is not standard,
the behaviour can be different on other systems.
>
>>Nothing about "pipe" is to be found in the info docs of
>>gforth installed by Ubuntu.
>
>That's not surprising given that Ubuntu follows Debian in not
>installing the Gforth documentation (not even as a "non-free"
>package).
>
>What "info docs of gforth installed by Ubuntu" are you referring to?
>There are no info docs of Gforth on my Ubuntu 22.04 laptop except
>those that I installed myself.

Maybe I have installed it myself. It commences with
"This manual corresponds to version 0.5.0."
That is later than 0.2.0.

>- anton
groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On Tue, 13 Jun 2023 11:27:00 +0200
albert@cherry.(none) (albert) wrote:
> I didn't realize that the open-pipe had nothing to do
> with the question he asked.
>
> I wasn't aware of the online documentation of gforth.
> Nothing about "pipe" is to be found in the info docs of
> gforth installed by Ubuntu.

Do you have any /usr/share/info/gforth* files ? If yes , what does
zcat /usr/share/info/gforth* | grep open-pipe

show ?

albert@cherry.(none) (albert) writes:
>In article <2023Jun13.185532@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>albert@cherry.(none) (albert) writes:
>>>In article <2023Jun12.224343@mips.complang.tuwien.ac.at>,
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>albert@cherry.(none) (albert) writes:
>>>>>I know no Forth that know "open-pipe" like that
>>>>
>>>>Maybe Gforth: <https://gforth.org/manual/Pipes.html>
>>>
>>>I intended to provoke an introductory remark:
>>>"using a bleeding edge version of Gforth."
>>
>>Bleeding edge since at least gforth-0.2 (1996).
....
>Maybe I have installed it myself. It commences with
>"This manual corresponds to version 0.5.0."

That's from 2000. At that time Debian may still have installed the
manual, but did Ubuntu exist?

Anyway, open-pipe was not documented in 0.5.0, but it was documented
in 0.6.2 (2003).

- 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 proceedings: http://www.euroforth.org/ef22/papers/

On 13/06/2023 7:49 pm, minforth wrote:
> Anton Ertl schrieb am Dienstag, 13. Juni 2023 um 09:48:28 UTC+2:
>> Brian Fox <bria...@brianfox.ca> writes:
>>> On Monday, June 12, 2023 at 3:55:13=E2=80=AFPM UTC-4, gobli...@gmail.com wr=
>>> ote:
>>>
>>> gForth seems to have NUMBER? .
>> Not in the development version. As for S>NUMBER (mentioned also in
>> this thread), the source code says:
>>
>> \ don't use this, there is no way to tell success
>>
>> The current recommendation is
>>
>> 'rec-num' ( addr u -- n/d table | notfound ) gforth-experimental "rec-num"
>> converts a number to a single/double integer
>>
>> where table is the xt of TRANSLATE-NUM (and n below table) or
>> TRANSLATE-DNUM (and d below table); or the top of stack ist the xt of
>> NOTFOUND.
>>
>> I find the combination of single- and double-cell numbers in one
>> recognizer suboptimal as an interface, but it actally simplifies the
>> implemetation compared to a variant that has separate recognizers for
>> singles and doubles and only combines them at the recognizer level.
>
> I use a non-standard
> NUMBER? \ ( a u -- 0 | n 1 | d 2 ) convert to single or double number
> that handles prefixes, 'c' chars, and the classic dpl. So no surprises here.
> Okay for interpreting legacy code.

Some well-known forths use that as it suits the forth interpreter. OTOH
it's overkill for most apps and requires more handling. What's missing
is the intermediate function, similar to >FLOAT but for integer.

dxforth schrieb am Mittwoch, 14. Juni 2023 um 05:54:04 UTC+2:
> On 13/06/2023 7:49 pm, minforth wrote:
> > Anton Ertl schrieb am Dienstag, 13. Juni 2023 um 09:48:28 UTC+2:
> >> Brian Fox <bria...@brianfox.ca> writes:
> >>> On Monday, June 12, 2023 at 3:55:13=E2=80=AFPM UTC-4, gobli...@gmail.com wr=
> >>> ote:
> >>>
> >>> gForth seems to have NUMBER? .
> >> Not in the development version. As for S>NUMBER (mentioned also in
> >> this thread), the source code says:
> >>
> >> \ don't use this, there is no way to tell success
> >>
> >> The current recommendation is
> >>
> >> 'rec-num' ( addr u -- n/d table | notfound ) gforth-experimental "rec-num"
> >> converts a number to a single/double integer
> >>
> >> where table is the xt of TRANSLATE-NUM (and n below table) or
> >> TRANSLATE-DNUM (and d below table); or the top of stack ist the xt of
> >> NOTFOUND.
> >>
> >> I find the combination of single- and double-cell numbers in one
> >> recognizer suboptimal as an interface, but it actally simplifies the
> >> implemetation compared to a variant that has separate recognizers for
> >> singles and doubles and only combines them at the recognizer level.
> >
> > I use a non-standard
> > NUMBER? \ ( a u -- 0 | n 1 | d 2 ) convert to single or double number
> > that handles prefixes, 'c' chars, and the classic dpl. So no surprises here.
> > Okay for interpreting legacy code.
> Some well-known forths use that as it suits the forth interpreter. OTOH
> it's overkill for most apps and requires more handling. What's missing
> is the intermediate function, similar to >FLOAT but for integer.

That's besides the point (there is still >NUMBER). The point is whether
recognizers like rec-num or rec-dnum should be part of a Forth kernel.
I won't criticise gforth design decisions, but ISTM that _this_ is overkill
as long as there are easier ways.

On 14/06/2023 4:38 pm, minforth wrote:
> dxforth schrieb am Mittwoch, 14. Juni 2023 um 05:54:04 UTC+2:
>> On 13/06/2023 7:49 pm, minforth wrote:
>>> Anton Ertl schrieb am Dienstag, 13. Juni 2023 um 09:48:28 UTC+2:
>>>> Brian Fox <bria...@brianfox.ca> writes:
>>>>> On Monday, June 12, 2023 at 3:55:13=E2=80=AFPM UTC-4, gobli...@gmail.com wr=
>>>>> ote:
>>>>>
>>>>> gForth seems to have NUMBER? .
>>>> Not in the development version. As for S>NUMBER (mentioned also in
>>>> this thread), the source code says:
>>>>
>>>> \ don't use this, there is no way to tell success
>>>>
>>>> The current recommendation is
>>>>
>>>> 'rec-num' ( addr u -- n/d table | notfound ) gforth-experimental "rec-num"
>>>> converts a number to a single/double integer
>>>>
>>>> where table is the xt of TRANSLATE-NUM (and n below table) or
>>>> TRANSLATE-DNUM (and d below table); or the top of stack ist the xt of
>>>> NOTFOUND.
>>>>
>>>> I find the combination of single- and double-cell numbers in one
>>>> recognizer suboptimal as an interface, but it actally simplifies the
>>>> implemetation compared to a variant that has separate recognizers for
>>>> singles and doubles and only combines them at the recognizer level.
>>>
>>> I use a non-standard
>>> NUMBER? \ ( a u -- 0 | n 1 | d 2 ) convert to single or double number
>>> that handles prefixes, 'c' chars, and the classic dpl. So no surprises here.
>>> Okay for interpreting legacy code.
>> Some well-known forths use that as it suits the forth interpreter. OTOH
>> it's overkill for most apps and requires more handling. What's missing
>> is the intermediate function, similar to >FLOAT but for integer.
>
> That's besides the point (there is still >NUMBER). The point is whether
> recognizers like rec-num or rec-dnum should be part of a Forth kernel.
> I won't criticise gforth design decisions, but ISTM that _this_ is overkill
> as long as there are easier ways.

If ANS' >NUMBER is the reference then anything over becomes 'overkill'.
Early forths had NUMBER (as did Forth-79 in the Reference wordset).
ANS ignored it - perhaps due to lack of common practice. I'm getting
the sense >NUMBER is not enough. The opportunity and willingness to
determine what is has likely passed us by.

On Wednesday, 14 June 2023 at 09:38:03 UTC+1, dxforth wrote:
> On 14/06/2023 4:38 pm, minforth wrote:
> > dxforth schrieb am Mittwoch, 14. Juni 2023 um 05:54:04 UTC+2:
> >> On 13/06/2023 7:49 pm, minforth wrote:
> >>> Anton Ertl schrieb am Dienstag, 13. Juni 2023 um 09:48:28 UTC+2:
> >>>> Brian Fox <bria...@brianfox.ca> writes:
> >>>>> On Monday, June 12, 2023 at 3:55:13=E2=80=AFPM UTC-4, gobli...@gmail.com wr=
> >>>>> ote:
> >>>>>
> >>>>> gForth seems to have NUMBER? .
> >>>> Not in the development version. As for S>NUMBER (mentioned also in
> >>>> this thread), the source code says:
> >>>>
> >>>> \ don't use this, there is no way to tell success
> >>>>
> >>>> The current recommendation is
> >>>>
> >>>> 'rec-num' ( addr u -- n/d table | notfound ) gforth-experimental "rec-num"
> >>>> converts a number to a single/double integer
> >>>>
> >>>> where table is the xt of TRANSLATE-NUM (and n below table) or
> >>>> TRANSLATE-DNUM (and d below table); or the top of stack ist the xt of
> >>>> NOTFOUND.
> >>>>
> >>>> I find the combination of single- and double-cell numbers in one
> >>>> recognizer suboptimal as an interface, but it actally simplifies the
> >>>> implemetation compared to a variant that has separate recognizers for
> >>>> singles and doubles and only combines them at the recognizer level.
> >>>
> >>> I use a non-standard
> >>> NUMBER? \ ( a u -- 0 | n 1 | d 2 ) convert to single or double number
> >>> that handles prefixes, 'c' chars, and the classic dpl. So no surprises here.
> >>> Okay for interpreting legacy code.
> >> Some well-known forths use that as it suits the forth interpreter. OTOH
> >> it's overkill for most apps and requires more handling. What's missing
> >> is the intermediate function, similar to >FLOAT but for integer.
> >
> > That's besides the point (there is still >NUMBER). The point is whether
> > recognizers like rec-num or rec-dnum should be part of a Forth kernel.
> > I won't criticise gforth design decisions, but ISTM that _this_ is overkill
> > as long as there are easier ways.
> If ANS' >NUMBER is the reference then anything over becomes 'overkill'.
> Early forths had NUMBER (as did Forth-79 in the Reference wordset).
> ANS ignored it - perhaps due to lack of common practice. I'm getting
> the sense >NUMBER is not enough. The opportunity and willingness to
> determine what is has likely passed us by.

The most important thing to realise is that >number is not meant to be the
final word but a stepping stone..

It applies to integers.

Its weakness is that if there is an overflow there is no signal to the caller.

In article <03f1626b-811e-467e-a691-50742d24bd97n@googlegroups.com>,
minforth <minforth@arcor.de> wrote:
>dxforth schrieb am Mittwoch, 14. Juni 2023 um 05:54:04 UTC+2:
>> On 13/06/2023 7:49 pm, minforth wrote:
>> > Anton Ertl schrieb am Dienstag, 13. Juni 2023 um 09:48:28 UTC+2:
>> >> Brian Fox <bria...@brianfox.ca> writes:
>> >>> On Monday, June 12, 2023 at 3:55:13=E2=80=AFPM UTC-4,
>gobli...@gmail.com wr=
>> >>> ote:
>> >>>
>> >>> gForth seems to have NUMBER? .
>> >> Not in the development version. As for S>NUMBER (mentioned also in
>> >> this thread), the source code says:
>> >>
>> >> \ don't use this, there is no way to tell success
>> >>
>> >> The current recommendation is
>> >>
>> >> 'rec-num' ( addr u -- n/d table | notfound ) gforth-experimental "rec-num"
>> >> converts a number to a single/double integer
>> >>
>> >> where table is the xt of TRANSLATE-NUM (and n below table) or
>> >> TRANSLATE-DNUM (and d below table); or the top of stack ist the xt of
>> >> NOTFOUND.
>> >>
>> >> I find the combination of single- and double-cell numbers in one
>> >> recognizer suboptimal as an interface, but it actally simplifies the
>> >> implemetation compared to a variant that has separate recognizers for
>> >> singles and doubles and only combines them at the recognizer level.
>> >
>> > I use a non-standard
>> > NUMBER? \ ( a u -- 0 | n 1 | d 2 ) convert to single or double number
>> > that handles prefixes, 'c' chars, and the classic dpl. So no
>surprises here.
>> > Okay for interpreting legacy code.
>> Some well-known forths use that as it suits the forth interpreter. OTOH
>> it's overkill for most apps and requires more handling. What's missing
>> is the intermediate function, similar to >FLOAT but for integer.
>
>That's besides the point (there is still >NUMBER). The point is whether
>recognizers like rec-num or rec-dnum should be part of a Forth kernel.
>I won't criticise gforth design decisions, but ISTM that _this_ is overkill
>as long as there are easier ways.

I for me would regret that rec-num etc would be forced into the kernel,
and would be not in an optional wordset.
A similar case is the prefixes $ # etc. It refers to numbers and the
general view is that that cannot made optional.
In the design of ciforth I decided that I absolutely want the $ #
prefixes optional. The consequential changes to the interpreter are
minimal, allowing the prefixes to be more or less normal words.
For example you could have a linux wordlist where you redefine $
to mean "fetch the environment variable", and introduce 0x for
hexadecimal.

I explained prefixes before. If you understood them and are tired
of hearing it again, you can skip the remainder.
PREFIX is a property similar to IMMEDIATE and apply to the word just
completed.
A prefix is found in the dictionary, observing the current search
order, as soon as it matches the first part of a word.
Then the parse pointer is advanced by the
length of the word found, be it a prefix or regular word.

That's it. Numbers can be handled by prefixes -+0..9 .
They find the number to be converted in the input stream however,
not as the string passed to INTERPRET.
They are to be made IMMEDIATE to be used in definitions, as usual.
The $ prefix can be added later, or not at all.
A " prefix for strings is easy, and can be added modularly as well.

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

In article <0a763f38-bc21-4486-a833-b55e668c0a87n@googlegroups.com>,
NN <november.nihal@gmail.com> wrote:
<SNIP>
>
>
>The most important thing to realise is that >number is not meant to be the
>final word but a stepping stone..
>
>It applies to integers.
>
>Its weakness is that if there is an overflow there is no signal to the caller.

On the contrary, it has all options open. However you have to add overflow.
It is a "Swiss army knife" (or egg vending machine).

The word >NUMBER used as a stepping stone suggest that it should be
used internally. Don't fall for the temptation. Forcing a Forth to use
this "switch army knife" result in a cumbersome Forth implementation.

Come to think of this. >NUMBER is in the ciforth kernel and it is never
used there. It wastes a whopping 300 bytes there and it is one of the
5 most complicated definitions in my whole Forth, making it look worse
than it should be.
>NUMBER should a loadable extension. A typical example where it is used
in is a lisp interpreter.
In normal situation it is rare. E.g. in my 400+ solutions of euler
problems, it came up once.
That was euler 13:
"
Work out the first ten digits of the sum of the following one-hundred
50-digit numbers.
37107287533902102798797998220837590246510135740250
..
"
You can see how that is appropriate.
Groetjes Albert.

>
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat spinning. - the Wise from Antrim -

On 14/06/2023 7:56 pm, albert wrote:
> In article <0a763f38-bc21-4486-a833-b55e668c0a87n@googlegroups.com>,
> NN <november.nihal@gmail.com> wrote:
> <SNIP>
>>
>>
>> The most important thing to realise is that >number is not meant to be the
>> final word but a stepping stone..
>>
>> It applies to integers.
>>
>> Its weakness is that if there is an overflow there is no signal to the caller.
>
> On the contrary, it has all options open. However you have to add overflow.
> It is a "Swiss army knife" (or egg vending machine).
>
> The word >NUMBER used as a stepping stone suggest that it should be
> used internally. Don't fall for the temptation. Forcing a Forth to use
> this "switch army knife" result in a cumbersome Forth implementation.

No one is forced to use it. That 99% or more of forths have suggests
it's adequate. There's no overflow protection but IIRC neither has C .