On 3/11/2021 00:29, Brian Fox wrote:
> On Saturday, October 30, 2021 at 12:15:34 PM UTC-4, dxforth wrote:
>> On 31/10/2021 01:17, Brian Fox wrote:
>> > On Friday, October 29, 2021 at 10:47:28 PM UTC-4, dxforth wrote:
>> >> The TRUE reason for PARSE-NAME is that it has to parse a number of "white space" characters.
>> >> AFAIK that was also true for 'BL WORD' under ANS. Some special-cased
>> >> BL SKIP/SCAN. My approach was >BLANKS ( a u -- ) which first converts
>> >> controls to blanks. It has proven useful for applications unrelated
>> >> to the forth parser.
>> >>
>> >> But we digress. I'm happy with WORD not least because FIND still needs
>> >> a counted string. The factor of WORD which moves and stores - I've
>> >> called it WPACK ( adr len -- adr2 ) - is potentially useful for other
>> >> things e.g. SEARCH-WORDLIST. The result from WORD goes into the same
>> >> buffer as S" on a shared basis. The latter building up and the former
>> >> building down to a maximum of 255+31 chars. There's little I've needed
>> >> to do that couldn't be done with : TOKEN BL WORD COUNT ;
>> >
>> > For my hobby system I found it useful to modify Camel Forth and factor out
>> > PARSE-WORD which is then used to make WORD.
>> >
>> > : PARSE-WORD ( char -- c-addr u)
>> > DUP SOURCE >IN @ /STRING
>> > ROT SKIP
>> > DROP SOURCE -ROT - MIN 0 MAX >IN !
>> > PARSE
>> > ;
>> >
>> > : WORD ( char -- c-addr)
>> > PARSE-WORD HERE PLACE
>> > HERE BL OVER COUNT + C! \ append blank character
>> > ;
>> >
>> > With PARSE-WORD I can choose not to copy to HERE if that's
>> > what I need or use WORD in the traditional way.
>> > (Yes, Camel Forth still appends a BL to the WORD string)
>> So does mine. If SF couldn't be certain they wouldn't need it again
>> who am I to know :)
>> >
>> > So your TOKEN would become:
>> > : TOKEN ( -- c-addr u) BL PARSE-WORD ;
>> I'd be struggling to find a use for PARSE-WORD :)
>>
>> I factored mine as follows:
>>
>> : PARSE ( char -- c-addr u ) false (parse) ;
>> : WORD ( char -- c-addr ) true (parse) wpack ;
>>
>> (parse) and wpack are currently headerless.
>>
>> Once S" ," .( etc. are defined, there's probably not a lot of use for PARSE
>> if my apps are any indication.
>
> On a "glacial" speed system like 9900 copying to HERE or not can make a
> difference in execution speed. So I use PARSE-WORD whenever the data
> does not need that extra copying but I want to skip leading blanks.
> It's a small hit for WORD calling PARSE-WORD.
>

DX-Forth was written on/for glacial hardware :) ISTM dictionary search
time would be the limiting factor as most parsed words go through FIND
which uses WORD. For me the greater issue is redundancy. I have PARSE
and /PARSE. I'd like to remove the former but it's too well-known.
200x has the same issue with S" and S\" .

some will f, I've not found them think it boils down to preference.

ANS argued against WORD but until
there's an alternative to FIND.