Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Does forth text manipulation use filters, NOT pointers?
28 views
Skip to first unread message
no.to...@gmail.com
Feb 4, 2012, 2:11:07 AM2/4/12
to
I recently tried to ask this question here, and got
replies that <I should buy the forth book>.
I've read the forth-book decades ago, and anybody
who's read Backus' AGM prize winning 70's publication
will know what I'm driving at.
The *nix approach of processing text via serially
connected filters instead of the painfull and primitive
use of pointers and inindices, fit's naturally with forth's
<cascading functions via the stack>.
An example task, which impressed me, of serially
transforming/reformatting the next 5 lines:--
>> Since lisp has a functional point-of-view, which matches
>> the idea
>> of serially transforming the data, I'm wondering how
>> emacs
>> would approach the above problem?
...
to equal length lines of default size, is done easily by
the *nix-tools approach of filtering the data through
multiple stages [it's economical in effort]:
remove all ">"|
translate EOL to <space> |
insert EOL at word-break before default-line-len |
prepend "> " to each line|
prepend "> " to each line
In order to profitably use this powerful & economical method,
you need to have a library of suitable filters, which unix has.
Since forth is FORCED to use the serial filtering paradigm,
I'm speculating that over the decades, a suitable library
of <text filters> has evolved. And probably this would be
seen in a 'classical' forth text editor.
So, what is the approach of THE forth editor?
---------
Is there anybody here who has thought about the deeper
principles behind forth, or do you just DO-IT, like riding a
bicycle?
== TIA.
replies that <I should buy the forth book>.
I've read the forth-book decades ago, and anybody
who's read Backus' AGM prize winning 70's publication
will know what I'm driving at.
The *nix approach of processing text via serially
connected filters instead of the painfull and primitive
use of pointers and inindices, fit's naturally with forth's
<cascading functions via the stack>.
An example task, which impressed me, of serially
transforming/reformatting the next 5 lines:--
>> Since lisp has a functional point-of-view, which matches
>> the idea
>> of serially transforming the data, I'm wondering how
>> emacs
>> would approach the above problem?
...
to equal length lines of default size, is done easily by
the *nix-tools approach of filtering the data through
multiple stages [it's economical in effort]:
remove all ">"|
translate EOL to <space> |
insert EOL at word-break before default-line-len |
prepend "> " to each line|
prepend "> " to each line
In order to profitably use this powerful & economical method,
you need to have a library of suitable filters, which unix has.
Since forth is FORCED to use the serial filtering paradigm,
I'm speculating that over the decades, a suitable library
of <text filters> has evolved. And probably this would be
seen in a 'classical' forth text editor.
So, what is the approach of THE forth editor?
---------
Is there anybody here who has thought about the deeper
principles behind forth, or do you just DO-IT, like riding a
bicycle?
== TIA.
Peter Knaggs
Feb 4, 2012, 7:30:59 AM2/4/12
to
You wrote:
>
> I recently tried to ask this question here, and got
> replies that <I should buy the forth book>.
Mainly because the "pipline" approach you refer too generic a definition,
>
> I recently tried to ask this question here, and got
> replies that <I should buy the forth book>.
what are you wanting to pipline. From the rest of your text I suspect you
mean text as in the Standard Input/Output.
> I've read the forth-book decades ago, and anybody
> who's read Backus' AGM prize winning 70's publication
> will know what I'm driving at.
>
> The *nix approach of processing text via serially
> connected filters instead of the painfull and primitive
> use of pointers and inindices, fit's naturally with forth's
> <cascading functions via the stack>.
placing string on the stack (c-addr u) and each word copy the string into
its own string buffer.
> Since forth is FORCED to use the serial filtering paradigm,
> I'm speculating that over the decades, a suitable library
> of <text filters> has evolved. And probably this would be
> seen in a 'classical' forth text editor.
--
Peter Knaggs
Elizabeth D. Rather
Feb 4, 2012, 12:53:57 PM2/4/12
to
On 2/3/12 9:11 PM, no.to...@gmail.com wrote:
> I recently tried to ask this question here, and got
> replies that<I should buy the forth book>.
> I've read the forth-book decades ago, and anybody
> who's read Backus' AGM prize winning 70's publication
> will know what I'm driving at.
Well, I know Forth inside-out, but haven't read the Backus book. But
> I recently tried to ask this question here, and got
> replies that<I should buy the forth book>.
> I've read the forth-book decades ago, and anybody
> who's read Backus' AGM prize winning 70's publication
> will know what I'm driving at.
I'll try to answer.
> The *nix approach of processing text via serially
> connected filters instead of the painfull and primitive
> use of pointers and inindices, fit's naturally with forth's
> <cascading functions via the stack>.
>
> An example task, which impressed me, of serially
> transforming/reformatting the next 5 lines:--
>>> Since lisp has a functional point-of-view, which matches
>>> the idea
>>> of serially transforming the data, I'm wondering how
>>> emacs
>>> would approach the above problem?
> ...
> to equal length lines of default size, is done easily by
> the *nix-tools approach of filtering the data through
> multiple stages [it's economical in effort]:
> remove all ">"|
> translate EOL to<space> |
> insert EOL at word-break before default-line-len |
> prepend "> " to each line|
> prepend "> " to each line
Forths) kept source text in 1024-byte blocks, with no line separators.
It was formatted in 16 lines of 64 characters for display, but for
parsing purposes was a single string.
> In order to profitably use this powerful& economical method,
> you need to have a library of suitable filters, which unix has.
>
> Since forth is FORCED to use the serial filtering paradigm,
> I'm speculating that over the decades, a suitable library
> of<text filters> has evolved. And probably this would be
> seen in a 'classical' forth text editor.
Not really. Forth's text interpreter is interested in "words" (strings
>
> Since forth is FORCED to use the serial filtering paradigm,
> I'm speculating that over the decades, a suitable library
> of<text filters> has evolved. And probably this would be
> seen in a 'classical' forth text editor.
delimited by spaces or whitespace) which is a single, very simple
filter. Parsing words can find any character.
> So, what is the approach of THE forth editor?
users can use their favorite programmer's editor.
> ---------
> Is there anybody here who has thought about the deeper
> principles behind forth, or do you just DO-IT, like riding a
> bicycle?
simplicity, and his guiding principle was to have the simplest tools
possible to do what he had to do. He believed that in simplicity one
found the greatest power; complex systems make the programmer a slave of
the system.
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
Rod Pemberton
Feb 4, 2012, 11:26:36 PM2/4/12
to
<no.to...@gmail.com> wrote in message news:jgilma$srd$1...@dont-email.me...
There is quite a bit of good Forth information available online, but it's
not comprehensive. Some is easy to locate and some isn't. Ask ... If you
think or feel you need more in-depth references, a library, bookstore, or
online bookstore will provide what you need.
> I've read the forth-book decades ago, [...]
Ok.
> [...] and anybody
If it's important for me to know as to what you are referring to, you'll
have to expound. Don't mention Fortran. It sucked!
1970's? You know ...
You really should probably forget about most, but not all, computer
programming concepts developed prior to 1978 or 1981 anyway. The
standardized microprocessor based computing platform that we're familiar
with today didn't exist prior to 1974 and wasn't widespread until 1984 or
later. Concepts developed prior to then weren't as fully developed until
much later due to the chaos of early competing and radically different
computing platforms. Any good concepts that existed prior to 1974, which
are exceptionally few IMO, still exist today in some form or another.
Concepts from around that time which are still good are: C and Forth,
contiguous memory, various algorithms, 8-bit bytes and ASCII and EBCDIC,
etc. I.e., although I know how to power a vacuum tube, construct a cpu from
logic-gates, such ancient things serve little to no purpose today. Most of
the ideas and theorems that power corporations like Google and Facebook and
Apple products are modern.
> The *nix approach of processing text via serially
> connected filters instead of the painfull and primitive
> use of pointers and inindices, fit's naturally with forth's
> <cascading functions via the stack>.
>
I just converted by mostly fig-Forth like Forth interpreter in C from buffer
address and offsets via IN to IN using pointers directly. Straight pointers
fit better with the C code and primitives or low-level words in C. So, if
you know that some modification or change suits your situation better, you
should just go ahead an use it. I.e., if you think "processing text via
serially connected filters" will work better for Forth, go ahead and
implement it. You'll either prove or disprove it.
> [reformat example snipped]
...
> Since forth is FORCED to use the serial filtering paradigm,
> I'm speculating that over the decades, a suitable library
> of <text filters> has evolved. And probably this would be
> seen in a 'classical' forth text editor.
Why is Forth "FORCED" to use the "serial filtering paradigm" ?
That reformmating is fairly easy to do in C. With no intent of stirring up
"C is better at it than Forth arguments" to which I like to respond, Forth
programmers should be able to come up with some solution.
> So, what is the approach of THE forth editor?
WHAT "forth editor?" What are you talking about? BL WORD? QUERY?
FIND? INTERPRET? The "inner interpreter" and "outer interpreter"?
> Is there anybody here who has thought about the deeper
> principles behind forth, [...]
What "deeper principles"? Lack of syntax? Chaos and confusion? Do it
yourself? Lost in numerous nested colons and semicolons? Keep track of
stack data in your head? You can't do that in ANS? No interpretation
semantics, really? Is that stack diagram for real? Syntax error?!?!?
Obviously, being pro-Forth as I assume you are and know most others are
here, you should qualify what "deeper principles" actually means to you.
The only standard principle I'm aware of is "factoring". The process by
which you code things in the smallest possible unit. Unfortunately, that
makes for small code, but not necessarily fast code, especially with
interpreters.
So far, during the implementation of my Forth interpreter in C, I've not
seen any "principles" that I would classify as "deep". The classic Forth
interpreter is novel in a few regards. However, that novelty is lost when
combined with a language like Forth that was not well suited to it as it
could've been. Also, ISTM, that Forth seriously missed the mark in a few
critical areas, at least as compared to C. Unfortunately, many other
languages, especially of the same era as Forth and C, suck so bad that Forth
looks brilliant by comparison, e.g., Fortran, Pascal, BASIC, Cobol, Snobol,
Lisp, etc. Most modern languages are either built upon C or are convertable
directly to C, so they typically inherent C's abilities and flaws. Forth
and C are the two most widely implemented languages. That said, let me know
when you find people building languages upon Forth ... Otherwise, most of
Forth fits very well with C, at least in my interpreter, and is simple to
implement, but time consuming. There are a few things in Forth that are
more complicated to implement. The compiled or high-level words are built
upon the primitives or low-level words. This is no different than any other
language or language library, at least at first. I provided a couple of
posts on this a few years ago to various NGs with compartive data. I
believe one was to c.l.f. You need some constants, and a couple stacks, and
an few "registers" for an interpreter, and a whole lot of words coded in
Forth, etc.
Rod Pemberton
> I recently tried to ask this question here, and got
> replies that <I should buy the forth book>.
Yeah, just ignore those ...
> replies that <I should buy the forth book>.
There is quite a bit of good Forth information available online, but it's
not comprehensive. Some is easy to locate and some isn't. Ask ... If you
think or feel you need more in-depth references, a library, bookstore, or
online bookstore will provide what you need.
> I've read the forth-book decades ago, [...]
Ok.
> [...] and anybody
> who's read Backus' AGM prize winning 70's
> publication will know what I'm driving at.
Uh ... ?
> publication will know what I'm driving at.
If it's important for me to know as to what you are referring to, you'll
have to expound. Don't mention Fortran. It sucked!
1970's? You know ...
You really should probably forget about most, but not all, computer
programming concepts developed prior to 1978 or 1981 anyway. The
standardized microprocessor based computing platform that we're familiar
with today didn't exist prior to 1974 and wasn't widespread until 1984 or
later. Concepts developed prior to then weren't as fully developed until
much later due to the chaos of early competing and radically different
computing platforms. Any good concepts that existed prior to 1974, which
are exceptionally few IMO, still exist today in some form or another.
Concepts from around that time which are still good are: C and Forth,
contiguous memory, various algorithms, 8-bit bytes and ASCII and EBCDIC,
etc. I.e., although I know how to power a vacuum tube, construct a cpu from
logic-gates, such ancient things serve little to no purpose today. Most of
the ideas and theorems that power corporations like Google and Facebook and
Apple products are modern.
> The *nix approach of processing text via serially
> connected filters instead of the painfull and primitive
> use of pointers and inindices, fit's naturally with forth's
> <cascading functions via the stack>.
>
address and offsets via IN to IN using pointers directly. Straight pointers
fit better with the C code and primitives or low-level words in C. So, if
you know that some modification or change suits your situation better, you
should just go ahead an use it. I.e., if you think "processing text via
serially connected filters" will work better for Forth, go ahead and
implement it. You'll either prove or disprove it.
> [reformat example snipped]
...
> Since forth is FORCED to use the serial filtering paradigm,
> I'm speculating that over the decades, a suitable library
> of <text filters> has evolved. And probably this would be
> seen in a 'classical' forth text editor.
That reformmating is fairly easy to do in C. With no intent of stirring up
"C is better at it than Forth arguments" to which I like to respond, Forth
programmers should be able to come up with some solution.
> So, what is the approach of THE forth editor?
FIND? INTERPRET? The "inner interpreter" and "outer interpreter"?
> Is there anybody here who has thought about the deeper
What "deeper principles"? Lack of syntax? Chaos and confusion? Do it
yourself? Lost in numerous nested colons and semicolons? Keep track of
stack data in your head? You can't do that in ANS? No interpretation
semantics, really? Is that stack diagram for real? Syntax error?!?!?
Obviously, being pro-Forth as I assume you are and know most others are
here, you should qualify what "deeper principles" actually means to you.
The only standard principle I'm aware of is "factoring". The process by
which you code things in the smallest possible unit. Unfortunately, that
makes for small code, but not necessarily fast code, especially with
interpreters.
So far, during the implementation of my Forth interpreter in C, I've not
seen any "principles" that I would classify as "deep". The classic Forth
interpreter is novel in a few regards. However, that novelty is lost when
combined with a language like Forth that was not well suited to it as it
could've been. Also, ISTM, that Forth seriously missed the mark in a few
critical areas, at least as compared to C. Unfortunately, many other
languages, especially of the same era as Forth and C, suck so bad that Forth
looks brilliant by comparison, e.g., Fortran, Pascal, BASIC, Cobol, Snobol,
Lisp, etc. Most modern languages are either built upon C or are convertable
directly to C, so they typically inherent C's abilities and flaws. Forth
and C are the two most widely implemented languages. That said, let me know
when you find people building languages upon Forth ... Otherwise, most of
Forth fits very well with C, at least in my interpreter, and is simple to
implement, but time consuming. There are a few things in Forth that are
more complicated to implement. The compiled or high-level words are built
upon the primitives or low-level words. This is no different than any other
language or language library, at least at first. I provided a couple of
posts on this a few years ago to various NGs with compartive data. I
believe one was to c.l.f. You need some constants, and a couple stacks, and
an few "registers" for an interpreter, and a whole lot of words coded in
Forth, etc.
Rod Pemberton
jc
Feb 4, 2012, 11:58:59 PM2/4/12
to
On Feb 4, 8:26 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> <no.top.p...@gmail.com> wrote in messagenews:jgilma$srd$1...@dont-email.me...
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/e9b01abe8c64717e
wrote:
> <no.top.p...@gmail.com> wrote in messagenews:jgilma$srd$1...@dont-email.me...
> > [...] and anybody
> > who's read Backus' AGM prize winning 70's
> > publication will know what I'm driving at.
>
> > who's read Backus' AGM prize winning 70's
> > publication will know what I'm driving at.
>
> If it's important for me to know as to what you are referring to, you'll
> have to expound. Don't mention Fortran. It sucked!
You'd have to reference some of his older posts, like this one:
> have to expound. Don't mention Fortran. It sucked!
http://groups.google.com/group/comp.lang.forth/browse_thread/thread/e9b01abe8c64717e
BruceMcF
Feb 5, 2012, 10:16:16 AM2/5/12
to
On Feb 4, 2:11 am, no.top.p...@gmail.com wrote:
> I recently tried to ask this question here, and got
> replies that <I should buy the forth book>.
> I've read the forth-book decades ago, and anybody
> who's read Backus' AGM prize winning 70's
> publication will know what I'm driving at.
What an obscure way to refer to a publication. Do you mean Backus
> I recently tried to ask this question here, and got
> replies that <I should buy the forth book>.
> I've read the forth-book decades ago, and anybody
> who's read Backus' AGM prize winning 70's
> publication will know what I'm driving at.
(1978), as in the Turing Prize lecture?
That's not a "prize winning publication", its a speech given on the
occasion of being *awarded* a prize.
Mark Wills
Feb 6, 2012, 4:31:03 AM2/6/12
to
Troll.
Doug Hoffman
Feb 7, 2012, 7:44:15 AM2/7/12
to
On 2/4/12 2:11 AM, no.to...@gmail.com wrote:
...
Regardless, one approach (of many possible) using existing string
library code follows:
-Doug
\ non-minimalist
\ cross-posted to comp.lang.forth.desktop
\ library code required
\ http://soton.mpeforth.com/flag/fms/index.html
\ all code is ANS compatible
\ ------------- start code ----------------
40 constant wrapColumn \ set as desired
13 value cr# \ use 10 for non-Mac ??
string+ s \ input string
string+ s1 \ output string
-1 [if]
: load-s \ directly without a file
s" >> Since lisp has a functional " s !:
s" point-of-view, which matches " s add:
cr# s +:
s" >> the idea" s add:
cr# s +:
s" >> of serially transforming the " s add:
s" data, I'm wondering how " s add:
cr# s +:
s" >> emacs " s add:
cr# s +:
s" >> would approach the above problem?" s add:
cr# s +: ;
[else]
file f
: load-s \ or load from a text file
s" cite data.txt" f open: drop
s f read: 2drop
f close: drop ;
[then]
load-s
: delete-all ( char -- )
s reset:
begin
dup s chsearch:
while
s delete:
repeat drop ;
char > delete-all
cr# delete-all
9 ( tab) delete-all
bl s +: \ add trailing space
\ --- begin word-wrap support defs ---
variable column
\ if another space-delimited word
\ is found in string s then select it
\ and report success/failure
: next-word? ( -- flag )
bl s word: ;
\ fetch next-word to stack
\ and increase column# by len
: @word ( -- addr len )
s @sub: dup column +! ;
\ true if word fits on current line
: fit? ( -- flag )
column @ wrapColumn < ;
: add-space bl s1 +: 1 column +! ;
: add-word ( addr len -- ) s1 add: ;
\ len = len of next word to add
: new-line ( len -- len )
cr# s1 +: \ add cr
add-space
( len) dup column ! ;
: process-word
@word fit? if add-space
else new-line
then add-word ;
\ --- end word-wrap support defs ---
\ Source string is s (unwrapped).
\ Wrapped string is built one word
\ at a time from s -> s1.
: word-wrap
0 column ! s reset: pad 0 s1 !:
begin
next-word?
while
process-word
repeat ;
word-wrap
: cite
s1 reset:
begin
s" >" s1 insert:
cr# s1 chsearch:
while
1 s1 start: +! \ bump start pos to just past cr
repeat ;
cite cite
s1 p: \ print the output string
0 [if]
s free: s1 free: \ free memory when done
[then]
\ ------------- end code ----------------
...
> An example task, which impressed me, of serially
> transforming/reformatting the next 5 lines:--
>>> Since lisp has a functional point-of-view, which matches
>>> the idea
>>> of serially transforming the data, I'm wondering how
>>> emacs
>>> would approach the above problem?
> ...
> to equal length lines of default size, is done easily by
> the *nix-tools approach of filtering the data through
> multiple stages [it's economical in effort]:
> remove all ">"|
> translate EOL to<space> |
> insert EOL at word-break before default-line-len |
> prepend "> " to each line|
> prepend "> " to each line
>
> In order to profitably use this powerful& economical method,
> transforming/reformatting the next 5 lines:--
>>> Since lisp has a functional point-of-view, which matches
>>> the idea
>>> of serially transforming the data, I'm wondering how
>>> emacs
>>> would approach the above problem?
> ...
> to equal length lines of default size, is done easily by
> the *nix-tools approach of filtering the data through
> multiple stages [it's economical in effort]:
> remove all ">"|
> translate EOL to<space> |
> insert EOL at word-break before default-line-len |
> prepend "> " to each line|
> prepend "> " to each line
>
> you need to have a library of suitable filters, which unix has.
...
> So, what is the approach of THE forth editor?
What is THE forth editor?
Regardless, one approach (of many possible) using existing string
library code follows:
-Doug
\ non-minimalist
\ cross-posted to comp.lang.forth.desktop
\ library code required
\ http://soton.mpeforth.com/flag/fms/index.html
\ all code is ANS compatible
\ ------------- start code ----------------
40 constant wrapColumn \ set as desired
13 value cr# \ use 10 for non-Mac ??
string+ s \ input string
string+ s1 \ output string
-1 [if]
: load-s \ directly without a file
s" >> Since lisp has a functional " s !:
s" point-of-view, which matches " s add:
cr# s +:
s" >> the idea" s add:
cr# s +:
s" >> of serially transforming the " s add:
s" data, I'm wondering how " s add:
cr# s +:
s" >> emacs " s add:
cr# s +:
s" >> would approach the above problem?" s add:
cr# s +: ;
[else]
file f
: load-s \ or load from a text file
s" cite data.txt" f open: drop
s f read: 2drop
f close: drop ;
[then]
load-s
: delete-all ( char -- )
s reset:
begin
dup s chsearch:
while
s delete:
repeat drop ;
char > delete-all
cr# delete-all
9 ( tab) delete-all
bl s +: \ add trailing space
\ --- begin word-wrap support defs ---
variable column
\ if another space-delimited word
\ is found in string s then select it
\ and report success/failure
: next-word? ( -- flag )
bl s word: ;
\ fetch next-word to stack
\ and increase column# by len
: @word ( -- addr len )
s @sub: dup column +! ;
\ true if word fits on current line
: fit? ( -- flag )
column @ wrapColumn < ;
: add-space bl s1 +: 1 column +! ;
: add-word ( addr len -- ) s1 add: ;
\ len = len of next word to add
: new-line ( len -- len )
cr# s1 +: \ add cr
add-space
( len) dup column ! ;
: process-word
@word fit? if add-space
else new-line
then add-word ;
\ --- end word-wrap support defs ---
\ Source string is s (unwrapped).
\ Wrapped string is built one word
\ at a time from s -> s1.
: word-wrap
0 column ! s reset: pad 0 s1 !:
begin
next-word?
while
process-word
repeat ;
word-wrap
: cite
s1 reset:
begin
s" >" s1 insert:
cr# s1 chsearch:
while
1 s1 start: +! \ bump start pos to just past cr
repeat ;
cite cite
s1 p: \ print the output string
0 [if]
>> Since lisp has a functional
>> point-of-view, which matches the idea of
>> serially transforming the data, I'm
>> wondering how emacs would approach the
>> above problem?
1234567890123456789012345678901234567890
>> point-of-view, which matches the idea of
>> serially transforming the data, I'm
>> wondering how emacs would approach the
>> above problem?
s free: s1 free: \ free memory when done
[then]
\ ------------- end code ----------------
WJ
Mar 3, 2012, 1:59:29 AM3/3/12
to
Forth for this task. Why not try Ruby?
text =
">> Since lisp has a functional point-of-view, which matches
>> the idea
>> of serially transforming the data, I'm wondering how
>> emacs
>> would approach the above problem?"
class String
>> the idea
>> of serially transforming the data, I'm wondering how
>> emacs
>> would approach the above problem?"
def wrap( width )
whole = self.split( /( +)/ )
text = ""
line = whole.shift
whole.each{|str|
if (line + str).rstrip.size <= width or line.empty?
line << str
else
text << line.rstrip + "\n"
line = str
end }
text << line
end
end
# Now for the grand and glorious pipeline:
puts text.gsub( /^>> /, "" ).gsub( /\n/, " ").wrap( 50 ).
gsub( /^/, ">> " )
==== output ====
0 new messages