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

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

string-stack.4th

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

Contents

  string-stack.4th hughaguilar96@gmail.com - 2016-03-03 21:42 -0800
    Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-03 21:54 -0800
    Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-04 18:01 -0800
      Re: string-stack.4th Mark Wills <markwills1970@gmail.com> - 2016-03-05 02:52 -0800
        Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-05 15:17 -0800
          Re: string-stack.4th foxaudioresearch@gmail.com - 2016-03-06 08:50 -0800
            Re: string-stack.4th foxaudioresearch@gmail.com - 2016-03-06 10:54 -0800
              Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-06 14:08 -0800
                Re: string-stack.4th "HAA" <someone@microsoft.com> - 2016-03-07 10:30 +1100
                  Re: string-stack.4th foxaudioresearch@gmail.com - 2016-03-06 16:45 -0800
                    Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-06 19:09 -0800
                      Re: string-stack.4th Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-07 12:27 +0000
                        Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-07 22:44 -0800
                          Re: string-stack.4th JennyB <jennybrien@googlemail.com> - 2016-03-11 03:47 -0800
                        Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-09 22:27 -0800
                          Re: string-stack.4th Coos Haak <chforth@hccnet.nl> - 2016-03-10 11:05 +0100
                            Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-10 09:28 -0800
                              Re: string-stack.4th Coos Haak <chforth@hccnet.nl> - 2016-03-11 00:10 +0100
                                Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-10 22:42 -0800
                                  Re: string-stack.4th Coos Haak <chforth@hccnet.nl> - 2016-03-11 12:29 +0100
                                    Re: string-stack.4th JennyB <jennybrien@googlemail.com> - 2016-03-12 01:33 -0800
                                      Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-12 16:56 -0800
                            Re: string-stack.4th "WJ" <w_a_x_man@yahoo.com> - 2016-04-22 09:55 +0000
                            Re: string-stack.4th "WJ" <w_a_x_man@yahoo.com> - 2016-04-22 10:00 +0000
                          Re: string-stack.4th "WJ" <w_a_x_man@yahoo.com> - 2016-03-11 06:24 +0000
                        Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-21 23:26 -0700
                      Re: string-stack.4th franck.bensusan@gmail.com - 2016-03-10 10:42 -0800
                        Re: string-stack.4th hughaguilar96@gmail.com - 2016-03-10 23:00 -0800
                          Re: string-stack.4th hughaguilar96@gmail.com - 2016-04-10 20:23 -0700
                            Re: string-stack.4th stephen@mpeforth.com (Stephen Pelc) - 2016-04-11 09:45 +0000
                              Re: string-stack.4th hughaguilar96@gmail.com - 2016-04-11 20:00 -0700
                            Re: string-stack.4th Mark Wills <markwills1970@gmail.com> - 2016-04-11 03:16 -0700
                              Re: string-stack.4th Mark Wills <markwills1970@gmail.com> - 2016-04-11 03:47 -0700
                              Re: string-stack.4th Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-11 05:50 -0500
                                Re: string-stack.4th Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-04-11 04:21 -0700
                                  Re: string-stack.4th Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-04-11 06:36 -0500
                                  Re: string-stack.4th hughaguilar96@gmail.com - 2016-04-11 20:34 -0700
                                Re: string-stack.4th hughaguilar96@gmail.com - 2016-04-11 20:20 -0700
                            Re: string-stack.4th hughaguilar96@gmail.com - 2016-06-03 05:53 -0700
                Re: string-stack.4th Mark Wills <markwills1970@gmail.com> - 2016-03-08 11:29 -0800

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

#45981

On Friday, 11 March 2016 11:29:18 UTC, Coos Haak  wrote:
> Op Thu, 10 Mar 2016 22:42:09 -0800 (PST) schreef hughaguilar96@gmail.com:
> 
> > On Thursday, March 10, 2016 at 4:10:41 PM UTC-7, Coos Haak wrote:
> >> Op Thu, 10 Mar 2016 09:28:02 -0800 (PST) schreef hughaguilar96@gmail.com:
> >> 
> >> <snip>
> >>> Where is this SPLIT-TEXT defined? Some code-library?
> >> 
> >> Straight high level, standard code:
> >> 
> >>: SPLIT-TEXT    ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 c-addr1 u4 )
> >>         >r >r 2dup r> r@ search
> >>         if      r> over >r /string 2swap r> -
> >>         else    2drop "" 2swap rdrop
> >>         then
> >>     ;
> >> 
> >> Where "" could be defined as : "" 0 0 ;
> > 
> > The problem I notice immediately is that c-addr3 points to inside of a memory-block on the heap --- if you use FREE on this, it will fail --- how do you keep track of which strings can be given to FREE and which can not?
> 
> No problem, I can type the string or concatenate two strings.
> 
> do-debug  ok
> ( ) "foo:=bar" ":=" split-text  ok
> ( "bar" "foo" ) ":=" strcat  ok
> ( "bar" "foo:=" ) 2swap  ok
> ( "foo:=" "bar" ) strcat  ok
> ( "foo:=bar" ) type foo:=bar ok
> The strings live in a circular heap.
> strcat ensures (by strdup) that the first string is placed at the end
> of the string pointer so it can add the second to its end.
> This also works for strings outside the heap e.g. in colon definitions.
> It speaks for itself that the length of the strings is on the
> stack, not between the strings like the old counted strings.
> 
> groet Coos

That is very neat! Just one big circular buffer, and hardly any memory management overhead. I presume that with strcat you can do the following optimisations:

   If str1 is at the string pointer, append str2 and bump the pointer.
   If str2 is at the string pointer, and str1 is directly below it
   (easily checked by simple arithmetic) do NIP +

It should be easy to maintain more than one buffer if you need to cope with growing multiple strings simultaneously.

Another thought:

  Instead of having negative counts represent 'derived strings' they could represent 'braids' - strings of addr count pairs that may themselves represent either strings or other braids.  

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

#46021

On Saturday, March 12, 2016 at 2:33:05 AM UTC-7, JennyB wrote:
> On Friday, 11 March 2016 11:29:18 UTC, Coos Haak  wrote:
> > Op Thu, 10 Mar 2016 22:42:09 -0800 (PST) schreef hughaguilar96@gmail.com:
> > 
> > > On Thursday, March 10, 2016 at 4:10:41 PM UTC-7, Coos Haak wrote:
> > >> Op Thu, 10 Mar 2016 09:28:02 -0800 (PST) schreef hughaguilar96@gmail.com:
> > >> 
> > >> <snip>
> > >>> Where is this SPLIT-TEXT defined? Some code-library?
> > >> 
> > >> Straight high level, standard code:
> > >> 
> > >>: SPLIT-TEXT    ( c-addr1 u1 c-addr2 u2 -- c-addr3 u3 c-addr1 u4 )
> > >>         >r >r 2dup r> r@ search
> > >>         if      r> over >r /string 2swap r> -
> > >>         else    2drop "" 2swap rdrop
> > >>         then
> > >>     ;
> > >> 
> > >> Where "" could be defined as : "" 0 0 ;
> > > 
> > > The problem I notice immediately is that c-addr3 points to inside of a memory-block on the heap --- if you use FREE on this, it will fail --- how do you keep track of which strings can be given to FREE and which can not?
> > 
> > No problem, I can type the string or concatenate two strings.
> > 
> > do-debug  ok
> > ( ) "foo:=bar" ":=" split-text  ok
> > ( "bar" "foo" ) ":=" strcat  ok
> > ( "bar" "foo:=" ) 2swap  ok
> > ( "foo:=" "bar" ) strcat  ok
> > ( "foo:=bar" ) type foo:=bar ok
> > The strings live in a circular heap.
> > strcat ensures (by strdup) that the first string is placed at the end
> > of the string pointer so it can add the second to its end.
> > This also works for strings outside the heap e.g. in colon definitions.
> > It speaks for itself that the length of the strings is on the
> > stack, not between the strings like the old counted strings.
> > 
> > groet Coos
> 
> That is very neat! Just one big circular buffer, and hardly any memory management overhead. I presume that with strcat you can do the following optimisations:
> 
>    If str1 is at the string pointer, append str2 and bump the pointer.
>    If str2 is at the string pointer, and str1 is directly below it
>    (easily checked by simple arithmetic) do NIP +
> 
> It should be easy to maintain more than one buffer if you need to cope with growing multiple strings simultaneously.

I already have a circular buffer in the novice package, but I don't like it. It is deprecated now that I have this string-stack.4th package (although I still use it in string-stack.4th for SPLITS$).

A problem with the buffer is that it doesn't handle gigantic strings. Also, the strings have limited lifespan before the buffer wraps around and they get over-written, but there is no way to ensure that this doesn't happen.

I like my string-stack.4th --- I'm going with it for any string-handling software in the future.
 
> Another thought:
> 
>   Instead of having negative counts represent 'derived strings' they could represent 'braids' - strings of addr count pairs that may themselves represent either strings or other braids.

Well, my derivative string can be derived from a unique or from another derivative string --- so it is a "braid" already.

s" abcdefgh" >$  ok
dup$ 2 3 mid$  ok
dup$ 1 1 mid$  ok
.s$ 
STRING STACK:
derivative: |d|
derivative: |cde|
unique:     |abcdefgh| ok
third$ 2@  second$ 2@  first$ 2@  .s 
DATA STACK
     top
             -1 FFFF:FFFF
       67356647 0403:C7E7
             -3 FFFF:FFFD
       67356646 0403:C7E6
              8 0000:0008
       67356644 0403:C7E4
 ok-6 

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

#46710

Coos Haak wrote:

> Using strings on a heap, not a stack:
> 
> want split-text  ok
> "foo:=bar"  ok
> ":="  ok
> split-text  ok
> type foo ok
> type bar ok

#load "str.cma";;

",  foo  :=   bar,  and more,   the end"
|> Str.split (Str.regexp ", +\\| *:= *") ;;

 ===>
["foo"; "bar"; "and more"; "the end"]

-- 
"A Jew always has a much higher soul than a gentile, even if he is a
homosexual," he [Israel's Deputy Defense Minister Eli Ben-Dahan] said.
theoccidentalobserver.net/2015/10/israeli-minister-latest-in-long-line-of-jews-asserting-the-inferiority-of-non-jews

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

#46711

Coos Haak wrote:

> Using strings on a heap, not a stack:
> 
> want split-text  ok
> "foo:=bar"  ok
> ":="  ok
> split-text  ok
> type foo ok
> type bar ok

OCaml:

#load "str.cma";;

",  foo  :=   bar,  and more,   the end"
|> Str.split (Str.regexp ", +\\| *:= *") ;;

 ===>
["foo"; "bar"; "and more"; "the end"]

-- 
"A Jew always has a much higher soul than a gentile, even if he is a
homosexual," he [Israel's Deputy Defense Minister Eli Ben-Dahan] said.
theoccidentalobserver.net/2015/10/israeli-minister-latest-in-long-line-of-jews-asserting-the-inferiority-of-non-jews

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

#45968

hughaguilar96@gmail.com wrote:

> In the meantime, I upgraded the capability of string-stack.4th
> a bit. I can do this now:
> 
> s" foo:=bar" >$  ok
> s" :=" >$ infix$ . -1  ok
> extract$  ok
> .$ bar ok
> .$ foo ok
> 
> INFIX$ returns a flag indicating if it found the pattern in
> the string. The dot gave me -1 (TRUE) so I then used EXTRACT$
> to remove the infix and return the prefix and suffix that were
> surrounding the infix. So, I parsed a little bit of Pascal
> code there (in Pascal, := is an assignment).

Don't forget that ":=" can be surrounded by whitespace.

Ruby:

" foo  :=    bar ".split(":=").map(&:strip)
 ===>
["foo", "bar"]


OCaml:

#load "str.cma";;

List.map String.trim (Str.split (Str.regexp ":=") " foo  :=    bar ") ;;
 ===>
["foo"; "bar"]

If you want a considerable amount of string-manipulation power,
you'll have to implement a regular-expression engine.

Example: find each integer in a string and increment it.

Ruby:

"9, 10, 11 I see, now that 1983 has come and gone".
gsub(/\d+/){|s| s.to_i + 1}
 ===>
"10, 11, 12 I see, now that 1984 has come and gone"

OCaml:

#load "str.cma";;

Str.global_substitute (Str.regexp "[0-9]+")
  (fun s -> string_of_int ((int_of_string (Str.matched_string s)) + 1))
  "9, 10, 11 I see, now that 1983 has come and gone";;
 ===>
"10, 11, 12 I see, now that 1984 has come and gone"


Instead of splitting a string, shatter it.  In other words,
keep the separating strings instead of discarding them.

Ruby:

"foo := bar; write 8*9; end".split(/([^\w]+)/)
 ===>
["foo", " := ", "bar", "; ", "write", " ", "8", "*", "9", "; ", "end"]


OCaml:

#load "str.cma";;
open Str;;

Str.full_split (Str.regexp "[^a-z0-9]+") "foo := bar; write 8*9; end" ;;
 ===>
[Text "foo"; Delim " := "; Text "bar"; Delim "; "; Text "write"; Delim " ";
 Text "8"; Delim "*"; Text "9"; Delim "; "; Text "end"]

-- 
From the New York Times of October 11, 1991, ... we learn that ... researchers
at Boston University admitted that, "There is no question but that Dr. King
plagiarized in the dissertation." ... "Dr. Martin Luther King, Jr." [Michael
King] spent his last night on Earth having sexual intercourse with two women at
the motel and physically beating and abusing a third.  --  K. A. Strom

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

#46156

On Monday, March 7, 2016 at 5:27:32 AM UTC-7, Albert van der Horst wrote:
> hughaguilar96@gmail.com writes:
> >BTW: My ultimate goal with all of this is to write a program that can trans=
> >late Esperanto into English or Spanish or whatever. I thought of this way b=
> >ack in 1984 when I was learning Esperanto. It is too difficult for a progra=
> >m to translate directly from Spanish to English or vice-versa because those=
> > language are difficult to figure out (this was true 30 years ago and is st=
> >ill true). By making the human write in Esperanto however, most of the work=
> > can be dumped on the human. Translating from Esperanto to English or Spani=
> >sh should be possible. All the Esperanto words have a suffix that tells you=
> > exactly what part of speech they are. In string-stack.4th I have functions=
> > for working with prefixes and suffixes that I provided specifically for ta=
> >king apart Esperanto words. The idea is that the front-end of the program b=
> >uilds a lexical tree for the Esperanto sentence. There would be a back-end =
> >of the program specific to each output language that converts the lexical t=
> >ree into English, Spanish, etc..
> 
> That is interesting. A collegue of mine Toon Witkam had this idea of translating
> into Esperanto to disambiguate natural language. It turned into a project
> for the EU and earned him a doctorate, later he became professor.
> The EU didn't really like it too much, at the time it was slow (80's),
> but mostly they didn't want too clear language in their treatises.
> That was a multi-manyear project. I don't see you pull off a similar project
> without a team.

I'm switching from Esperanto to Ido. These are some reasons:
1.) Ido doesn't have any diacritical marks like Esperanto, so it can be ASCII.
2.) Ido is not sexist like Esperanto or English. It is possible to use pan-gender words to avoid implying gender.
3.) The Ido words seem to be borrowed from more common languages than in Esperanto, so they are easier to learn --- Esperanto borrowed from too many languages in an effort to please everybody, but a lot of those words are just obscure (I don't even know what language they come from) and are hard to remember.
3.) Ido word-roots have only one meaning, so there is no ambiguity. It is never necessary to figure out the meaning of a word from the context. This is really the most important feature!

I think that, using string-stack.4th, I can take apart the words' prefixes and suffixes to obtain the word-root. I can also make a lexical-tree out of the sentence and determine if the sentence is grammatically legal. All of this can be done without knowing what the words mean. This would be the front-end for the program.

The back-end would convert the lexical-tree into some natural language such as English or Spanish. This is going to require a big dictionary. Putting this together would likely require a team as there are tens of thousands of words. Also, every target language needs a team who know that language (I only know English).

Anyway, the front-end for the program is something that I should be able to write.

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

#45964

Le lundi 7 mars 2016 04:09:14 UTC+1, hughag...@gmail.com a écrit :
 
> 1.) JUGGLERS --- These include SWAP$ etc. and they just move items around on the string-stack.
> 
> 2.) DUPLICATORS --- These include DUP$ etc. and they make a derivative item.
> 
> 3.) CONSUMERS --- These include .$ etc. and they consume an item. If the item is a derivative it is just dropped. If the item is a unique, then FIX-DERIVATIVES is called first (this searches the string-stack for derivatives that are inside of this unique and changes them into uniques) and then it is dropped.
> 
> 4.) MUTATORS --- These include UCASE$ etc. and they modify an item. If the item is a derivative it gets changed into a unique first, and if the item is a unique then FIX-DERIVATIVES gets called first, then the item is modified.
> 

This is an interesting memory management. I wonder how this compare to 
a memory management using a garbage collector.

Did you run some benchmark tests ?

Franck

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

#45972

On Thursday, March 10, 2016 at 11:42:43 AM UTC-7, franck....@gmail.com wrote:
> Le lundi 7 mars 2016 04:09:14 UTC+1, hughag...@gmail.com a écrit :
>  
> > 1.) JUGGLERS --- These include SWAP$ etc. and they just move items around on the string-stack.
> > 
> > 2.) DUPLICATORS --- These include DUP$ etc. and they make a derivative item.
> > 
> > 3.) CONSUMERS --- These include .$ etc. and they consume an item. If the item is a derivative it is just dropped. If the item is a unique, then FIX-DERIVATIVES is called first (this searches the string-stack for derivatives that are inside of this unique and changes them into uniques) and then it is dropped.
> > 
> > 4.) MUTATORS --- These include UCASE$ etc. and they modify an item. If the item is a derivative it gets changed into a unique first, and if the item is a unique then FIX-DERIVATIVES gets called first, then the item is modified.
> > 
> 
> This is an interesting memory management. I wonder how this compare to 
> a memory management using a garbage collector.
> 
> Did you run some benchmark tests ?
> 
> Franck

Here is some code run using .S$ to show the string-stack throughout:

s" foo:=bar" >$ dup$  ok
.s$ 
STRING STACK:
derivative: |foo:=bar|
unique:     |foo:=bar| ok
s" :=" >$ infix$ . -1  ok
.s$ 
STRING STACK:
derivative: |:=|
derivative: |foo:=bar|
unique:     |foo:=bar| ok
extract$  ok
.s$ 
STRING STACK:
derivative: |bar|
derivative: |foo|
unique:     |foo:=bar| ok
third$ 2@  second$ 2@  first$ 2@  .s 
DATA STACK
     top
             -3 FFFF:FFFD
       67355897 0403:C4F9
             -3 FFFF:FFFD
       67355892 0403:C4F4
              8 0000:0008
       67355892 0403:C4F4
 ok-6 

Notice that only the original string s" foo:=bar" is put on the heap (also the pattern string s" :=" but it is freed by INFIX$). The |:=| string returned by INFIX$ is not the pattern string given to it, but instead is a derivative string inside of the original string. All the way to the very end, nothing is getting put on the heap, but everything that I'm working with are derivative strings.

At the very end I show what the three strings are, and only the original string is a unique, but the other two strings (the prefix and suffix) are derivatives. I expect that this is faster than a system in which every string is put on the heap and then freed later, and significantly faster than a system in which every string is put on the heap and then GC'd later --- I'm just manipulating adr/cnt pairs and not messing with the heap at all --- that has got to be fast!

If I do need to convert a derivative into a unique however, this gets done automatically. Here is some more code:

3drop 3drop  ok
ucase$  ok
.s$ 
STRING STACK:
unique:     |BAR|
derivative: |foo|
unique:     |foo:=bar| ok
third$ 2@  second$ 2@  first$ 2@  .s 
DATA STACK
     top
              3 0000:0003
       67355916 0403:C50C
             -3 FFFF:FFFD
       67355892 0403:C4F4
              8 0000:0008
       67355892 0403:C4F4
 ok-6 

UCASE$ is a mutator, which means that if it is given a derivative (as in this case) it converts it into a unique before mutating it --- if it is given a unique it calls FIX-DERIVATIVES to fix any derivatives of the string that may be on the string-stack before mutating it --- so, I avoid messing with the heap as much as possible, but when it is necessary then it is done automatically.

Anyway --- no --- I haven't run any benchmark tests. For one thing, I'm not familiar enough with oForth to write the oForth code --- also, it depends upon which ANS-Forth compiler is used (VFX generates pretty fast code, but SwiftForth generates abysmally bloated and slow code), so a benchmark against oForth tests the compiler more than the algorithm.

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

#46614

On Friday, March 11, 2016 at 12:00:08 AM UTC-7, hughag...@gmail.com wrote:
> Here is some code run using .S$ to show the string-stack throughout:
> 
> s" foo:=bar" >$ dup$  ok
> .s$ 
> STRING STACK:
> derivative: |foo:=bar|
> unique:     |foo:=bar| ok
> s" :=" >$ infix$ . -1  ok
> .s$ 
> STRING STACK:
> derivative: |:=|
> derivative: |foo:=bar|
> unique:     |foo:=bar| ok
> extract$  ok
> .s$ 
> STRING STACK:
> derivative: |bar|
> derivative: |foo|
> unique:     |foo:=bar| ok
> third$ 2@  second$ 2@  first$ 2@  .s 
> DATA STACK
>      top
>              -3 FFFF:FFFD
>        67355897 0403:C4F9
>              -3 FFFF:FFFD
>        67355892 0403:C4F4
>               8 0000:0008
>        67355892 0403:C4F4
>  ok-6 
> 
> Notice that only the original string s" foo:=bar" is put on the heap (also the pattern string s" :=" but it is freed by INFIX$). The |:=| string returned by INFIX$ is not the pattern string given to it, but instead is a derivative string inside of the original string. All the way to the very end, nothing is getting put on the heap, but everything that I'm working with are derivative strings.
> 
> At the very end I show what the three strings are, and only the original string is a unique, but the other two strings (the prefix and suffix) are derivatives. I expect that this is faster than a system in which every string is put on the heap and then freed later, and significantly faster than a system in which every string is put on the heap and then GC'd later --- I'm just manipulating adr/cnt pairs and not messing with the heap at all --- that has got to be fast!

I made a substantial improvement to the efficiency of the system. It was pretty simple: I made >$ to require that it be given a constant string (typically a S" string) and I made it create a derivative rather than a unique on the string-stack. So it is possible now to have derivatives on the string-stack that are not derived from any unique on the string-stack but are instead derived from a constant string in the dictionary. Now, in many cases, I don't have to put any string on the heap. Of course, this is still done automatically when necessary (by the mutators). Here is that code again with the new system:

s" foo:=bar" >$ dup$  ok
.s$ 
STRING STACK:
derivative: |foo:=bar|
derivative: |foo:=bar| ok
s" :=" >$ infix$ . -1  ok
.s$ 
STRING STACK:
derivative: |:=|
derivative: |foo:=bar|
derivative: |foo:=bar| ok
extract$  ok
.s$ 
STRING STACK:
derivative: |bar|
derivative: |foo|
derivative: |foo:=bar| ok
third$ 2@ second$ 2@ first$ 2@ .s 
DATA STACK
     top
             -3 FFFF:FFFD
        5050918 004D:1226
             -3 FFFF:FFFD
        5050913 004D:1221
             -8 FFFF:FFF8
        5050913 004D:1221
 ok-6 

I was reading about Stephen Pelc's BNF interpreter that is in VFX. It looks pretty interesting. I notice that his code is not ANS-Forth however.

: || IF R> DROP 1 THEN ;

This is obviously illegal in ANS-Forth. Section 3.2.3.3. says: 
A program shall not access values on the return stack (using R@, R>, 2R@ or 2R>) that it did not place there using >R or 2>R;

Pelc should have written this:

macro: ||  if 1 exit then ;

Or, for improved readability:

macro: ||  ( flag -- true | )  \ exits the parent function on a true flag
    dup if  exit then          \ if the flag is true, exit and return the flag
    drop ;                     \ if the flag is false, drop the flag and keep going

MACRO: is in the novice-package and, like everything in the novice-package, it is ANS-Forth. 

Also, I don't know why he is using 1 rather than -1 for true, but that doesn't matter very much.

My string-stack is a stack, so it supports recursive functions. I think my string-stack.4th can do everything that Pelc's BNF interpreter can do, although I don't have the BNF-like appearance which might be useful to somebody who is working from a language-specification that is in BNF.

The most important point is that my string-stack.4th is written in ANS-Forth whereas Pelc's BNF interpreter is written in VFX-specific code that will trap the user in vendor lock-in. Also, my string-stack.4th is available for free. Pelc's BNF interpreter is described in the manual, but doesn't seem to be available in the evaluation version of VFX, so you have to spend money to get it --- and I doubt that you get the source-code even if you do spend the money.

Has anybody ever written a traditional-language interpreter in Forth, either using Pelc's BNF interpreter or writing it manually?

I'm not much interested in writing a traditional-language interpreter in Forth. I know that Ching has his ABC (Advanced BASIC Compiler) written in Forth, and he likes it. I really just program in Forth myself. It is somewhat useful though to have BASIC or some other well-known language available for users who don't want to program in Forth.

I'm planning on using string-stack.4th primarily for interpreting human-language text, especially Ido.

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

#46617

On Sun, 10 Apr 2016 20:23:27 -0700 (PDT), hughaguilar96@gmail.com
wrote:

>I was reading about Stephen Pelc's BNF interpreter that is in VFX. It looks=
> pretty interesting.

The world's greatest and only Forth programmer was probably trying to
read the VFX Forth manual. Just to avoid confusion here's an
extract from the VFX Forth manual:

"This article first appeared in ACM SigFORTH Newsletter vol. 2 no. 2.
Since then the code has been updated from the original by staff at
MPE, and this documentation has been derived from the article supplied
by Brad Rodriguez, whose original implementation is a model of Forth
programming."

> Pelc's BNF interpreter is described in the manual, but doesn't seem =
>to be available in the evaluation version of VFX, so you have to spend mone=
>y to get it --- and I doubt that you get the source-code even if you do spe=
>nd the money.
>
>Has anybody ever written a traditional-language interpreter in Forth, eithe=
>r using Pelc's BNF interpreter or writing it manually?

The world's greatest and only Forth programmer appears not be able to
read. Try
  whereis ::=
in the console of the Eval version. The resource compiler supplied
with VFX Forths for Windows makes heavy use of the BNF parser.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#46635

On Monday, April 11, 2016 at 2:45:16 AM UTC-7, Stephen Pelc wrote:
> The world's greatest and only Forth programmer appears not be able to
> read. Try
>   whereis ::=
> in the console of the Eval version. The resource compiler supplied
> with VFX Forths for Windows makes heavy use of the BNF parser.

I did this:
whereis <BNF

I was told that it wasn't there, so I didn't bother looking any further

Now, reading your post, I did this:
whereis ::= 
File: %VFXPATH%\VFXBase\BNF.fth, line 747  ok

Unfortunately, there is no BNF.fth file provided with the evaluation version. Maybe if I paid you for the pro version I would get the BNF.fth file, but maybe not as there is no guarantee made on this anywhere.

I'm not realistically going to use your BNF stuff if I don't have the source-code. You documented <BNF and BNF> but they aren't available, so that was misleading. Also, your documentation is very vague. Here is an example:
------------------------------------------------------------------------
::= name starts the definition of the BNF production name.
;; ends a BNF definition.
------------------------------------------------------------------------

That doesn't really tell me anything about what they do. You aren't providing a stack-picture for your words or really giving me any information at all.

You are assuming that I am a "user" who is going to use this code without understanding how it works. You are also assuming that I am a "client" who is okay with vendor lock-in to VFX.

If you aren't going to provide the BNF.fth file and/or if it is not written in ANS-Forth (I'll bet it is not!), then I have no interest in using your BNF stuff --- I already said that my string-stack.4th can do everything that is needed --- so I recommend that everybody just ignore your BNF stuff and use string-stack.4th to get "commercial level string handling."

Earlier, we had this exchange:

On Saturday, March 5, 2016 at 4:22:03 AM UTC-7, Stephen Pelc wrote: 
> On Fri, 4 Mar 2016 15:07:29 -0800 (PST), hughaguilar96@gmail.com 
> wrote: 
> 
> > Stephen Pelc says: "For practical applications, all Forth standards to 
> > date have been inadequate for commercial level string handling." 
> 
> Yes, I said that 
> 
> > Oh nooooooo! A Forth-200x committee member says= 
> > that Forth can't be used for "practical applications" involving "commercia= 
> >l level string handling" 
> 
> No, I did not say that. The solution in Forth, as you well know, is to 
> expand the base Forth system to have a commercial-level string 
> handling package. That's what several of our clients have done. 

Your use of the word "clients" implies that you believe only your clients ($$$) deserve to get "commercial level string handling" --- that is not true --- Forthers can avoid paying you any money at all by simply ignoring your closed-source BNF stuff and using my open-source string-stack.4th.

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

#46618

On Monday, 11 April 2016 04:23:29 UTC+1, hughag...@gmail.com  wrote:
> On Friday, March 11, 2016 at 12:00:08 AM UTC-7, hughag...@gmail.com wrote:
> > Here is some code run using .S$ to show the string-stack throughout:
> > 
> > s" foo:=bar" >$ dup$  ok
> > .s$ 
> > STRING STACK:
> > derivative: |foo:=bar|
> > unique:     |foo:=bar| ok
> > s" :=" >$ infix$ . -1  ok
> > .s$ 
> > STRING STACK:
> > derivative: |:=|
> > derivative: |foo:=bar|
> > unique:     |foo:=bar| ok
> > extract$  ok
> > .s$ 
> > STRING STACK:
> > derivative: |bar|
> > derivative: |foo|
> > unique:     |foo:=bar| ok
> > third$ 2@  second$ 2@  first$ 2@  .s 
> > DATA STACK
> >      top
> >              -3 FFFF:FFFD
> >        67355897 0403:C4F9
> >              -3 FFFF:FFFD
> >        67355892 0403:C4F4
> >               8 0000:0008
> >        67355892 0403:C4F4
> >  ok-6 
> > 
> > Notice that only the original string s" foo:=bar" is put on the heap (also the pattern string s" :=" but it is freed by INFIX$). The |:=| string returned by INFIX$ is not the pattern string given to it, but instead is a derivative string inside of the original string. All the way to the very end, nothing is getting put on the heap, but everything that I'm working with are derivative strings.
> > 
> > At the very end I show what the three strings are, and only the original string is a unique, but the other two strings (the prefix and suffix) are derivatives. I expect that this is faster than a system in which every string is put on the heap and then freed later, and significantly faster than a system in which every string is put on the heap and then GC'd later --- I'm just manipulating adr/cnt pairs and not messing with the heap at all --- that has got to be fast!
> 
> I made a substantial improvement to the efficiency of the system. It was pretty simple: I made >$ to require that it be given a constant string (typically a S" string) and I made it create a derivative rather than a unique on the string-stack. So it is possible now to have derivatives on the string-stack that are not derived from any unique on the string-stack but are instead derived from a constant string in the dictionary. Now, in many cases, I don't have to put any string on the heap. Of course, this is still done automatically when necessary (by the mutators). Here is that code again with the new system:
> 
> s" foo:=bar" >$ dup$  ok
> .s$ 
> STRING STACK:
> derivative: |foo:=bar|
> derivative: |foo:=bar| ok
> s" :=" >$ infix$ . -1  ok
> .s$ 
> STRING STACK:
> derivative: |:=|
> derivative: |foo:=bar|
> derivative: |foo:=bar| ok
> extract$  ok
> .s$ 
> STRING STACK:
> derivative: |bar|
> derivative: |foo|
> derivative: |foo:=bar| ok
> third$ 2@ second$ 2@ first$ 2@ .s 
> DATA STACK
>      top
>              -3 FFFF:FFFD
>         5050918 004D:1226
>              -3 FFFF:FFFD
>         5050913 004D:1221
>              -8 FFFF:FFF8
>         5050913 004D:1221
>  ok-6 
> 
> I was reading about Stephen Pelc's BNF interpreter that is in VFX. It looks pretty interesting. I notice that his code is not ANS-Forth however.
> 
> : || IF R> DROP 1 THEN ;
> 
> This is obviously illegal in ANS-Forth. Section 3.2.3.3. says: 
> A program shall not access values on the return stack (using R@, R>, 2R@ or 2R>) that it did not place there using >R or 2>R;
> 
> Pelc should have written this:
> 
> macro: ||  if 1 exit then ;
> 
> Or, for improved readability:
> 
> macro: ||  ( flag -- true | )  \ exits the parent function on a true flag
>     dup if  exit then          \ if the flag is true, exit and return the flag
>     drop ;                     \ if the flag is false, drop the flag and keep going
> 
> MACRO: is in the novice-package and, like everything in the novice-package, it is ANS-Forth. 
> 
> Also, I don't know why he is using 1 rather than -1 for true, but that doesn't matter very much.
> 
> My string-stack is a stack, so it supports recursive functions. I think my string-stack.4th can do everything that Pelc's BNF interpreter can do, although I don't have the BNF-like appearance which might be useful to somebody who is working from a language-specification that is in BNF.
> 
> The most important point is that my string-stack.4th is written in ANS-Forth whereas Pelc's BNF interpreter is written in VFX-specific code that will trap the user in vendor lock-in. Also, my string-stack.4th is available for free. Pelc's BNF interpreter is described in the manual, but doesn't seem to be available in the evaluation version of VFX, so you have to spend money to get it --- and I doubt that you get the source-code even if you do spend the money.
> 
> Has anybody ever written a traditional-language interpreter in Forth, either using Pelc's BNF interpreter or writing it manually?
> 
> I'm not much interested in writing a traditional-language interpreter in Forth. I know that Ching has his ABC (Advanced BASIC Compiler) written in Forth, and he likes it. I really just program in Forth myself. It is somewhat useful though to have BASIC or some other well-known language available for users who don't want to program in Forth.
> 
> I'm planning on using string-stack.4th primarily for interpreting human-language text, especially Ido.

The string stack library is developing into an awesome thing! Really
good!

Re "traditional" language development: In Forth Dimensions, Volume III
issue 6, you'll find "Charles Moores BASIC Compiler Re-visited" by
Michael Perry.

In Volume VI, issue 4, you'll find a PASCAL P-Code interpreter.

You might find Volue VIII issue 6 interesting: Seven Thousand Seven 
Hundred and Seventy Six Limericks, by Nathanial Grossman. An excercise
in string manipulation.

Volume X, Issue 1: IMPROVED STRING HANDLING BY MIKE ELOLA

Volume X, Issue 3: USING A STRING STACK - RON BRAITHWAITE
Continued in Vol X, No 4.

Not related, but this looks really cool, and I'm going to read it later:
Vol XI no. 1
FORTH NEEDS THREE MORE STACKS - AYMAN ABU-MOSTAFA
Standard Forth uses the return stack for a number of disparate tasks: that
is bad programming at best, confusing and error-prone at worst. This article
suggests an aux stack for loop parameters and temporary storage. And a 
method of handling conditionals without branching allows use of conditionals
outside colon definitions; this is done with a condition stack and a case
stack.

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

#46619

On Monday, 11 April 2016 11:16:41 UTC+1, Mark Wills  wrote:
> On Monday, 11 April 2016 04:23:29 UTC+1, hughag...@gmail.com  wrote:
> > On Friday, March 11, 2016 at 12:00:08 AM UTC-7, hughag...@gmail.com wrote:
> > > Here is some code run using .S$ to show the string-stack throughout:
> > > 
> > > s" foo:=bar" >$ dup$  ok
> > > .s$ 
> > > STRING STACK:
> > > derivative: |foo:=bar|
> > > unique:     |foo:=bar| ok
> > > s" :=" >$ infix$ . -1  ok
> > > .s$ 
> > > STRING STACK:
> > > derivative: |:=|
> > > derivative: |foo:=bar|
> > > unique:     |foo:=bar| ok
> > > extract$  ok
> > > .s$ 
> > > STRING STACK:
> > > derivative: |bar|
> > > derivative: |foo|
> > > unique:     |foo:=bar| ok
> > > third$ 2@  second$ 2@  first$ 2@  .s 
> > > DATA STACK
> > >      top
> > >              -3 FFFF:FFFD
> > >        67355897 0403:C4F9
> > >              -3 FFFF:FFFD
> > >        67355892 0403:C4F4
> > >               8 0000:0008
> > >        67355892 0403:C4F4
> > >  ok-6 
> > > 
> > > Notice that only the original string s" foo:=bar" is put on the heap (also the pattern string s" :=" but it is freed by INFIX$). The |:=| string returned by INFIX$ is not the pattern string given to it, but instead is a derivative string inside of the original string. All the way to the very end, nothing is getting put on the heap, but everything that I'm working with are derivative strings.
> > > 
> > > At the very end I show what the three strings are, and only the original string is a unique, but the other two strings (the prefix and suffix) are derivatives. I expect that this is faster than a system in which every string is put on the heap and then freed later, and significantly faster than a system in which every string is put on the heap and then GC'd later --- I'm just manipulating adr/cnt pairs and not messing with the heap at all --- that has got to be fast!
> > 
> > I made a substantial improvement to the efficiency of the system. It was pretty simple: I made >$ to require that it be given a constant string (typically a S" string) and I made it create a derivative rather than a unique on the string-stack. So it is possible now to have derivatives on the string-stack that are not derived from any unique on the string-stack but are instead derived from a constant string in the dictionary. Now, in many cases, I don't have to put any string on the heap. Of course, this is still done automatically when necessary (by the mutators). Here is that code again with the new system:
> > 
> > s" foo:=bar" >$ dup$  ok
> > .s$ 
> > STRING STACK:
> > derivative: |foo:=bar|
> > derivative: |foo:=bar| ok
> > s" :=" >$ infix$ . -1  ok
> > .s$ 
> > STRING STACK:
> > derivative: |:=|
> > derivative: |foo:=bar|
> > derivative: |foo:=bar| ok
> > extract$  ok
> > .s$ 
> > STRING STACK:
> > derivative: |bar|
> > derivative: |foo|
> > derivative: |foo:=bar| ok
> > third$ 2@ second$ 2@ first$ 2@ .s 
> > DATA STACK
> >      top
> >              -3 FFFF:FFFD
> >         5050918 004D:1226
> >              -3 FFFF:FFFD
> >         5050913 004D:1221
> >              -8 FFFF:FFF8
> >         5050913 004D:1221
> >  ok-6 
> > 
> > I was reading about Stephen Pelc's BNF interpreter that is in VFX. It looks pretty interesting. I notice that his code is not ANS-Forth however.
> > 
> > : || IF R> DROP 1 THEN ;
> > 
> > This is obviously illegal in ANS-Forth. Section 3.2.3.3. says: 
> > A program shall not access values on the return stack (using R@, R>, 2R@ or 2R>) that it did not place there using >R or 2>R;
> > 
> > Pelc should have written this:
> > 
> > macro: ||  if 1 exit then ;
> > 
> > Or, for improved readability:
> > 
> > macro: ||  ( flag -- true | )  \ exits the parent function on a true flag
> >     dup if  exit then          \ if the flag is true, exit and return the flag
> >     drop ;                     \ if the flag is false, drop the flag and keep going
> > 
> > MACRO: is in the novice-package and, like everything in the novice-package, it is ANS-Forth. 
> > 
> > Also, I don't know why he is using 1 rather than -1 for true, but that doesn't matter very much.
> > 
> > My string-stack is a stack, so it supports recursive functions. I think my string-stack.4th can do everything that Pelc's BNF interpreter can do, although I don't have the BNF-like appearance which might be useful to somebody who is working from a language-specification that is in BNF.
> > 
> > The most important point is that my string-stack.4th is written in ANS-Forth whereas Pelc's BNF interpreter is written in VFX-specific code that will trap the user in vendor lock-in. Also, my string-stack.4th is available for free. Pelc's BNF interpreter is described in the manual, but doesn't seem to be available in the evaluation version of VFX, so you have to spend money to get it --- and I doubt that you get the source-code even if you do spend the money.
> > 
> > Has anybody ever written a traditional-language interpreter in Forth, either using Pelc's BNF interpreter or writing it manually?
> > 
> > I'm not much interested in writing a traditional-language interpreter in Forth. I know that Ching has his ABC (Advanced BASIC Compiler) written in Forth, and he likes it. I really just program in Forth myself. It is somewhat useful though to have BASIC or some other well-known language available for users who don't want to program in Forth.
> > 
> > I'm planning on using string-stack.4th primarily for interpreting human-language text, especially Ido.
> 
> The string stack library is developing into an awesome thing! Really
> good!
> 
> Re "traditional" language development: In Forth Dimensions, Volume III
> issue 6, you'll find "Charles Moores BASIC Compiler Re-visited" by
> Michael Perry.
> 
> In Volume VI, issue 4, you'll find a PASCAL P-Code interpreter.
> 
> You might find Volue VIII issue 6 interesting: Seven Thousand Seven 
> Hundred and Seventy Six Limericks, by Nathanial Grossman. An excercise
> in string manipulation.
> 
> Volume X, Issue 1: IMPROVED STRING HANDLING BY MIKE ELOLA
> 
> Volume X, Issue 3: USING A STRING STACK - RON BRAITHWAITE
> Continued in Vol X, No 4.
> 
> Not related, but this looks really cool, and I'm going to read it later:
> Vol XI no. 1
> FORTH NEEDS THREE MORE STACKS - AYMAN ABU-MOSTAFA
> Standard Forth uses the return stack for a number of disparate tasks: that
> is bad programming at best, confusing and error-prone at worst. This article
> suggests an aux stack for loop parameters and temporary storage. And a 
> method of handling conditionals without branching allows use of conditionals
> outside colon definitions; this is done with a condition stack and a case
> stack.

In addition, there's lots of Pascal to Forth type articles on the web
(and one in Forth Dimensions, too, but I didn't come across it when
looking through the issues):

https://www.google.co.uk/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#safe=active&q=pascal+in+forth

http://tangentstorm.github.io/winfield-pascal-83.html


More on languages in Forth:

From The Rochester Papers (JFAR Vol III)


BNF: A Parser Written in Forth
Leonard Morgenstern
BNF, named in honor of Backus and Naur, is a parser, written in Forth, capable of analyzing complex
input. Parser words can be intennixed with ordinary Forth words, so that BNF can analyze the text for
correctness and also act on it. BNF provides for parallel, series, repetition, and nulls, the latter being elements
that must or may be absent. BNF does not conform to the conventional requirement of "one symbol look-ahead
without backtracking", a feature that provides certain advantages.

An Approach to Natural Language Parsing
Jack Park
Brownsville, CA
A description of the design of an expectation-based parser is given. The parser uses a three-part structure
consisting of primitive structures, expectation procedures and heuristics, and a lexical dictionary. By use of
this structure in a Forth environment, a self-parsing vocabulary is built.


A Prolog Interpreter
C. H. Ting
San Mateo, CA
Prolog is an interesting language with simple syntax structure. It is rather straightforward to implement
it in Forth. Since most of the work in interpreting Prolog queries is in string comparison, the interpreter can
be constructed by running two pointers, one for the query string and the other for the data base. This method
thus eliminates the need to build data structures according to the data types used in Prolog. In this paper, only
relations are allowed in the data base. Both the "does" and "which" queries are implemented to use the data base.
Work to implement rules in data base is in progress.


A Forth LISP
Martin J. Tracy
Micromotion
Los Angeles, CA
Forth is an extensible language and can be extended to handle lists of facts. The LISP language has many
good list operators which can be translated to Forth in a straightforward manner. By choosing appropriate data
structures and algorithms, Forth can have all of the power of LISP without the performance penalties. On the
other hand, Forth pays for this with greater complexity and the accompanying risk of producing incorrect code.
This paper, which freely combines source code with text, describes a hybrid Forth/LISP list handler. It
discusses list data structures, list primitives, "aliases", dynamic garbage collection, determining symbol
uniqueness, and other implementation details. As a demonstration of the power of the hybrid, it is itself used
to implement the "micro-LISP" described in Winston and Hom's liSP, 2nd edition, (Addison-Wesley, 1984).

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

#46620

Mark Wills <markwills1970@gmail.com> wrote:
> Not related, but this looks really cool, and I'm going to read it later:
> Vol XI no. 1
> FORTH NEEDS THREE MORE STACKS - AYMAN ABU-MOSTAFA
> Standard Forth uses the return stack for a number of disparate
> tasks: that is bad programming at best, confusing and error-prone at
> worst. This article suggests an aux stack for loop parameters and
> temporary storage. And a method of handling conditionals without
> branching allows use of conditionals outside colon definitions; this
> is done with a condition stack and a case stack.

IMO this is misguided.  Forth design in embedded systems (its
traditional field of use) has tended to use small tasks, each one
dedicated to doing a single job.This has turned out to be a useful
design principle as long as when it is applied consistently.  And by
small, I mean really small: maybe each task is only a few words long.
The super-lightweight multi-tasker originally from Moore himself, then
from others at Forth, Inc. is designed to make this work well even on
very small systems.

It's not hard to partition memory for arrays of small tasks if each
one has a data stack, a return stack, and a user area.  If you have
five stacks it gets to be difficult, not to mention rather space-
inefficient.

Andrew.

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

#46621

luni, 11 aprilie 2016, 13:50:57 UTC+3, Andrew Haley a scris:
> Mark Wills <markwills1970@gmail.com> wrote:
> > Not related, but this looks really cool, and I'm going to read it later:
> > Vol XI no. 1
> > FORTH NEEDS THREE MORE STACKS - AYMAN ABU-MOSTAFA
> > Standard Forth uses the return stack for a number of disparate
> > tasks: that is bad programming at best, confusing and error-prone at
> > worst. This article suggests an aux stack for loop parameters and
> > temporary storage. And a method of handling conditionals without
> > branching allows use of conditionals outside colon definitions; this
> > is done with a condition stack and a case stack.
> 
> IMO this is misguided.  Forth design in embedded systems (its
> traditional field of use) has tended to use small tasks, each one
> dedicated to doing a single job.This has turned out to be a useful
> design principle as long as when it is applied consistently.  And by
> small, I mean really small: maybe each task is only a few words long.
> The super-lightweight multi-tasker originally from Moore himself, then
> from others at Forth, Inc. is designed to make this work well even on
> very small systems.
> 
> It's not hard to partition memory for arrays of small tasks if each
> one has a data stack, a return stack, and a user area.  If you have
> five stacks it gets to be difficult, not to mention rather space-
> inefficient.
> 
> Andrew.

Difficult, same for any number of stacks. Space inefficient? yes, for
every stack or two (if facing each other) you loose some space.
If the performance hit is acceptable you can use any number of stacks
based on linked lists with 100% efficiency but more overhead, on a single
area. Probably an overkill unless you really have a lot of stacks :)

What I found is this: with a good compiler you can have locals and
loop indexes and temporary data (emulated r> r@ etc.) working on the same 
return stack with no collisions. This compiler is around 16K for a cortex-m0
system. A simple compiler like eforth or the like will be indeed in the
5K-8K range, but I prefer my ~16K one anytime.

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

#46622

Raimond Dragomir <raimond.dragomir@gmail.com> wrote:
> luni, 11 aprilie 2016, 13:50:57 UTC+3, Andrew Haley a scris:
>>
>> It's not hard to partition memory for arrays of small tasks if each
>> one has a data stack, a return stack, and a user area.  If you have
>> five stacks it gets to be difficult, not to mention rather space-
>> inefficient.
> 
> Difficult, same for any number of stacks.

I'm not quite sure why you think this.  When partitioning the system
you have to look at the total data + return size of every task and
partition accoringly.  Maybe I'm just a weakling, but I think I'd find
having to figure out the stack sizes for every task would be tricky.

> Space inefficient? yes, for every stack or two (if facing each
> other) you loose some space.  If the performance hit is acceptable
> you can use any number of stacks based on linked lists with 100%
> efficiency but more overhead, on a single area. Probably an overkill
> unless you really have a lot of stacks :)

Hmm, surely this is just another way to waste space and CPU time.

> What I found is this: with a good compiler you can have locals and
> loop indexes and temporary data (emulated r> r@ etc.) working on the
> same return stack with no collisions.

Exactly so.  The return stack is great!

Andrew.

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

#46637

On Monday, April 11, 2016 at 4:21:22 AM UTC-7, Raimond Dragomir wrote:
> luni, 11 aprilie 2016, 13:50:57 UTC+3, Andrew Haley a scris:
> > Mark Wills <markwills1970@gmail.com> wrote:
> > > Not related, but this looks really cool, and I'm going to read it later:
> > > Vol XI no. 1
> > > FORTH NEEDS THREE MORE STACKS - AYMAN ABU-MOSTAFA
> > > Standard Forth uses the return stack for a number of disparate
> > > tasks: that is bad programming at best, confusing and error-prone at
> > > worst. This article suggests an aux stack for loop parameters and
> > > temporary storage. And a method of handling conditionals without
> > > branching allows use of conditionals outside colon definitions; this
> > > is done with a condition stack and a case stack.
> > 
> > IMO this is misguided.  Forth design in embedded systems (its
> > traditional field of use) has tended to use small tasks, each one
> > dedicated to doing a single job.This has turned out to be a useful
> > design principle as long as when it is applied consistently.  And by
> > small, I mean really small: maybe each task is only a few words long.
> > The super-lightweight multi-tasker originally from Moore himself, then
> > from others at Forth, Inc. is designed to make this work well even on
> > very small systems.
> > 
> > It's not hard to partition memory for arrays of small tasks if each
> > one has a data stack, a return stack, and a user area.  If you have
> > five stacks it gets to be difficult, not to mention rather space-
> > inefficient.
> > 
> > Andrew.
> 
> Difficult, same for any number of stacks. Space inefficient? yes, for
> every stack or two (if facing each other) you loose some space.
> If the performance hit is acceptable you can use any number of stacks
> based on linked lists with 100% efficiency but more overhead, on a single
> area. Probably an overkill unless you really have a lot of stacks :)
> 
> What I found is this: with a good compiler you can have locals and
> loop indexes and temporary data (emulated r> r@ etc.) working on the same 
> return stack with no collisions. This compiler is around 16K for a cortex-m0
> system. A simple compiler like eforth or the like will be indeed in the
> 5K-8K range, but I prefer my ~16K one anytime.

I'm familiar with Raimond's LFTforth (for the record: I thought up the name LFTforth). I think this is a very good design!

I'm learning more about Forth all the time. For example, I had originally thought that I would have a double-stack that contained both double-precision integers and also strings (the address and count are the two cells). Now that I have written this string-stack.4th I realize that the strings need their own stack. The reason is that FIX-DERIVATIVES needs to search the string-stack and fix any derivatives (turn them into uniques) if the unique that they are derived from is getting mutated or is getting dropped. FIX-DERIVATIVES can't distinguish between strings and double-integers though, so it needs to have only strings on the stack.

I now think that I need both a string-stack and a double-precision-integer stack --- these are both in addition to the single-precision-integer stack (also contains pointers, or any other single-cell data) and the return-stack (also contains locals).

For the most part, I don't see a problem with having multiple stacks in regard to memory-efficiency. These are very small stacks --- maybe 32 elements each --- memory-efficiency isn't going to be a problem except on an extremely memory-constrained micro-controller, but even small micro-controllers such as the MSP-430 typically have 32KB of RAM which is quite a lot (this isn't the 1980s anymore). Also, something like the string-stack is going to be an extension to the language anyway --- most micro-controllers aren't going to need this just because they don't work with strings.

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

#46636

On Monday, April 11, 2016 at 3:50:57 AM UTC-7, Andrew Haley wrote:
> Mark Wills <markwills1970@gmail.com> wrote:
> > Not related, but this looks really cool, and I'm going to read it later:
> > Vol XI no. 1
> > FORTH NEEDS THREE MORE STACKS - AYMAN ABU-MOSTAFA
> > Standard Forth uses the return stack for a number of disparate
> > tasks: that is bad programming at best, confusing and error-prone at
> > worst. This article suggests an aux stack for loop parameters and
> > temporary storage. And a method of handling conditionals without
> > branching allows use of conditionals outside colon definitions; this
> > is done with a condition stack and a case stack.
> 
> IMO this is misguided.  Forth design in embedded systems (its
> traditional field of use) has tended to use small tasks, each one
> dedicated to doing a single job.This has turned out to be a useful
> design principle as long as when it is applied consistently.  And by
> small, I mean really small: maybe each task is only a few words long.
> The super-lightweight multi-tasker originally from Moore himself, then
> from others at Forth, Inc. is designed to make this work well even on
> very small systems.

What I think is misguided is using the same Forth for both micro-controllers and desktop-computers.

I have said many times that my FloatForth is intended to be a standard for desktop-computers. One application program that can be written in FloatForth is a cross-compiler for a micro-controller --- but the Forth used on the micro-controller isn't compatible with FloatForth --- for one thing, FloatForth requires a 64-bit cell size (and, realistically, a 64-bit processor), whereas a micro-controller would be either 16-bit or 32-bit.

There are a lot of design decisions that are going to be different between a language used on a desktop-computer with a 64-bit x86 and a language used on an MSP-430. Right now I want FloatForth to be the standard for desktop-computers. I'm dubious that it is a good idea to have a standard for micro-controllers at all --- programs aren't going to be portable anyway, because they are hardware-specific --- the micro-controllers also vary a lot in their capabilities, from the 16-bit MSP-430 to the 32-bit ARM Cortex.

One of the many failures of ANS-Forth was that it specified one language for both desktop-computers and micro-controllers. This made sense in the 1970s and early 1980s when the 6502 and Z80 were used for both desktop-computers and micro-controllers. By 1994 however, it no longer made sense because most desktop-computers used the 32-bit Pentium, and micro-controllers continued to use 8-bit or 16-bit processors (mostly the Dallas 80c320, but also such things as the MC6808 and MC6812).

I hate ANS-Forth! This is really 1970s technology in every way --- it was a joke in 1994, and the joke is getting pretty stale in 2016.

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

#47793

On Sunday, April 10, 2016 at 8:23:29 PM UTC-7, hughag...@gmail.com wrote:
> I was reading about Stephen Pelc's BNF interpreter that is in VFX. It looks pretty interesting. I notice that his code is not ANS-Forth however.
> 
> : || IF R> DROP 1 THEN ;
> 
> This is obviously illegal in ANS-Forth. Section 3.2.3.3. says: 
> A program shall not access values on the return stack (using R@, R>, 2R@ or 2R>) that it did not place there using >R or 2>R;
> 
> Pelc should have written this:
> 
> macro: ||  if 1 exit then ;
> 
> Or, for improved readability:
> 
> macro: ||  ( flag -- true | )  \ exits the parent function on a true flag
>     dup if  exit then          \ if the flag is true, exit and return the flag
>     drop ;                     \ if the flag is false, drop the flag and keep going
> 
> MACRO: is in the novice-package and, like everything in the novice-package, it is ANS-Forth. 
> 
> Also, I don't know why he is using 1 rather than -1 for true, but that doesn't matter very much.

Not only is Pelc's code not ANS-Forth, but it also has a bug in it. If the colon word that calls || uses locals, it will crash when || is called because the EXIT in || is trying to exit out of the calling function but doesn't know that it has locals on top of the return-address.

By comparison, my version of || works fine whether the calling function has locals or not.

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

#45940

On Sunday, 6 March 2016 22:08:15 UTC, hughag...@gmail.com  wrote:
> On Sunday, March 6, 2016 at 11:54:30 AM UTC-7, foxaudio...@gmail.com wrote:
> > On Sunday, March 6, 2016 at 11:50:23 AM UTC-5, foxaudio...@gmail.com wrote:
> > > On Saturday, March 5, 2016 at 6:17:20 PM UTC-5, hughag...@gmail.com wrote:
> > > > On Saturday, March 5, 2016 at 3:52:48 AM UTC-7, Mark Wills wrote:
> > > > > Good job. Pleased to see someone else working with string stacks.
> > > > 
> > > > For the record, I was inspired to write string-stack.4th by Mark Wills (this is mentioned in my documentation). He has Turbo Forth code and an ANS-Forth implementation as well. My internal workings are different, but the general idea of a stack for strings came from him. To a large extent my API is the same as his, but there are some differences --- the API is largely derived from QBASIC with MID$ and +$ etc..
> > > 
> > > And for the record, I wrote these kind of concepts in the 1980s for Ti-Forth for the the TI-99 as a recovering BASIC programmer and submitted an article to Dr. Dobbs but it was declined.  I re-wrote the code for HS/Forth in the 1990s for use in real world applications.  In the 2000s somewhere I shared that code with Mark after I saw his cool work on the TI-99. (hard to forget your first machine)  Mark re-wrote string stack code based on these concepts for Turbo Forth putting them back into the TI-99.  That's kind of amusing. :-)
> 
> When Mark discussed this topic with me, he recommended that I hold the strings in the heap. This is what I did. My string-stack is only 2 cells wide (the adr/cnt pair). My strings are not limited to 255 chars as yours are.
> 
> My own innovation was to work out a method in which I minimize the calls to ALLOC and DEALLOC on the assumption that these are the speed-killers. I mentioned in my first post that DUP$ does not call ALLOC but all it does is make a copy of the adr/cnt of the string that it is duplicating. The LEFT$ just modifies this adr/cnt (adjusts the cnt). The .$ just types out the string and drops the adr/cnt from the string-stack. The next .$ also types out the string but it has to DEALLOC the string before it drops the adr/cnt from the string-stack.
> 
> Most likely, my code is going to be faster than yours. You don't list DUP$ in your code, but if you did then it would call MOVE$ which copies the string --- copying a string is also a speed-killer that I avoid.
> 
> Anyway, I'm not saying that I invented the concept of the string-stack. I got the idea from Mark Wills. He apparently got the idea from you. The idea may have been independently invented several times (Forth has a stack for cells so a stack for strings is an obvious next step).
> 
> All I'm saying is that my string-stack.4th is the most efficient.

There are various attempts at string stacks in the various editions
of Forth Dimensions over the years.

[toc] | [prev] | [standalone]

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

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

csiph-web