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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#42738

On Monday, October 19, 2015 at 2:38:31 PM UTC-4, Elizabeth D. Rather wrote:
 
> There are many free Forths, including free evaluation versions of 
> SwiftForth and VFX. You really should be learning to use Forth before 
> setting out to write one. It will make it a lot easier for you.

I switch between learning Forth, improving the code that underlies it, and learning more about Intel assembly language. The last one might be the easiest for me, because I've been programming in mainframe assembly language for thirty-odd years.

At any rate, I find a nice feedback loop in shifting among them. Ideas beget ideas.

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

#42739

Alfred Singlestone wrote:
> On Monday, October 19, 2015 at 2:38:31 PM UTC-4, Elizabeth D. Rather wrote:
>
> > There are many free Forths, including free evaluation versions of
> > SwiftForth and VFX. You really should be learning to use Forth before
> > setting out to write one. It will make it a lot easier for you.
>
> I switch between learning Forth, improving the code that underlies it, and learning
> more about Intel assembly language. The last one might be the easiest for me, because
> I've been programming in mainframe assembly language for thirty-odd years.
>
> At any rate, I find a nice feedback loop in shifting among them. Ideas beget ideas.

Producing a forth of any quality isn't easy and of course it's a never-ending project.
The danger is tiring of it before really getting to know the language - which IMO is
only done through writing applications (lots of them).

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

#42872

"HAA" <someone@microsoft.com> writes:
> Producing a forth of any quality isn't easy and of course it's a
> never-ending project.  The danger is tiring of it before really
> getting to know the language - which IMO is only done through writing
> applications (lots of them).

Agreed.  I'm keeping an eye on Forth repositories at GitHub, and I see a
lot of half-finished toy Forths (and very few applications or
libraries).  Nothing wrong with that, but it doesn't seem to be a good
way to learn programming in Forth.

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

#42874

On Tuesday, October 27, 2015 at 6:30:22 AM UTC-4, Lars Brinkhoff wrote:
> "HAA" <someone@microsoft.com> writes:
> > Producing a forth of any quality isn't easy and of course it's a
> > never-ending project.  The danger is tiring of it before really
> > getting to know the language - which IMO is only done through writing
> > applications (lots of them).
> 
> Agreed.  I'm keeping an eye on Forth repositories at GitHub, and I see a
> lot of half-finished toy Forths (and very few applications or
> libraries).  Nothing wrong with that, but it doesn't seem to be a good
> way to learn programming in Forth.
Guilty as charged! :D
I am a software developer by trade, and as such, I spend 8-10 hours a day writing code. So I doubt I will be writing "lots" of Forth programs in my spare time. I am one of those people who has many interests. This is just one of my current interests, competing with hockey, vortex-based math, stock trending analysis, woodworking and working on my car. As it turns out, having my own implementation of Forth may play a role in many of those as well, because you can also use it to control a CNC machine, and an engine management system. Then there is that whole machine learning and robotics area that also interest me.

Damn, I need to win the lottery or something. A couple of hours at night it not nearly enough time.

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

#42876

Chris Curl <ccurl609@gmail.com> writes:
>> Agreed.  I'm keeping an eye on Forth repositories at GitHub, and I see a
>> lot of half-finished toy Forths (and very few applications or
>> libraries).  Nothing wrong with that, but it doesn't seem to be a good
>> way to learn programming in Forth.
> Guilty as charged! :D

So am I! :-) :-(

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

#42875

On Tuesday, October 27, 2015 at 6:30:22 AM UTC-4, Lars Brinkhoff wrote:
> I'm keeping an eye on Forth repositories at GitHub, and I see a
> lot of half-finished toy Forths (and very few applications or
> libraries).  Nothing wrong with that, but it doesn't seem to be a good
> way to learn programming in Forth.
There may be another one up there soon ... this one being an x86 assembler version I am working on. It has about 50 primitives, and a table of vectors instead of a big switch statement to execute the primitives. It builds an exe that is under 40K.

I don't know why, but I feel like implementing my own Forth is a rite of passage of sorts. If I am no longer able to implement my own Forth compiler/interpreter, then I am not worthy and should not be using Forth.

For some reason though, I don't feel the same way about the other languages, just Forth. Maybe it's because of my history, and the fact that my first Forth implementation was in the 1980s on a 6502. I guess this takes me back to my youth.

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

#42877

Chris Curl <ccurl609@gmail.com> writes:
> I don't know why, but I feel like implementing my own Forth is a rite
> of passage of sorts. If I am no longer able to implement my own Forth
> compiler/interpreter, then I am not worthy and should not be using
> Forth.

Shouldn't it be self-hosting too? ;-)

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

#42885

On Tuesday, October 27, 2015 at 10:04:55 AM UTC-4, Lars Brinkhoff wrote:
> Chris Curl <...@gmail.com> writes:
> > I don't know why, but I feel like implementing my own Forth is a rite
> > of passage of sorts. If I am no longer able to implement my own Forth
> > compiler/interpreter, then I am not worthy and should not be using
> > Forth.
> 
> Shouldn't it be self-hosting too? ;-)
Heh ... yeah .. probably ... that might be a ways off ... :D

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

#42886

On 10/27/15 11:26 AM, Chris Curl wrote:
> On Tuesday, October 27, 2015 at 10:04:55 AM UTC-4, Lars Brinkhoff wrote:
>> Chris Curl <...@gmail.com> writes:
>>> I don't know why, but I feel like implementing my own Forth is a rite
>>> of passage of sorts. If I am no longer able to implement my own Forth
>>> compiler/interpreter, then I am not worthy and should not be using
>>> Forth.
>>
>> Shouldn't it be self-hosting too? ;-)
> Heh ... yeah .. probably ... that might be a ways off ... :D
>

In my experience, it's easier to build a standalone Forth than one under 
an OS.

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]

#42889

Elizabeth D. Rather wrote
> Chris Curl wrote:
>> Lars Brinkhoff wrote:
>>> Chris Curl wrote:
>>>> I feel like implementing my own Forth is a rite of passage of
>>>> sorts. If I am no longer able to implement my own Forth compiler/
>>>> interpreter, then I am not worthy and should not be using Forth.
>>> Shouldn't it be self-hosting too? ;-)
>> Heh ... yeah .. probably ... that might be a ways off ... :D
> In my experience, it's easier to build a standalone Forth than one
> under an OS.

"Self-hosting" means that the language is implemented in itself, and can
generate new versions of itself without any other language being
involved.  E.g. a metacompiled Forth.

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

#42704

Anton Ertl wrote:
>
> Or you can tell your system implementor that his system is lacking and
> that other systems do it better.  Otherwise they'll continue to say
> things along the lines of: "Counted strings are a great representation
> for storing strings.  Longer strings are not needed: Our users have
> not complained about the limited length."

Or this:

"The counted string as an internal format in Forth is extremely
practical.  It is designed primarily for word names and program-internal
strings such as S" and ." which are virtually never longer than 256
bytes.  So, what's to be embarrassed about?

To be sure, there are applications in which longer strings are
necessary, but like all application needs, they are most appropriately
handled in the application or possibly in optional wordsets."

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

#42719

On 10/18/2015 6:40 PM, Johan Kotlinski wrote:
> On Saturday, October 17, 2015 at 7:41:43 PM UTC+2, Jason Damisch
> wrote:
>> But, I'll answer.  In regular Forth the strings have a byte count
>> and that first byte can be reached with C@.  The strings can
>> therefore not be longer than 255 characters long.
>
> Hi! It happened to me that I hit the limit, that s" was given too
> many characters. Does anyone have nice tricks or workarounds for that
> problem?
>
> What I want in the end is c-addr u representation, so the exact
> intermediate storage form is not important.

I'm a bit confused.  I think Jason meant to say "counted strings" 
instead of just "strings".  s" uses a  cell pair to specify a string of 
length up to the max number represented by a cell.  I don't see any 
other limit to what can be represented by s".  Maybe this was a limit of 
the internal functionality of the forth when parsing the string?  I 
don't find anything limiting this in the standard.  I also don't find 
anything where the system has to describe this limitation.  Should it be 
required?

-- 

Rick

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

#42724

On 10/20/15 8:47 AM, rickman wrote:
> On 10/18/2015 6:40 PM, Johan Kotlinski wrote:
>> On Saturday, October 17, 2015 at 7:41:43 PM UTC+2, Jason Damisch
>> wrote:
>>> But, I'll answer.  In regular Forth the strings have a byte count
>>> and that first byte can be reached with C@.  The strings can
>>> therefore not be longer than 255 characters long.
>>
>> Hi! It happened to me that I hit the limit, that s" was given too
>> many characters. Does anyone have nice tricks or workarounds for that
>> problem?
>>
>> What I want in the end is c-addr u representation, so the exact
>> intermediate storage form is not important.
>
> I'm a bit confused.  I think Jason meant to say "counted strings"
> instead of just "strings".  s" uses a  cell pair to specify a string of
> length up to the max number represented by a cell.  I don't see any
> other limit to what can be represented by s".  Maybe this was a limit of
> the internal functionality of the forth when parsing the string?  I
> don't find anything limiting this in the standard.  I also don't find
> anything where the system has to describe this limitation.  Should it be
> required?

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.

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]

#42726

On 10/20/2015 3:48 PM, Elizabeth D. Rather wrote:
> On 10/20/15 8:47 AM, rickman wrote:
>> On 10/18/2015 6:40 PM, Johan Kotlinski wrote:
>>> On Saturday, October 17, 2015 at 7:41:43 PM UTC+2, Jason Damisch
>>> wrote:
>>>> But, I'll answer.  In regular Forth the strings have a byte count
>>>> and that first byte can be reached with C@.  The strings can
>>>> therefore not be longer than 255 characters long.
>>>
>>> Hi! It happened to me that I hit the limit, that s" was given too
>>> many characters. Does anyone have nice tricks or workarounds for that
>>> problem?
>>>
>>> What I want in the end is c-addr u representation, so the exact
>>> intermediate storage form is not important.
>>
>> I'm a bit confused.  I think Jason meant to say "counted strings"
>> instead of just "strings".  s" uses a  cell pair to specify a string of
>> length up to the max number represented by a cell.  I don't see any
>> other limit to what can be represented by s".  Maybe this was a limit of
>> the internal functionality of the forth when parsing the string?  I
>> don't find anything limiting this in the standard.  I also don't find
>> anything where the system has to describe this limitation.  Should it be
>> required?
>
> 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.

The standard requires the value on the stack to be a cell, but does that 
require that s" be capable of working with string lengths longer than 
will fit in a byte if there is some internal limitation of the 
implementation?

-- 

Rick

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

#42727

rickman wrote:
>
> The standard requires the value on the stack to be a cell, but does that
> require that s" be capable of working with string lengths longer than
> will fit in a byte if there is some internal limitation of the
> implementation?

AFAIK it doesn't say.  If it did it would need to specify a minimum as with:
- The maximum length of a counted string shall be at least 255.
- The size of the region identified by WORD shall be at least 33 characters.

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

#42740

HAA wrote:
> rickman wrote:
> >
> > The standard requires the value on the stack to be a cell, but does that
> > require that s" be capable of working with string lengths longer than
> > will fit in a byte if there is some internal limitation of the
> > implementation?
>
> AFAIK it doesn't say.  If it did it would need to specify a minimum as with:
> - The maximum length of a counted string shall be at least 255.
> - The size of the region identified by WORD shall be at least 33 characters.

Correction.

3.4.1 Parsing
Unless otherwise noted, the number of characters parsed may be from
zero to the implementation-defined maximum length of a counted string.

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

#42745

On 10/21/15 3:21 PM, HAA wrote:
> HAA wrote:
>> rickman wrote:
>>>
>>> The standard requires the value on the stack to be a cell, but does that
>>> require that s" be capable of working with string lengths longer than
>>> will fit in a byte if there is some internal limitation of the
>>> implementation?
>>
>> AFAIK it doesn't say.  If it did it would need to specify a minimum as with:
>> - The maximum length of a counted string shall be at least 255.
>> - The size of the region identified by WORD shall be at least 33 characters.
>
> Correction.
>
> 3.4.1 Parsing
> Unless otherwise noted, the number of characters parsed may be from
> zero to the implementation-defined maximum length of a counted string.

Good catch! Indeed, the description of S" includes this:

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.

I still am of the opinion that S" isn't very useful for managing really 
long strings.

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]

#42747

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 10/21/15 3:21 PM, HAA wrote:
>> 3.4.1 Parsing
>> Unless otherwise noted, the number of characters parsed may be from
>> zero to the implementation-defined maximum length of a counted string.
>
>Good catch! Indeed, the description of S" includes this:
>
>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

You are free to submit an RfD, but I think that it would be better to
move this limitation to WORD where it probably comes from.  There is
no technical reason to have such a limitation for PARSE-NAME or PARSE.

- 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]

#42769

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.

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

#42788

"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.   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, so it probably is a bug in Forth-94 (and
-2012).

- 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]

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

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

csiph-web