Newsgroups: comp.lang.forth
References: <5c65a8f1fdfc3e9937a825842fe23dc2758f48ef@i2pn2.org> <73ec4c8359439c78d77d4fce31fc50b2@www.novabbs.com> <nnd$549dec93$58c68246@b439a59014c98079> <fea4967aee99bd0d235a21fbd6253e167b5690a9@i2pn2.org>
From: albert@spenarnc.xs4all.nl
Subject: Re: Reverse SCAN SPLIT
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: albert@cherry.(none) (albert)
Message-ID: <nnd$54569771$3e4512f7@bce98109a865b792>
Organization: KPN B.V.
Date: Sat, 19 Oct 2024 13:36:37 +0200
Path: ...!news.mixmin.net!news.neodome.net!feeder2.feed.ams11.usenet.farm!feed.usenet.farm!feed.abavia.com!abe007.abavia.com!abp001.abavia.com!news.kpn.nl!not-for-mail
Lines: 69
Injection-Date: Sat, 19 Oct 2024 13:36:37 +0200
Injection-Info: news.kpn.nl; mail-complaints-to="abuse@kpn.com"
Bytes: 3335

In article <fea4967aee99bd0d235a21fbd6253e167b5690a9@i2pn2.org>,
dxf  <dxforth@gmail.com> wrote:
>On 17/10/2024 9:48 pm, albert@spenarnc.xs4all.nl wrote:
>> In article <73ec4c8359439c78d77d4fce31fc50b2@www.novabbs.com>,
>> mhx <mhx@iae.nl> wrote:
>>> On Thu, 17 Oct 2024 8:28:26 +0000, albert@spenarnc.xs4all.nl wrote:
>>>
>>>> In article <nnd$231969a2$24a04042@87f25e33f755b9dd>,
>>> [..]
>>>> Compare to what I'm doing. Promoting the actual API specification
>>>> so that you can decide whether you want to actually use it.
>>>>
>>>>    $/
>>>>
>>>>
>>>>   STACKEFFECT: sc c --- sc1 sc2
>>>>
>>>>   DESCRIPTION: []
>>>>
>>>>   Find the first c in the string constant sc and split it at that
>>>>   address. Return the strings after and before c into sc1 and sc2
>>>>   respectively. If the character is not present sc1 is a null string
>>>>   (its address is zero) and sc2 is the original string. Both sc1 and
>>>>   sc2 may be empty strings (i.e. their count is zero), if c is the
>>>>   last or first character in sc .
>>>
>>> Wil Baden chose to keep c in sc2. Do you have a reason to
>>> remove it?
>>>
>>> It seems logical to remove it. I normally use lots of
>>> `1 /STRING' and `-LEADING' or `-TRAILING' sequences in further
>>> processing of Split-At-Char results, but not always.
>>> Maybe because an empty sc2 is less informative than an sc2 of
>>> size 1?
>>
>> In the rare case that you want the delimiter :
>> "orang utan" BL $/
>> ( *utan" "orang" )
>> you simply do
>>   1+
>> ( *utan" "orang " )
>
>Applying 1+ is not foolproof in the case of empty sc2.
 Realize that
 " " BL $/ results in (OKAY)
 "" ""
 "" BL $/ results in (this goes wrong)
 0.0 ""

You mean if the character is missing, resulting in a sc1
that is a null-string.
If the character is present 1+ works all the time.

If the character is not present, you shouldn't do that, right.
In that case sc1 is a null string, (not merely empty) and
you should test sc1 first.
That could happen if you split a linux files on linefeeds and the
last linefeed is missing. Normally I would do
  BEGIN ^J $/ TYPE CR OVER 0= UNTIL
Or splitting on $A.
  BEGIN $A $/ TYPE $A EMIT OVER 0= UNTIL

Groetjes Albert
-- 
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.