What in ANSI Forth is case sensitive and what is not?
Rickman
in the ANSI spec where they say if these words are case sensitive, not
case sensitive or implementation defined. The spec addresses the search
words for interpreting, but that does not seem to apply to the string
search words.
So how do they work; sensitive, not sensitive, or implementation defined?
--
Rick Collins
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design http://www.arius.com
4 King Ave. 301-682-7772 Voice
Frederick, MD 21701-3110 GNU tools for the ARM http://www.gnuarm.com
Elizabeth D. Rather
news:4rWdnYKi9a7...@adelphia.com...
> I am doing some parsing of text using SEARCH and COMPARE and I don't see
> in the ANSI spec where they say if these words are case sensitive, not
> case sensitive or implementation defined. The spec addresses the search
> words for interpreting, but that does not seem to apply to the string
> search words.
>
> So how do they work; sensitive, not sensitive, or implementation defined?
In the absence of any specification to the contrary, I would assume that
these words are looking for literal matches, i.e., case sensitive. I don't
remember ever encountering versions that weren't.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310-491-3356
5155 W. Rosecrans Ave. #1018 Fax: +1 310-978-9454
Hawthorne, CA 90250
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Rickman
> "Rickman" <spamgo...@yahoo.com> wrote in message
> news:4rWdnYKi9a7...@adelphia.com...
>
>>I am doing some parsing of text using SEARCH and COMPARE and I don't see
>>in the ANSI spec where they say if these words are case sensitive, not
>>case sensitive or implementation defined. The spec addresses the search
>>words for interpreting, but that does not seem to apply to the string
>>search words.
>>
>>So how do they work; sensitive, not sensitive, or implementation defined?
>
>
> In the absence of any specification to the contrary, I would assume that
> these words are looking for literal matches, i.e., case sensitive. I don't
> remember ever encountering versions that weren't.
>
> Cheers,
> Elizabeth
Thanks. To make them case sensitive, I guess I have to convert both
strings to the same case. I don't see any words to do that. I guess
I'll have to write my own. :)
--
Rick Collins
rick.c...@XYarius.com
Alex McDonald
If it's Win32Forth you're using, try str(nc)= in later versions;
signature is
STR(NC)= ( adr1 len1 adr2 len2 -- flag ) \ compares two strings, case
insensitive
I believe gforth has the same word.
To convert case;
UPPER ( addr len -- ) \ translate to uppercase
LOWER ( addr len -- ) \ translate to lowercase
--
Regards
Alex McDonald
Alex McDonald
At Anton Ertl's request (and as a matter of good netiquette), I've been
attempting to ensure that my quoted posts don't run over into the next
line. Using Google gives the above effect, partly because the original
extends into nearly column 70; the quoted text gets broken at 72 (or
thereabouts). Looking at the unformattted reply, the breaks are there
too. Your help in understanding how to avoid this appreciated.
--
Regards
Alex McDonald
Rickman
I found the UPPER and LOWER words, but I can't find STR(NC) in
Win32Forth v. 6.08.00.
> At Anton Ertl's request (and as a matter of good netiquette), I've been
> attempting to ensure that my quoted posts don't run over into the next
> line. Using Google gives the above effect, partly because the original
> extends into nearly column 70; the quoted text gets broken at 72 (or
> thereabouts). Looking at the unformattted reply, the breaks are there
> too. Your help in understanding how to avoid this appreciated.
Good luck on that one. I think it is asking a bit much for people to
deal with the various line lengths that everyone else is using by
reformatting the quoted text. I don't know how you would prevent
extraneous line wraps otherwise. Even if there is a standard for where
you should wrap your lines when posting, the added "> " at the beginning
of each line is going to push the quoted material past the wrap point.
Am I missing something?
Anton Ertl
>If it's Win32Forth you're using, try str(nc)= in later versions;
>signature is
>
>STR(NC)= ( adr1 len1 adr2 len2 -- flag ) \ compares two strings, case
>insensitive
>
>I believe gforth has the same word.
No. And apparently, nothing else, either.
BTW, word names containing ')' are usually a bad idea.
- 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
Anton Ertl
>At Anton Ertl's request (and as a matter of good netiquette), I've been
>attempting to ensure that my quoted posts don't run over into the next
>line. Using Google gives the above effect, partly because the original
>extends into nearly column 70; the quoted text gets broken at 72 (or
>thereabouts). Looking at the unformattted reply, the breaks are there
>too. Your help in understanding how to avoid this appreciated.
Can't help you with google, but if you use an NNTP server (e.g.,
news.individual.net offers free accounts, registration required), you
can use a number of news readers, among them well-behaved ones (take a
look at http://www.xs4all.nl/~js/gnksa/gnksa-evaluations.html for how
well various newsreaders behave, and in any case try test postings to
test groups first (e.g., misc.test), and check them, before posting in
discussion groups like comp.lang.forth).
Bruce McFarling
Anton Ertl wrote:
> "Alex McDonald" <alex...@btopenworld.com> writes:
> >At Anton Ertl's request (and as a matter of good netiquette), I've
been
> >attempting to ensure that my quoted posts don't run over into the
next
> >line. Using Google gives the above effect, partly because the
original
> >extends into nearly column 70; the quoted text gets broken at 72 (or
> >thereabouts). Looking at the unformattted reply, the breaks are
there
> >too. Your help in understanding how to avoid this appreciated.
> Can't help you with google, but if you use an NNTP server (e.g.,
> news.individual.net offers free accounts, registration required), you
> can use a number of news readers, among them well-behaved ones (take
a
> look at http://www.xs4all.nl/~js/gnksa/gnksa-evaluations.html for how
> well various newsreaders behave, and in any case try test postings to
> test groups first (e.g., misc.test), and check them, before posting
in
> discussion groups like comp.lang.forth).
With google, use the manual system -- hit return before the line
gets too long. Thanks for the info on news.individual.net, I
prefer real newsreaders.
Ed
> Elizabeth D. Rather wrote:
>
> [...]
> >
> > In the absence of any specification to the contrary, I would assume that
> > these words are looking for literal matches, i.e., case sensitive. I don't
> > remember ever encountering versions that weren't.
> >
> > Cheers,
> > Elizabeth
>
> Thanks. To make them case sensitive, I guess I have to convert both
> strings to the same case.
Which will mean moving the strings if you don't want them
corrupted.
Other solutions are the creation of new case-insensitive
versions of COMPARE SEARCH etc.
In my case I found it preferable to use modifiers such
as CAPS that automatically reset when COMPARE
SEARCH SCAN SKIP completes. As I use MS-DOS,
another useful modifier is SSEG which lets me change
the search segment of the first string.
All non-standard of course...
Ed
Alex McDonald
Rickman wrote:
> Alex McDonald wrote:
>
> > Alex McDonald wrote:
> >
> >>
> >>If it's Win32Forth you're using, try str(nc)= in later versions;
> >>signature is
> >>
> >>STR(NC)= ( adr1 len1 adr2 len2 -- flag ) \ compares two strings,
case
> >>insensitive
> >>
> >>I believe gforth has the same word.
> >>
> >>To convert case;
> >>
> >>UPPER ( addr len -- ) \ translate to uppercase
> >>LOWER ( addr len -- ) \ translate to lowercase
>
> I found the UPPER and LOWER words, but I can't find STR(NC) in
> Win32Forth v. 6.08.00.
It's in later versions; see www.win32forth.org for a download of
6.09.xx. The name's STR(NC)= but given the poor selection of name, this
may change by the time 6.10 comes out (this January 2005).
--
Regards
Alex McDonald
Alex McDonald
In W32F there's a STR= equivalent to COMPARE 0= that is case sensitive.
It's more efficent than COMPARE in that it doesn't return anything
other than true/false. STR(NC)= is intended as a case-insensitive
analog. Suggestions for both words welcome.
--
Regards
Alex McDonald
Anton Ertl
>My bad.
>
>In W32F there's a STR= equivalent to COMPARE 0= that is case sensitive.
Gforth also has this word.
rickman
As someone else posted, I suggest that using parens in a name be
strictly avoided unless it is flagging text such as .( . How about
STR-NC= ?
I find it odd that the ANSI standard for Forth includes the word (LOCAL)
. What were they thinking???
rickman
> "Rickman" <spamgo...@yahoo.com> wrote in message
> news:4rWdnYKi9a7...@adelphia.com...
>
>>I am doing some parsing of text using SEARCH and COMPARE and I don't see
>>in the ANSI spec where they say if these words are case sensitive, not
>>case sensitive or implementation defined. The spec addresses the search
>>words for interpreting, but that does not seem to apply to the string
>>search words.
>>
>>So how do they work; sensitive, not sensitive, or implementation defined?
>
>
> In the absence of any specification to the contrary, I would assume that
> these words are looking for literal matches, i.e., case sensitive. I don't
> remember ever encountering versions that weren't.
Is it just me or should this be specified in the standard? Is this
something to consider in the 200x standard effort? I would like to see
a wider variety of useful string words.
--
Rick Collins
rick.c...@XYarius.com
Bernd Paysan
> As someone else posted, I suggest that using parens in a name be
> strictly avoided unless it is flagging text such as .( . How about
> STR-NC= ?
At least better than C, where strcasecmp is the one which *ignores* case. I
think this follows the logic that strcmp returns 0 when the strings are
equal. Instead of NC, we could use IC (ignore case) or CI (case
insensitive). My favorite is STR~, for "string similar".
> I find it odd that the ANSI standard for Forth includes the word (LOCAL)
> . What were they thinking???
That no one would accept LOCALS|, but would implement locals with other
syntax using (LOCAL) as portable primitive. The were right in the first
assumption, but apart from harnesses, no one uses (LOCAL) either.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Marcel Hendrix
> rickman wrote:
[..]
>> I find it odd that the ANSI standard for Forth includes the word (LOCAL)
>> . What were they thinking???
> That no one would accept LOCALS|, but would implement locals with other
> syntax using (LOCAL) as portable primitive. The were right in the first
> assumption, but apart from harnesses, no one uses (LOCAL) either.
I'm using it to define local arrays and matrices in vsn 2.0 of the FSL :-)
: XSOLVE ( A{{ b{{ x{{ -- )
0e FLOCAL err
2 PICK DIMS 0 LOCALS| iters n m x{{ b{{ A{{ |
A{{ MTYPE LDMATRIX QAt{{
...
(The above "A{{ MTYPE" is there because (hopefully) this new FSL will support
any type matrices -- SINGLE DOUBLE FLOAT XFLOAT COMPLEX BYTE INTEGER LONG
2INDEX and STRING).
-marcel
Anton Ertl
>As someone else posted, I suggest that using parens in a name be
>strictly avoided unless it is flagging text such as .( . How about
>STR-NC= ?
>
>I find it odd that the ANSI standard for Forth includes the word (LOCAL)
>. What were they thinking???
There is a traditional use of having parenthesized names for words
that are just used as helper words, for implementing other words,
e.g., "(LOOP)". For these words the ')' in the name is hardly a
problem, because they are only used in very few places; and having it
in the name has the benefit of avoiding collisions with non-helper
words.
So, what the committee thought when they named the word "(LOCAL)" was
that they were defining a helper word.
rickman
> rickman <spamgo...@yahoo.com> writes:
>
>>As someone else posted, I suggest that using parens in a name be
>>strictly avoided unless it is flagging text such as .( . How about
>>STR-NC= ?
>>
>>I find it odd that the ANSI standard for Forth includes the word (LOCAL)
>>. What were they thinking???
>
>
> There is a traditional use of having parenthesized names for words
> that are just used as helper words, for implementing other words,
> e.g., "(LOOP)". For these words the ')' in the name is hardly a
> problem, because they are only used in very few places; and having it
> in the name has the benefit of avoiding collisions with non-helper
> words.
>
> So, what the committee thought when they named the word "(LOCAL)" was
> that they were defining a helper word.
I understand what you are saying, but I still feel this is poorly
thought out. Using parens around a word to flag a helper word has
obvious (at least now) issues with comments, especially when code is
being debugged. My point is that perhaps some other flag should be used
that does not have this sort of conflict.
What a tool does internally is up to the developer. But (LOCAL) is part
of the standard (and the only such word that I could find). My
suggestion is to use some other form.
Jerry Avins
...
> I understand what you are saying, but I still feel this is poorly
> thought out. Using parens around a word to flag a helper word has
> obvious (at least now) issues with comments, especially when code is
> being debugged. My point is that perhaps some other flag should be used
> that does not have this sort of conflict.
>
> What a tool does internally is up to the developer. But (LOCAL) is part
> of the standard (and the only such word that I could find). My
> suggestion is to use some other form.
I think you may be missing something. the initial parenthesis that
starts a comment is space delimited, like any other word. Is it the
final parenthesis that distresses you? I always use backslash for
whole-line or end-of-line comments, so I'm unlikely to embed any Forth
word in a comment. In MAXforth:
: \ 0 WORD DROP ; IMMEDIATE \ Skip-rest-of-line word.
Jerry
--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Anton Ertl
[(LOCAL)]
>I understand what you are saying, but I still feel this is poorly
>thought out. Using parens around a word to flag a helper word has
>obvious (at least now) issues with comments, especially when code is
>being debugged.
Yes. The idea is that helper words are used in very few places; once
these few places are debugged, you will never see them again. For
debugging these places you have to use one of the other commenting
words rather than '(', i.e., \ ... <newline>, or 0 [IF] ... [THEN].
>What a tool does internally is up to the developer. But (LOCAL) is part
>of the standard (and the only such word that I could find). My
>suggestion is to use some other form.
That's water down the river.
BTW, you can ask around how much problems this aspect of (LOCAL) has
caused. I have not had any.
rickman
> rickman wrote:
>
> ...
>
>
>
>>I understand what you are saying, but I still feel this is poorly
>>thought out. Using parens around a word to flag a helper word has
>>obvious (at least now) issues with comments, especially when code is
>>being debugged. My point is that perhaps some other flag should be used
>>that does not have this sort of conflict.
>>
>>What a tool does internally is up to the developer. But (LOCAL) is part
>>of the standard (and the only such word that I could find). My
>>suggestion is to use some other form.
>
>
> I think you may be missing something. the initial parenthesis that
> starts a comment is space delimited, like any other word. Is it the
> final parenthesis that distresses you? I always use backslash for
> whole-line or end-of-line comments, so I'm unlikely to embed any Forth
> word in a comment. In MAXforth:
>
> : \ 0 WORD DROP ; IMMEDIATE \ Skip-rest-of-line word.
Yes, it is the final paren. If I have a line of code and I want to
remove part of it, the closing paren in (LOCAL) can trigger the end of
the comment section. I am not always trying to remove a line.
I just find this to be an awkward anomaly. Any time I remove a section
of code with ( ), I have to make sure there are no other words that use
). For a language that encourages simplifying things to prevent
mistakes, this just seems to stick out like a bump on a log.
rickman
> rickman <spamgo...@yahoo.com> writes:
> [(LOCAL)]
>
>>I understand what you are saying, but I still feel this is poorly
>>thought out. Using parens around a word to flag a helper word has
>>obvious (at least now) issues with comments, especially when code is
>>being debugged.
>
>
> Yes. The idea is that helper words are used in very few places; once
> these few places are debugged, you will never see them again. For
> debugging these places you have to use one of the other commenting
> words rather than '(', i.e., \ ... <newline>, or 0 [IF] ... [THEN].
>
>
>>What a tool does internally is up to the developer. But (LOCAL) is part
>>of the standard (and the only such word that I could find). My
>>suggestion is to use some other form.
>
>
> That's water down the river.
>
> BTW, you can ask around how much problems this aspect of (LOCAL) has
> caused. I have not had any.
Hmmm... I am of the school that you use methods consistently. But let
me ask it this way. If a new word were proposed that included parens,
would you be opposed to that? Is your justification that you don't want
to bother changing it because it is already there?
Jerry Avins
...
>> : \ 0 WORD DROP ; IMMEDIATE \ Skip-rest-of-line word.
>
> Yes, it is the final paren. If I have a line of code and I want to
> remove part of it, the closing paren in (LOCAL) can trigger the end of
> the comment section. I am not always trying to remove a line.
>
> I just find this to be an awkward anomaly. Any time I remove a section
> of code with ( ), I have to make sure there are no other words that use
> ). For a language that encourages simplifying things to prevent
> mistakes, this just seems to stick out like a bump on a log.
That's probably why I long ago acquired the habit of using '\'. I even
took the trouble to add it to my file of MAXforth supplementary
definitions. If you use it where you can, it will simplify a great deal.
It comments out not just entire lines, but "here to end", just like ';'
in many assemblers. Note the comment in its definition I posted.
Anton Ertl
>But let
>me ask it this way. If a new word were proposed that included parens,
>would you be opposed to that?
In most cases, yes, in some cases, not. But in any case, I would not
argue for the name. One could also name such words with names like
...-HELPER.
> Is your justification that you don't want
>to bother changing it because it is already there?
That would certainly be the justification for rejecting any proposal
to remove (LOCAL) (even if it was reintroduced under another name).
Alex McDonald
becomes multi-line if there's a file wordset included.
Try \ comment to end of line; or W32F's (( ... )) (or the C-like /* */
) which is multiline but easier to see, and won't stop on a single ).
With W32F you can turn this multiline ( feature off;
0 to multi-line?
--
Regards
Alex McDonald
rickman
Actually, the issue I come up against is the convention of documenting
the stack with ( stuff -- other ). Any time I try to comment out
multi-line, it picks up the ) . But I realize my problem is limited to
debug where I can use other things to do multi-line comments as you and
other have suggested.
(Still it bugs me... ;( It just seems like someone wasn't thinking )
Jerry Avins
...
>> (Still it bugs me... ;( It just seems like someone wasn't thinking )
I was once given a tour of his high-pressure lab by Percy Bridgman (ice
II and all that). At one end of the lab, he told me to stand in a
particular place while he went on to operate various controls. At one
place in the aisle he went back and forth in, he stepped over what
seemed like an imaginary pole about half a yard above the floor, first
with one leg, then the other. If nothing else, it was excellent
pantomime. When I asked him about it, he told me that he was stepping
over the trajectory of the blow-out plug. Only mortals like us need
safety guards. '/' is a way to step over the difficulty, even when you
believe it won't blow.
Howard Lee Harkness
>At one
>place in the aisle he went back and forth in, he stepped over what
>seemed like an imaginary pole about half a yard above the floor, first
>with one leg, then the other. If nothing else, it was excellent
>pantomime. When I asked him about it, he told me that he was stepping
>over the trajectory of the blow-out plug.
After spending most of the afternoon reading Feynman's _The Pleasure of Finding
Things Out_, that struck me as particularly funny, in a Feynmanish sort of way.
>Only mortals like us need safety guards.
While I am a great believer in safety guards, the only safety that really counts
is just behind the forehead. (I'm a firearms instructor, a driving safety
instructor, and an insurance agent, among other things, now that I'm
'overqualified' to write software)
--
Howard
www.chl-tx.com Concealed handgun license training
www.hlhins.com Insurance stuff & link to driver safety training
Graham Smith
McDonald <alex...@btopenworld.com> writes
In the same spirit I use ISTR= ( addr1 len1 addr2 len2 -- flag) and
ISEARCH
Regards
Graham Smith
--
EMail: Remove X's and underscores from X_gra...@tectime.com
Alex McDonald
--
Regards
Alex McDonald