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

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

Re: string-stack.4th

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-15 16:54 -0700
    Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-15 19:55 -0700
      Re: string-stack.4th Julian Fondren <julian.fondren@gmail.com> - 2017-04-15 20:08 -0700
      Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 13:50 +0000
        Re: string-stack.4th anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-16 15:51 +0000
          Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-16 22:16 +0000
            Re: string-stack.4th anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-04-17 12:04 +0000
              Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-17 13:11 -0700
                Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-17 23:18 +0000
                  Re: string-stack.4th albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-18 01:49 +0200
                    Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-19 23:03 +0000
                      Re: string-stack.4th "Elizabeth D. Rather" <erather@forth.com> - 2017-04-19 13:19 -1000
                        Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-20 00:15 +0000
                          Re: string-stack.4th "Elizabeth D. Rather" <erather@forth.com> - 2017-04-19 14:34 -1000
                            Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-20 17:16 +0000
                            Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-20 15:08 -0700
                        Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-20 00:16 +0000
                          Re: string-stack.4th albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 21:10 +0200
                            Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-21 09:59 +0000
                        Re: string-stack.4th albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-04-20 20:50 +0200
                  Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-17 19:47 -0700
                    Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-19 23:08 +0000
                Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-18 00:10 -0700
                  Re: string-stack.4th Alex <alex@rivadpm.com> - 2017-04-18 13:48 +0100
                    Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-18 09:15 -0700
                      Re: string-stack.4th Alex <alex@rivadpm.com> - 2017-04-18 18:23 +0100
              Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-17 23:07 +0000
              Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-18 09:09 -0700
                Re: string-stack.4th lehs <skydda.barnen@gmail.com> - 2017-04-18 10:27 -0700
        Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-16 19:26 -0700
          Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-17 23:13 +0000
            Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-23 12:39 -0700
              Re: string-stack.4th Michael Barry <barrym95838@yahoo.com> - 2017-04-23 22:25 -0700
                Re: string-stack.4th foxaudioresearch@gmail.com - 2017-04-24 14:06 -0700
                  Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-29 03:19 +0000
              Re: string-stack.4th Ron Aaron <rambamist@gmail.com> - 2017-04-24 08:35 +0300
                Re: string-stack.4th Paul Rubin <no.email@nospam.invalid> - 2017-04-23 23:51 -0700
                  Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-24 00:10 -0700
                  Re: string-stack.4th Ron Aaron <rambamist@gmail.com> - 2017-04-24 10:11 +0300
                    Re: string-stack.4th Lars Brinkhoff <lars.spam@nocrew.org> - 2017-04-24 09:27 +0200
                    Re: string-stack.4th Paul Rubin <no.email@nospam.invalid> - 2017-04-24 01:14 -0700
              Re: string-stack.4th Alex <alex@rivadpm.com> - 2017-04-24 14:38 +0100
              Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-29 03:18 +0000
              Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-29 03:27 +0000
                Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-28 22:13 -0700
                  Re: string-stack.4th Alex <alex@rivadpm.com> - 2017-04-29 09:41 +0100
                    Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-29 07:05 -0700
                  Re: string-stack.4th "Rudy Velthuis" <newsgroups@rvelthuis.de> - 2017-04-29 11:43 +0000
    Re: string-stack.4th hughaguilar96@gmail.com - 2017-04-15 21:15 -0700

Page 1 of 3  [1] 2 3  Next page →

#57396 — Re: string-stack.4th

Anton Ertl's post came from here:
https://groups.google.com/forum/#!topic/comp.lang.forth/EkjxmjenL5s

I'm replying to it in this thread because this is where the answer is.

On Saturday, April 15, 2017 at 1:08:54 AM UTC-7, Anton Ertl wrote:
> hughaguilar96@gmail.com writes:
> >1.) I read that Forth-200x description of S\" and found this bizarre restri=
> >ction:
> >"A program shall not alter the returned string."
> >I don't know why they have that restriction, and I certainly don't.
> 
> : foo s\" bla" ;
> 'x foo drop c!
> foo type
> 
> If programs were allowed to alter the returned string, what should the
> output of TYPE be?  Is the returned string required to be in RAM?
> Should it make a new copy every time it runs?  How long is that copy
> guaranteed to live?

This is really the whole point of having a string-stack --- so you have somewhere to put your strings.

S" and S\" would create a string that can't be altered, but when they execute that push a string onto the string-stack. They don't have to copy the string because the string pushed onto the string-stack is a derivative. After the string is pushed onto the string-stack it can be worked with just like any string. If it is modified, it internally gets converted into a unique string first (a unique copy is made). If a string is consumed (such as by .$ etc.) then it gets dropped (if it is a derivative it just gets dropped, but if it is unique then it gets a DEALLOC to remove it from the heap before it gets dropped). 

A string on the string-stack is guaranteed to live forever --- until it gets consumed. When it gets consumed (such as by .$ or DROP$ etc.) it gets freed from the heap if it is a unique, so the programmer doesn't have to manually use FREE or DEALLOC on it. Also, if a unique string gets consumed, before it id freed we internally search the entire string-stack for derivatives and convert them into uniques.

Here is an example (using .S$ to show what is on the string-stack):

s" hello world" >$  ok
dup$  ok
.s$ 
STRING STACK:
derivative: |hello world|
derivative: |hello world| ok

reverse$  ok
.s$ 
STRING STACK:
unique:     |dlrow olleh|
derivative: |hello world| ok

.$ dlrow olleh ok
.$ hello world ok

A major failing of ANS-Forth is that you pass data between functions in global variables. This is extremely bad programming! For example, your S" stores the string in a global variable when it is used interpretively. Then you do another S" and you overwrite it. Another example is that <# #> stores the string in a global variable. When you do another <# #> it overwrites it. All of these problems get solved by the use of a string-stack.

[toc] | [next] | [standalone]

#57416

On Saturday, April 15, 2017 at 4:54:24 PM UTC-7, hughag...@gmail.com wrote:
> Anton Ertl's post came from here:
> https://groups.google.com/forum/#!topic/comp.lang.forth/EkjxmjenL5s
> 
> I'm replying to it in this thread because this is where the answer is.
> 
> On Saturday, April 15, 2017 at 1:08:54 AM UTC-7, Anton Ertl wrote:
> > hughaguilar96@gmail.com writes:
> > >1.) I read that Forth-200x description of S\" and found this bizarre restri=
> > >ction:
> > >"A program shall not alter the returned string."
> > >I don't know why they have that restriction, and I certainly don't.
> > 
> > : foo s\" bla" ;
> > 'x foo drop c!
> > foo type
> > 
> > If programs were allowed to alter the returned string, what should the
> > output of TYPE be?  Is the returned string required to be in RAM?
> > Should it make a new copy every time it runs?  How long is that copy
> > guaranteed to live?
> 
> This is really the whole point of having a string-stack --- so you have somewhere to put your strings.
> 
> S" and S\" would create a string that can't be altered, but when they execute that push a string onto the string-stack. They don't have to copy the string because the string pushed onto the string-stack is a derivative. After the string is pushed onto the string-stack it can be worked with just like any string. If it is modified, it internally gets converted into a unique string first (a unique copy is made). If a string is consumed (such as by .$ etc.) then it gets dropped (if it is a derivative it just gets dropped, but if it is unique then it gets a DEALLOC to remove it from the heap before it gets dropped). 
> 
> A string on the string-stack is guaranteed to live forever --- until it gets consumed. When it gets consumed (such as by .$ or DROP$ etc.) it gets freed from the heap if it is a unique, so the programmer doesn't have to manually use FREE or DEALLOC on it. Also, if a unique string gets consumed, before it id freed we internally search the entire string-stack for derivatives and convert them into uniques.
> 
> Here is an example (using .S$ to show what is on the string-stack):
> 
> s" hello world" >$  ok
> dup$  ok
> .s$ 
> STRING STACK:
> derivative: |hello world|
> derivative: |hello world| ok
> 
> reverse$  ok
> .s$ 
> STRING STACK:
> unique:     |dlrow olleh|
> derivative: |hello world| ok
> 
> .$ dlrow olleh ok
> .$ hello world ok
> 
> A major failing of ANS-Forth is that you pass data between functions in global variables. This is extremely bad programming! For example, your S" stores the string in a global variable when it is used interpretively. Then you do another S" and you overwrite it. Another example is that <# #> stores the string in a global variable. When you do another <# #> it overwrites it. All of these problems get solved by the use of a string-stack.

The important point here is that we never have an address and count on the data-stack. You can't just modify strings willy-nilly. You don't have to worry about keeping track of whether a particular string can be modified or if this is forbidden (it is forbidden for S" and S\" strings, and maybe some others). Strings are only modified when they are on the string-stack, and the words that modify them follow the rules:
1.) Turn a derivative into a unique first
2.) If it is already a unique then turn any derivatives it has into uniques.

Also, storing string in the heap is not a good solution. 

1.) This involves copying the string every time. By comparison, the string-stack just makes a derivative --- the derivative doesn't get turned into a unique until this is necessary --- in many cases, the derivative never gets turned into a unique.

2.) The user has to manually FREE the string. This bloats out the source-code, and it is confusing to the user to remember when to do this. If the user forgets to do this, he gets a memory leak. By comparison, the string-stack consumers takes care of this internally when necessary.

What ANS-Forth does is just pass strings between functions in global variables ( PAD and the S" pad and the <# #> pad). This is terrible programming! This was done in the early 1970s when computers had such limited RAM that there was no room for multiple strings. Charles Moore came up with these global pads as an expedient measure to get some application program finished --- apparently it was an application program that didn't need to work with more than one string at a time.

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

#57417

On Saturday, April 15, 2017 at 9:55:50 PM UTC-5, hughag...@gmail.com wrote:
> You can't just modify strings willy-nilly.

https://www.youtube.com/watch?v=764T6P7cnKM

I recommend that you learn Rust.

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

#57439

hughaguilar96@gmail.com wrote:

> Also, storing string in the heap is not a good solution. 
> 
> 1.) This involves copying the string every time. 

Ok, not speaking from Forth experience, but from a lot of experience
with using and implementing string code in several languages: the above
is nonsense.

If possible, use COW (copy on write), if possible paired with some kind
of (automatic) reference counting (or similar) and you won't have to
copy each time. Only if the string is modified and the refcount is > 1.
Note that the refcount and length should be part of the string data on
the heap (the so-called "payload"), not part of the "string pointer".

You could also make ALL strings immutable. That would only require a
copy if the string is modified, otherwise you can simply return (a
pointer to) the original. Also easier to handle concurrent access that
way.

I don't really understand why currently, in Forth, an address/length
combination is used so often. The length should, when possible, be
stored as part of the string data, just like old-fashioned (byte)
counted strings. The address-length pair only make sense if the string
data is read directly from some kind of buffer and the buffer should
not/cannot be modified. This only makes sense for transient data, e.g.
when parsing a word or string of which the string data that can easily
be discarded after use (e.g. when interpreting or compiling and you
only parse to, er, find out what to do next).

-- 
Rudy Velthuis        http://www.rvelthuis.de

"I still live." -- Daniel Webster, dying words

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

#57450

"Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
>I don't really understand why currently, in Forth, an address/length
>combination is used so often. The length should, when possible, be
>stored as part of the string data, just like old-fashioned (byte)
>counted strings.

Why?

Concerning reasons: From
<http://www.complang.tuwien.ac.at/anton/euroforth/ef13/papers/ertl-strings.pdf>:

|The favoured string representation in standard
|Forth is c-addr u. It allows representing strings
|of any length with any content, and you can pro-
|duce arbitrary substrings without needing to copy
|the string to a new buffer. The disadvantage of
|this representation is that it takes two cells on the
|stack, and dealing with several strings at once can
|therefore be cumbersome.
|
|   The other common string representation in stan-
|dard Forth is the counted string: The on-stack rep-
|resentation is the address of the count byte; the
|count byte is followed by the characters of the
|string. The advantage of this representation is that
|it needs only one cell on the stack. But it can only
|represent strings with up to 255 chars, and any
|substring operation needs to create a new string
|buffer. Converting from counted to c-addr u is
|easy (count), but the other direction is cumber-
|some. Some people have suggested using cell counts
|instead of byte counts to get rid of the length limi-
|tation.

> The address-length pair only make sense if the string
>data is read directly from some kind of buffer and the buffer should
>not/cannot be modified. This only makes sense for transient data, e.g.
>when parsing a word or string of which the string data that can easily
>be discarded after use (e.g. when interpreting or compiling and you
>only parse to, er, find out what to do next).

Much of my strings usage is like that.  A good reason to use c-addr u.
Do you really want to copy a substring to a separate buffer (and where
do you allocate that?) before you can, e.g., write it to a file?  I
don't.

- 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 2016: http://www.euroforth.org/ef16/

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

#57461

Anton Ertl wrote:

> > The address-length pair only make sense if the string
> > data is read directly from some kind of buffer and the buffer should
> > not/cannot be modified. This only makes sense for transient data,
> > e.g.  when parsing a word or string of which the string data that
> > can easily be discarded after use (e.g. when interpreting or
> > compiling and you only parse to, er, find out what to do next).
> 
> Much of my strings usage is like that.  A good reason to use c-addr u.
> Do you really want to copy a substring to a separate buffer (and where
> do you allocate that?) before you can, e.g., write it to a file?  I
> don't.

No, of course not. Then you use c-addr u, like in other languages. But
if you have to manipulate or keep around more than one string, and
these are referenced in more than one spot, it often makes sense to
have semi-permanent or permanent storage. So, yes, often such strings
are simply stored in the word, or in an allocated buffer, or, well, in
a separate heap, but then a double-cell "pointer" is useless. Then the
length can be stored with (before) the string data.
-- 
Rudy Velthuis        http://www.rvelthuis.de

"Dying is a very dull, dreary affair. And my advice to you is to
 have nothing whatever to do with it." -- W. Somerset Maugham.

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

#57486

"Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
>Anton Ertl wrote:
>
>> > The address-length pair only make sense if the string
>> > data is read directly from some kind of buffer and the buffer should
>> > not/cannot be modified. This only makes sense for transient data,
>> > e.g.  when parsing a word or string of which the string data that
>> > can easily be discarded after use (e.g. when interpreting or
>> > compiling and you only parse to, er, find out what to do next).
>> 
>> Much of my strings usage is like that.  A good reason to use c-addr u.
>> Do you really want to copy a substring to a separate buffer (and where
>> do you allocate that?) before you can, e.g., write it to a file?  I
>> don't.
>
>No, of course not. Then you use c-addr u, like in other languages.

So that's why we have c-addr u.  Now adding another string
representation complicates things.  I need to decide which string
representation is appropriate where, have to keep track of which
string representation is used where, have to insert conversion words
in various places, have to write some words in two variants, etc.  And
what benefit do we get for putting up with these complications?

> But
>if you have to manipulate or keep around more than one string, and
>these are referenced in more than one spot, it often makes sense to
>have semi-permanent or permanent storage. So, yes, often such strings
>are simply stored in the word, or in an allocated buffer, or, well, in
>a separate heap, but then a double-cell "pointer" is useless.

The c-addr u representation is just as useful as ever: It tells you
where the string starts and how long it is.

- 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 2016: http://www.euroforth.org/ef16/

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

#57499

On Monday, April 17, 2017 at 5:13:27 AM UTC-7, Anton Ertl wrote:
> "Rudy Velthuis" <newsgroups@rvelthuis.de> writes:
> >Anton Ertl wrote:
> >
> >> > The address-length pair only make sense if the string
> >> > data is read directly from some kind of buffer and the buffer should
> >> > not/cannot be modified. This only makes sense for transient data,
> >> > e.g.  when parsing a word or string of which the string data that
> >> > can easily be discarded after use (e.g. when interpreting or
> >> > compiling and you only parse to, er, find out what to do next).
> >> 
> >> Much of my strings usage is like that.  A good reason to use c-addr u.
> >> Do you really want to copy a substring to a separate buffer (and where
> >> do you allocate that?) before you can, e.g., write it to a file?  I
> >> don't.
> >
> >No, of course not. Then you use c-addr u, like in other languages.
> 
> So that's why we have c-addr u.  

Rudy Velthuis doesn't know what he is talking about. Consumers work fine with derivative strings; they don't need to convert the derivative into a unique (which involves calling ALLOCATE and copying it the string over). You can write a string to a file or whatever.

Only modifiers need to convert the derivative into a unique (or, if it is a unique already, need to convert all of its derivatives into uniques). Modifiers (such as REVERSE$ etc.) aren't used very much, so this doesn't need to be done very much.

Anton Ertl doesn't know what he is talking about either, because he cheerfully agreed with Rudy Velthuis in this bogus criticism of my STRING-STACK.4TH package. It is possible that Anton Ertl doesn't know how COW (copy-on-write) works. It is also possible that Anton Ertl does know how COW (copy-on-write) works and he is just being dishonest --- pretending that any criticism of my STRING-STACK.4TH is valid --- brown-nosing Elizabeth Rather as usual (because she appointed him to his job as the Forth-200x committee chairpersone).

> Now adding another string
> representation complicates things.  I need to decide which string
> representation is appropriate where, have to keep track of which
> string representation is used where, have to insert conversion words
> in various places, have to write some words in two variants, etc.  And
> what benefit do we get for putting up with these complications?

LOL! No, you don't have to decide which string representation is appropriate where, or keep track of which string representation is used where, etc..
You just press the flush lever on Elizabeth Rather's stupid string representation! Why is this so difficult for you??? 

It is utterly stupid to pass strings in global variables (the <# #> pad, the S" pad, and PAD). 
It is utterly stupid to have address/count pairs on the data-stack. 
It is utterly stupid to have some strings that can't be modified (because they came from S" or S\"), although there is nothing to actually stop you from modifying them, and have to remember that this.
It is utterly stupid to have some strings that are on the heap and will eventually need a FREE, and have to remember this.
It is utterly stupid to have some strings that are in global variables and will get overwritten, and have to remember this.
It is utterly stupid to modify strings willy-nilly without any kind of system in place. 

It is never appropriate to use Elizabeth Rather's shit-head string scheme! Way back in the 1984 I was well aware of the problem with passing data between functions in global variables. This was the major problem in line-number BASIC. I really expected Forth to do better, but Forth-83 had the same problem. Forth-83 was introduced one year after Elizabeth Rather kicked Charles Moore out of Forth Inc. and it was Elizabeth Rather's shit-head scheme. At that time, everybody expected a new standard pretty soon that would fix these obvious blunders. A lot of time went by! Eventually ANS-Forth came out in 1994 and this continued to feature Elizabeth Rather's shit-head scheme.

The whole point of introducing a new standard is to kick Elizabeth Rather out of the Forth community. She is a shit-head! She has to go!

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

#57507

hughaguilar96@gmail.com wrote:

> > > No, of course not. Then you use c-addr u, like in other languages.
> > 
> > So that's why we have c-addr u.

I understand the need for c-addr u in certain situations, but it is IMO
not a good idea to always having to supply the u. Only supply it where
it is needed.
 
> Rudy Velthuis doesn't know what he is talking about. Consumers work
> fine with derivative strings;

Rudy Velthuis does know what he is talking about. He is just not so
familiar with current affairs in Forth yet and wonders why certain
things are done the way they are currently done, in Forth.

I don't quite know what you mean with "derivative strings" though. 

And where I come from, strings are often modified, e.g. concatenated,
replaced, searched, etc. They often have a life that is a little bit
longer than what could be found in the current input buffer or other
volatile storate.

I assume this is not the case in most Forth code? Or are such strings
generally compiled into a definition or stored in a variable, meaning
they are copied after all?

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Alas, to wear the mantle of Galileo it is not enough that you
 be persecuted by an unkind establishment, you must also be
 right." -- Bob Park

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

#57512

In article <xn0kov39w5a0bjd002@nntp.aioe.org>,
Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
>hughaguilar96@gmail.com wrote:
>
>> > > No, of course not. Then you use c-addr u, like in other languages.
>> >
>> > So that's why we have c-addr u.
>
>I understand the need for c-addr u in certain situations, but it is IMO
>not a good idea to always having to supply the u. Only supply it where
>it is needed.
>
>> Rudy Velthuis doesn't know what he is talking about. Consumers work
>> fine with derivative strings;
>
>Rudy Velthuis does know what he is talking about. He is just not so
>familiar with current affairs in Forth yet and wonders why certain
>things are done the way they are currently done, in Forth.

Both stringconstants (addr n) and stringvariable (storage with
first cell containing the length are useful.
The ease with which forth can pass around double items on the stack
means that we have no need to allocate or store strings
in many cases. In C that would require a struct instead of '' char *pc ''

This script copies a file in argument 1 to standard output
and removes all empty lines:

-------------------------
#!/usr/bin/lina -s

1 ARG[]  GET-FILE
BEGIN DUP WHILE ^J $/ -TRAILING DUP IF TYPE CR ELSE 2DROP THEN REPEAT
2DROP
----------------------------------------------

All strings here are (addr n) , the only buffer is implicitly allocated
by GET-FILE. Pieces of the input are copied to the output.

>
>--
>Rudy Velthuis        http://www.rvelthuis.de

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#57608

Albert van der Horst wrote:

> In article <xn0kov39w5a0bjd002@nntp.aioe.org>,
> Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
> > hughaguilar96@gmail.com wrote:
> > 
> >> > > No, of course not. Then you use c-addr u, like in other
> languages.  >> >
> >> > So that's why we have c-addr u.
> > 
> > I understand the need for c-addr u in certain situations, but it is
> > IMO not a good idea to always having to supply the u. Only supply
> > it where it is needed.
> > 
> >> Rudy Velthuis doesn't know what he is talking about. Consumers work
> >> fine with derivative strings;
> > 
> > Rudy Velthuis does know what he is talking about. He is just not so
> > familiar with current affairs in Forth yet and wonders why certain
> > things are done the way they are currently done, in Forth.
> 
> Both stringconstants (addr n) and stringvariable (storage with
> first cell containing the length are useful.

Ok, fine. But are all c-addr u combinations really supposed to be
constants, or is that just how you call them?

> The ease with which forth can pass around double items on the stack
> means that we have no need to allocate or store strings
> in many cases. In C that would require a struct instead of '' char
> *pc ''
> 
> This script copies a file in argument 1 to standard output
> and removes all empty lines:
> 
> -------------------------
> #!/usr/bin/lina -s
> 
> 1 ARG[]  GET-FILE
> BEGIN DUP WHILE ^J $/ -TRAILING DUP IF TYPE CR ELSE 2DROP THEN REPEAT
> 2DROP
> ----------------------------------------------


What does GET-FILE do? 

What does $/ do? Split the string at the first occurrence of a given
char?

And I assume that ^J is a syntax for Ctrl-J or linefeed.


-- 
Rudy Velthuis        http://www.rvelthuis.de

"Everyone likes to say Hitler did this and Hitler did that. But
 the truth is Hitler did very little. He was a world class
 asshole, but the evil actually done, from the death camps to
 World War Two, was all done by citizens who were afraid to
 question if what they were told by their government was the
 truth or not, and who because they did not want to admit to
 themselves that they were afraid to question the government,
 refused to see the truth behind the Reichstag Fire, refused to
 see the invasion by Poland was a staged fake, and followed
 Hitler into national disaster."
 -- Michael Rivero

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

#57612

On 4/19/17 1:03 PM, Rudy Velthuis wrote:
> Albert van der Horst wrote:
>
>> In article <xn0kov39w5a0bjd002@nntp.aioe.org>,
>> Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
>>> hughaguilar96@gmail.com wrote:
>>>
>>>>>> No, of course not. Then you use c-addr u, like in other
>> languages.  >> >
>>>>> So that's why we have c-addr u.
>>>
>>> I understand the need for c-addr u in certain situations, but it is
>>> IMO not a good idea to always having to supply the u. Only supply
>>> it where it is needed.
>>>
>>>> Rudy Velthuis doesn't know what he is talking about. Consumers work
>>>> fine with derivative strings;
>>>
>>> Rudy Velthuis does know what he is talking about. He is just not so
>>> familiar with current affairs in Forth yet and wonders why certain
>>> things are done the way they are currently done, in Forth.
>>
>> Both stringconstants (addr n) and stringvariable (storage with
>> first cell containing the length are useful.
>
> Ok, fine. But are all c-addr u combinations really supposed to be
> constants, or is that just how you call them?

The arguments c-addr u just denote a region of memory u address units 
long. It may be in a scratch area, an input buffer, RAM, ROM, or 
anywhere. Nothing is implied about its contents or location. Any 
implications as to the nature of this region is embodied in what the 
program does with it, that is, the word processing the c-addr u stack 
arguments such as MOVE etc.

>> The ease with which forth can pass around double items on the stack
>> means that we have no need to allocate or store strings
>> in many cases. In C that would require a struct instead of '' char
>> *pc ''

Yes the "2---" words (2DUP, 2OVER, 2SWAP, etc.) are particularly useful 
with these pairs of cells.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#57615

Elizabeth D. Rather wrote:

> > > The ease with which forth can pass around double items on the
> > > stack means that we have no need to allocate or store strings
> > > in many cases. In C that would require a struct instead of '' char
> > > *pc ''
> 
> Yes the "2---" words (2DUP, 2OVER, 2SWAP, etc.) are particularly
> useful with these pairs of cells.

Sure, and they are easy to implement. But the single cell equivalents
are probably still more efficient, so manipulating a stack with
single-cell values is probably still better.

Of course, if there is no need to store strings, then it makes no sense
to do that just to save having to pass around a single value.

-- 
Rudy Velthuis        http://www.rvelthuis.de

"He'd noticed that sex bore some resemblance to cookery: it 
 fascinated people, they sometimes bought books full of 
 complicated recipes and interesting pictures, and sometimes when 
 they were really hungry they created vast banquets in their 
 imagination - but at the end of the day they'd settle quite 
 happily for egg and chips. If it was well done and maybe had a 
 slice of tomato."
 -- Terry Pratchett (The Fifth Elephant)

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

#57618

On 4/19/17 2:15 PM, Rudy Velthuis wrote:
> Elizabeth D. Rather wrote:
>
>>>> The ease with which forth can pass around double items on the
>>>> stack means that we have no need to allocate or store strings
>>>> in many cases. In C that would require a struct instead of '' char
>>>> *pc ''
>>
>> Yes the "2---" words (2DUP, 2OVER, 2SWAP, etc.) are particularly
>> useful with these pairs of cells.
>
> Sure, and they are easy to implement. But the single cell equivalents
> are probably still more efficient, so manipulating a stack with
> single-cell values is probably still better.

If you mean passing the single address of a counted string, yes there 
are times when that is convenient, but to do something with the string 
you still have to fetch the length, and in my experience it's usually 
easier to deal with the string as c-addr u pairs.

> Of course, if there is no need to store strings, then it makes no sense
> to do that just to save having to pass around a single value.

Well, the string has to be somewhere, even if only temporarily, and the 
data stack isn't a good place for it.

Cheers,
Elizabeth

-- 
Elizabeth D. Rather
FORTH, Inc.
6080 Center Drive, Suite 600
Los Angeles, CA  90045
USA

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

#57648

Elizabeth D. Rather wrote:

> On 4/19/17 2:15 PM, Rudy Velthuis wrote:
> > Elizabeth D. Rather wrote:
> > 
> > > > > The ease with which forth can pass around double items on the
> > > > > stack means that we have no need to allocate or store strings
> > > > > in many cases. In C that would require a struct instead of ''
> > > > > char *pc ''
> > > 
> > > Yes the "2---" words (2DUP, 2OVER, 2SWAP, etc.) are particularly
> > > useful with these pairs of cells.
> > 
> > Sure, and they are easy to implement. But the single cell
> > equivalents are probably still more efficient, so manipulating a
> > stack with single-cell values is probably still better.
> 
> If you mean passing the single address of a counted string, yes there
> are times when that is convenient, but to do something with the
> string you still have to fetch the length

Inside the word, yes. 

-- 
Rudy Velthuis        http://www.rvelthuis.de

"Don't sweat the petty things, just pet the sweaty things."

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

#57670

On Wednesday, April 19, 2017 at 5:34:59 PM UTC-7, Elizabeth D. Rather wrote:
> On 4/19/17 2:15 PM, Rudy Velthuis wrote:
> > Elizabeth D. Rather wrote:
> >
> >>>> The ease with which forth can pass around double items on the
> >>>> stack means that we have no need to allocate or store strings
> >>>> in many cases. In C that would require a struct instead of '' char
> >>>> *pc ''
> >>
> >> Yes the "2---" words (2DUP, 2OVER, 2SWAP, etc.) are particularly
> >> useful with these pairs of cells.
> >
> > Sure, and they are easy to implement. But the single cell equivalents
> > are probably still more efficient, so manipulating a stack with
> > single-cell values is probably still better.
> 
> If you mean passing the single address of a counted string, yes there 
> are times when that is convenient, but to do something with the string 
> you still have to fetch the length, and in my experience it's usually 
> easier to deal with the string as c-addr u pairs.
> 
> > Of course, if there is no need to store strings, then it makes no sense
> > to do that just to save having to pass around a single value.

All of this seems like nonsense to me. 

In Straight Forth and Traditional Forth both, there is a double-stack. One of the many blunders of ANS-Forth is to intermix single and double data on the same stack. This results in a muddle of stack jugglers! Elizabeth Rather is just maintaining Charles Moore's Forth written in the 1970s --- in those days the processors, such as the PDP-11, had a shortage of registers --- Charles Moore didn't implement a double-stack because he didn't have a register available to use as the stack-pointer.

Double precision integers and ratios (a single-precision numerator and denominator) should go on the double-stack. 

As for strings, it is a mistake to have the address/count accessible to the user. It is a mistake to force the user to remember which strings can be modified, which can not be modified (because they came from S" or S\") and which will likely get overwritten (because they are in a statically defined global buffer such as PAD or the <# #> buffer or the S" buffer from interpretive mode). 
 
> Well, the string has to be somewhere, even if only temporarily, and the 
> data stack isn't a good place for it.

Who is saying that strings should be held on the data-stack? I suppose you mean with a 0 sentinel underneath. Nobody ever does this though; it is very clumsy.

Strings should be held in the string-stack when working on them. I wrote STRING-STACK.4TH --- it is the best string-stack implementation ever written in Forth --- it is some of the best Forth code I've written in many years.

It annoys me that I start this thread discussing STRING-STACK.4TH and then you, proclaiming yourself to be the "leading expert" of Forth, show up and spout idiotic nonsense --- this is just a distraction --- go away, arrogant sales-clown!

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

#57616

Elizabeth D. Rather wrote:

> On 4/19/17 1:03 PM, Rudy Velthuis wrote:
> > Albert van der Horst wrote:
> > 
> > > In article <xn0kov39w5a0bjd002@nntp.aioe.org>,
> >>Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
> > > > hughaguilar96@gmail.com wrote:
> > > > 
> > > > > > > No, of course not. Then you use c-addr u, like in other
> >>languages.  >> >
> > > > > > So that's why we have c-addr u.
> > > > 
> > > > I understand the need for c-addr u in certain situations, but
> > > > it is IMO not a good idea to always having to supply the u.
> > > > Only supply it where it is needed.
> > > > 
> > > > > Rudy Velthuis doesn't know what he is talking about.
> > > > > Consumers work fine with derivative strings;
> > > > 
> > > > Rudy Velthuis does know what he is talking about. He is just
> > > > not so familiar with current affairs in Forth yet and wonders
> > > > why certain things are done the way they are currently done, in
> > > > Forth.
> > > 
> > > Both stringconstants (addr n) and stringvariable (storage with
> > > first cell containing the length are useful.
> > 
> > Ok, fine. But are all c-addr u combinations really supposed to be
> > constants, or is that just how you call them?
> 
> The arguments c-addr u just denote a region of memory u address units
> long. It may be in a scratch area, an input buffer, RAM, ROM, or
> anywhere. Nothing is implied about its contents or location. Any
> implications as to the nature of this region is embodied in what the
> program does with it, that is, the word processing the c-addr u stack
> arguments such as MOVE etc.

I understand that. 

But the current topic was "c-addr u" for (single byte) strings. I see
that Albert van der Horst likes to call these "c-addr u" combinations
"string constants" ("sc" in his docs for e.g. wina or lina), even if
they are actually not necessarily constants at all.
-- 
Rudy Velthuis        http://www.rvelthuis.de

"In general the art of government consists in taking as much
 money as possible from one class of citizens to give to the
 other."
 -- Voltaire

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

#57662

In article <xn0koxxxi86xwbb007@nntp.aioe.org>,
Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
>
>I understand that.
>
>But the current topic was "c-addr u" for (single byte) strings. I see
>that Albert van der Horst likes to call these "c-addr u" combinations
>"string constants" ("sc" in his docs for e.g. wina or lina), even if
>they are actually not necessarily constants at all.

Of course they are not constants. They are string constants!
The analogy is as good as it gets:

OK
CREATE PAD 100 ALLOT
12 PAD !
OK
14 PAD +!
OK
PAD @ .
26  OK
"AAP" PAD $!
OK
"NOOT" PAD $+!
OK
PAD $@ TYPE
AAPNOOT OK
12 1+ .
13  OK
WANT /STRING
OK
"AAP" 1 /STRING TYPE
AP OK

(PAD is used here as a string variable. You can't use the real PAD
because it moves while allocating strings>)

It is extremely important to have a denotation for strings to get
in the right mindset. If one looks at S" aap" and sees a weird
function ( S") that manipulates characters, one can't pass a certain
level. But there is "AAP" : a string constant.

Compare a proficiant musician. I see a one bar below, a C, then an E
oops flattened, then a G. The musician sees a C minor chord,
or rather he hears internally a tonica in E flat (or some such).

So embrace the expression string constant and you will be enlightened.
(Well maybe the top of you little toe ...)

Groetjes Albert

>--
>Rudy Velthuis        http://www.rvelthuis.de
>
>"In general the art of government consists in taking as much
> money as possible from one class of citizens to give to the
> other."
> -- Voltaire
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#57710

Albert van der Horst wrote:

> In article <xn0koxxxi86xwbb007@nntp.aioe.org>,
> Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
> > 
> > I understand that.
> > 
> > But the current topic was "c-addr u" for (single byte) strings. I
> > see that Albert van der Horst likes to call these "c-addr u"
> > combinations "string constants" ("sc" in his docs for e.g. wina or
> > lina), even if they are actually not necessarily constants at all.
> 
> Of course they are not constants. They are string constants!

Er, ... so string _constants_ are not, well, _constants_?
-- 
Rudy Velthuis        http://www.rvelthuis.de

"The difference between what the most and the least learned 
 people know is inexpressibly trivial in relation to that which 
 is unknown."  -- Albert Einstein

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

#57661

In article <i7OdnfdUKfz0bWrFnZ2dnUU7-UHNnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 4/19/17 1:03 PM, Rudy Velthuis wrote:
>> Albert van der Horst wrote:
>>
>>> In article <xn0kov39w5a0bjd002@nntp.aioe.org>,
>>> Rudy Velthuis <newsgroups@rvelthuis.de> wrote:
>>>> hughaguilar96@gmail.com wrote:
>>>>
>>>>>>> No, of course not. Then you use c-addr u, like in other
>>> languages.  >> >
>>>>>> So that's why we have c-addr u.
>>>>
>>>> I understand the need for c-addr u in certain situations, but it is
>>>> IMO not a good idea to always having to supply the u. Only supply
>>>> it where it is needed.
>>>>
>>>>> Rudy Velthuis doesn't know what he is talking about. Consumers work
>>>>> fine with derivative strings;
>>>>
>>>> Rudy Velthuis does know what he is talking about. He is just not so
>>>> familiar with current affairs in Forth yet and wonders why certain
>>>> things are done the way they are currently done, in Forth.
>>>
>>> Both stringconstants (addr n) and stringvariable (storage with
>>> first cell containing the length are useful.
>>
>> Ok, fine. But are all c-addr u combinations really supposed to be
>> constants, or is that just how you call them?
>
>The arguments c-addr u just denote a region of memory u address units
>long. It may be in a scratch area, an input buffer, RAM, ROM, or
>anywhere. Nothing is implied about its contents or location. Any
>implications as to the nature of this region is embodied in what the
>program does with it, that is, the word processing the c-addr u stack
>arguments such as MOVE etc.
>
>>> The ease with which forth can pass around double items on the stack
>>> means that we have no need to allocate or store strings
>>> in many cases. In C that would require a struct instead of '' char
>>> *pc ''
>
>Yes the "2---" words (2DUP, 2OVER, 2SWAP, etc.) are particularly useful
>with these pairs of cells.

I find SDSWAP and DSSWAP useful for swapping a string and a cell.
If I use ROT I get always confused.

>
>Cheers,
>Elizabeth
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web