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

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

list processing in Forth tutorials

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

Contents

  list processing in Forth tutorials Julian Fondren <julian.fondren@gmail.com> - 2017-03-08 19:59 -0800
    Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-08 22:28 -0800
      Re: list processing in Forth tutorials Julian Fondren <julian.fondren@gmail.com> - 2017-03-08 23:33 -0800
        Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-11 15:10 -0800
    Re: list processing in Forth tutorials NN <november.nihal@gmail.com> - 2017-03-09 04:58 -0800
    Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-11 15:23 -0800
      Re: list processing in Forth tutorials Alex <alex@rivadpm.com> - 2017-03-11 23:45 +0000
        Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-11 16:24 -0800
          Re: list processing in Forth tutorials Julian Fondren <julian.fondren@gmail.com> - 2017-03-11 21:14 -0800
            Re: list processing in Forth tutorials "Elizabeth D. Rather" <erather@forth.com> - 2017-03-11 19:29 -1000
              Re: list processing in Forth tutorials mhx@iae.nl - 2017-03-12 00:36 -0800
              Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-12 19:10 -0700
            Re: list processing in Forth tutorials mhx@iae.nl - 2017-03-12 00:24 -0800
              Re: list processing in Forth tutorials Julian Fondren <julian.fondren@gmail.com> - 2017-03-12 07:35 -0700
            Re: list processing in Forth tutorials minforth@arcor.de - 2017-03-12 01:19 -0800
              Re: list processing in Forth tutorials NN <november.nihal@gmail.com> - 2017-03-14 07:40 -0700
            Re: list processing in Forth tutorials Ron Aaron <rambamist@gmail.com> - 2017-03-12 11:24 +0200
            Re: list processing in Forth tutorials humptydumpty <ouatubi@gmail.com> - 2017-03-12 10:48 -0700
            Re: list processing in Forth tutorials humptydumpty <ouatubi@gmail.com> - 2017-03-12 10:56 -0700
            Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-12 19:31 -0700
        Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-11 18:31 -0800
    Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-15 13:18 -0700
      Re: list processing in Forth tutorials NN <november.nihal@gmail.com> - 2017-03-16 06:02 -0700
        Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-16 12:11 -0700
          Re: list processing in Forth tutorials NN <november.nihal@gmail.com> - 2017-03-17 04:14 -0700
            Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-17 15:13 -0700
      Re: list processing in Forth tutorials hughaguilar96@gmail.com - 2017-03-17 15:19 -0700
    Re: list processing in Forth tutorials Coherent Systems <CoherentSystems@cosy.com> - 2017-03-21 15:46 -0700

Page 1 of 2  [1] 2  Next page →

#55564 — list processing in Forth tutorials

Hello clf,

As you all know, Forth is famous for its list processing capabilities.
Although it has other data structures, we all reach first for the
linked list, and Forth programs in the wild generally exhibit the
epigram "It is better to have 100 functions operate on one data
structure than 10 functions on 10 data structures."

However, I was startled the other day during a conversation with a
fellow who said he didn't quite understand lists until he'd
reimplemented them with objects in Python -- this, after using Forth.
He was conversant with Forth's rich list vocabulary, he'd written
several non-trivial Forth programs, and he'd learned the language from
a tutorial that he'd summarized as "page 1. hello world; page 2. how
to use lists for everything". We spoke for quite a while, and I came
away feeling that I had a good handle on the problem.

The problem is that Forth documentation takes the following forms:

  1. here are all the major words implemented by this system and here
  are examples of their use.

  2. here are all the words in this standard.

  3. here's a bunch of fully coded applications in Forth.

Generally it reads like a operations manual for a machine: here are
the knobs and this is what happens when you turn them. It does not
invite the reader to reflect on the construction of the knobs, or of
the machine in general. Lists, to continue the metaphor, would appear
on the machine as an especially intricate panel with numerous controls
and displays, and by the time you'd finished listing off what all
those controls do for sure you'd feel exhausted - and feel as if you'd
exhausted the subject of lists. Even when you neglected to say what
lists *are*, or to say even a word about *why* we put such emphasis on
them.

I suggest that the solution is this: write documentation AS IF it were
written for a language with actually no list processing capabilities
of note at all. Build those list processing capabilities using more
primitive operations, perhaps wearily, as this were a chore the
language required of you before you can get around to actually doing
anything, but explaining the construction and its merits as you go.
Then, at the end, say -- just kidding! This is all built in!

Of course you can make it clear at the beginning that this is a
pretense. Forth and lists are such a pair in the culture that a reader
might otherwise discard your tutorial as some kind of weak troll.

Here is where I'd like to submit my own example of a tutorial like
this, but I've tried and it's actually very difficult to write Forth
without lists. I hope that some of you who are in the middle of
writing your next "what are monads?" mini-tutorial can give my
suggestion a try, instead.


But consider, with traditional link-first lists and these words...

  : each[ ( list -- )
    POSTPONE begin POSTPONE dup POSTPONE while ; immediate

    ( list -- list )

  : ]each ( list -- )
    POSTPONE @ POSTPONE repeat POSTPONE drop ; immediate

... just how many list operators a clumsy low-level language like
Common Lisp must have in order to provide more limited functionality!

  MAPCAR applies a function to each member of a list, producing a new
  list. The EACH[ ]EACH version is obvious, with the new list
  constructed as the next-on-stack.
  
  MAPC is like MAPCAR except no list is built. EACH[ ]EACH without
  list construction.
  
  MAPLIST is like MAPCAR except the function is given successive
  sublists instead of each element of the list. EACH[ ]EACH with
  *less* work than required by MAPCAR.
  
  MAPL is like MAPLIST except no list is built.
  
  MAPCAN and MAPCON are like MAPCAR and MAPLIST except the result of
  the function should be a list, which is appended together to form
  the final result.
  
  And then there's DOLIST which is just MAPC with code instead a
  passed-in function -- exactly EACH[ ]EACH

And then none of these functions can abort iteration halfway through,
so there are still more operators to tell you efficiently if a list
has a certain member or not, what it's index is, or if the lists
successive members maintain a property all the way through, and so on.

When was the last time you picked up a Forth book that said "here's
EACH[ ]EACH and some example uses of it" which then moved on, without
emphasizing the supremacy of this expression, which other languages
can only have pale shadows of? It's been every time for me. This is a
perfect example of why Forth is such a superior list processing
language -- and it's glossed over. I remember that my impression was
1) hey where are the rest of the words, and 2) wow I bet only system
implementators can provide words like this, they must be syntax.

I know that you're all reluctant to engage in unseemly *advocacy*, or
to say outrageous things like "Forth is actually very good and should
be used preferentially to other languages". But your aloof and
practical masks fit too well; you do others a disservice when they
believe you and then go on to waste a lot of time learning the fine
differences between MAPLIST and MAPCAR.

Anyway, I'm tickled by the idea of Forth tutorials that proceed as if
Forth were 'poor'. Like a numerical recipes guide that doesn't begin
by telling you how to import NumFor. There's plenty of blogspam-type
tutorials that show how you can write jabber clients and servers using
xmpp.4th - wouldn't it be absurd to begin with an XML parser, or with
BSD sockets? I even have a good framing device in mind, where for
*pedagogic* reasons these libraries won't be used.

[toc] | [next] | [standalone]

#55565

On Wednesday, March 8, 2017 at 8:59:39 PM UTC-7, Julian Fondren wrote:
>   : each[ ( list -- )
>     POSTPONE begin POSTPONE dup POSTPONE while ; immediate
> 
>     ( list -- list )
> 
>   : ]each ( list -- )
>     POSTPONE @ POSTPONE repeat POSTPONE drop ; immediate

This code is no good. Julien Fondren is making more than one mistake:

2.) The next-node pointer is not being obtained prior to the user's code being executed. If the current node is removed from the list (for example: moved to another list) then its .FORE field gets modified and ]EACH will not obtain the correct next-node when it does the @ of the .FORE field.

1.) The internal data (in this case, the node pointer) is held on the data-stack during the execution of the user's code. This gets in the way of the user's data. The internal data needs to be held on the return-stack during the execution of the user's code so the user's data is available.

Here is what I have in the novice package:

0
    w field .fore                   \ .FORE will be fast because it is in the front
constant list

SwiftForth? [if]

icode next>r ( node -- node )                   \ r: -- next-node
    0 [ebx] push
    ret end-code

[else]

macro: next>r ( node -- node )                  \ r: -- next-node
    dup .fore @ >r ;

[then]

macro: each[                                    \ toucher: i*x node -- j*x
    begin  dup while
        next>r ;

macro: ]each
        r> repeat drop ;

\ EACH[...]EACH generates faster-executing code than EACH, and can be more readable, but the code is more bloated.
\ EACH[...]EACH uses the return stack. This can create havoc in functions that use locals or use >R and R>.
\ EACH[...]EACH is mostly only used when speed is important, which largely precludes locals anyway.
\ FIND-NODE and FIND-PRIOR can't be written like this because they both involve an early-out.

\ EACH allows the toucher (the code that touches the node) to be tested on its own, and also to be used on its own.
\ EACH also allows the toucher to use local variables.
\ Both of these advantages can be achieved with EACH[...]EACH by factoring the toucher into a function and calling it.
\ EACH can easily be rewritten in assembly language, which might not be true of EACH[...]EACH.

\ Because of these reasons, EACH should generally be used rather than EACH[...]EACH.

SwiftForth? [if]

icode each ( i*x head 'toucher -- j*x )             \ toucher: i*x node -- j*x
    ebx push  [drop]                                \ -- node                       \r: -- 'toucher
    begin  non-zero? while
        0 [ebx] push                                \ -- node                       \r: -- 'toucher next
        w [esp] eax mov  edi eax add  eax call      \ --
        [dup]  ebx pop                              \ -- next                       \r: -- 'toucher
        repeat
    [drop]  [rdrop]  ret end-code

[else]

: each ( i*x head 'toucher -- j*x )                 \ toucher: i*x node -- j*x
    >r
    begin  dup while                                \ -- node                       \r: -- 'toucher
        r@  over .fore @ >r                         \ -- node 'toucher              \r: -- 'toucher next
        execute  r> repeat drop
    rdrop ;

[then]

\ It is possible for the toucher to access data underneath the node,
\ as EACH has no internal data on the stack (that is why we put everything on the return stack during the EXECUTE).

\ It is ok for the toucher to REMOVE the node from this list,
\ as we already have our next node on the r-stack.
\ When writing a filter, you REMOVE all of the nodes that you don't want to keep.
\ The toucher shouldn't remove multiple nodes however,
\ as it might clobber the next-node that EACH has waiting on the r-stack.

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

#55567

On Thursday, March 9, 2017 at 12:28:49 AM UTC-6, hughag...@gmail.com wrote:
> On Wednesday, March 8, 2017 at 8:59:39 PM UTC-7, Julian Fondren wrote:
> >   : each[ ( list -- )
> >     POSTPONE begin POSTPONE dup POSTPONE while ; immediate
> > 
> >     ( list -- list )
> > 
> >   : ]each ( list -- )
> >     POSTPONE @ POSTPONE repeat POSTPONE drop ; immediate
> 
> This code is no good. Julien Fondren is making more than one mistake:
> 
> 2.) The next-node pointer is not being obtained prior to the user's code being executed. If the current node is removed from the list (for example: moved to another list) then its .FORE field gets modified and ]EACH will not obtain the correct next-node when it does the @ of the .FORE field.
> 

My thoughts are:

1. Almost all of the time when I'm walking a list, I expect to leave
its structure alone. So the (little) extra work here would be wasted
almost all of the time.

2. If I'm mutating the structure of a list while walking it, I'd
expect to have to do a little extra work to make that work. It's a red
flag and a concern in itself, not something I want to be so neat that
I forget about it.

But it's a fair point and in your case it's also mirroring your EACH
word that takes an XT

I don't like that HOF in this case, because it loses a lot of
flexibility vs. some very very simple control-structure code. For
example:

  : contains? ( x list -- f )
    each[
      2dup cell+ @ = if 2drop true exit then
    ]each drop false ;

With EACH you'd have to walk the remainder of the list even if you
find X right at the very front of it. Probably you'd rather have a
different HOF that accepts a flag from the XT , to tell it whether to
continue to walk the list.

Another example of flexibility:

  \ given a list of (f xt f xt ...) , execute XT if f is true
  : silly ( list -- )
    each[
      dup cell+ @ if
        @ dup cell+ @ execute
      else @ then
    ]each ;

However, putting the @ in ]EACH *does* mean that you can't as easily
start walking a different list, or restart from the beginning of the
original list. The TOS must be the address of the *next* node to be
processed.

> 1.) The internal data (in this case, the node pointer) is held on the data-stack during the execution of the user's code. This gets in the way of the user's data. The internal data needs to be held on the return-stack during the execution of the user's code so the user's data is available.

The whole point of EACH[ ]EACH is to walk a list. The list on the
stack isn't "getting in the way", rather it is "immediately
accessible".

If you've got a current object pointer in a register though, for sure
that'd be a good place to put the current node of the list. Then it's
out of the way but just as accessible.


Anyway, I don't love EACH[ ... ]EACH

Mainly I don't love the name. The premier list-processing programming
language, which is most famous for how lists are used constantly, it
should have more natural words.

  FOR NEXT
  DOLIST REPEAT
  LIST OFF
  BEGIN -NIL ... @ REPEAT
  GO THROUGH
  WALK LIST

...?

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

#55644

On Thursday, March 9, 2017 at 12:33:46 AM UTC-7, Julian Fondren wrote:
> On Thursday, March 9, 2017 at 12:28:49 AM UTC-6, hughag...@gmail.com wrote:
> But it's a fair point and in your case it's also mirroring your EACH
> word that takes an XT
> 
> I don't like that HOF in this case, because it loses a lot of
> flexibility vs. some very very simple control-structure code. For
> example:
> 
>   : contains? ( x list -- f )
>     each[
>       2dup cell+ @ = if 2drop true exit then
>     ]each drop false ;
> 
> With EACH you'd have to walk the remainder of the list even if you
> find X right at the very front of it. Probably you'd rather have a
> different HOF that accepts a flag from the XT , to tell it whether to
> continue to walk the list.

I have these:

SwiftForth? [if]

code find-node ( i*x head 'toucher -- j*x node|false )          \ toucher: i*x node -- j*x flag
    ebx push  [drop]                                \ -- node                       \r: -- 'toucher
    begin  non-zero? while
        0 [ebx] push  ebx push                      \ -- node                       \r: -- 'toucher next node
        w 2* [esp] eax mov  edi eax add  eax call   \ --
        non-zero? if  ebx pop  [2rdrop]  ret  then
        [rdrop]  ebx pop
        repeat
    [rdrop]  ret end-code

[else]

: find-node ( i*x head 'toucher -- j*x node|false )             \ toucher: i*x node -- j*x flag
    >r
    begin  dup while                                \ -- node                       \r: -- toucher
        r@  over .fore @ >r  over >r                \ -- node toucher               \r: -- toucher next node
        execute if  r>  2rdrop  exit then                                       \ return node
        rdrop  r> repeat                            \ -- next                       \r: -- toucher
    rdrop ;                                         \ return the node, which is NIL (FALSE) by now

[then]

\ FIND-NODE is like EACH except that it stops when the toucher returns true,
\ and it either returns the found node or false

SwiftForth? [if]

code find-prior ( i*x head 'toucher -- j*x -1|node|false )      \ toucher: i*x node -- j*x flag
    ebx push  [drop]                                \ -- node                       \ r: -- 'toucher
    -1 # push                                                                       \ r: -- 'toucher prior   \ prior is -1
    begin  non-zero? while
        0 [ebx] push  ebx push                      \ -- node                       \ r: -- 'toucher prior next node
        w 3 * [esp] eax mov  edi eax add  eax call  \ -- flag
        non-zero? if  [2rdrop]  ebx pop  [rdrop]  ret  then
        eax pop  ebx pop  [rdrop]  eax push
        repeat
    [2rdrop]  ret end-code

[else]

: find-prior ( i*x head 'toucher -- j*x -1|node|false )         \ toucher: i*x node -- j*x flag
    >r  -1 >r                                                   \ prior is -1, meaning found node was the head
    begin  dup while                                \ -- node                       \r: -- 'toucher prior
        rr@  over .fore @ >r  over >r               \ -- node toucher               \r: -- 'toucher prior next node
        execute if  2rdrop  r>  rdrop  exit then                                \ return prior
        2r>  rdrop  >r repeat                       \ -- next                       \r: -- 'toucher node
    2rdrop ;                                        \ return the node, which is NIL (FALSE) by now

[then]

\ FIND-PRIOR is like FIND-NODE except that it returns the node prior to the found node,
\ or -1 if the found node was the head --- or false if no node was found.

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

#55572

Hi Julian, 

The problem is and isnt the documentation.

When I say 'isnt' I mean: there are good books to read 
but there arent enough of them. And then there is whats 
available online. I am more likely to read a free book or 
blog but how many can you list ( excluding starting forth 
and thinking forth ) ? 

When I say 'is' I mean : Lets take two tutorials and you 
find they more often than not they use the same examples. 
Sure they explain it in a slightly different way but the 
bottom line is they arent showing something new.

NN

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

#55646

On Wednesday, March 8, 2017 at 8:59:39 PM UTC-7, Julian Fondren wrote:
> Hello clf,
> 
> As you all know, Forth is famous for its list processing capabilities.
> Although it has other data structures, we all reach first for the
> linked list...

My prediction for 2017 is that Stephen Pelc will resign from the Forth-200x committee and will also order his employee Peter Knaggs to resign. When this happens, Elizabeth Rather will need to appoint two new committee members to replace them.

You post was very long-winded, and it was just a load of brown-nosing with all of this talk about how ANS-Forth is famous --- there are only about 20 people on this planet who take ANS-Forth seriously --- none of them know how to implement a list-processing code-library.

I think that you are aware that two slots in the Forth-200x committee will be opening up this year --- your long-winded brown-nosing post was an attempt to attract Elizabeth Rather's attention so that she will appoint you --- also, Alex McDonald has been more active that usual recently, saying that my SORT and my <SCIENTIFIC> don't work (they work fine), so he is campaigning for the other appointment.

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

#55648

On 3/11/2017 23:23, hughaguilar96@gmail.com wrote:

>
> Alex McDonald has been more active that
> usual recently, saying that my SORT and my <SCIENTIFIC> don't work

I am quite clear that I believe you don't understand much about sorting 
and pointers, demonstrated by your hugely inefficient and over 
generalized code. Your own description of <SCIENTIFIC> not working 
didn't mean that the standard was wrong as you claimed; it meant your 
code had a bug.

> (they work fine), so he is campaigning for the other appointment.

I look forward to your support.

-- 
Alex

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

#55650

On Saturday, March 11, 2017 at 4:45:50 PM UTC-7, Alex wrote:
> On 3/11/2017 23:23, hughaguilar96@gmail.com wrote:
> 
> >
> > Alex McDonald has been more active that
> > usual recently, saying that my SORT and my <SCIENTIFIC> don't work
> 
> I am quite clear that I believe you don't understand much about sorting 
> and pointers, demonstrated by your hugely inefficient and over 
> generalized code. Your own description of <SCIENTIFIC> not working 
> didn't mean that the standard was wrong as you claimed; it meant your 
> code had a bug.
> 
> > (they work fine), 

I rewrote <# etc. so that they would work --- that was where the bug was --- this wasn't a bug in VFX's implementation though, because VFX was following the ANS-Forth standard.

My <SCIENTIFIC> didn't have any bug.

> so he is campaigning for the other appointment.
> 
> I look forward to your support.

You've got my support! 

I 100% support Alex McDonald and Julien Fondren being appointed to the Forth-200x committee --- I have predicted that Stephen Pelc and his employee Peter Knaggs will resign in 2017 --- Elizabeth Rather will need to appoint two new committee members to take their places, and there is nobody better qualified than Alex McDonald and Julien Fondren.

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

#55667

On Saturday, March 11, 2017 at 6:24:43 PM UTC-6, hughag...@gmail.com wrote:
> You've got my support! 
> 
> I 100% support Alex McDonald and Julien Fondren being appointed to the Forth-200x committee ... there is nobody better qualified than Alex McDonald and Julien Fondren.

I appreciate how hard it must have been for you to say this.

Once I am appointed to the Forth-200x committee, I will pursue a
four-point plan to immediately improve the language:

> 1.) Mandate the W D F constants for data-type sizes to obtain portability between 16-bit, 32-bit and 64-bit systems.

1. Mandate the CELLS and FLOATS words for data-type sizes to obtain
portability between 16-bit, 32-bit and 64-bit systems.

> 2.) Mandate that LITERAL etc. should be vectored so we can have literal numbers in TARG colon words in a cross-compiler. 

2. Declare that cross-compilers are not important. Forth shall not
become a language that people use *only* to write a cross-compiler in.
I'm honestly quite sick of all the "look at my cross compiler", "am I
doing this cross compiler right?", "my cross compiler isn't working on
gforth after upgrading!" posts that plague clf.

> 3.) Mandate { ... } (the John Hopkins format) for locals, make the locals provide an address, and make the locals large enough to hold doubles and floats as well as singles. 

3. Mandate that Forth provide and document no less than three (3)
stacks: data, return, and float, so that Forth code can pass data
among words without having to stuff everything into the dictionary. At
the forefront of programming language research we find
combinator-heavy, 'point-free' programming in Haskell, and I believe
that Forth can adopt this style of programming at an even more
fundamental level.

> 4.) Mandate that my rquotations work. 

4. Mandate the formalization of a 'control stack' and a control-flow
vocabulary that is both closer to the machine and much more flexible
than legacy quotations-only control flow. It should be possible to
write new control-flow words without resort to compiler hacks!  Yes,
these new BEGIN WHILE IF ELSE words are not as 'postfix', and I admit
that quotations have a readability niche, but the advantages of
'coding with branches' must not be ignored any longer.

I will not mandate, but I will *strongly* suggest that literally every
Forth of note remain capable of elaborate return-stack manipulation,
as a powerful alternative to quotations.  Consider the following:

  begin-structure lab-item
    cell + ( cdr )
    cell +field odd?
    128 +field prefix
  end-structure
  
  variable labs
  
  : lab ( "prefix" f-odd? -- )
    lab-item allocate throw
    labs @ over ! dup labs !
    tuck odd? !
    parse-name rot prefix place ;
  
  : call ( cont -- )  >r ;
  : this ( -- x )     r> r> r@ -rot >r >r ; 
  
  : each-lab ( -- )  \ this cont: ( -- ) 
    labs @ begin dup while
      r@ swap >r call
    r> @ repeat drop r> drop ;
  
  : .labs ( -- )
    each-lab
    cr this odd? ? ." lab " this prefix count type ;
  
   0 lab LABX7
   0 lab LABX5
   0 lab LABX3
  -1 lab LABN11
  -1 lab LRC

And then look at this interaction under a so-called 'optimizing'
compiler:

  include labs.fs
  Including labs.fs
  PREFIX is redefined  ok
  .labs
  -1 lab LRC
  -1 lab LABN11
  0 lab LABX3
  0 lab LABX5
  0 lab LABX7 ok


Outrageous.

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

#55668

On 3/11/17 7:14 PM, Julian Fondren wrote:
> 2. Declare that cross-compilers are not important. Forth shall not
> become a language that people use *only* to write a cross-compiler in.
> I'm honestly quite sick of all the "look at my cross compiler", "am I
> doing this cross compiler right?", "my cross compiler isn't working on
> gforth after upgrading!" posts that plague clf.

In the late 90's a great deal of work went into proposing a separate 
cross-compiler standard. It's worth doing, because embedded systems have 
always been, and continue to be, a major application area for Forth. 
However, the difficulties of incorporating cross-compiler features in a 
main-stream Forth standard are great. I hope that work can resume on the 
cross-compiler standard by a separate (though overlapping) working 
group. An overview of this effort is here 
http://oco.org.ua/wp-content/files/m3forth/XCpaper.pdf.

Cheers,
Elizabeth

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

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

#55671

On Sunday, March 12, 2017 at 6:29:24 AM UTC+1, Elizabeth D. Rather wrote:
> On 3/11/17 7:14 PM, Julian Fondren wrote:
> > 2. Declare that cross-compilers are not important. Forth shall not
> > become a language that people use *only* to write a cross-compiler in.
> > I'm honestly quite sick of all the "look at my cross compiler", "am I
> > doing this cross compiler right?", "my cross compiler isn't working on
> > gforth after upgrading!" posts that plague clf.
> 
> In the late 90's a great deal of work went into proposing a separate
> cross-compiler standard. It's worth doing, because embedded systems have
> always been, and continue to be, a major application area for Forth.
> However, the difficulties of incorporating cross-compiler features in a
> main-stream Forth standard are great. I hope that work can resume on the
> cross-compiler standard by a separate (though overlapping) working
> group. An overview of this effort is here
> http://oco.org.ua/wp-content/files/m3forth/XCpaper.pdf.
>
> Cheers,
> Elizabeth

A cross-compiler could be a straightforward way to allow
compiled, optimized, minimum size, Forth applications.
The main difficulty is agreeing on where such a compiled
app is allowed to differ from its interpreted source.

I find it strange that this is not one of the main 
thrusts of the standardizing effort.

-marcel

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

#55718

On Saturday, March 11, 2017 at 10:29:24 PM UTC-7, Elizabeth D. Rather wrote:
> On 3/11/17 7:14 PM, Julian Fondren wrote:
> > 2. Declare that cross-compilers are not important. Forth shall not
> > become a language that people use *only* to write a cross-compiler in.
> > I'm honestly quite sick of all the "look at my cross compiler", "am I
> > doing this cross compiler right?", "my cross compiler isn't working on
> > gforth after upgrading!" posts that plague clf.
> 
> In the late 90's a great deal of work went into proposing a separate 
> cross-compiler standard. It's worth doing, because embedded systems have 
> always been, and continue to be, a major application area for Forth. 
> However, the difficulties of incorporating cross-compiler features in a 
> main-stream Forth standard are great. I hope that work can resume on the 
> cross-compiler standard by a separate (though overlapping) working 
> group. An overview of this effort is here 
> http://oco.org.ua/wp-content/files/m3forth/XCpaper.pdf.

I think that you purposely sabotaged ANS-Forth to prevent cross-compilers from being written by common Forth in competition with Forth Inc. and MPE.

The primary failing of ANS-Forth is that LITERAL etc. are not vectored. If they were vectored, then they could be revectored by the TARG colon and the restored by semicolon again --- this is so we could have literal numbers inside of TARG colon words and these, when given to LITERAL by the outer-interpreter, would compile into TARG memory rather than into HOST memory.

In my MFX, I was only able to support literal numbers in TARG colon words like this:
[ 12345 ] LITERAL
By explicitly using LITERAL I was able to use my own LITERAL rather than the LITERAL that is used by the outer-interpreter. I shortened this somewhat:
[ 12345 ]L
I have also heard of cross-compilers that do this:
S# 12345

All of this is crap! This is not Forth --- ANS-Forth is not capable of supporting a cross-compiler that compiles ANS-Forth --- that is just gross sabotage on your part.

Because of the failure of ANS-Forth to have a vectored LITERAL (also 2LITERAL and FLITERAL) it is not possible to write a cross-compiler in ANS-Forth that uses the built-in outer-interpreter and supports literal numbers inside of TARG colon words. You and your the Forth-200x committee members that you appointed absolutely refuse to make a vectored LITERAL part of the standard --- this would be a trivial upgrade --- you refuse to do this because you want to prevent Forth programmers from writing a cross-compiler in standard Forth that uses the built-in outer-interpreter because Forth Inc. and MPE make most of their money by selling cross-compilers.

You also sabotaged FIND in ANS-Forth. We now have SwiftForth, VFX and Gforth that all have a FIND that is incompatible with each other, yet all of them claim to be ANS-Forth compliant --- the definition of FIND is ambiguous so all of them can interpret the definition differently and yet be ANS-Forth compliant. 

I work around your sabotaged FIND however! My disambiguifiers make FIND work in a way that makes sense, and is consistent between all three ANS-Forth compilers.

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

#55670

On Sunday, March 12, 2017 at 6:14:15 AM UTC+1, Julian Fondren wrote:
[..]
> I will not mandate, but I will *strongly* suggest that literally every
> Forth of note remain capable of elaborate return-stack manipulation,
> as a powerful alternative to quotations.  Consider the following:
> 
[ code ]
> Outrageous.

To try it in iForth, include
"needs -structs" and define
: place pack drop ;
to get the non-standard words.

Then add [ -opt ] to dumb down the
r-stack manipulations in CALL and THIS .

I have no idea if the final output is what you want
to see -- to me the only clearly outrageous thing in
this code is its deliberate lack of documentation :-)

==============
NEEDS -structs
: place pack drop ;
ANEW -labs

begin-structure lab-item
    cell + ( cdr )
    cell +field odd?
    128 +field prefix
end-structure

variable labs

: lab ( "prefix" f-odd? -- )
    lab-item allocate throw
    labs @ over ! dup labs !
    tuck odd? !
    parse-name rot prefix place ;
  
: call ( cont -- )  >r [ -opt ] ;
: this ( -- x )     r> r> r@ -rot >r >r [ -opt ] ;

: each-lab ( -- )  \ this cont: ( -- )
    labs @ begin dup while
      r@ swap >r call
    r> @ repeat drop r> drop ;
  
: .labs ( -- )
    each-lab
    cr this odd? ? ." lab " this prefix count type ;
  
   0 lab LABX7
   0 lab LABX5
   0 lab LABX3
  -1 lab LABN11
  -1 lab LRC

\  .labs
\  -1 lab LRC
\  -1 lab LABN11
\  0 lab LABX3
\  0 lab LABX5
\  0 lab LABX7
==============

-marcel

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

#55699

On Sunday, March 12, 2017 at 3:24:14 AM UTC-5, m...@iae.nl wrote:
> On Sunday, March 12, 2017 at 6:14:15 AM UTC+1, Julian Fondren wrote:
> [..]
> > I will not mandate, but I will *strongly* suggest that literally every
> > Forth of note remain capable of elaborate return-stack manipulation,
> > as a powerful alternative to quotations.  Consider the following:
> > 
> [ code ]
> > Outrageous.
> 
> To try it in iForth, include
> "needs -structs" and define
> : place pack drop ;
> to get the non-standard words.
> 
> Then add [ -opt ] to dumb down the
> r-stack manipulations in CALL and THIS .
> 

Oh.

I got this working in iForth and then wrote a benchmark to time
different versions: this one, an EACH[ ... ]EACH version without
tricks or HOFs (labs2), an XT-receiving version (labs3), and a
continuation-using version that passes the list on the data stack
instead of return stack (labs4).

The benchmark seemed to indicate that I'd picked for this post the
slowest possible version by a huge margin, but I was using -OPT
wrong.  With correct -OPT (and with I/O words temporarily replaced
with DROPs):

  0.089 seconds elapsed..labs
  0.055 seconds elapsed..labs2
  0.054 seconds elapsed..labs3
  0.055 seconds elapsed..labs4 ok

it's only consistently 50% slower. And there are no longer any
differences in the runtime for the others! That last version:

  : each-lab4 ( -- )  r> LOCAL cont ( x -- x )
    labs @ begin dup while
      cont call
    @ repeat drop ;

  : .labs4 ( -- )
    each-lab4
    cr dup odd? ? ." lab " dup prefix count type ;

> I have no idea if the final output is what you want
> to see -- to me the only clearly outrageous thing in
> this code is its deliberate lack of documentation :-)
> 

The output's correct. LABS is a list of prefixes and an oddity boolean
for the names of workstations in different physical labs in a
college. The full names are the prefix + a number, and odd ones are
different (IIRC they didn't have 0 padding).

So there might be, on the LAN:

  LRC1
  LRC2
  LRC3
  LABX3001
  LABX3002
  LABX3003

The full application would discover these (by their successful DNS
resolution) and then permit some administration of them.

Rewriting this in Forth turned the workstation discovery step from
"I'll run this and then come back in an hour." to "I'll run this
and--oh it's done instantly." Though only because writing it in Forth
permitted the use of Windows API calls and cached DNS.

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

#55672

Am Sonntag, 12. März 2017 06:14:15 UTC+1 schrieb Julian Fondren:
> On Saturday, March 11, 2017 at 6:24:43 PM UTC-6, hughag...@gmail.com wrote:
> > You've got my support! 
> > 
> > I 100% support Alex McDonald and Julien Fondren being appointed to the Forth-200x committee ... there is nobody better qualified than Alex McDonald and Julien Fondren.
> 
> I appreciate how hard it must have been for you to say this.
> 
> Once I am appointed to the Forth-200x committee, I will pursue a
> four-point plan to immediately improve the language:
> 
> > 1.) Mandate the W D F constants for data-type sizes to obtain portability between 16-bit, 32-bit and 64-bit systems.
> 
> 1. Mandate the CELLS and FLOATS words for data-type sizes to obtain
> portability between 16-bit, 32-bit and 64-bit systems.
> 
> > 2.) Mandate that LITERAL etc. should be vectored so we can have literal numbers in TARG colon words in a cross-compiler. 
> 
> 2. Declare that cross-compilers are not important. Forth shall not
> become a language that people use *only* to write a cross-compiler in.
> I'm honestly quite sick of all the "look at my cross compiler", "am I
> doing this cross compiler right?", "my cross compiler isn't working on
> gforth after upgrading!" posts that plague clf.
> 
> > 3.) Mandate { ... } (the John Hopkins format) for locals, make the locals provide an address, and make the locals large enough to hold doubles and floats as well as singles. 
> 
> 3. Mandate that Forth provide and document no less than three (3)
> stacks: data, return, and float, so that Forth code can pass data
> among words without having to stuff everything into the dictionary. At
> the forefront of programming language research we find
> combinator-heavy, 'point-free' programming in Haskell, and I believe
> that Forth can adopt this style of programming at an even more
> fundamental level.
> 
> > 4.) Mandate that my rquotations work. 
> 
> 4. Mandate the formalization of a 'control stack' and a control-flow
> vocabulary that is both closer to the machine and much more flexible
> than legacy quotations-only control flow. It should be possible to
> write new control-flow words without resort to compiler hacks!  Yes,
> these new BEGIN WHILE IF ELSE words are not as 'postfix', and I admit
> that quotations have a readability niche, but the advantages of
> 'coding with branches' must not be ignored any longer.
> 
> I will not mandate, but I will *strongly* suggest that literally every
> Forth of note remain capable of elaborate return-stack manipulation,
> as a powerful alternative to quotations.  Consider the following:
> 
>   begin-structure lab-item
>     cell + ( cdr )
>     cell +field odd?
>     128 +field prefix
>   end-structure
>   
>   variable labs
>   
>   : lab ( "prefix" f-odd? -- )
>     lab-item allocate throw
>     labs @ over ! dup labs !
>     tuck odd? !
>     parse-name rot prefix place ;
>   
>   : call ( cont -- )  >r ;
>   : this ( -- x )     r> r> r@ -rot >r >r ; 
>   
>   : each-lab ( -- )  \ this cont: ( -- ) 
>     labs @ begin dup while
>       r@ swap >r call
>     r> @ repeat drop r> drop ;
>   
>   : .labs ( -- )
>     each-lab
>     cr this odd? ? ." lab " this prefix count type ;
>   
>    0 lab LABX7
>    0 lab LABX5
>    0 lab LABX3
>   -1 lab LABN11
>   -1 lab LRC
> 
> And then look at this interaction under a so-called 'optimizing'
> compiler:
> 
>   include labs.fs
>   Including labs.fs
>   PREFIX is redefined  ok
>   .labs
>   -1 lab LRC
>   -1 lab LABN11
>   0 lab LABX3
>   0 lab LABX5
>   0 lab LABX7 ok
> 
> 
> Outrageous.

*grin*  scratching with the chicken, isn't it?

as long as there is no consensus for "complex" data processing words (bitfields, strings, stacks, lists, queues, decks, etc) Forth remains in the small systems niche.

and the foundations for data processing words are: libraries and OO

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

#55773

 
> > Outrageous.
> 
> *grin*  scratching with the chicken, isn't it?
> 
> as long as there is no consensus for "complex" data processing words (bitfields, strings, stacks, lists, queues, decks, etc) Forth remains in the small systems niche.
> 
> and the foundations for data processing words are: libraries and OO

Is consensus is formed by usage & what users want? Then the are libraries out there. We just have to use them.

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

#55673

On 12/03/2017 7:14, Julian Fondren wrote:
> On Saturday, March 11, 2017 at 6:24:43 PM UTC-6, hughag...@gmail.com wrote:
>> You've got my support! 
>>
>> I 100% support Alex McDonald and Julien Fondren being appointed to the Forth-200x committee ... there is nobody better qualified than Alex McDonald and Julien Fondren.
> 
> I appreciate how hard it must have been for you to say this.
> 
> Once I am appointed to the Forth-200x committee, I will pursue a
> four-point plan to immediately improve the language:

You need a five-year plan.

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

#55710

On Sunday, March 12, 2017 at 7:14:15 AM UTC+2, Julian Fondren wrote:
> On Saturday, March 11, 2017 at 6:24:43 PM UTC-6, hughag...@gmail.com wrote:
> > You've got my support! 
> > 
> > I 100% support Alex McDonald and Julien Fondren being appointed to the Forth-200x committee ... there is nobody better qualified than Alex McDonald and Julien Fondren.
> 
> I appreciate how hard it must have been for you to say this.
> 
> Once I am appointed to the Forth-200x committee, I will pursue a
> four-point plan to immediately improve the language:
> 
> > 1.) Mandate the W D F constants for data-type sizes to obtain portability between 16-bit, 32-bit and 64-bit systems.
> 
> 1. Mandate the CELLS and FLOATS words for data-type sizes to obtain
> portability between 16-bit, 32-bit and 64-bit systems.
> 
> > 2.) Mandate that LITERAL etc. should be vectored so we can have literal numbers in TARG colon words in a cross-compiler. 
> 
> 2. Declare that cross-compilers are not important. Forth shall not
> become a language that people use *only* to write a cross-compiler in.
> I'm honestly quite sick of all the "look at my cross compiler", "am I
> doing this cross compiler right?", "my cross compiler isn't working on
> gforth after upgrading!" posts that plague clf.
> 
> > 3.) Mandate { ... } (the John Hopkins format) for locals, make the locals provide an address, and make the locals large enough to hold doubles and floats as well as singles. 
> 
> 3. Mandate that Forth provide and document no less than three (3)
> stacks: data, return, and float, so that Forth code can pass data
> among words without having to stuff everything into the dictionary. At
> the forefront of programming language research we find
> combinator-heavy, 'point-free' programming in Haskell, and I believe
> that Forth can adopt this style of programming at an even more
> fundamental level.
> 
> > 4.) Mandate that my rquotations work. 
> 
> 4. Mandate the formalization of a 'control stack' and a control-flow
> vocabulary that is both closer to the machine and much more flexible
> than legacy quotations-only control flow. It should be possible to
> write new control-flow words without resort to compiler hacks!  Yes,
> these new BEGIN WHILE IF ELSE words are not as 'postfix', and I admit
> that quotations have a readability niche, but the advantages of
> 'coding with branches' must not be ignored any longer.
> 
> I will not mandate, but I will *strongly* suggest that literally every
> Forth of note remain capable of elaborate return-stack manipulation,
> as a powerful alternative to quotations.  Consider the following:
> 
>   begin-structure lab-item
>     cell + ( cdr )
>     cell +field odd?
>     128 +field prefix
>   end-structure
>   
>   variable labs
>   
>   : lab ( "prefix" f-odd? -- )
>     lab-item allocate throw
>     labs @ over ! dup labs !
>     tuck odd? !
>     parse-name rot prefix place ;
>   
>   : call ( cont -- )  >r ;
>   : this ( -- x )     r> r> r@ -rot >r >r ; 
>   
>   : each-lab ( -- )  \ this cont: ( -- ) 
>     labs @ begin dup while
>       r@ swap >r call
>     r> @ repeat drop r> drop ;
>   
>   : .labs ( -- )
>     each-lab
>     cr this odd? ? ." lab " this prefix count type ;
>   
>    0 lab LABX7
>    0 lab LABX5
>    0 lab LABX3
>   -1 lab LABN11
>   -1 lab LRC
> 
> And then look at this interaction under a so-called 'optimizing'
> compiler:
> 
>   include labs.fs
>   Including labs.fs
>   PREFIX is redefined  ok
>   .labs
>   -1 lab LRC
>   -1 lab LABN11
>   0 lab LABX3
>   0 lab LABX5
>   0 lab LABX7 ok
> 
> 
> Outrageous.

Hi!

Alternative HOF (untested):

: each::  ( node -- )  >r begin r@ while r> r@ over @ >r call repeat 2rdrop ;

: .labs  ( -- )  labs each:: ( node) dup odd? ? ." lab " ( node) prefix count type ;

--
humptyd

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

#55711

On Sunday, March 12, 2017 at 7:14:15 AM UTC+2, Julian Fondren wrote:
> On Saturday, March 11, 2017 at 6:24:43 PM UTC-6, hughag...@gmail.com wrote:
> > You've got my support! 
> > 
> > I 100% support Alex McDonald and Julien Fondren being appointed to the Forth-200x committee ... there is nobody better qualified than Alex McDonald and Julien Fondren.
> 
> I appreciate how hard it must have been for you to say this.
> 
> Once I am appointed to the Forth-200x committee, I will pursue a
> four-point plan to immediately improve the language:
> 
> > 1.) Mandate the W D F constants for data-type sizes to obtain portability between 16-bit, 32-bit and 64-bit systems.
> 
> 1. Mandate the CELLS and FLOATS words for data-type sizes to obtain
> portability between 16-bit, 32-bit and 64-bit systems.
> 
> > 2.) Mandate that LITERAL etc. should be vectored so we can have literal numbers in TARG colon words in a cross-compiler. 
> 
> 2. Declare that cross-compilers are not important. Forth shall not
> become a language that people use *only* to write a cross-compiler in.
> I'm honestly quite sick of all the "look at my cross compiler", "am I
> doing this cross compiler right?", "my cross compiler isn't working on
> gforth after upgrading!" posts that plague clf.
> 
> > 3.) Mandate { ... } (the John Hopkins format) for locals, make the locals provide an address, and make the locals large enough to hold doubles and floats as well as singles. 
> 
> 3. Mandate that Forth provide and document no less than three (3)
> stacks: data, return, and float, so that Forth code can pass data
> among words without having to stuff everything into the dictionary. At
> the forefront of programming language research we find
> combinator-heavy, 'point-free' programming in Haskell, and I believe
> that Forth can adopt this style of programming at an even more
> fundamental level.
> 
> > 4.) Mandate that my rquotations work. 
> 
> 4. Mandate the formalization of a 'control stack' and a control-flow
> vocabulary that is both closer to the machine and much more flexible
> than legacy quotations-only control flow. It should be possible to
> write new control-flow words without resort to compiler hacks!  Yes,
> these new BEGIN WHILE IF ELSE words are not as 'postfix', and I admit
> that quotations have a readability niche, but the advantages of
> 'coding with branches' must not be ignored any longer.
> 
> I will not mandate, but I will *strongly* suggest that literally every
> Forth of note remain capable of elaborate return-stack manipulation,
> as a powerful alternative to quotations.  Consider the following:
> 
>   begin-structure lab-item
>     cell + ( cdr )
>     cell +field odd?
>     128 +field prefix
>   end-structure
>   
>   variable labs
>   
>   : lab ( "prefix" f-odd? -- )
>     lab-item allocate throw
>     labs @ over ! dup labs !
>     tuck odd? !
>     parse-name rot prefix place ;
>   
>   : call ( cont -- )  >r ;
>   : this ( -- x )     r> r> r@ -rot >r >r ; 
>   
>   : each-lab ( -- )  \ this cont: ( -- ) 
>     labs @ begin dup while
>       r@ swap >r call
>     r> @ repeat drop r> drop ;
>   
>   : .labs ( -- )
>     each-lab
>     cr this odd? ? ." lab " this prefix count type ;
>   
>    0 lab LABX7
>    0 lab LABX5
>    0 lab LABX3
>   -1 lab LABN11
>   -1 lab LRC
> 
> And then look at this interaction under a so-called 'optimizing'
> compiler:
> 
>   include labs.fs
>   Including labs.fs
>   PREFIX is redefined  ok
>   .labs
>   -1 lab LRC
>   -1 lab LABN11
>   0 lab LABX3
>   0 lab LABX5
>   0 lab LABX7 ok
> 
> 
> Outrageous.

Hi! 

Alternative HOF (untested): 

: each::  ( node -- )  >r begin r@ while r> r@ over @ >r call repeat 2rdrop ; 

: .labs  ( -- )  labs @ each:: ( node) dup odd? ? ." lab " ( node) prefix count type ; 

-- 
humptyd 

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

#55719

On Saturday, March 11, 2017 at 10:14:15 PM UTC-7, Julian Fondren wrote:
> On Saturday, March 11, 2017 at 6:24:43 PM UTC-6, hughag...@gmail.com wrote:
> > You've got my support! 
> > 
> > I 100% support Alex McDonald and Julien Fondren being appointed to the Forth-200x committee ... there is nobody better qualified than Alex McDonald and Julien Fondren.
> 
> I appreciate how hard it must have been for you to say this.
> 
> Once I am appointed to the Forth-200x committee, I will pursue a
> four-point plan to immediately improve the language: ...

It wasn't hard for me to write this --- it was hard for me to keep myself from laughing out loud while writing this.

I am trying to kill ANS-Forth and its deformed spawn Forth-200x. If Elizabeth Rather appoints Alex McDonald and Julien Fondren to the Forth-200x committee this will certainly kill Forth-200x --- both of you are dumber than a box of hammers --- nobody will take Forth-200x seriously when they find out that Elizabeth Rather has appointed Dumb and Dumber to be their leaders.

My prediction is that Stephen Pelc and his employee Peter Knaggs will resign from the Forth-200x committee in 2017. Forth-200x is just getting stupider by the day --- when the stupidometer hits 10 they will resign --- the stupidometer is at about 8 or 9 right now...

I think that Alex McDonald and Julien Fondren are purposely trying to red-line the stupidometer for the purpose of forcing Stephen Pelc and Peter Knaggs to resign --- they know that Elizabeth Rather will need to appoint two new Forth-200x committee members to replace them --- they know that they are the most likely candidates because nobody else is as loyal to ANS-Forth as they are.

I think that the reason why Stephen Pelc and his employee Peter Knaggs haven't yet resigned is because they know that Elizabeth Rather will continue to list their names as supporters of Forth-200x. They are embarrassed by this, as it implies that Elizabeth Rather never wanted their expertise, but only wanted their names. Also, this shows that they are too poor to hire a lawyer to file a libel lawsuit --- they are just a pair of schmucks with no legal standing.

Both Ray Duncan and Charles Moore were opposed to ANS-Forth, but Elizabeth Rather continued to list their names as supporters on the ANS-Forth document. Charles Moore made his exit speech in 1989 (I have a copy of the speech) yet Elizabeth Rather sent the ANS-Forth document to ANSI with Charles Moore's name listed as a supporter --- ANSI doesn't know anything about Forth, but they do know that Charles Moore is the inventor and hence that he alone has the right to define a Forth standard --- when ANSI saw his name on the document, they rubber-stamped it.

Elizabeth Rather is a professional name-dropper --- her entire career is built on claiming that people who have accomplishments support her --- she is also a liar, as none of these people actually support her.

I quit the Forth-200x mailing list. I also have consistently spoken out against the Paysan-faked quotations. Yet, Alex McDonald listed my name on the RfD for the Paysan-faked quotations as a supporter. I threatened a libel lawsuit if Forth-200x continued to list my name as a supporter on the Rfd. At this time, Alex McDonald disappeared and the RfD was left in limbo. Later, Anton Ertl began pushing the RfD himself, and he also listed my name as a supporter. Once again, I threatened a libel lawsuit if Forth-200x continued to list my name as a supporter on the Rfd. At this time Anton Ertl removed my name from the RfD. If the Forth-200x committee puts my name back in as a supporter, then I really will hit Forth-200x with a libel lawsuit.

The only purpose of the Forth-200x mailing-list is that Elizabeth Rather can collect names of people who are interested in Forth and can list them as supporters --- she doesn't actually care about their suggestions --- she just wants their names so she can list them as supporters, because she is a professional name-dropper.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web