Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #42677 > unrolled thread

Questions about strings

Back to article view | Back to comp.lang.forth

Contents

  Questions about strings Chris Curl <ccurl609@gmail.com> - 2015-10-17 06:46 -0700
    Re: Questions about strings rickman <gnuarm@gmail.com> - 2015-10-17 11:25 -0400
      Re: Questions about strings Chris Curl <ccurl609@gmail.com> - 2015-10-17 10:43 -0700
        Re: Questions about strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-17 17:52 +0000
        Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-17 07:56 -1000
        Re: Questions about strings rickman <gnuarm@gmail.com> - 2015-10-17 14:07 -0400
        Re: Questions about strings "HAA" <someone@microsoft.com> - 2015-10-18 12:50 +1000
    Re: Questions about strings Ron Aaron <rambamist@gmail.com> - 2015-10-17 19:30 +0300
    Re: Questions about strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-17 17:10 +0000
    Re: Questions about strings Jason Damisch <jasondamisch@yahoo.com> - 2015-10-17 10:41 -0700
      Re: Questions about strings foxaudioresearch@gmail.com - 2015-10-17 21:41 -0700
      Re: Questions about strings Johan Kotlinski <kotlinski@gmail.com> - 2015-10-18 15:40 -0700
        Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-18 13:41 -1000
          Re: Questions about strings Johan Kotlinski <kotlinski@gmail.com> - 2015-10-19 07:58 -0700
            Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-19 08:36 -1000
            Re: Questions about strings "HAA" <someone@microsoft.com> - 2015-10-23 00:08 +1000
        Re: Questions about strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-19 07:15 +0000
          Re: Questions about strings Chris Curl <ccurl609@gmail.com> - 2015-10-19 05:03 -0700
            Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-19 08:38 -1000
              Re: Questions about strings Chris Curl <ccurl609@gmail.com> - 2015-10-19 14:28 -0700
              Re: Questions about strings Alfred Singlestone <vitonis@gmail.com> - 2015-10-21 16:21 -0700
                Re: Questions about strings "HAA" <someone@microsoft.com> - 2015-10-22 11:07 +1000
                  Re: Questions about strings Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-27 11:29 +0100
                    Re: Questions about strings Chris Curl <ccurl609@gmail.com> - 2015-10-27 06:14 -0700
                      Re: Questions about strings Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-27 15:04 +0100
                    Re: Questions about strings Chris Curl <ccurl609@gmail.com> - 2015-10-27 07:01 -0700
                      Re: Questions about strings Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-27 15:04 +0100
                        Re: Questions about strings Chris Curl <ccurl609@gmail.com> - 2015-10-27 14:26 -0700
                          Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-27 11:45 -1000
                            Re: Questions about strings Lars Brinkhoff <lars.spam@nocrew.org> - 2015-10-28 07:43 +0100
          Re: Questions about strings "HAA" <someone@microsoft.com> - 2015-10-19 23:25 +1000
        Re: Questions about strings rickman <gnuarm@gmail.com> - 2015-10-20 14:47 -0400
          Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-20 09:48 -1000
            Re: Questions about strings rickman <gnuarm@gmail.com> - 2015-10-20 23:25 -0400
              Re: Questions about strings "HAA" <someone@microsoft.com> - 2015-10-21 15:11 +1000
                Re: Questions about strings "HAA" <someone@microsoft.com> - 2015-10-22 11:21 +1000
                  Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-21 18:31 -1000
                    Re: Questions about strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-22 05:51 +0000
                    Re: Questions about strings "HAA" <someone@microsoft.com> - 2015-10-24 12:44 +1000
                      Re: Questions about strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-25 10:17 +0000
                        Re: Questions about strings "HAA" <someone@microsoft.com> - 2015-10-26 15:14 +1100
                          Re: Questions about strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-26 11:20 +0000
                            Re: Questions about strings "HAA" <someone@microsoft.com> - 2015-10-31 00:20 +1100
                              Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-30 19:06 -1000
                                Re: Questions about strings Paul Rubin <no.email@nospam.invalid> - 2015-10-30 23:27 -0700
                                  Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-30 21:28 -1000
                                    Re: Questions about strings Paul Rubin <no.email@nospam.invalid> - 2015-10-31 00:37 -0700
                                      Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-30 21:48 -1000
            Re: Questions about strings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-21 06:10 +0000
    Re: Questions about strings Chris Curl <ccurl609@gmail.com> - 2015-10-31 10:48 -0700
      Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-31 09:57 -1000
        Re: Questions about strings Chris Curl <ccurl609@gmail.com> - 2015-10-31 13:34 -0700
          Re: Questions about strings "Elizabeth D. Rather" <erather@forth.com> - 2015-10-31 12:06 -1000
      Re: Questions about strings "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-02 02:34 -0500

Page 3 of 3 — ← Prev page 1 2 [3]

#42817

Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >Elizabeth D. Rather wrote:
> >> ...
> >> Compilation: ( "ccchquotei" - - )
> >> *Parse* ccc delimited by " (double-quote). Append the run-time semantics
> >> given below to the current definition.
> >>
> >> ...so it is limited by 3.4.1. If I were on the current standards
> >> committee I'd look for a way to be more explicit about that, although I
> >> now see that 6.1.2165 S" does include a cross-reference to 3.4.1.
> >
> >PARSE has the same cross-reference which implies retrieved strings
> >are limited to 255 chars for a standard program.  3.4.1. has an "unless
> >otherwise noted" proviso but I could find no such exemption for PARSE.
>
> There is no technical reason for that, because PARSE is specified to
> produce an address in the input buffer, so it must not use a counted
> string as intermediate storage.

That's more than 3.4.1 states.  It places a limit on any parsed strings in
a standard program 'unless otherwise noted' but doesn't say why.

> A.6.2.2008 PARSE says:
>
> |2)
> |  3) The count character limits the length of the string returned by
> |     WORD to 255 characters (longer strings can easily be stored in
> |     blocks!). This limitation does not exist for PARSE.
>
> So it was obviously not the intent of the Forth-94 committee to have
> this limitation for PARSE,

It's suggestive, though I wouldn't consider promotion of a new word in
the annex of a standard as authoritative or binding.

> so it probably is a bug in Forth-94 (and
> -2012).

If the entire input buffer is accessible to the programmer, then a
standard program should be able to code PARSE from scratch using
SOURCE and >IN without any length limit.  Maybe it's not guaranteed.

[toc] | [prev] | [next] | [standalone]

#42835

"HAA" <someone@microsoft.com> writes:
>Anton Ertl wrote:
>> >PARSE has the same cross-reference which implies retrieved strings
>> >are limited to 255 chars for a standard program.  3.4.1. has an "unless
>> >otherwise noted" proviso but I could find no such exemption for PARSE.
>>
>> There is no technical reason for that, because PARSE is specified to
>> produce an address in the input buffer, so it must not use a counted
>> string as intermediate storage.
>
>That's more than 3.4.1 states.  It places a limit on any parsed strings in
>a standard program 'unless otherwise noted' but doesn't say why.
>
>> A.6.2.2008 PARSE says:
>>
>> |2)
>> |  3) The count character limits the length of the string returned by
>> |     WORD to 255 characters (longer strings can easily be stored in
>> |     blocks!). This limitation does not exist for PARSE.
>>
>> So it was obviously not the intent of the Forth-94 committee to have
>> this limitation for PARSE,
>
>It's suggestive, though I wouldn't consider promotion of a new word in
>the annex of a standard as authoritative or binding.

Not sure what you mean with "promotion", but yes, the rationale is not
authoritative.  It does give us insight into the intent of the
committee, though.

>> so it probably is a bug in Forth-94 (and
>> -2012).
>
>If the entire input buffer is accessible to the programmer, then a
>standard program should be able to code PARSE from scratch using
>SOURCE and >IN without any length limit.

Yes, you can write PARSE using SOURCE, >IN and other standard
words.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#42999

Anton Ertl wrote:
> "HAA" <someone@microsoft.com> writes:
> >Anton Ertl wrote:
> >> >PARSE has the same cross-reference which implies retrieved strings
> >> >are limited to 255 chars for a standard program.  3.4.1. has an "unless
> >> >otherwise noted" proviso but I could find no such exemption for PARSE.
> >>
> >> There is no technical reason for that, because PARSE is specified to
> >> produce an address in the input buffer, so it must not use a counted
> >> string as intermediate storage.
> >
> >That's more than 3.4.1 states.  It places a limit on any parsed strings in
> >a standard program 'unless otherwise noted' but doesn't say why.
> >
> >> A.6.2.2008 PARSE says:
> >>
> >> |2)
> >> |  3) The count character limits the length of the string returned by
> >> |     WORD to 255 characters (longer strings can easily be stored in
> >> |     blocks!). This limitation does not exist for PARSE.
> >>
> >> So it was obviously not the intent of the Forth-94 committee to have
> >> this limitation for PARSE,
> >
> >It's suggestive, though I wouldn't consider promotion of a new word in
> >the annex of a standard as authoritative or binding.
>
> Not sure what you mean with "promotion", but yes, the rationale is not
> authoritative.  It does give us insight into the intent of the
> committee, though.

Intent?  Or opinion of one or more members?  Elizabeth might know.

> >> so it probably is a bug in Forth-94 (and
> >> -2012).
> >
> >If the entire input buffer is accessible to the programmer, then a
> >standard program should be able to code PARSE from scratch using
> >SOURCE and >IN without any length limit.
>
> Yes, you can write PARSE using SOURCE, >IN and other standard
> words.

This passage would appear to confirm it.

"A program may directly examine the input buffer using its address and length
as returned by SOURCE"

> - anton

[toc] | [prev] | [next] | [standalone]

#43018

On 10/30/15 3:20 AM, HAA wrote:
> Anton Ertl wrote:
>> "HAA" <someone@microsoft.com> writes:
>>> Anton Ertl wrote:
>>>>> PARSE has the same cross-reference which implies retrieved strings
>>>>> are limited to 255 chars for a standard program.  3.4.1. has an "unless
>>>>> otherwise noted" proviso but I could find no such exemption for PARSE.
>>>>
>>>> There is no technical reason for that, because PARSE is specified to
>>>> produce an address in the input buffer, so it must not use a counted
>>>> string as intermediate storage.
>>>
>>> That's more than 3.4.1 states.  It places a limit on any parsed strings in
>>> a standard program 'unless otherwise noted' but doesn't say why.
>>>
>>>> A.6.2.2008 PARSE says:
>>>>
>>>> |2)
>>>> |  3) The count character limits the length of the string returned by
>>>> |     WORD to 255 characters (longer strings can easily be stored in
>>>> |     blocks!). This limitation does not exist for PARSE.
>>>>
>>>> So it was obviously not the intent of the Forth-94 committee to have
>>>> this limitation for PARSE,
>>>
>>> It's suggestive, though I wouldn't consider promotion of a new word in
>>> the annex of a standard as authoritative or binding.
>>
>> Not sure what you mean with "promotion", but yes, the rationale is not
>> authoritative.  It does give us insight into the intent of the
>> committee, though.
>
> Intent?  Or opinion of one or more members?  Elizabeth might know.

Historically, the reason WORD moved its string was that overwhelmingly 
the most searches occur when a program is being compiled, and that is 
the process being optimized overall. WORD moved the string to the next 
available location in the dictionary, leaving it positioned such that, 
if the program is going to construct a definition for it, it doesn't 
have to be moved again; all that needs to be done is to fill in other 
elements of the new definition. I am not sure that the thought of 
leaving the string in the input buffer was actually considered by Chuck. 
I don't recall it being debated.

Certainly we never felt the 255-char to be a serious limitation. In the 
late 70's, Chuck wrote an extensive word processing application for 
FORTH, Inc. documentation. The polyFORTH Reference Manual, the first ed. 
of Starting Forth, and countless other documents were composed using it. 
That was probably the most string-intensive program we ever worked on, 
but it treated strings as data in ways that were never limited by that 
parameter.

As for invoking that limitation in PARSE, it does appear to me now that 
it was an oversight, and you might want to fix it.

Cheers,
Elizabeth

>>>> so it probably is a bug in Forth-94 (and
>>>> -2012).
>>>
>>> If the entire input buffer is accessible to the programmer, then a
>>> standard program should be able to code PARSE from scratch using
>>> SOURCE and >IN without any length limit.
>>
>> Yes, you can write PARSE using SOURCE, >IN and other standard
>> words.
>
> This passage would appear to confirm it.
>
> "A program may directly examine the input buffer using its address and length
> as returned by SOURCE"
>
>> - anton
>
>


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43019

"Elizabeth D. Rather" <erather@forth.com> writes:
> In the late 70's, Chuck wrote an extensive word processing application
> for FORTH, Inc. documentation. The polyFORTH Reference Manual, the
> first ed. of Starting Forth, and countless other documents were
> composed using it.

Is that program still in use?  Any chance of releasing it?  It sounds
neat, and I doubt that having it in the wild would interfere with Forth
Inc. revenue.

[toc] | [prev] | [next] | [standalone]

#43024

On 10/30/15 8:27 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> In the late 70's, Chuck wrote an extensive word processing application
>> for FORTH, Inc. documentation. The polyFORTH Reference Manual, the
>> first ed. of Starting Forth, and countless other documents were
>> composed using it.
>
> Is that program still in use?  Any chance of releasing it?  It sounds
> neat, and I doubt that having it in the wild would interfere with Forth
> Inc. revenue.
>

It certainly wouldn't impact revenue, but I have no idea whether Leon 
(who has all the old files, discs, mostly unreadable, etc.) could 
resurrect it enough to be useful to you. We ceased using it 30 years 
ago! Its design was somewhat like what (little) I understand of LaTex: 
in other words, commands relating to what to do with the text that 
followed. Ask him.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43025

"Elizabeth D. Rather" <erather@forth.com> writes:
> It certainly wouldn't impact revenue, but I have no idea whether Leon
> (who has all the old files, discs, mostly unreadable, etc.) could
> resurrect it enough to be useful to you. We ceased using it 30 years
> ago! 

Yes, it's quite understandable if exhuming the code is too much hassle
to be worthwhile just for curiosity's sake.  I don't have any great to
desire to actually use it beyond trying it out a little.  It's more an
interest in seeing how something like that was written.

> Its design was somewhat like what (little) I understand of LaTex: in
> other words, commands relating to what to do with the text that
> followed. 

That's about what I'd guessed, so I was mostly interested in seeing what
the commands looked like, the implementation technique, what using it
was like, etc.  Was it done with blocks and screens, using a block
editor to write the input document?

> Ask him.

I've never met him and he doesn't post here, but maybe someday.

Thanks!

[toc] | [prev] | [next] | [standalone]

#43026

On 10/30/15 9:37 PM, Paul Rubin wrote:
> "Elizabeth D. Rather" <erather@forth.com> writes:
>> It certainly wouldn't impact revenue, but I have no idea whether Leon
>> (who has all the old files, discs, mostly unreadable, etc.) could
>> resurrect it enough to be useful to you. We ceased using it 30 years
>> ago!
>
> Yes, it's quite understandable if exhuming the code is too much hassle
> to be worthwhile just for curiosity's sake.  I don't have any great to
> desire to actually use it beyond trying it out a little.  It's more an
> interest in seeing how something like that was written.
>
>> Its design was somewhat like what (little) I understand of LaTex: in
>> other words, commands relating to what to do with the text that
>> followed.
>
> That's about what I'd guessed, so I was mostly interested in seeing what
> the commands looked like, the implementation technique, what using it
> was like, etc.  Was it done with blocks and screens, using a block
> editor to write the input document?

Yes. polyFORTH was entirely block-oriented, even after we started 
keeping blocks in DOS files.

>> Ask him.
>
> I've never met him and he doesn't post here, but maybe someday.

leon@forth.com should work. He is an active participant in Forth20xx, 
but doesn't usually check in to c.l.f.

Cheers,
Elizabeth


-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#42729

"Elizabeth D. Rather" <erather@forth.com> writes:
>You are correct, neither Forth94 nor Forth2012 limits the size of the 
>string in S". It is likely that some implementations use a byte for the 
>length, as that was standard practice for many years, but it seems to me 
>that that would be non-compliant. Maybe someone in the Forth 200x 
>committee would like to clarify that.

There is no limit specified, so the length of the string is only
limited by other limits, not by the standard; other limits in this
context are the available memory, and the input line length (the
standard guarantees that the TIB is at least 80 characters, file input
lines can be 128 bytes long (11.3.5), blocks can be 1024 characters
long, and an EVALUATEd string is only limited by available memory).

For interpretive S" and S\", Forth-2012 guarantees that each buffer
can hold 80 characters.

So, a standard-compliant compiled S" is able to deal with strings
longer than 255 characters, because such usage of S" can occur in
blocks and EVALUATEd strings.  Given that one usually builds S" on top
of SLITERAL, and the strings passed to SLITERAL are only limited by
memory, this just means that system implementors should implement
SLITERAL properly, and S" will be catered for.

- 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: http://www.forth200x.org/forth200x.html
   EuroForth 2015: http://www.rigwit.co.uk/EuroForth2015/

[toc] | [prev] | [next] | [standalone]

#43047

I have decided that in my own personal Forth, strings will be both counted and NULL terminated. The count is in the first BYTE and does NOT include the NULL terminator.

So "ABC" would use 5 bytes and look like this:

3 65 66 67 0

This makes it easy to work with the strings using either approach. And I find that some activities are more straightforward when stopping at NULL as opposed to keeping a count and stopping when that count exceeds the count byte.

If it turns out that I have a need to deal with longer strings in the future, then I will cross that bridge when I get to it.

[toc] | [prev] | [next] | [standalone]

#43052

On 10/31/15 7:48 AM, Chris Curl wrote:
> I have decided that in my own personal Forth, strings will be both counted and NULL terminated. The count is in the first BYTE and does NOT include the NULL terminator.
>
> So "ABC" would use 5 bytes and look like this:
>
> 3 65 66 67 0
>
> This makes it easy to work with the strings using either approach. And I find that some activities are more straightforward when stopping at NULL as opposed to keeping a count and stopping when that count exceeds the count byte.

Which operations are those? Most string operations such as FILL, MOVE 
and CMOVE are usually implemented as code primitives on an ITC Forth. 
The only real use I find for null-terminated strings is for issuing 
calls to an OS or C library that requires them (and can be handled with 
a small set of special operators). Otherwise, runtime counting is 
grossly inefficient, and the effort to place nulls at the ends of your 
strings is usually unnecessary.

> If it turns out that I have a need to deal with longer strings in the future, then I will cross that bridge when I get to it.
>

That's a good plan. And when the situation arises, you can add specific 
words to do what you need, rather than re-do all your strings and 
string-handling words.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43055

On Saturday, October 31, 2015 at 3:57:55 PM UTC-4, Elizabeth D. Rather wrote:
> Which operations are those? Most string operations such as FILL, MOVE 
> and CMOVE are usually implemented as code primitives on an ITC Forth. 
> The only real use I find for null-terminated strings is for issuing 
> calls to an OS or C library that requires them (and can be handled with 
> a small set of special operators). Otherwise, runtime counting is 
> grossly inefficient, and the effort to place nulls at the ends of your 
> strings is usually unnecessary.
> 
> > If it turns out that I have a need to deal with longer strings in the future, then I will cross that bridge when I get to it.
> >
> 
> That's a good plan. And when the situation arises, you can add specific 
> words to do what you need, rather than re-do all your strings and 
> string-handling words.
> 
> Cheers,
> Elizabeth
Specifically, the routine that parses the input line. I find it easier just keep going until I hit a NULL, which of course means I am the end of the line.

And yes, I was planning on writing new words for long strings if need be.

[toc] | [prev] | [next] | [standalone]

#43065

On 10/31/15 10:34 AM, Chris Curl wrote:
> On Saturday, October 31, 2015 at 3:57:55 PM UTC-4, Elizabeth D. Rather wrote:
>> Which operations are those? Most string operations such as FILL, MOVE
>> and CMOVE are usually implemented as code primitives on an ITC Forth.
>> The only real use I find for null-terminated strings is for issuing
>> calls to an OS or C library that requires them (and can be handled with
>> a small set of special operators). Otherwise, runtime counting is
>> grossly inefficient, and the effort to place nulls at the ends of your
>> strings is usually unnecessary.
>>
>>> If it turns out that I have a need to deal with longer strings in the future, then I will cross that bridge when I get to it.
>>>
>>
>> That's a good plan. And when the situation arises, you can add specific
>> words to do what you need, rather than re-do all your strings and
>> string-handling words.
>>
>> Cheers,
>> Elizabeth
> Specifically, the routine that parses the input line. I find it easier just keep going until I hit a NULL, which of course means I am the end of the line.
>
> And yes, I was planning on writing new words for long strings if need be.

Indeed, many implementers have found terminating the input stream with a 
null is convenient. I don't think that generalizes to all strings, though.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[toc] | [prev] | [next] | [standalone]

#43085

On Sat, 31 Oct 2015 13:48:36 -0400, Chris Curl <ccurl609@gmail.com> wrote:

> I have decided that in my own personal Forth, strings will be both
> counted and NULL terminated. The count is in the first BYTE and does
> NOT include the NULL terminator.
>
> So "ABC" would use 5 bytes and look like this:
>
> 3 65 66 67 0
>
> This makes it easy to work with the strings using either approach.
> And I find that some activities are more straightforward when
> stopping at NULL as opposed to keeping a count and stopping when
> that count exceeds the count byte.
>
> If it turns out that I have a need to deal with longer strings in
> the future, then I will cross that bridge when I get to it.

BTW, NULL is used by C for a pointer to non-C-object area,
but NUL is a character of all bits zero for ASCII and EBCDIC,
probably Unicode too.  Or, NUL is a C-sized byte of all bits
zero for C where C's byte may be larger than the character
size in bits.

Some issues you might run into is which one to use and
what to do if the length of the nul terminated string
exceeds the ability to store the length in the byte.

I implemented null terminated strings in my Forth, as have
some others here.  I've not noticed any serious issues yet.

IIRC, you only need to change one Forth word to work
slightly differently than intended by the specifications,
but isn't in violation of them.

I had planned to insert a byte for the count since null
terminated strings won't pass Hayes Core tests as they're
currently implemented, but I have yet to do so as it will
require reformatting my dictionary code.

Having programmed heavily in both C and PL/1 (a PL/I variant),
one which uses nul-terminated strings and the other counted
strings, I'm of the strong opinion that nul terminated strings
is the better solution.  However, saying so seems to consistently
incite some flames here.

As Ms. Rather noted, some of Forth's string words are
typically implemented as primitives, many of which almost
map directly onto various C string functions.

CMOVE strncpy()
ENCLOSE strchr() or strpbrk()
COMPARE strcmp()
COUNT strlen()


Rod Pemberton

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.forth

csiph-web