Current standings: Strawpoll: better name for PARSE-WORD

 XXXX@XXXXX.COM  (Anton Ertl) writes:

Ok the following names have been proposed and support for them has
been announced:
NextWord (conflict: exists with different meaning in Win32Forth)
TOKEN
  Supported by: Alex McDonald
NAME (existing practice: exists with this meaning in Gforth)
  Supported by: Coos Haak
  Supported by: Albert van der Horst
EXTRACTWORD
EXTRACT-WORD
  Supported by: Ward McFarland
GET-WORD
GET-NAME
GET-TOKEN
PARSE-NAME
  Supported by: Stephen Pelc
  Second choice: Albert van der Horst
  Could live with it: Ward McFarland
PARSE-STREAM

None of the names has had enough open support that I feel comfortable
in using it in an RfD.  Maybe people are not interested enough in such
a word to try to standardize it.  Or people want such a word, but do
care much which name it gets and have therefore not announced support
for any of the names.

My current plan is to shelve this RfD, unless I see some more support
for it.  If anyone else wants to pick it up, you are welcome.

- anton
-- 
M. Anton Ertl   http://www.**--****.com/ 
comp.lang.forth FAQs:  http://www.**--****.com/ 
New standard:  http://www.**--****.com/ 

BTW: Recently, I wrote a GDS II generating program, and GDS II has a number
of places where you want simple strings (so you'd use PARSE-WORD or
whatever better name you want). However, I want to make this program fully
scriptable, so I also need a way to pass these strings as such (>STRING,
and >" <text>" for string literals). I used a NEXTNAME-like approach, like
Gforth's NEXTNAME. However, Gforth's NEXTNAME modifies the way headers are
generated, while >STRING changes the way my PARSE-WORD wrapper works.
Instead of parsing, it takes the last string shifted in. In an ad-hoc
fashion, I named the readers <WORD and <LINE (the latter takes the rest of
the line). ATM, >STRING can push only one item, but a generalized version
would be a stack.

My conclusion is that PARSE-WORD is not exactly the right factor, at least
not for this application. And to find a good name is even more difficult,
since all good names apparently are already taken.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
 http://www.**--****.com/ ~paysan/

Alex McDonald could also support

 PARSE-NAME
  Supported by: Stephen Pelc
  Second choice: Albert van der Horst
  Could live with it: Ward McFarland 

-- 
Regards
Alex McDonald

 XXXX@XXXXX.COM  (Anton Ertl) wrote Re: Current standings: Strawpoll: better name for PARSE-WORD


In iForth this word would be defined as BL <WORD> , a phrase indeed used
all over the kernel source code. I can live with PARSE-NAME , although
imho BL PARSE-STRING or BL PARSE-WORD better shows what is actually done, 
with negligeable cost.


-marcel

 XXXX@XXXXX.COM  (Marcel Hendrix) writes:

Do you ever use <WORD> with a different delimiter than BL?  If so,
which one and for what?  (I have a hard time imagining that skipping
non-white-space delimiters is useful.)


Thanks, noted.


I have just tried whether TABs work as white space in iforth.  They
do.  It's not clear to me how passing BL as a delimiter shows better
what is actually done than having a word that is specified as using
white space as delimiter.

- anton
-- 
M. Anton Ertl   http://www.**--****.com/ 
comp.lang.forth FAQs:  http://www.**--****.com/ 
New standard:  http://www.**--****.com/ 

Op Sun, 17 Apr 2005 19:36:18 GMT schreef Marcel Hendrix:


I find it hard to believe that '<delmiter> PARSE' would not have worked
here ;-(

Coos
-- 
CHForth, 16 bit DOS
 http://www.**--****.com/ 

I am strongly opposed to the use of word "token" since we already have
got execution tokens and compiled execution tokens (run-time semantics IIRC),
as well as F-Code tokens.

(To be honest, I define words TOKEN<blablabla> to mean access to the
code being generated).


Sort of conflicts with >NAME NAME> that used to be sort of standard.


Looks like it's important, but cannot be agreed upon.

I have seen  lot of code doing 0 WORD to parse till EOL.

I regret that the DPANS annex meaning for PARSE-WORD must be
abandoned, because it seems natural to me; but I can live with
PARSE-NAME.

I agree with Michael Gassanenko's implication that it's important
not to leave this unsettled.

What becomes of the status of PARSE-WORD?  I take it that the
meaning in the annex is to be declared nonportable.  With that
meaning off the table, is enough agreement possible that it can
be portable, or should PARSE-WORD be declared unusable for ANS
Forth portable programming?

-- David

"David N. Williams" < XXXX@XXXXX.COM > writes:

It's the same status that it has now: A non-standard word that has two
commonly implemented, conflicting meanings.


It is non-portable.  No need for declarations.


I don't understand this question.


PARSE-WORD is not in ANS Forth, so it obviously cannot be used in ANS
Forth programs.

- anton
-- 
M. Anton Ertl   http://www.**--****.com/ 
comp.lang.forth FAQs:  http://www.**--****.com/ 
New standard:  http://www.**--****.com/ 

 XXXX@XXXXX.COM  (Anton Ertl) writes Re: Current standings: Strawpoll: better name for PARSE-WORD




[..]

[..]

And more of the same.


I see a pattern. It seems PARSE behaves differently from what I 
thought the Standard described.

What is the exact behavior for the following test cases?

char " PARSE "HELLO" .S
char " PARSE HELLO""" .S
char " PARSE HELLO" .S
char " PARSE    HELLO" .S
char " PARSE"HELLO" .S
char " PARSE """HELLO" .S

char " <WORD> "HELLO" .S
char " <WORD> HELLO""" .S
char " <WORD> HELLO" .S
char " <WORD>    HELLO" .S
char " <WORD>"HELLO" .S
char " <WORD> """HELLO" .S

-marcel

 XXXX@XXXXX.COM  (Marcel Hendrix) writes:

The essential difference between PARSE and <WORD> (i.e., F83's
PARSE-WORD) is that <WORD> skips leading delimiters and PARSE does
not.  And I don't think that skipping leading delimiters is
appropriate in the cases you showed, nor in any case where the
delimiter is not white space.  E.g.,

.STATUS" """a string" \ wrong with PARSE, right with <WORD>.
.STATUS" " DUP \ wrong with <WORD>, right with PARSE

Most users probably expect the first case to be wrong, and the second
case to be right (or at least, they certainly don't expect the
behaviour that <WORD> produces for the second case, i.e., consuming
the rest of the line as parsed string).


I have run these cases through iForth 2.0.257.  Looks like iForth is
doing the right thing for PARSE, and its <WORD> works like F83's
PARSE-WORD.

FORTH> char " PARSE "HELLO" .S 
Error -13 
char " PARSE "HELLO" .S
--------------------^
HELLO" ? 
FORTH> char " PARSE HELLO""" .S 
Error -13 
char " PARSE HELLO""" .S
---------------------^
"" ? 
FORTH> char " PARSE HELLO" .S 
  Data: 136182797 5 ---
System: ---
 Float: --- ok
[2]FORTH> char " PARSE    HELLO" .S 
  Data: 136182797 5 136182797 8 ---
System: ---
 Float: --- ok
[4]FORTH> char " PARSE"HELLO" .S 
Error -13 
char " PARSE"HELLO" .S
-------------------^
PARSE"HELLO" ? 
FORTH> char " PARSE """HELLO" .S 
Error -13 
char " PARSE """HELLO" .S
----------------------^
""HELLO" ? 
FORTH>   ok
FORTH> char " <WORD> "HELLO" .S 
<WORD> is not portable. 
  Data: 136182799 5 ---
System: ---
 Float: --- ok
[2]FORTH> char " <WORD> HELLO""" .S 
<WORD> is not portable. 
Error -13 
char " <WORD> HELLO""" .S
----------------------^
"" ? 
FORTH> char " <WORD> HELLO" .S 
<WORD> is not portable. 
  Data: 136182798 5 ---
System: ---
 Float: --- ok
[2]FORTH> char " <WORD>    HELLO" .S 
<WORD> is not portable. 
  Data: 136182798 5 136182798 8 ---
System: ---
 Float: --- ok
[4]FORTH> char " <WORD>"HELLO" .S 
Error -13 
char " <WORD>"HELLO" .S
--------------------^
<WORD>"HELLO" ? 
FORTH> char " <WORD> """HELLO" .S 
<WORD> is not portable. 
  Data: 136182801 5 ---
System: ---
 Float: --- ok

Running this in Gforth (with ": <word> sword ;") reveals a bug in the
error reporting, but otherwise seems to produce the same results.

- anton
-- 
M. Anton Ertl   http://www.**--****.com/ 
comp.lang.forth FAQs:  http://www.**--****.com/ 
New standard:  http://www.**--****.com/ 

two

I was certainly unclear.  My brain conflates more often than I
would like, in this case common practise with ANS Forth
portability.

What I was trying to get at was, if the definition of PARSE-WORD
in the annex is eschewed, can the remaining usage justifiably be
called common practise?

-- David

"Eschew the sinister hand, espouse the dexter." --dnw on magnetism