Until recently I treated SKIP/SCAN as exotic functions only found in
medium to large forths. That changed when I encountered them in small
microcontroller forths e.g. FlashForth, SwiftX.

If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
would say it's time to reconsider - not standardization as hell will
freeze first - rather treat them as ubiquitously and with as little
need of explanation or definition as is currently afforded PLACE.
Regarding compatibility, the only consideration is 'white space'.
SKIP/SCAN has the same restriction as WORD when BL is used as the
scan character. Which should come as no surprise as WORD is typically
implemented with SKIP/SCAN.

In article <t9to17$1u6s$1@gioia.aioe.org>, dxforth <dxforth@gmail.com> wrote:
>Until recently I treated SKIP/SCAN as exotic functions only found in
>medium to large forths. That changed when I encountered them in small
>microcontroller forths e.g. FlashForth, SwiftX.
>
>If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
>would say it's time to reconsider - not standardization as hell will
>freeze first - rather treat them as ubiquitously and with as little
>need of explanation or definition as is currently afforded PLACE.
>Regarding compatibility, the only consideration is 'white space'.
>SKIP/SCAN has the same restriction as WORD when BL is used as the
>scan character. Which should come as no surprise as WORD is typically
>implemented with SKIP/SCAN.

In modern Forth WORD is not typically implemented but a loadable extension.

For SKIP SCAN I can't remember what it is supposed to do.
Gforth 0.7.3 has it, but I can't find in the documentation.
Swiftforth has it, but I can't find in the documentation.

Bottom line, as soon as it standardized, I will look into it,
if it worthwhile to add to ciforth.

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

none albert schrieb am Montag, 4. Juli 2022 um 09:43:40 UTC+2:
> In article <t9to17$1u6s$1...@gioia.aioe.org>, dxforth <dxf...@gmail.com> wrote:
> >Until recently I treated SKIP/SCAN as exotic functions only found in
> >medium to large forths. That changed when I encountered them in small
> >microcontroller forths e.g. FlashForth, SwiftX.
> >
> >If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
> >would say it's time to reconsider - not standardization as hell will
> >freeze first - rather treat them as ubiquitously and with as little
> >need of explanation or definition as is currently afforded PLACE.
> >Regarding compatibility, the only consideration is 'white space'.
> >SKIP/SCAN has the same restriction as WORD when BL is used as the
> >scan character. Which should come as no surprise as WORD is typically
> >implemented with SKIP/SCAN.
> In modern Forth WORD is not typically implemented but a loadable extension.
>
> For SKIP SCAN I can't remember what it is supposed to do.
> Gforth 0.7.3 has it, but I can't find in the documentation.
> Swiftforth has it, but I can't find in the documentation.
>
> Bottom line, as soon as it standardized, I will look into it,
> if it worthwhile to add to ciforth.

I consider Forth source text as pre-tokenized because every word/number
appears space-delimited.

For non-tokenized text those classic SKIP/SCAN words are practically useless.

In article <3051af2f-1cec-4aca-885c-76a54938e1f0n@googlegroups.com>,
minf...@arcor.de <minforth@arcor.de> wrote:
>none albert schrieb am Montag, 4. Juli 2022 um 09:43:40 UTC+2:
>> In article <t9to17$1u6s$1...@gioia.aioe.org>, dxforth
><dxf...@gmail.com> wrote:
>> >Until recently I treated SKIP/SCAN as exotic functions only found in
>> >medium to large forths. That changed when I encountered them in small
>> >microcontroller forths e.g. FlashForth, SwiftX.
>> >
>> >If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
>> >would say it's time to reconsider - not standardization as hell will
>> >freeze first - rather treat them as ubiquitously and with as little
>> >need of explanation or definition as is currently afforded PLACE.
>> >Regarding compatibility, the only consideration is 'white space'.
>> >SKIP/SCAN has the same restriction as WORD when BL is used as the
>> >scan character. Which should come as no surprise as WORD is typically
>> >implemented with SKIP/SCAN.
>> In modern Forth WORD is not typically implemented but a loadable extension.
>>
>> For SKIP SCAN I can't remember what it is supposed to do.
>> Gforth 0.7.3 has it, but I can't find in the documentation.
>> Swiftforth has it, but I can't find in the documentation.
>>
>> Bottom line, as soon as it standardized, I will look into it,
>> if it worthwhile to add to ciforth.
>
>I consider Forth source text as pre-tokenized because every word/number
>appears space-delimited.
>
>For non-tokenized text those classic SKIP/SCAN words are practically useless.
>

No any more. The modern insights is that
"we gaan naar Rome"
is a token.
You can't have much success if considering Forth as pre-tokenized,
nowadays. That was cure in the seventies.

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

On Monday, July 4, 2022 at 5:50:02 AM UTC+2, dxforth wrote:
> Until recently I treated SKIP/SCAN as exotic functions only found in
> medium to large forths.

I use SKIP and SCAN quite often when processing strings.

I would not know how to skip leading characters, or scan for words
delimited by a specified character, without SKIP and SCAN.

It came as a surprise to me that these useful words have not been
included into the ANS standard. They should be added.

Henry

> It came as a surprise to me that these useful words have not been
> included into the ANS standard. They should be added.

I believe these two words -- and any other -- everyone can include
on one's own, without trying to make the whole Forth-world happy
with new, even better standard.

none albert schrieb am Montag, 4. Juli 2022 um 09:59:19 UTC+2:
> In article <3051af2f-1cec-4aca...@googlegroups.com>,
> minf...@arcor.de <minf...@arcor.de> wrote:
> >none albert schrieb am Montag, 4. Juli 2022 um 09:43:40 UTC+2:
> >> In article <t9to17$1u6s$1...@gioia.aioe.org>, dxforth
> ><dxf...@gmail.com> wrote:
> >> >Until recently I treated SKIP/SCAN as exotic functions only found in
> >> >medium to large forths. That changed when I encountered them in small
> >> >microcontroller forths e.g. FlashForth, SwiftX.
> >> >
> >> >If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
> >> >would say it's time to reconsider - not standardization as hell will
> >> >freeze first - rather treat them as ubiquitously and with as little
> >> >need of explanation or definition as is currently afforded PLACE.
> >> >Regarding compatibility, the only consideration is 'white space'.
> >> >SKIP/SCAN has the same restriction as WORD when BL is used as the
> >> >scan character. Which should come as no surprise as WORD is typically
> >> >implemented with SKIP/SCAN.
> >> In modern Forth WORD is not typically implemented but a loadable extension.
> >>
> >> For SKIP SCAN I can't remember what it is supposed to do.
> >> Gforth 0.7.3 has it, but I can't find in the documentation.
> >> Swiftforth has it, but I can't find in the documentation.
> >>
> >> Bottom line, as soon as it standardized, I will look into it,
> >> if it worthwhile to add to ciforth.
> >
> >I consider Forth source text as pre-tokenized because every word/number
> >appears space-delimited.
> >
> >For non-tokenized text those classic SKIP/SCAN words are practically useless.
> >
> No any more. The modern insights is that
> "we gaan naar Rome"
> is a token.
> You can't have much success if considering Forth as pre-tokenized,
> nowadays. That was cure in the seventies.

That's a question of definition. Scanning and parsing is fuzzy anyhow in Forth.

I had my revelations when treating non-Forth code with Forth eg
4*alpha+0.01
with alpha being a known constant.

In article <85102527-f82a-4ddb-9638-70d83174cad8n@googlegroups.com>,
Heinrich Hohl <hheinrich.hohl@gmail.com> wrote:
>On Monday, July 4, 2022 at 5:50:02 AM UTC+2, dxforth wrote:
>> Until recently I treated SKIP/SCAN as exotic functions only found in
>> medium to large forths.
>
>I use SKIP and SCAN quite often when processing strings.
>
>I would not know how to skip leading characters, or scan for words
>delimited by a specified character, without SKIP and SCAN.
>
>It came as a surprise to me that these useful words have not been
>included into the ANS standard. They should be added.

Then propose and give a watertight definition, and get it approved.
As everybody agrees with the definition, that is the motivation
to add to every Forth.

>
>Henry

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

On Monday, July 4, 2022 at 5:50:02 AM UTC+2, dxforth wrote:
> If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
> would say it's time to reconsider - not standardization as hell will
> freeze first - rather treat them as ubiquitously and with as little
> need of explanation or definition as is currently afforded PLACE.
I rarely use SCAN/SKIP, because I read most strings from file - and
there (in 4tH) I can use PARSE, PARSE-NAME - or numerous other
(loadable) variations - including PARSE-CSV.

Where SCAN/SKIP is concerned I have some other variations on that
theme where the SCAN, SKIP or SPLIT function is a DEFERed word
that can e.g. do numeric characters or non-alphabetic characters -
you name it.

> Regarding compatibility, the only consideration is 'white space'.
> SKIP/SCAN has the same restriction as WORD when BL is used as the
> scan character. Which should come as no surprise as WORD is typically
> implemented with SKIP/SCAN.
WORD is loadable in 4tH - but I don't think I've used it in decades.

In short - yeah, I got 'em. No, I barely use 'em.

Hans Bezemer

On Sunday, July 3, 2022 at 11:50:02 PM UTC-4, dxforth wrote:
> Until recently I treated SKIP/SCAN as exotic functions only found in
> medium to large forths. That changed when I encountered them in small
> microcontroller forths e.g. FlashForth, SwiftX.
>
> If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
> would say it's time to reconsider - not standardization as hell will
> freeze first - rather treat them as ubiquitously and with as little
> need of explanation or definition as is currently afforded PLACE.
> Regarding compatibility, the only consideration is 'white space'.
> SKIP/SCAN has the same restriction as WORD when BL is used as the
> scan character. Which should come as no surprise as WORD is typically
> implemented with SKIP/SCAN.

At least one post says they don't know what SKIP and SCAN are supposed to do. I don't see where anyone mentions this. Can someone explain it for my benefit?

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

gnuarm.del...@gmail.com schrieb am Montag, 4. Juli 2022 um 17:51:17 UTC+2:
> On Sunday, July 3, 2022 at 11:50:02 PM UTC-4, dxforth wrote:
> > Until recently I treated SKIP/SCAN as exotic functions only found in
> > medium to large forths. That changed when I encountered them in small
> > microcontroller forths e.g. FlashForth, SwiftX.
> >
> > If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
> > would say it's time to reconsider - not standardization as hell will
> > freeze first - rather treat them as ubiquitously and with as little
> > need of explanation or definition as is currently afforded PLACE.
> > Regarding compatibility, the only consideration is 'white space'.
> > SKIP/SCAN has the same restriction as WORD when BL is used as the
> > scan character. Which should come as no surprise as WORD is typically
> > implemented with SKIP/SCAN.
> At least one post says they don't know what SKIP and SCAN are supposed to do. I don't see where anyone mentions this. Can someone explain it for my benefit?
>

See here page 101ff (89/90 in the document)
http://www.forth.org/OffeteStore/1003_InsideF83.pdf

In article <f2d6e47e-d462-4dc0-a317-d9cfb7089902n@googlegroups.com>,
minf...@arcor.de <minforth@arcor.de> wrote:
>gnuarm.del...@gmail.com schrieb am Montag, 4. Juli 2022 um 17:51:17 UTC+2:
>> On Sunday, July 3, 2022 at 11:50:02 PM UTC-4, dxforth wrote:
>> > Until recently I treated SKIP/SCAN as exotic functions only found in
>> > medium to large forths. That changed when I encountered them in small
>> > microcontroller forths e.g. FlashForth, SwiftX.
>> >
>> > If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
>> > would say it's time to reconsider - not standardization as hell will
>> > freeze first - rather treat them as ubiquitously and with as little
>> > need of explanation or definition as is currently afforded PLACE.
>> > Regarding compatibility, the only consideration is 'white space'.
>> > SKIP/SCAN has the same restriction as WORD when BL is used as the
>> > scan character. Which should come as no surprise as WORD is typically
>> > implemented with SKIP/SCAN.
>> At least one post says they don't know what SKIP and SCAN are supposed
>to do. I don't see where anyone mentions this. Can someone explain it
>for my benefit?
>>
>
>See here page 101ff (89/90 in the document)
>http://www.forth.org/OffeteStore/1003_InsideF83.pdf

Please note that this refers to a single implementation of
Forth. (f83.exe).
These words are not present in the FORTH 83 standard.
http://forth.sourceforge.net/standard/fst83/

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

On Mon, 4 Jul 2022 09:19:15 -0700 (PDT)
"minf...@arcor.de" <minforth@arcor.de> wrote:

> gnuarm.del...@gmail.com schrieb am Montag, 4. Juli 2022 um 17:51:17 UTC+2:
> > On Sunday, July 3, 2022 at 11:50:02 PM UTC-4, dxforth wrote:
> > > Until recently I treated SKIP/SCAN as exotic functions only found in
> > > medium to large forths. That changed when I encountered them in small
> > > microcontroller forths e.g. FlashForth, SwiftX.
> > >
> > > If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
> > > would say it's time to reconsider - not standardization as hell will
> > > freeze first - rather treat them as ubiquitously and with as little
> > > need of explanation or definition as is currently afforded PLACE.
> > > Regarding compatibility, the only consideration is 'white space'.
> > > SKIP/SCAN has the same restriction as WORD when BL is used as the
> > > scan character. Which should come as no surprise as WORD is typically
> > > implemented with SKIP/SCAN.
> > At least one post says they don't know what SKIP and SCAN are supposed to do. I don't see where anyone mentions this. Can someone explain it for my benefit?
> >
>
> See here page 101ff (89/90 in the document)
> http://www.forth.org/OffeteStore/1003_InsideF83.pdf

There's a typo in the asm code for SKIP on that page:
<quote>
LABEL DONE A common returning point when the input stream is exhausted.
CX PUSH Push the contents of CX on stack and return. CX register has the remaining length
of the stream.
NEXT

CODE SKIP ( addr len char -- addr1 len1 )
Given the address and length of a string, and a character to look for, scan through
the string while we continue to find the character. Leave the address of the
mismatch and the length of the remaining string.
AX POP Move char to AX register.
CX POP Move len to CX register.
DONE JCXZ If length of string is zero, jump to DONE and return.
DI POP Move addr to DI register.
DX DX MOV
DX ES MOV Set ES=DS for string manipulations.
REPZ BYTE SCAS Repeatedly scan the string until we find a character different from that in AX.
0<> IF CX now has the count of characters in the remaining string. If CX is not zero,
</quote>

I'm pretty sure it should be:
DX DS MOV
before
DX ES MOV Set ES=DS for string manipulations.
--
Bah, and indeed Humbug.

On 4/07/2022 19:58, Heinrich Hohl wrote:
> On Monday, July 4, 2022 at 5:50:02 AM UTC+2, dxforth wrote:
>> Until recently I treated SKIP/SCAN as exotic functions only found in
>> medium to large forths.
>
> I use SKIP and SCAN quite often when processing strings.
>
> I would not know how to skip leading characters, or scan for words
> delimited by a specified character, without SKIP and SCAN.
>
> It came as a surprise to me that these useful words have not been
> included into the ANS standard. They should be added.

Checking occurrence of SCAN (approx, excluding false matches but not
duplicated sources):

SwiftForth: 35
VfxForth: 168
Win32Forth: 269 (???)
Gforth: 34

SCAN is used in literally every application I write (command-tail parsing).

For those who use SKIP and SCAN, does it specially handle TABs?
e.g. VFX versions treat TABs in the string as if they were BL.
Has it caused any issues in practice?

On 5/07/2022 02:19, minf...@arcor.de wrote:
> gnuarm.del...@gmail.com schrieb am Montag, 4. Juli 2022 um 17:51:17 UTC+2:
>> On Sunday, July 3, 2022 at 11:50:02 PM UTC-4, dxforth wrote:
>> > Until recently I treated SKIP/SCAN as exotic functions only found in
>> > medium to large forths. That changed when I encountered them in small
>> > microcontroller forths e.g. FlashForth, SwiftX.
>> >
>> > If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
>> > would say it's time to reconsider - not standardization as hell will
>> > freeze first - rather treat them as ubiquitously and with as little
>> > need of explanation or definition as is currently afforded PLACE.
>> > Regarding compatibility, the only consideration is 'white space'.
>> > SKIP/SCAN has the same restriction as WORD when BL is used as the
>> > scan character. Which should come as no surprise as WORD is typically
>> > implemented with SKIP/SCAN.
>> At least one post says they don't know what SKIP and SCAN are supposed to do.

ANS said there were folks oblivious about locals - so they introduced it!
Their way of getting something into the 'forth common consciousness'.

On 5/07/2022 06:16, Kerr-Mudd, John wrote:
>>
>> See here page 101ff (89/90 in the document)
>> http://www.forth.org/OffeteStore/1003_InsideF83.pdf
>
> There's a typo in the asm code for SKIP on that page:
> <quote>
> LABEL DONE A common returning point when the input stream is exhausted.
> CX PUSH Push the contents of CX on stack and return. CX register has the remaining length
> of the stream.
> NEXT
>
> CODE SKIP ( addr len char -- addr1 len1 )
> Given the address and length of a string, and a character to look for, scan through
> the string while we continue to find the character. Leave the address of the
> mismatch and the length of the remaining string.
> AX POP Move char to AX register.
> CX POP Move len to CX register.
> DONE JCXZ If length of string is zero, jump to DONE and return.
> DI POP Move addr to DI register.
> DX DX MOV
> DX ES MOV Set ES=DS for string manipulations.
> REPZ BYTE SCAS Repeatedly scan the string until we find a character different from that in AX.
> 0<> IF CX now has the count of characters in the remaining string. If CX is not zero,
> </quote>
>
>
> I'm pretty sure it should be:
> DX DS MOV
> before
> DX ES MOV Set ES=DS for string manipulations.

A nice trick is to allow ES to be set from a variable. This allows SKIP
and other string operators to be used on segments other than forth e.g.

\ Return DOS environment segment
: ENVSEG ( -- seg ) $2C @ ;

\ Search DOS environment for string a u. Return null
\ terminated remainder. Null not included in count.
: GETENV ( a u -- seg zadr len true | false )
2>r envseg dup sseg !
0 begin 2dup @l while 1+ repeat 2+
r@ 0 rot 2r> caps search
if rot /string drop zcount true
else 2drop 2drop 0 then cseg sseg ! ;

On 4/07/2022 23:30, Hans Bezemer wrote:
> On Monday, July 4, 2022 at 5:50:02 AM UTC+2, dxforth wrote:
>> If forthers are avoiding SKIP/SCAN because it's 'not ANS' then I
>> would say it's time to reconsider - not standardization as hell will
>> freeze first - rather treat them as ubiquitously and with as little
>> need of explanation or definition as is currently afforded PLACE.
> I rarely use SCAN/SKIP, because I read most strings from file - and
> there (in 4tH) I can use PARSE, PARSE-NAME - or numerous other
> (loadable) variations - including PARSE-CSV.
>
> Where SCAN/SKIP is concerned I have some other variations on that
> theme where the SCAN, SKIP or SPLIT function is a DEFERed word
> that can e.g. do numeric characters or non-alphabetic characters -
> you name it.

Staying on that thought, Wil Baden did a 'generalized' SKIP/SCAN -
macros in a BEGIN WHILE REPEAT. It could scan backwards, forwards,
skip white-space etc. I've wondered who came up with the original
SKIP/SCAN factors - Laxen & Perry - or perhaps another Baden suggestion
like PLACE ?

On Tuesday, July 5, 2022 at 5:23:51 AM UTC+2, dxforth wrote:
> For those who use SKIP and SCAN, does it specially handle TABs?
> e.g. VFX versions treat TABs in the string as if they were BL.
> Has it caused any issues in practice?

SKIP and SCAN are only supposed to skip or scan for the specified character.
Space ($20) and tab ($09) are clearly not the same characters, and the two
words should be able to distinguish them. You may want to distinguish them!

In SwiftForth, SKIP and SCAN work as expected. They will distinguish space and tab.
Both words are code definitions and written as short as possible with no extra actions.
This is how it should be.

I looked at VFX and yes, this is weird. The definitions for SKIP and SCAN are more
complicated than necessary and contain extra tests for $09 and $20.

In my eyes this is not a good solution. Treating space and tab as identical characters
may be convenient at times, but this requirement should be handled differently.

In Forth, basic words should perform simple actions. This makes their actions predictable
and avoids unexpected side effects.

The only good thing that I can say about it is that the VFX manual clearly describes the
unusual behavior of SKIP and SCAN:
"Note that when a space char is given, tabs are also ignored."

Henry

Heinrich Hohl schrieb am Dienstag, 5. Juli 2022 um 11:23:47 UTC+2:
> On Tuesday, July 5, 2022 at 5:23:51 AM UTC+2, dxforth wrote:
> > For those who use SKIP and SCAN, does it specially handle TABs?
> > e.g. VFX versions treat TABs in the string as if they were BL.
> > Has it caused any issues in practice?
> SKIP and SCAN are only supposed to skip or scan for the specified character.
> Space ($20) and tab ($09) are clearly not the same characters, and the two
> words should be able to distinguish them. You may want to distinguish them!
>
> In SwiftForth, SKIP and SCAN work as expected. They will distinguish space and tab.
> Both words are code definitions and written as short as possible with no extra actions.
> This is how it should be.
>
> I looked at VFX and yes, this is weird. The definitions for SKIP and SCAN are more
> complicated than necessary and contain extra tests for $09 and $20.
>
> In my eyes this is not a good solution. Treating space and tab as identical characters
> may be convenient at times, but this requirement should be handled differently.
>
> In Forth, basic words should perform simple actions. This makes their actions predictable
> and avoids unexpected side effects.
>
> The only good thing that I can say about it is that the VFX manual clearly describes the
> unusual behavior of SKIP and SCAN:
> "Note that when a space char is given, tabs are also ignored."
>

Things shouldn't be taken too religiously. The standard speaks even of ignoring
whitespaces for some words.

On 5/07/2022 19:23, Heinrich Hohl wrote:
> On Tuesday, July 5, 2022 at 5:23:51 AM UTC+2, dxforth wrote:
>> For those who use SKIP and SCAN, does it specially handle TABs?
>> e.g. VFX versions treat TABs in the string as if they were BL.
>> Has it caused any issues in practice?
>
> SKIP and SCAN are only supposed to skip or scan for the specified character.
> Space ($20) and tab ($09) are clearly not the same characters, and the two
> words should be able to distinguish them. You may want to distinguish them!
>
> In SwiftForth, SKIP and SCAN work as expected. They will distinguish space and tab.
> Both words are code definitions and written as short as possible with no extra actions.
> This is how it should be.
>
> I looked at VFX and yes, this is weird. The definitions for SKIP and SCAN are more
> complicated than necessary and contain extra tests for $09 and $20.

Specifically it checks input char read - if $09 it substitutes $20 and compares
that against the reference.
> In my eyes this is not a good solution. Treating space and tab as identical characters
> may be convenient at times, but this requirement should be handled differently.

It means SCASB can't be employed and $09 becomes opaque. OTOH it simplifies
text parsing. Lines containing tabs won't require additional handling.

> In Forth, basic words should perform simple actions. This makes their actions predictable
> and avoids unexpected side effects.

That's the question. I currently use the classic SKIP/SCAN. Am I gaining
anything by staying with it, or would I be better off switching to what VFX
and FlashForth uses? FlashForth likely hasn't had much use but VFX presumably
has.

> The only good thing that I can say about it is that the VFX manual clearly describes the
> unusual behavior of SKIP and SCAN:
> "Note that when a space char is given, tabs are also ignored."

What it omits to say is that when tab is given, it will never be found :)

On 5 Jul 2022 at 11:23:45 CEST, "Heinrich Hohl" <hheinrich.hohl@gmail.com>
wrote:

> I looked at VFX and yes, this is weird. The definitions for SKIP and SCAN are
> more
> complicated than necessary and contain extra tests for $09 and $20.
>
> In my eyes this is not a good solution. Treating space and tab as identical
> characters
> may be convenient at times, but this requirement should be handled differently.
>
> In Forth, basic words should perform simple actions. This makes their actions
> predictable
> and avoids unexpected side effects.
>
> The only good thing that I can say about it is that the VFX manual clearly
> describes the
> unusual behavior of SKIP and SCAN:
> "Note that when a space char is given, tabs are also ignored."

The behaviour come from when we swtched from block files to text files.
We wished to retain the ability to keep source in chunks, and to keep the
text small, so we treated ^L (12) as a page separator and TAB (9) as white
space. At that time many text editors behaved the same way.

This behaviour has, to our knowledge, only inconvenienced one client
in the last 30 years or more, and they just redefined SKIP and SCAN
in their application. Apart from that client this behaviour has created no
technical support. I believe it is in the spirit of the ANS and following
standards use of the term "whitespace".

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

Stephen Pelc <stephen@vfxforth.com> writes:
>The behaviour come from when we swtched from block files to text files.
>We wished to retain the ability to keep source in chunks, and to keep the
>text small, so we treated ^L (12) as a page separator and TAB (9) as white
>space. At that time many text editors behaved the same way.

11.3.5
|When parsing from a text file using a space delimiter, control
|characters shall be treated the same as the space character.

[funky behaviour of SKIP and SCAN in VFX]
>I believe it is in the spirit of the ANS

It certainly does: Systems are allowed to implement non-standard words
like SKIP and SCAN with whatever semantics they like. And apparently
that's what's happening. Let's see:

s\" \x01\z\v\f\t abc" bl scan . c@ .

Gforth prints 4 32
iForth 5.1-mini prints 5 9
lxf prints 4 32
SwiftForth 3.11 prints 4 32
vfx64 5.11 prints 5 9

>and following
>standards use of the term "whitespace".

I'm not sure the standard uses that term. I certainly does not in the
sentence I cited above.

- 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 5/07/2022 19:23, Heinrich Hohl wrote:
> ...
> In SwiftForth, SKIP and SCAN work as expected. They will distinguish space and tab.
> Both words are code definitions and written as short as possible with no extra actions.
> This is how it should be.
>
> I looked at VFX and yes, this is weird. The definitions for SKIP and SCAN are more
> complicated than necessary and contain extra tests for $09 and $20.
>
> In my eyes this is not a good solution. Treating space and tab as identical characters
> may be convenient at times, but this requirement should be handled differently.

It appears NT/FORTH has SKIP SCAN (as per F83, SwiftForth etc) and two additional
ones:

BL-SKIP ( adr len -- adr' len' )

BL-SCAN ( adr len -- adr' len' )

'BL' for these means $20 and below.

This seems like a good solution. Most forths should be able to get by with one
set in the kernel and the other as loadable source for when the need arises.
Resource-restrained systems that can only afford one might consider a VFX-style
SKIP/SCAN.

On Tuesday, July 5, 2022 at 5:54:35 PM UTC+2, Anton Ertl wrote:
> Stephen Pelc <ste...@vfxforth.com> writes:
[..]
> [funky behaviour of SKIP and SCAN in VFX]
> >I believe it is in the spirit of the ANS
> It certainly does: Systems are allowed to implement non-standard words
> like SKIP and SCAN with whatever semantics they like. And apparently
> that's what's happening. Let's see:
>
> s\" \x01\z\v\f\t abc" bl scan . c@ .
>
>
> Gforth prints 4 32
> iForth 5.1-mini prints 5 9
> lxf prints 4 32
> SwiftForth 3.11 prints 4 32
> vfx64 5.11 prints 5 9

FORTH> help scan
SCAN IFORTH
( c-addr1 u1 delimiter -- c-addr2 u2 )
Scan the string identified by c-addr1 u1 for delimiter. If this
character is found, leave its address in c-addr2 and the count remaining
in u2, otherwise c-addr2 points after the string and u2 is 0.
When the delimiter is not a <tab>, <lf> or <cr>, all three of these
characters are considered equivalent to a space.
This means BL SCAN is a special case.
See also: SKIP

-marcel

In article <2022Jul5.173251@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Stephen Pelc <stephen@vfxforth.com> writes:
>>The behaviour come from when we swtched from block files to text files.
>>We wished to retain the ability to keep source in chunks, and to keep the
>>text small, so we treated ^L (12) as a page separator and TAB (9) as white
>>space. At that time many text editors behaved the same way.
>
>11.3.5
>|When parsing from a text file using a space delimiter, control
>|characters shall be treated the same as the space character.
>
>[funky behaviour of SKIP and SCAN in VFX]
>>I believe it is in the spirit of the ANS
>
>It certainly does: Systems are allowed to implement non-standard words
>like SKIP and SCAN with whatever semantics they like. And apparently
>that's what's happening. Let's see:
>
>s\" \x01\z\v\f\t abc" bl scan . c@ .
>
>
>Gforth prints 4 32
>iForth 5.1-mini prints 5 9
>lxf prints 4 32
>SwiftForth 3.11 prints 4 32
>vfx64 5.11 prints 5 9
>
>>and following
>>standards use of the term "whitespace".
>
>I'm not sure the standard uses that term. I certainly does not in the
>sentence I cited above.

I have separated out ?BLANK that decides whether a character is to
be considered a blank in ciforth.
This is default:
: ?BLANK BL 1+ < ;

[All colon definitions in ciforth can be revectored.]

>
>- anton

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