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

#57527

On Monday, April 17, 2017 at 4:18:43 PM UTC-7, Rudy Velthuis 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.
> 
> I don't quite know what you mean with "derivative strings" though. 

You don't know what you are talking about when you criticize my STRING-STACK.4TH for now using COW --- it does use COW --- that is the whole point.

A "unique" string is on the heap. A "derivative" string is a reference to another string, either a unique or a non-mutable (such as came from S").

The consumers (such as with .$ DROP$ etc.) will FREE the string afterward if it unique, but will first convert any derivatives of that string into uniques (involves calling ALLOCATE and copying the string). Whether it is unique or derivative it gets dropped from the string-stack. I have a lot of functions for searching strings, and these are all consumers.

The modifiers (such as REVERSE$ etc.) change a string. If the string is unique, they first search the string-stack for any derivatives of this string and convert them into uniques (involves calling ALLOCATE and copying the string). If the string is derivative, they first convert the string into a unique (involves calling ALLOCATE and copying the string). 

My string-concatenation function +$ was one of the most complicated functions I've written in quite some time. It was complicated because there are two parameters, and each parameter can be either unique or derivative, so there are 4 permutations of kinds of strings being concatenated. 

I have a lot of functions for extracting substrings from strings. These are not modifiers. They produce a derivative string whose address is inside of the unique string. If that unique later gets modified or consumed, they are found on the string-stack and determined to be derivatives of that string, so they get converted into uniques at that time.

The stack jugglers (such as SWAP$ ROT$ etc.) just move around the items on the string-stack without concern as to them being unique or derivative. The duplicators (such as DUP$ OVER$ etc.) made a derivative string (doesn't matter if the string being duplicated was a unique or a derivative).

Notice that when DUP$ OVER$ etc. are used, you end up with a derivative on the stack and the unique that it is derived from underneath. This is a good thing! If you then consume that string, it is very efficient, because consuming a derivative is efficient (no need to mess with the heap). Here is an example:

empty$  ok
s" abcdefgh" >$  dup$ .$ abcdefgh ok
.s$ 
STRING STACK:
derivative: |abcdefgh| ok

The DUP$ just made a derivative, and then .$ consumed it. The original string (which was a derivative of the non-mutable S" string given to >$) is still on the stack.

Here is another example:

empty$  ok
s" abcdefgh" >$  s" FGH" >$ isuffix$  ok-1 
. -1  ok
.s$ 
STRING STACK:
derivative: |fgh|
derivative: |abcdefgh| ok

The top value of the string-stack (the |fgh| string) is a derivative of the second value of the string-stack (the |abcdefgh| string) --- it is inside of that string that it is derived from.

Here is another example (this one useful enough that I made it into a function and put it in the package):

: maybe-extract$ ( -- extracted? )                              \ string: a b -- str        \ extract B from A if possible
    2dup$ swap$ find$  dup -1 = if  drop  drop$  false exit then                            \ drop the -1, DROP$ B and return A with a false flag
    len$ anti-mid$ 
    true ;

\ MAYBE-EXTRACT returns TRUE if it could extract B from A, and it returns STR which is A with B extracted from it.
\ If it couldn't, then it returns FALSE and it returns STR as A unchanged.

Here is a test:

empty$  ok
s" abcdefgh" >$  s" DEF" >$ maybe-extract$  ok-1 
. -1  ok
.s$ 
STRING STACK:
unique:     |abcgh| ok
empty$  ok
s" abcdefgh" >$  s" XYZ" >$ maybe-extract$  ok-1 
. 0  ok
.s$ 
STRING STACK:
derivative: |abcdefgh| ok

Note that here, when we find the string and extract it, the new string is a unique because it has been modified (it had the substring extracted from it).

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

Most Forth code is crap.

Every time that I write any ANS-Forth code, I help to kill ANS-Forth. This STRING-STACK.4TH is a typical example. By writing it I induced Anton Ertl to step forward and defend Elizabeth Rather's idiotic scheme of holding strings in global variables (the <# #> pad, the S" pad, and PAD) --- he makes himself look like an idiot by doing this --- it is obvious that he does this because Elizabeth Rather appointed him to the Forth-200x committee and he is obliged to defend all of her design decisions in ANS-Forth, not matter how idiotic.

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

#57609

hughaguilar96@gmail.com wrote:

> > > 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. 
> 
> You don't know what you are talking about when you criticize my
> STRING-STACK.4TH for now using COW

I haven't criticized your file, because I haven't even seen it (nor do
I care a lot about it, at the moment).

I merely reacted to your claim that: 

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

That is indeed nonsense. If you do it right, you only copy it once.

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

"Contraction of theological influence has at once been the best
 measure, and the essential condition of intellectual advance."
 -- William H. Lecky

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

#57533

On Monday, April 17, 2017 at 1:11:22 PM UTC-7, hughag...@gmail.com wrote:
> On Monday, April 17, 2017 at 5:13:27 AM UTC-7, Anton Ertl wrote:
> > 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. 

I'm trying to kill ANS-Forth. I think STRING-STACK.4TH just by itself is capable of killing ANS-Forth. The supporters of ANS-Forth are put in the awkward position of defending the use of global variables for holding strings, which is utterly stupid. I knew that PAD was a bad idea in 1984 at the age of 18. It doesn't take a programming expert to understand this. Yet, the ANS-Forth supporters have to defend PAD because Elizabeth Rather put PAD in the ANS-Forth standard, and she continues to be highly enthusiastic about PAD over a quarter of a century later. 

Although killing ANS-Forth is a worthy goal, it is also a pretty easy goal, as ANS-Forth is almost dead. There are fewer than 20 ANS-Forth programmers in the world today, and all of them are old.

Another goal I had with writing STRING-STACK.4TH is to provide a useful tool for my program that parses Ido text. There are about 200 people in the world who speak Ido, so that is an order of magnitude more popular than ANS-Forth, which means that somebody might actually use my program. With this goal in mind, I provided some functions for extracting prefixes and suffixes from words:
---------------------------------------------------------------------------

Section 1.4.) prefixes and suffixes and infixes, oh my!

PREFIX$                     ( -- found? )                       \ string: a b -- a | c
This determines if B is a prefix of A. If PREFIX$ returns true, then it returns C which is the prefix inside of A (it is a derivative).

IPREFIX$                    ( -- found? )                       \ string: a b -- a | c
This is like PREFIX$ except case-insensitive.

SUFFIX$                     ( -- found? )                       \ string: a b -- a | c
This determines if B is a suffix of A. If SUFFIX$ returns true, then it returns C which is the suffix inside of A (it is a derivative).

ISUFFIX$                    ( -- found? )                       \ string: a b -- a | c
This is like SUFFIX$ except case-insensitive.

INFIX$                      ( -- found? )                       \ string: a b -- a | c
This determines if B is an infix of A. If INFIX$ returns true, then it returns C which is the infix inside of A (it is a derivative).

IINFIX$                     ( -- found? )                       \ string: a b -- a | c
This is like INFIX$ except case-insensitive.

EXTRACT$                    ( -- )                              \ string: a b -- c d
This requires B to be a derivative inside of A (it is also okay for B to be an empty unique). EXTRACT$ removes the B string from the A string and returns the prefix (the C string) and the suffix (the D string). This should only be used on the results returned by: INFIX$ PREFIX$ SUFFIX$ IINFIX$ IPREFIX$ or ISUFFIX$

Note that EXTRACT$ is the only function we have that requires the parameters to be derived one from the other. All of our other functions work on either unique or derivative strings. EXTRACT$ is context-sensitive, in that it is supposed to be used after certain other functions. See also ANTIMID$ that uses EXTRACT$ internally.

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

#57545

On 4/18/2017 08:10, hughaguilar96@gmail.com wrote:
> I'm trying to kill ANS-Forth. I think STRING-STACK.4TH just by itself is capable of killing ANS-Forth.

Snort.

-- 
Alex

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

#57557

On Tuesday, April 18, 2017 at 5:48:15 AM UTC-7, Alex wrote:
> On 4/18/2017 08:10, hughaguilar96@gmail.com wrote:
> > I'm trying to kill ANS-Forth. I think STRING-STACK.4TH just by itself is capable of killing ANS-Forth.
> 
> Snort.
> 
> -- 
> Alex

Please tell us more about how your leading expert's PAD is superior to my STRING-STACK.4TH package as a:
"transient region that can be used to hold data for intermediate processing."

Try to be more articulate --- rather that just saying "snort" your could say: "oink" --- that would be almost like using words!

Hee Haw!

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

#57559

On 4/18/2017 17:15, hughaguilar96@gmail.com wrote:
> On Tuesday, April 18, 2017 at 5:48:15 AM UTC-7, Alex wrote:
>> On 4/18/2017 08:10, hughaguilar96@gmail.com wrote:
>>> I'm trying to kill ANS-Forth. I think STRING-STACK.4TH just by
>>> itself is capable of killing ANS-Forth.
>> 
>> Snort.
>> 
>> -- Alex
> 
> Please tell us more about how your leading expert's PAD is superior
> to my STRING-STACK.4TH package as a: "transient region that can be
> used to hold data for intermediate processing."
> 

Why? I'm not making any stupid or preposterous claims, you are.

-- 
Alex

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

#57504

Anton Ertl wrote:

> >> 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 am not talking about another string *representation*. If I were to
design this, I would store strings (when there is a need to store them)
as counted strings, but with a 32 bit length. But like in other
langages, if you copy or search or do other operations on strings, you
must often also supply a length. Then you supply one or more u's.

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

"It is a miracle that curiosity survives formal education." 
 -- Albert Einstein

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

#57556

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

ANS-Forth is a cult. Being an ANS-Forth "programmer" is all about loyalty. Elizabeth Rather, the creator of ANS-Forth, has declared herself to be the "leading expert" of Forth, and she has surrounded herself with sycophants who accept this. The only interpretation of the title "leading expert" is that all Forth programmers are inferior to her in knowledge of Forth.

Like all cults, ANS-Forth is founded upon willful ignorance; knowledge is what the cult members hate and fear the most. Above we see Anton Ertl speaking out against my STRING-STACK.4TH --- most likely, he actually knows what COW (copy on write) is, but he is pretending that he is ignorant of this for the sake of the cult. Elizabeth Rather provided ANS-Forth with static buffers to hold strings (the <# #> and the S" buffer and PAD which is limited to 84 chars) because she is too dumb to know better. She says:
-----------------------------------------------------------------------
People are much too phobic about [global] variables. The cry, "They aren't 
re-entrant" simply means you have to look at the whole application and how 
it is organized.
-----------------------------------------------------------------------
This works well when the "whole application" is small enough to fit on the chalkboard that she uses in her novice class at Forth Inc. (also taught by Andrew Haley, whom she appointed to the Forth-200x committee as a reward for his loyalty). This doesn't work well when the "whole application" is non-trivial. Also, this assumes that the programmer has the source-code for the "whole application," which isn't true if code-libraries are being used.

Elizabeth Rather is an ignoramus. By this, I mean that she is not just ignorant, but she is proud of her ignorance and she refuses to learn. She is really dumber than a box of rocks! The cult members who accept Elizabeth Rather as their "leading expert" are required to accept an abysmal level of ignorance for themselves so they can stay safely below their cult member. This is why I say that STRING-STACK.4TH will kill ANS-Forth --- code like this shines a spotlight on the stupidity of ANS-Forth --- the cult members are put in the awkward position of defending PAD as being superior --- this makes them look stupid, even by the standards of cults, which are pretty low. If I just said that ANS-Forth is stupid, but didn't write any ANS-Forth code, the cult members would respond by saying that I am incapable of writing ANS-Forth code and hence have nothing to say on the subject of ANS-Forth. Of course, the cult members say this anyway (Alex McDonald has spent almost 4 years saying that my array SORT proves that I have a "serious misunderstanding of how pointers work"), but their accusations are so ridiculous that they just make themselves look foolish --- every time that I write ANS-Forth code, this makes the ANS-Forth enthusiasts look foolish, which is why there is a dearth of volunteers to be ANS-Forth enthusiasts (none under the age of 40).

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

#57561

Den tisdag 18 april 2017 kl. 18:09:36 UTC+2 skrev hughag...@gmail.com:
> 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.  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.
> 
> ANS-Forth is a cult. Being an ANS-Forth "programmer" is all about loyalty. Elizabeth Rather, the creator of ANS-Forth, has declared herself to be the "leading expert" of Forth, and she has surrounded herself with sycophants who accept this. The only interpretation of the title "leading expert" is that all Forth programmers are inferior to her in knowledge of Forth.
> 
> Like all cults, ANS-Forth is founded upon willful ignorance; knowledge is what the cult members hate and fear the most. Above we see Anton Ertl speaking out against my STRING-STACK.4TH --- most likely, he actually knows what COW (copy on write) is, but he is pretending that he is ignorant of this for the sake of the cult. Elizabeth Rather provided ANS-Forth with static buffers to hold strings (the <# #> and the S" buffer and PAD which is limited to 84 chars) because she is too dumb to know better. She says:
> -----------------------------------------------------------------------
> People are much too phobic about [global] variables. The cry, "They aren't 
> re-entrant" simply means you have to look at the whole application and how 
> it is organized.
> -----------------------------------------------------------------------
> This works well when the "whole application" is small enough to fit on the chalkboard that she uses in her novice class at Forth Inc. (also taught by Andrew Haley, whom she appointed to the Forth-200x committee as a reward for his loyalty). This doesn't work well when the "whole application" is non-trivial. Also, this assumes that the programmer has the source-code for the "whole application," which isn't true if code-libraries are being used.
> 
ANS-Forth isn't a cult, it's a standard. ANS-Forth programming isn't about loyalty, but about portability. As you very well know. Your Novice package and String-stack has nothing to do with cults or loyalty.

Against my will I have become interested in Novice package and String-stack. Surely, Novice package isn't at all for novices. It's a collection of rather smart words, most of them yours. Novis-package is a transformation from ANS-Forth to a preliminary Hugh-Forth. I wouldn't advice novices to learn Hugh-Forth if they had become interested in Forth.

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

#57467

On Sunday, April 16, 2017 at 6:50:10 AM UTC-7, Rudy Velthuis wrote:
> 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).

My STRING-STACK.4TH does use COW (copy on write). Weirdly enough, you snipped my entire description of how I use COW and showed one sentence out of context that seemed to imply that I didn't use COW. When I said that storing strings in the heap is a bad idea, I meant a dumb implementation in which every copy requires an ALLOCATE and a MOVE.

COW only works when you know that a pointer is a string, and you know how to find all strings. It is necessary to be able to find all strings because, when a unique is modified, all of the derivatives of that unique have to be converted into uniques. So, you have to be able to find all strings and test them to determine if they are derivatives, and if so if they are derivative of the unique that is about to be modified. This is easy in STRING-STACK.4TH because all the strings are on the string-stack. This is also possible in other languages because they have typed data and so strings have a tag that indicates that they are a string, and there is an internal data-structure that keeps track of all the strings in existence.

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

#57506

hughaguilar96@gmail.com wrote:

> My STRING-STACK.4TH does use COW (copy on write). Weirdly enough, you
> snipped my entire description of how I use COW and showed one
> sentence out of context that seemed to imply that I didn't use COW.

You seemed to think that storing on the heap requires a lot of copying.
No, it doesn't necessarily do that.

> COW only works when you know that a pointer is a string, and you know
> how to find all strings.

COW does not rely on that at all. That is where refcounting would come
into play.

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

"Cancel the kitchen scraps for lepers and orphans! No more
 merciful beheadings! And call off Christmas!"
 -- The Sheriff of Nottingham

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

#57918

On Monday, April 17, 2017 at 4:13:59 PM UTC-7, Rudy Velthuis wrote:
> hughaguilar96@gmail.com wrote:
> 
> > My STRING-STACK.4TH does use COW (copy on write). Weirdly enough, you
> > snipped my entire description of how I use COW and showed one
> > sentence out of context that seemed to imply that I didn't use COW.
> 
> You seemed to think that storing on the heap requires a lot of copying.
> No, it doesn't necessarily do that.

Everybody wants me to be an idiot! Who the hell is Rudy Velthuis? He just shows up out of nowhere and begins talking to me like I'm an idiot. I bring this onto myself because I write code --- the clever way to be a programming expert is to never write any code --- then your code isn't a target for criticism, and you just sit on your throne and criticize those who do write code.

The strings on the string-stack are either unique or derivative. A unique string is on the heap. A derivative is a reference to another string. I only convert a derivative into a unique when the derivative is going to get modified, or when the unique that the derivative is referencing is going to get modified.

If strings aren't getting modified, but are only getting consumed, then they don't get copied --- there is no ALLOCATE and there is no move.

My intention with STRING-STACK.4TH was to bring ANS-Forth up to the level of BASIC that I was familiar with from the 1980s. In those days, it was not necessary to worry about copying strings. I don't know if COW was used internally or not --- the concept of COW is obvious though, so I did that in STRING-STACK.4TH --- I had never heard the term COW though, which is why the term isn't in my documentation.

> > COW only works when you know that a pointer is a string, and you know
> > how to find all strings.
> 
> COW does not rely on that at all. That is where refcounting would come
> into play.

This is utter nonsense! 

You have to be able to distinguish a string, and you have to be able to find all strings. This is why I couldn't use the double-stack for strings --- if I did that, I would have other data (double-precision integers and ratios) on the double-stack along with the strings and I wouldn't be able to distinguish which data were strings (unless I tag all data, as done in Scheme etc., but I'm not going to do that). It was necessary to have a string-stack that only contains strings, so I can find all the strings. This is because, when a unique is going to get modified, I first have to find all of the derivatives of that unique and convert them into uniques. How am I going to find them unless they are all in one place? The string-stack is the one place where all strings are --- my FIX-DERIVATIVES just searches the entire string-stack for derivatives of the string that is going to be modified, and it fixes them (converts them into uniques).

It is ridiculous that this little troll is trying to educate me on the subject of COW after I've written STRING-STACK.4TH that does COW. 

He wants me to use refcounting! That is stupid! That only works with tagged data --- Scheme etc. have tagged data, but Forth does not. 

This little troll should write some Forth code and prove that he can write Forth code --- I haven't seen anything yet --- I think he is another typical ANS-Forth "programmer" who never writes any code but is just given status as a Forth expert from Elizabeth Rather in exchange for saying that she is the "leading expert" of Forth.

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

#57959

On Sunday, April 23, 2017 at 12:39:21 PM UTC-7, hughag...@gmail.com wrote:
> ...
> This little troll should write some Forth code and prove that he can
> write Forth code --- I haven't seen anything yet --- I think he is
> another typical ANS-Forth "programmer" who never writes any code but
> is just given status as a Forth expert from Elizabeth Rather in
> exchange for saying that she is the "leading expert" of Forth.

How do you know that he's little?  He might be a lot bigger than us ;-)

Mike B.

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

#58020

On Monday, April 24, 2017 at 1:25:35 AM UTC-4, Michael Barry wrote:
> On Sunday, April 23, 2017 at 12:39:21 PM UTC-7, hughag...@gmail.com wrote:
> > ...
> > This little troll should write some Forth code and prove that he can
> > write Forth code --- I haven't seen anything yet --- I think he is
> > another typical ANS-Forth "programmer" who never writes any code but
> > is just given status as a Forth expert from Elizabeth Rather in
> > exchange for saying that she is the "leading expert" of Forth.
> 
> How do you know that he's little?  He might be a lot bigger than us ;-)
> 
> Mike B.

And since Netherlands produces the tallest people in the world on average it
is highly probable.

BF

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

#58330

foxaudioresearch@gmail.com wrote:

> On Monday, April 24, 2017 at 1:25:35 AM UTC-4, Michael Barry wrote:
> > On Sunday, April 23, 2017 at 12:39:21 PM UTC-7, hughag...@gmail.com
> > wrote:
> > > ...
> > > This little troll should write some Forth code and prove that he
> > > can write Forth code --- I haven't seen anything yet --- I think
> > > he is another typical ANS-Forth "programmer" who never writes any
> > > code but is just given status as a Forth expert from Elizabeth
> > > Rather in exchange for saying that she is the "leading expert" of
> > > Forth.
> > 
> > How do you know that he's little?  He might be a lot bigger than us
> > ;-)
> > 
> > Mike B.
> 
> And since Netherlands produces the tallest people in the world on
> average it is highly probable.

I'm 1.83m. Pretty short for a Dutchman. <g>


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

"We only acknowledge small faults in order to make it appear
 that we are free from great ones." -- La Rochefoucauld

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

#57961

On 04/23/17 22:39, hughaguilar96@gmail.com wrote:

> This is utter nonsense! ... 
> He wants me to use refcounting! That is stupid! That only works with tagged data --- Scheme etc. have tagged data, but Forth does not. 

The next step up in escalation is to use ALL CAPS so people REALLY PAY
ATTENTION to your ranting!!!!!!

Just FYI, 8th uses reference-counting, very successfully.  It does,
also, use tagged data - so one always knows exactly what kind of thing
is on the stack.

You can also do something like what OForth does, e.g. play magic with
the pointers to the stack items so that the data pointer itself tells
you what kind of item is on the stack.  That is (in my opinion) a
dangerous path, but if used with restraint it works nicely.

Having a separate stack for each kind of data (float-stack, string-stack
etc) is going to make things complicated for the users of
StraightJacketForth, should the day ever arrive when it's released.

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

#57967

Ron Aaron <rambamist@gmail.com> writes:
> You can also do something like what OForth does, e.g. play magic with
> the pointers to the stack items so that the data pointer itself tells
> you what kind of item is on the stack.  That is (in my opinion) a
> dangerous path, but if used with restraint it works nicely.

If you mean Oforth uses aligned pointers and steal one or two bits for
tags, that's a very common technique and works well.  The SPARC
processor even had hardware support for that, which nobody seems to have
used.  If you mean the heap uses different regions for different object
types and figures out the type of a pointed-to object from its address,
that's another venerable technique called BIBOP ("big bag of pages")
though it was used mostly in older, smaller systems.

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

#57970

On Sunday, April 23, 2017 at 11:51:14 PM UTC-7, Paul Rubin wrote:
> Ron Aaron <rambamist@gmail.com> writes:
> > You can also do something like what OForth does, e.g. play magic with
> > the pointers to the stack items so that the data pointer itself tells
> > you what kind of item is on the stack.  That is (in my opinion) a
> > dangerous path, but if used with restraint it works nicely.
> 
> If you mean Oforth uses aligned pointers and steal one or two bits for
> tags, that's a very common technique and works well.  The SPARC
> processor even had hardware support for that, which nobody seems to have
> used.  If you mean the heap uses different regions for different object
> types and figures out the type of a pointed-to object from its address,
> that's another venerable technique called BIBOP ("big bag of pages")
> though it was used mostly in older, smaller systems.

IIRC, Oforth uses one bit that indicates either an integer or a pointer to a struct. Racket uses 3 bits and Factor uses 4 bits. I'm not going to use tagged data in Straight Forth at all. The Forth proverb is: 
"Let the dictionary do the deciding." 
The user just has to use the correct function for the data, and if he uses the wrong function then chaos will result.

I had never heard of BIBOP. That is an interesting technique. I'm not going to use it --- it is interesting though --- so, I learned something new...

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

#57971

On 04/24/17 09:51, Paul Rubin wrote:
> Ron Aaron <rambamist@gmail.com> writes:
>> You can also do something like what OForth does, e.g. play magic with
>> the pointers to the stack items so that the data pointer itself tells
>> you what kind of item is on the stack.  That is (in my opinion) a
>> dangerous path, but if used with restraint it works nicely.
> 
> If you mean Oforth uses aligned pointers and steal one or two bits for
> tags, that's a very common technique and works well. 

Yes, that's what I mean.  The danger is that you can't (reliably) rely
on pointer layout in a cross-platform manner.   So it's a dangerous
technique, IMO.

> The SPARC
> processor even had hardware support for that, which nobody seems to have
> used.  If you mean the heap uses different regions for different object
> types and figures out the type of a pointed-to object from its address,
> that's another venerable technique called BIBOP ("big bag of pages")
> though it was used mostly in older, smaller systems.

Yeah, that's not such a bad technique.  I  could have used it in 8th
when I used discrete preallocated pools (though it would have been more
time-expensive than just looking at the item's "tag").

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

#57972

Ron Aaron wrote:
> Paul Rubin wrote:
>> Oforth uses aligned pointers and steal one or two bits for tags,
>> that's a very common technique and works well.
>
> Yes, that's what I mean.  The danger is that you can't (reliably) rely
> on pointer layout in a cross-platform manner.  So it's a dangerous
> technique, IMO.

If you write your implementation in a high-level language such as C, you
can't rely on the internal pointer representation if you want to be
portable to all present, past, and future targets.  However, if you only
take into account those that are in use now and the forseeable future,
you should be quite safe assuming pointers are linear byte indexes into
memory.

From a practical standpoint, it doesn't seem that dangerous.  But sure,
if you want 100% portability, stay away from pointer tricks.

[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