Call for Papers EuroForth 2019

[Anton Ertl]

EuroForth 2019 will be held in Hamburg, Germany on September 13-15.

The deadline for the academic stream (refereed) papers is June 30. So
now is the time to write up your research to have it ready by the
deadline. For industrial (non-refereed) papers the deadline is August
31.

The call for papers including submission instructions can be found on
<http://www.euroforth.org/ef19/cfp.html>. The conference home page
(including registration) is: <http://euro.theforth.net/>

All dates known up to now:

June 30: Deadline for draft papers (academic stream)
July 31: Notification of acceptance of academic stream papers
August 31: Deadline for camera-ready paper submission
September 11-13: Forth200x meeting
September 13-15: EuroForth 2019 conference

Paper proceedings are available at the conference, and online
proceedings (usually also including slides for presentations without
papers) are made available after the conference.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2019: http://euro.theforth.net/

[hughag...@gmail.com]

If anybody in the real world is going to take EuroForth seriously,
the following rules need to be made and enforced:

1.) No paper will be accepted if there is no proof-of-concept
code accompanying it. If the author is too incompetent to write
code that works, then his or her paper is not acceptable.
Vague speculation about what might work does not constitute design.

2.) No paper will be accepted if it is just an attack piece that
denounces existing code. This is not a positive contribution.
EuroForth should be a forum for presenting new designs, not attacking
other people's designs and code libraries.

At this time, because these rules are not in place, and most papers
would not be in compliance with these rules, EuroForth lacks
credibility in the real world. So far, what I have seen is that
the worst violators of these rules are Forth-200x committee members.
They are just dumb and mean --- they are not making a positive
contribution to Forth --- they have a political axe to grind.
Note that Anton Ertl is the referee for the "academic" papers,
yet he writes papers himself that grossly violate the above rules.

[hughag...@gmail.com]

On Wednesday, June 12, 2019 at 10:11:21 AM UTC-7, Anton Ertl wrote:

> The call for papers including submission instructions can be found on
> <http://www.euroforth.org/ef19/cfp.html>.

Eaker's CASE is the most useful aspect of ANS-Forth.
It is useful for supporting the claim by C programmers
that Forth programmers are low-functioning retards.
This is because any C programmer, even a high-school student,
can easily see that Eaker's CASE is utterly retarded.

Pretty much everything about ANS-Forth is retarded,
but most aspects are confusing and obscure.
For example, we have section 3.2.3.2:
--------------------------------------------------------
The control-flow stack may, but need not, physically exist
in an implementation. If it does exist, it may be, but need not be,
implemented using the data stack. The format of the control-flow stack
is implementation defined. Since the control-flow stack may be implemented
using the data stack, items placed on the data stack are unavailable
to a program after items are placed on the control-flow stack
and remain unavailable until the control-flow stack items are removed.
--------------------------------------------------------

This is utterly retarded! To understand how retarded this is though,
it is necessary to know what meta-compilation is.
Most C programmers don't know what meta-compilation is,
so they don't understand why it was retarded for Elizabeth Rather
to fail to provide a control-flow stack distinct from the data-stack.

On the other hand, Eaker's CASE is obviously retarded.
Anybody with one year of programming experience in C or pretty much
any other language (including HLA) can immediately understand
why putting Eaker's CASE in ANS-Forth was retarded.

If we follow Anton Ertl's link above we come to this:
http://www.complang.tuwien.ac.at/anton/paper-criteria.html
Anton Ertl is making a fool of himself by pretending that
EuroForth has academic standards.
He is ignoring the mental retardation stigma of ANS-Forth.
He asks questions such as these:
"Is the idea supported with an experimental implementation or data?"
"Is there enough evidence that the paper is at the edge of its domain?"
Within the context of the ANS-Forth' reputation for mental retardation,
pseudo-academic puffery such as this is going to result in gales of laughter,
even among high-school students who are just barely learning C.

I challenge the Forth-200x committee to put their heads together
and write a substitute for Eaker's CASE that isn't retarded.
So far, the only attempt made was by Andrew Haley:
https://wiki.forth-ev.de/doku.php/events:ef2018:case
His only Forth experience was teaching the Forth Inc. novice class,
so he unsurprisingly failed to write any working Forth code.
All he had was a vague dream about how a perfect hash function
would be super-duper (in a word: "perfect").
He isn't going to succeed in writing Forth code, but maybe if all
the Forth-200x committee members work together they can succeed.

These are the criteria they need to meet to succeed:
1.) Their code can be no more than twice as complicated as my code.
2.) Their generated code can be no less that half as efficient as my code.
3.) They can't copy my code or my algorithm.

This is my code (mostly written in 2016 IIRC):
----------------------------------------------------------------------
\ ******
\ ****** This is a <SWITCH control-structure like in C that generates a jump-table.
\ ******

\ You can build a colon word called XXX that switches on targ values. This is how:
\ <SWITCH
\ :NONAME ... ; targ CASE-OF
\ ...
\ :NONAME ... ; FAST-SWITCH> xxx ( selector -- )

\ There are some simple additions as well: RANGE-OF CHARS-OF for a range of values or a set of chars.
\ Also, we have CASE: suggested by DXForth that can be used instead of CASE-OF .

\ The colon word XXX executes a table-entry corresponding to the targ value.
\ If there is no match, then the xt value prior to FAST-SWITCH> is executed as the default.
\ All of the table-entries and the default are given the selector value which they DROP if not needed.
\ It was HAA's suggestion that the selector value be provided --- I had dropped it internally previously.

\ The targ values don't have to be provided in any particular order --- they get sorted internally.
\ If a duplicate targ value is provided, CASE-OF will abort with an error message at compile-time.

\ This is pretty crude because, unlike in C, the table entries can't have common local variables.
\ I would have liked to use my rquotations, but they don't have an xt that is known at compile-time,
\ so it is not possible to build a jump-table at compile-time. They have a "continuation" that is only known at run-time.
\ My <SWITCH that I have here uses :NONAME for the table entries --- they can have common global variables.

\ FAST-SWITCH> uses the selector value as an index to do the table look up. This is very fast.
\ If the range is too large however, then FAST-SWITCH> will abort with an error message to save memory.
\ In this case, use SLOW-SWITCH> instead. This builds a smaller table and uses BSEARCH to look up the table-entry.

\ Set JT-LIMIT to the range that you want FAST-SWITCH> to support.
\ It is currently set at 2^16 so you can have jump-tables with up to 64K entries. These consume a lot of memory.
\ If memory usage is an issue, then set JT-LIMIT to a smaller value. Use SLOW-SWITCH> instead of FAST-SWITCH>.
\ If the jump-table is sparse, SLOW-SWITCH> might be faster because there is less data-cache thrashing.

\ <SWITCH is primarily provided for writing VM simulators.
\ JT-LIMIT is currently set at 2^16, so it supports simulating a micro-processor with 16-bit opcodes (such as the AVR).
\ SLOW-SWITCH> would be needed for a micro-processor with 32-bit opcodes (such as the ARM or MIPS).

\ Some micro-processors (or byte-code VMs) have 8-bit opcodes, but also have post-bytes on some of the opcodes.
\ These variable-sized opcodes could be done with nested FAST-SWITCH> constructs.

list
w field .xt
w field .targ
constant jt

: init-jt ( xt targ node -- node )
init-list >r
r@ .targ !
r@ .xt !
r> ;

: new-jt ( xt targ -- node )
jt alloc
init-jt ;

: kill-jt ( head -- )
each[ dealloc ]each ;

: show-jt ( head -- )
each[ cr .targ @ . ]each ;

: jt> ( new-node node -- new-node flag ) \ used by INSERT-ORDERED to build an ascending list without duplicates
.targ @ over .targ @
2dup = abort" *** <SWITCH structures not allowed to have duplicate targ values ***"
> ;

: <switch ( -- head )
nil ;

: case-of ( head xt targ -- new-head ) \ provide a targ value
new-jt \ -- head node
['] jt> swap insert-ordered drop ;

: range-of { head xt lo hi -- new-head } \ provide a range from LO to HI inclusive
head
hi 1+ lo do
xt I case-of
loop ;

: chars-of { head xt adr cnt -- new-head } \ provide a string containing targ chars
head
adr cnt + adr do
xt I c@ case-of
loop ;

: digit-of ( head xt -- new-head )
[char] 0 [char] 9 range-of ;

: lower-of ( head xt -- new-head )
[char] a [char] z range-of ;

: upper-of ( head xt -- new-head )
[char] A [char] Z range-of ;

: alpha-of { head xt -- new-head }
head
xt lower-of xt upper-of ;

: punctuation-of ( head xt -- new-head )
s| .,!?'";:[]()@#$%&| chars-of ;

: blank-of ( head xt -- new-head )
0 32 range-of ;

1 16 lshift value jt-limit \ should be at least 256 so we can support byte-code simulators

\ JT-LIMIT is the index that is too big for the jump-table. This can be any reasonable size.
\ The jump-table size is limited so the programmer doesn't accidentally build a jump-table consuming megabytes.
\ I set it at 2^16 to support simulating a micro-processor with 16-bit opcodes.

: fast-switch> { head default | adr offset size -- } \ stream: name
align here to adr
head .targ @ to offset
head tail .targ @ offset - to size
size jt-limit u> abort" *** FAST-SWITCH> has too large of a range. Use SLOW-SWITCH> instead. ***"
offset head each[ >r \ -- targ
begin r@ .targ @ over <> while default , 1+ repeat
r> .xt @ , 1+ ]each drop
: ( selector -- )
dup, offset lit, -, \ -- selector index
dup, size lit, u>, if, drop, default lit, execute, end,
w lit, *, adr lit, +, @, execute, ;,
head kill-jt ;

: slow-search ( array limit target -- element|false ) \ hard-coded for use by SLOW-SWITCH>
>r \ -- array limit \ return: -- target
begin dup while
dup 1 rshift \ -- array limit mid
dup d * fourth + \ -- array limit mid mid-element
r@ over @ = if nip nip nip rdrop exit then \ if found, return MID-ELEMENT
r@ over @ < if \ search left side
drop nip \ -- array mid \ MID is the new limit
else
d + >r \ -- array limit mid \ return: -- target new-array \ NEW-ARRAY is one element above middle element
1+ - \ -- array new-limit \ the 1+ is so we don't include the middle element
nip r> swap \ -- new-array new-limit \ MID-ELEMENT is the new ARRAY
then
repeat \ LIMIT is zero, so it can be used as a FALSE flag
nip rdrop ; \ -- false

\ SLOW-SEARCH assumes that the array element is D in size (two cells),
\ and the first cell is the integer that we are comparing against.

: slow-switch> { head default | adr size -- } \ stream: name
align here to adr
head length to size
head each[ dup .targ @ , .xt @ , ]each
: ( selector -- )
adr lit, size lit, rover, postpone slow-search
dup, if, w lit, +, @, execute, end,
drop, default lit, execute, ;,
head kill-jt ;

\ CASE: and ;; were suggested by DXForth on comp.lang.forth to improve readability.
\ This works well when there is a list of integers, similar to CASE END-CASE in ANS-Forth.

get-current synonym case: :noname \ head targ -- head targ

: ;; ( head targ -- new-head ) \ this concludes the CASE: function (rather than ; as used in :NONAME usually)
postpone ; \ -- head targ xt
swap case-of ;
immediate

\ Note that the default should still be :NONAME and end with ; as usual.
----------------------------------------------------------------------

[hughag...@gmail.com]

On Thursday, June 20, 2019 at 9:58:00 PM UTC-7, hughag...@gmail.com wrote:
> \ SLOW-SEARCH assumes that the array element is D in size (two cells),
> \ and the first cell is the integer that we are comparing against.
>
> : slow-switch> { head default | adr size -- } \ stream: name
> align here to adr
> head length to size
> head each[ dup .targ @ , .xt @ , ]each
> : ( selector -- )
> adr lit, size lit, rover, postpone slow-search
> dup, if, w lit, +, @, execute, end,
> drop, default lit, execute, ;,
> head kill-jt ;

I made a slight improvement to the speed of SLOW-SEARCH .
In SLOW-SWITCH> I now align to a double-word rather
than to a word for the array. This reduces the amount of
data-cache thrashing that happens during SLOW-SEARCH .
The element is guaranteed to be in the same data-cache line
as the targ value.

I think the Forth-200x committee deserve Eaker's CASE
because they accept Elizabeth Rather as their leader.
They can't use my code, and they can't write their own <SWITCH
because the generated code will be less than half as fast
as my code, which does not meet my criteria for their success.
So they are left with using Eaker's CASE that Elizabeth Rather
put in the ANS-Forth Standard a quarter of a century ago.
They are left with Andrew Haley braying about how he is the world's
expert on a Forth <SWITCH despite his failure to write any code.
They deserve this pathetic fate!

I am not providing the Forth-200x committee with a path to success.
I am denying them any path to success!

This is the DALIGN code:
----------------------------------------------------------------------
: daligned ( adr -- dword-adr ) \ align adr to a dword boundary
[ d 1- ] literal +
[ d 1- invert ] literal and ;

: dalign ( -- ) \ align dictionary pointer to a dword boundary
here dup daligned swap - allot ;

\ DALIGN was provided mostly to support SLOW-SWITCH> in LIST.4TH
----------------------------------------------------------------------

This is the new SLOW-SWITCH> code:
----------------------------------------------------------------------

\ SLOW-SEARCH assumes that the array element is D in size (two cells),
\ and the first cell is the integer that we are comparing against.

: slow-switch> { head default | adr size -- } \ stream: name

dalign here to adr \ use DALIGN so the element SLOW-SEARCH finds will be in the same data-cache line

head length to size
head each[ dup .targ @ , .xt @ , ]each
: ( selector -- )
adr lit, size lit, rover, postpone slow-search
dup, if, w lit, +, @, execute, end,
drop, default lit, execute, ;,
head kill-jt ;

----------------------------------------------------------------------

[Alex McDonald]

On 25-Jun-19 07:28, hughag...@gmail.com wrote:
> They can't use my code,

What are the copyright terms for your code? Asking for a friend.

--
Alex

[Ron Aaron]

"friend"? You should use a term which Hugh is familiar with, instead.

[Alex McDonald]

Sorry.

Given Hugh's extreme dislike of having even his ideas referenced by
third parties, for which witness his threatening the committee with
legal action[*] for mentioning his name in an RfD, I think it's
incumbent on him to explain how he wishes his copyright should be licenced.

My code is under https://opensource.org/licenses/BSD-2-Clause if anyone
cares. Hugh obviously does care, but he's never indicated what he means
by "can't use my code". It's common practise to include some kind of
licence with source code, but the "novice" code of Hugh's that I have
downloaded doesn't contain any such thing.



[*] For what I'm not clear, since talking about something Hugh has
posted isn't a matter of copyright, since nothing is being copied. It
must be for defamation. But given Hugh's low standing in civil society,
and his consistent abuse of anyone he believes to be inferior to him
(basically, everyone) I don't think there is any reputational damage he
could get redress for.

--
Alex

[The Beez]

Hugh,

That's a hellovalot of code for a construct that can be resolved much better. My 4tH doesn't even have a CASE statement, because I think it's a brain dead concept anyway. The reason I still use it in C is:
(a) Because I'm lazy;
(b) Because it doesn't impact performance;
(c) Because function call overhead is a beach (calling functions by pointers);
(d) Because I can easily replace it with gcc extensions.

In 4tH you use TABLES. There are simple tables, that work much like brain dead C-compilers (let's try 'em all, till we find the one we love). There are smart tables (using binary search) and if the ranges are close together and "speed" comes before "size" they're fully indexed.

That's about the strategy any sane C compiler uses as well. So instead of a CASE statement, I have this:

create stringtable
," drop" ' drop ,
," dup" ' dup ,
," over" ' over ,
," rot" ' rot ,
," swap" ' swap ,
here stringtable - 2/ constant #stringtable ( for bsearch) OR:
NULL , ( I'm lazy)
DOES> (searchtable) ;

Or if I have room to spare:

0 ENUM _DROP
ENUM _DUP
ENUM _OVER
ENUM _ROT
constant _SWAP

create stringtable
_DROP , ' drop ,
_DUP , ' dup ,
_OVER , ' over ,
_ROT , ' rot ,
_SWAP , ' swap ,

And get a full index. It doesn't require a lot of code and I'm selecting myself which implementation serves my problem best.

Hans Bezemer

[hughag...@gmail.com]

On Thursday, July 25, 2019 at 7:10:56 AM UTC-7, The Beez wrote:
> Hugh,
>
> That's a hellovalot of code for a construct that can be resolved much better. My 4tH doesn't even have a CASE statement, because I think it's a brain dead concept anyway. The reason I still use it in C is:
> (a) Because I'm lazy;
> (b) Because it doesn't impact performance;
> (c) Because function call overhead is a beach (calling functions by pointers);
> (d) Because I can easily replace it with gcc extensions.
>
> In 4tH you use TABLES. There are simple tables, that work much like
> brain dead C-compilers (let's try 'em all, till we find the one we love).
> There are smart tables (using binary search) and if the ranges are close
> together and "speed" comes before "size" they're fully indexed.
>
> That's about the strategy any sane C compiler uses as well.
> So instead of a CASE statement, I have this:
>
> create stringtable
> ," drop" ' drop ,
> ," dup" ' dup ,
> ," over" ' over ,
> ," rot" ' rot ,
> ," swap" ' swap ,
> here stringtable - 2/ constant #stringtable ( for bsearch) OR:
> NULL , ( I'm lazy)
> DOES> (searchtable) ;

You are requiring the user to alphabetize the keys manually.
This isn't a job for a lazy user --- this requires a user
with a lot of time on his hands and a tolerance for tedious work.
The laziness is on the part of the implementer, not the user.

Apparently you are trying to implement a string-key association.
I never claimed that an association was an appropriate use for
my <SWITCH though; using <SWITCH doesn't actually make any sense here.
I would recommend my ASSOCIATION.4TH that has an LLRB tree in it.
Traditionally, Forth programmers would use the Forth dictionary
for as an improvised association (I've done this), but it is clumsy.

> Or if I have room to spare:
>
> 0 ENUM _DROP
> ENUM _DUP
> ENUM _OVER
> ENUM _ROT
> constant _SWAP
>
> create stringtable
> _DROP , ' drop ,
> _DUP , ' dup ,
> _OVER , ' over ,
> _ROT , ' rot ,
> _SWAP , ' swap ,
>
> And get a full index. It doesn't require a lot of code and
> I'm selecting myself which implementation serves my problem best.

You still have a lot of redundant code. The user has to build
both the ENUM words and the STRINGTABLE array, and both have to
be synchronized with each other (same order, no missing elements).
There is a huge opportunity for error with all this redundancy.

This is somewhat better though.
The user no longer has to manually sort (the ENUMs are sorted),
and you do a direct look-up rather than a binary serach.
This only works though, if you can think up names such as _ROT etc.
that are meaningful, so the user can know what key to use.

I said that my <SWITCH was useful for simulating a micro-processor
or a VM, with each key being the opcode and the payload being
the function that simulates that opcode.
This is a common use for C's SWITCH --- this is why C is used to
implement Forth interpreters (FICL, for example).
This is also common when cross-compiling to micro-processors when
you want to simulate on a desktop computer (possibly because the
micro-processor doesn't exist in hardware yet).
To use your method, the user would have to manually sort the
opcode values and use them as keys rather than use ENUM keys.
This is going to be a lot of tedious work given the
typical target that has two or three hundred opcodes.
Also, it is going to be slow because it uses a binary search,
whereas my FAST-SWITCH> uses a jump-table for 16-bit opcodes.
Your technique assumes that the key values are contiguous
(your ENUM values are), but opcodes aren't contiguous.
With opcodes you need a sparse array like my FAST-SWITCH> builds.

You said that my <SWITCH is:

"a hellovalot of code for a construct that can be resolved much better."

This isn't true.
My <SWITCH required me to write a small amount of straight-forward code,
and it is much better than anything that you or anybody else has.
I think that you should stop slinging around the insult "brain-dead"
and put more effort into using your own brain.
You aren't even close to achieving my challenge of being
no less than 1/2 as efficient as my solution and no more than 2* as bulky.
Simulating opcodes, your binary search is orders of magnitude slower
than my direct look-up. Manually sorting the opcodes is beyond dumb!
Keep trying! Write a EuroForth paper when you succeed (you won't though).

The ANS-Forth and Forth-200x cult assume that with two minutes of thought
and a lot of tedious hand-coding they can easily defeat me.
They have never actually succeeded at this.
I feel confident that my Forth code will always be far ahead of any
Forth code written by the ANS-Forth and Forth-200x cult.
My goal is that ANS-Forth and Forth-200x will be totally discredited
as a collection of ignoramuses --- thank you for helping me reach my goal!

P.S. "hellovalot" isn't a word.

P.P.S. My FAST-SWITCH> could be used as a very fast string-association
(faster than my ASSOCIATION.4TH) if I had a HASH function that was
fast and (most importantly) guaranteed that there would be no clashes.
I haven't written such a HASH function. It should be possible.
I doubt that it is going to generate a 16-bit number though,
so FAST-SEARCH> can't be used and SLOW-SEARCH> will be necessary.
This might still be faster than ASSOCIATION.4TH though.
It seems complicated. A traditional hash-table handles clashes
and is much easier to implement. You don't get sorted traversal though.
You also have to know a priori how many entries you will have, roughly.

[dxforth]

On Friday, 26 July 2019 00:10:56 UTC+10, The Beez wrote:
> Hugh,
>
> That's a hellovalot of code for a construct that can be resolved much better. My 4tH doesn't even have a CASE statement, because I think it's a brain dead concept anyway. The reason I still use it in C is:
> (a) Because I'm lazy;
> (b) Because it doesn't impact performance;
> (c) Because function call overhead is a beach (calling functions by pointers);
> (d) Because I can easily replace it with gcc extensions.
>
> In 4tH you use TABLES. There are simple tables, that work much like brain dead C-compilers (let's try 'em all, till we find the one we love). There are smart tables (using binary search) and if the ranges are close together and "speed" comes before "size" they're fully indexed.
>
> That's about the strategy any sane C compiler uses as well. So instead of a CASE statement, I have this:
>
> create stringtable
> ," drop" ' drop ,
> ," dup" ' dup ,
> ," over" ' over ,
> ," rot" ' rot ,
> ," swap" ' swap ,
> here stringtable - 2/ constant #stringtable ( for bsearch) OR:
> NULL , ( I'm lazy)
> DOES> (searchtable) ;

> ...

CASE statements typically execute a discrete set of commands and an
example along those lines would have been more representative.

Section 21.3.9 of the 4tH manual instructs users how to adapt ANS CASE
syntax to 4tH most notably by replacing OF with OVER = IF DROP and
ENDCASE with as many THENs as it takes, at which point the result is
labelled "ugly". Logically programs are little more than nested IF ELSE
so short of having a good reason to do otherwise I see no reason why
CASE statements can't be.

[hughag...@gmail.com]

On Friday, July 26, 2019 at 6:59:46 AM UTC-7, dxforth wrote:
> Logically programs are little more than nested IF ELSE
> so short of having a good reason to do otherwise I see no reason why
> CASE statements can't be.

A linear search has O( n ) efficiency.
My FAST-SWITCH> has O( 1 ) efficiency. That would be one reason!
FAST-SWITCH> is the same as C or HLA etc.. This is obvious and easy.

My SLOW-SWITCH> has O( lg(n) ) efficiency, which is pretty good.
This is general-purpose code that doesn't make any assumptions.
If you know something about the data, it may be possible to do better.
My <SWITCH is mostly for simulating a VM or small processor.
A Splay Tree might be faster; when you are simulating iterative code,
all the opcodes in the loop will move to the upper part of the tree.
This is very speculative though --- it might be slower...

I'm not too worried about improving SLOW-SWITCH> speed.
I'm mostly interested in 16-bit micro-controllers, which means
that FAST-SWITCH> can be used (the table is 64KW in size).

ANS-Forth made Eaker's CASE (linear search) the Standard in 1994,
and Forth has stagnated since then (despite the fact that many
Forth-83 programmers had implemented a fast SWITCH construct).
Further effort on my part isn't really necessary considering
that the ANS-Forth cult has made zero effort in a quarter century.

[Cecil - k5nwa]

On 8/21/2019 11:27 AM, hughag...@gmail.com wrote:

>
> ANS-Forth made Eaker's CASE (linear search) the Standard in 1994,
> and Forth has stagnated since then (despite the fact that many
> Forth-83 programmers had implemented a fast SWITCH construct).
> Further effort on my part isn't really necessary considering
> that the ANS-Forth cult has made zero effort in a quarter century.
>

25 years that is hard to believe, and in all that time major problems
such as ambiguity, lack of portability, use of downright stupid
practices such as using the same buffer for FIND and other words have
not been fixed.

Adding more complex items to the Standard while not fixing the problems
is a sure fire way to make sure that Forth is and remains dead.
--

Cecil - k5nwa

[hughag...@gmail.com]

On Wednesday, June 12, 2019 at 10:11:21 AM UTC-7, Anton Ertl wrote:

> EuroForth 2019 will be held in Hamburg, Germany on September 13-15.
>
> The deadline for the academic stream (refereed) papers is June 30. So
> now is the time to write up your research to have it ready by the
> deadline. For industrial (non-refereed) papers the deadline is August
> 31.

I have been reading some "inspiring Mark Twain quotes on life"
http://www.quoteambition.com/inspiring-mark-twain-quotes-life/

This quote should be very inspiring for the EuroForth writers:
“Never tell the truth to people who are not worthy of it.”

Anton Ertl is the referee for the "academic" papers.
He and Bernd Paysan wrote a refereed paper for EuroForth-2018
that had no purpose except to attack the rquotations.
They lied when they said:
"the higher-order word that calls the rquotation must not use locals."

AFAIK, Anton Ertl and Bernd Paysan are lying about the rquotations
as a service to Stephen Pelc who will later "invent" rquotations
or something similar as a proprietary VFX feature
Anton Ertl and Bernd Paysan don't believe that the Forthers
are worthy of being given rquotations for free, but instead believe
that Forthers must pay Stephen Pelc for this feature.

> The call for papers including submission instructions can be found on
> <http://www.euroforth.org/ef19/cfp.html>.

The actual "submission instructions" EuroForth aspirants need,
are obtained by getting on your knees and asking Stephen Pelc.
You may be told to attack my code by lying about it.
You may be told to not invent useful Forth features that
Stephen Pelc plans on inventing later as proprietary VFX features.
You may be told to not write any working Forth code, but instead
to submit vague dreams about what it would be like to write
working Forth code (as Peter Knaggs and Andrew Haley did).

Ultimately, everybody who goes to EuroForth will dishonor themselves
with blatant lying and purposeful ignorance.

[Jurgen Pitaske]

I had said it before.
This email has been sent to Testra just now:

To: John Hart, sup...@testra.com

http://testra.com/Forth/VHDL.htm

Regarding: https://groups.google.com/forum/#!topic/comp.lang.forth/9IHvRJmMn20

Dear John,

We have not spoken for a while.
This email is not really regarding business now, but trying to put the history right.
Regarding Testra and regarding Hugh Aguilar.

Hugh Aguilar basically says for years here on clf. that he has basically invented the MFX processor of Testra,
And the software that basically runs the company TESTRA.

I do not mind if this were true, but I really doubt it,
as now – over probably 10 or 20 years now -
Not much has been published by him as far as I have seen

– rather than these insults and telling other people are liars and worse
– actually everybody who has a different opinion.

According to his info here he now drives taxis or tractors for a living.
No reference to any programming.

See his last post from Comp Lang Forth; this triggered this email to Testra:

Such and worse posts come on a daily / weekly basis as you can verify yourself.
I have been a target myself as well.

Is it possible for you to tell
For how long he was an employee of Testra if he was
Or if he was just a contractor/consultant
How long this working relationship lasted
Why your relationship ceased,
and what he really achieved at TESTRA??

Some partial answers would be very helpful already.

Just to make it clear:
I have no business relationship with MPE anymore so this is a purely private activity.

But as it makes me sick how he behaves on clf,
It was worth at least trying to find out and write this email, to find out
if what he states about your relationship is true and his software runs or did run TESTRA
or if this can be put right.

This email sent to you has been published as is on clf as well.

Please mark in your answer to me,
which part of your answer I can quote.

Thank you very much in advance.

Kind regards
Juergen

[hughag...@gmail.com]

On Saturday, August 31, 2019 at 7:31:06 AM UTC-7, Jurgen Pitaske wrote:
> On Saturday, 31 August 2019 03:04:11 UTC+1, hughag...@gmail.com wrote:
> > I have been reading some "inspiring Mark Twain quotes on life"
> > http://www.quoteambition.com/inspiring-mark-twain-quotes-life/
> >
> > This quote should be very inspiring for the EuroForth writers:
> > “Never tell the truth to people who are not worthy of it.”
>

> Hugh Aguilar basically says for years here on clf.
> that he has basically invented the MFX processor of Testra,
> And the software that basically runs the company TESTRA.
>
> I do not mind if this were true, but I really doubt it,

Jurgen Pintaske (or Pitaske, or whatever) has his facts wrong.
MFX is not a processor. MFX is a cross-compiler that I wrote.
MFX generates code for the MiniForth processor --- it doesn't
"run the company" (whatever that might mean).

I doubt that John Hart would have spoken to Jurgen when
Jurgen was employed as the salesman for MPE because
John Hart doesn't really waste his time talking to salesmen.
It is possible that he might buy VFX, but he doesn't need
a sales clown to convince him to do so --- there is no evidence
to indicate that Jurgen has ever written a program in Forth
or knows anything about Forth beyond what he wrote in his
ultra-novice book: "A Start with Forth 2017" --- he is not going to
teach John Hart how to program in Forth, nor teach him about VFX.

Now that Jurgen has been fired from MPE, there is no reason
at all for John Hart to talk to him. I'm not aware of any
reason why anybody would talk to him. Jurgen is a nut-case!

Jurgen claims to have coauthored multiple famous books:
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM
* Brad Rodriquez' book: "Moving Forth"
* Charles Moore's book: "Programming a Problem-Oriented Language"
* C.H. Ting's book: "Zen and the Forth Language" (plus several others)
* Leo Brodie's book: "Starting Forth"
etc.
These are preposterous lies! Jurgen Pintaske didn't coauthor any
of those books, most of which were written in the 1980s
(the 1980s were the halcyon of Forth, before ANS-Forth killed Forth).

[hughag...@gmail.com]

On Friday, August 30, 2019 at 7:04:11 PM UTC-7, hughag...@gmail.com wrote:
> Anton Ertl is the referee for the "academic" papers.
> He and Bernd Paysan wrote a refereed paper for EuroForth-2018
> that had no purpose except to attack the rquotations.
> They lied when they said:
> "the higher-order word that calls the rquotation must not use locals."

This is the full text of their attack on rquotations:
------------------------------------------------------------
Of course, in classical Forth fashion, some users explored the idea
of what outer-locals accesses can be performed with minimal effort.
In particular, Usenet user “humptydumpty” introduced rquotations, a
simple quotation-like implementation that uses return-address manipulation.
The Forth system does not know about these rquotations and therefore
treats any locals accessed inside rquotations as if they were
accessed outside. In the case of Gforth (as currently implemented)
this works as long as the locals stack is not changed in the
meantime; e.g., the higher-order word that calls the rquotation
must not use locals. There is no easy way to see whether this restriction
has been met; this is also classical Forth style, but definitely not
user-friendly. Static analysis could be used to find out in many cases
whether the restriction has been met, but that would probably require
more effort than implementing the approach presented in this paper,
while not providing as much functionality.
------------------------------------------------------------

This is my rquotation code in which the rquotation has read/write
access to the parent function's local variables, despite the fact
that the higher-order function (HOF) has local variables of its own.
This is not complicated code, and it clearly shows that Anton Ertl
and Bernd Paysan were lying in their EuroForth-2018 paper:
------------------------------------------------------------
\ ******
\ ****** R[ ]R quotations.
\ ****** https://groups.google.com/forum/#!topic/comp.lang.forth/3LSqmBIZuzY
\ ****** This is highly non-standard! 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;
\ ******

\ In the stack-picture comments, RQ is a continuation (a vector to a quotation).

\ HumptyDumpty invented rquotations --- this was very good programming --- I hadn't thought of it.
\ What I call REX0 he called RCALL --- also, he didn't have REX which I invented (this only works in VFX and SwiftForth).
\ If only REX0 is used, rquotations can be used under any ANS-Forth system (theoretically non-standard though).
\ REX is a lot more useful though because the HOF almost always needs to have locals.

\ My improved version for VFX or SwiftForth should be easy to port to other ANS-Forth systems --- any Forth system with locals.
\ Some assembly-language is required, but it is pretty straight forward.

VFX? SwiftForth? or [if]

: rexit ( -- ) rdrop ;
: (r:) ( -- rq ) r@ 5 + ; \ 5 is the size of a JMP instruction in 32-bit x86
: r[ ( -- rq ) postpone (r:) postpone ahead ; immediate
: ]r ( -- ) postpone rexit postpone then ; immediate

: rex0 ( rq -- ) >r ; \ requires the HOF to not have locals

\ REX0 is the same as EXECUTE
\ We don't use EXECUTE however because in the other version (not VFX or SwiftForth) REX0 is different.

VFX? [if]

code rex ( rq -- ) \ requires the HOF to have locals
push edi \ this is the HOF's LF which won't be used by the quotation
mov edi, 0 [edi] \ this is the parent's LF which will be used by the quotation
mov eax, ebx
mov ebx, 0 [ebp] lea ebp, w [ebp]
call eax
pop edi \ restore HOF's LF
next, end-code

[then]

SwiftForth? [if]

156 constant lf-offset \ this is the offset for the local-frame in the user-variables (ESI is the user-variable base)

code rex ( rq -- ) \ requires the HOF to have locals
lf-offset [esi] edx mov
edx push \ this is the HOF's LF which won't be used by the quotation
-4 [edx] eax mov \ this is the old ESP
0 [eax] eax mov \ this is the parent's LF which will be used by the quotation
eax lf-offset [esi] mov
ebx eax mov [drop]
eax call
lf-offset [esi] pop \ restore HOF's LF
ret end-code

[then]

[else] \ this was written by HumptyDumpty and works on gForth, SwiftForth and VFX

: rexit ( -- ) RDROP ;
: (r:) ( -- rq ) R@ false ;
: r[ ( -- rq ) postpone (r:) postpone IF ; immediate
: ]r ( -- ) postpone REXIT postpone THEN ; immediate

: rex0 ( rq -- ) >R true ; \ requires the HOF to not have locals

\ REX is not supported in HumptyDumpty's code.

[then]

\ REX is used in a HOF that has local variables.
\ REX0 is used in a HOF that does not have local variables.
\ REX0 is also used in the parent function itself, when there is no HOF used.
------------------------------------------------------------

I have a lot more code that uses rquotations for various purposes,
but this is the fundamental rquotation code.

I believe that my rquotations can totally kill the credibility
of Forth-200x, because the Forth-200x committee members descend
to lying about the rquotations. Nobody in the real world wants
to associate with liars --- so, Forth-200x is essentially dead.

[Jurgen Pitaske]

Our CLF Top Liar Hugh Aguilar has posted again.
At least he is consistant.
He obviously does not like to get caught.

There have been a few conference calls with Testra
and I am just waiting for Tom's answer
to post here the truth about whatever Mr. Aguilar might have done there.

And here the link to Testra:

Hi Juergen,

Got your information and looked at your web site.


Have a Great Day!

Thomas W. Hart, Jr.
President

Testra Corporation
1201 N. Stadem Drive
Tempe, AZ 85281
Ph : 480-966-8428
Cell: 480-560-6141
fax : 480-907-2876
Web : www.testra.com
mail: tom...@testra.com


It is a small world - what some people forget.

And just to get the record straight:
I have published mostly,
I have co-authored some,
translated a few
and so on - just check it yourself on amazon.
I am not taking credit for other people's work as others do.
And all signed-off regarding copyright.
Quite normal professional work.

And if you do not know where to look, this list here not fully updated as I have more important things to do in life:

The current Forth Bookshelf 2018
a Collection of Forth Material
published via amazon

Juergen Pintaske, ExMark

The current Forth Bookshelf can be found at
https://www.amazon.co.uk/Juergen-Pintaske/e/B00N8HVEZM

And see the eBooks rate today in the top 100 at amazon under compilers
https://www.amazon.com/gp/bestsellers/books/3970/ref=pd_zg_hrsr_b_1_5_last#5

As 3 Blocks here:
A - How it started, How it was designed, The Classic, A Tutorial, Starting Basics/Hardware, How Internals work, Programming Forth, and more
1 Charles Moore - Forth - The Early Years: Background information about the beginnings of this Computer Language
2 Charles Moore - Programming A Problem Oriented Language: Forth - how the internals work
3 Leo Brodie - Starting Forth The Classic
4 Leo Wong – Juergen Pintaske – Stephen Pelc FORTH LITE TUTORIAL: Code tested with free MPE VFX Forth, SwiftForth and Gforth or else
5 Juergen Pintaske – A START WITH FORTH - Bits to Bites Collection – 12 Words to start, then 35 Words, Javascript Forth on the Web, more
6 Brad Rodriguez - Moving Forth / TTL CPU / B.Y.O. Assembler
- looking at how Forth works internally, his TTL CPU and Assembler in Forth
7 Stephen Pelc - Programming Forth: Version July 2016
8 Tim Hentlass - Real Time Forth - many Forth Code Examples

B - Some of the work of Dr. Chen-Hanson Ting
9 Chen-Hanson Ting - Footsteps In An Empty Valley issue 3, another classic
10 Chen-Hanson Ting - eForth Overview the background of eForth
11 Chen-Hanson Ting - Zen and the Forth Language: EFORTH for the MSP430G2552 from Texas Instruments
12 Chen-Hanson Ting - eForth and Zen - 3rd Edition 2017: with 32-bit 86eForth v5.2 for Visual Studio 2015
13 Chen-Hanson Ting - FIG-Forth Manual Document Test in 1802 FPGA IP
14 Chen-Hanson Ting - EP32 RISC Processor IP: Description and Implementation into FPGA – ASIC tested by NASA
15 Chen-Hanson Ting – Irriducible Complexity

C - Some others, e.g. micro:bit and mecrisp as addition; Simulated 4Bit Micro controlled via 3 switches, a Forth simulator in progress; Programmer via Internet, tested using Lars’ Forth and for Ken’s SMAL

16 Burkhard Kainka - BBC Micro:bit: Tests Tricks Secrets Code, Additional MicroBit information when running the Mecrisp Package

17 Burkhard Kainka - Learning Programming with MyCo: Learning Programming easily - independent of a PC (Forth code added)
18 Burkhard Kainka – Thomas Baum – Cheepit Sparrow – Tools on the Web - Programming ATYTINY13 without Programmer and Tools

( 19 A Taste of Forth Standard 2012 – an eBook that could not be done as of copyright issues – so here just the link to Forth-Standard.org and the PDF on the web instead )

Additional Material, part of the Forth-ev.de Wiki:

( 5 ) A Start with Forth VFX for download, Examples, Code, most of the chapters for download, print – and run the Forth Code – Forths provided
( 5 ) Forth Mug - the 35 Wortd Forth wrapped around a mug for everyday use – or for the 16 Forth Bookshelf Covers – did mine at Vistaprint
( 16 ) Micro:bit with mecrisp Forth add-ons documentation – as well for the German micro:bit version Calliope
MicroBox Project based on TI MSP430 – documetation at Eurocircuits ( search for Scouts Event) and Video from IET Event
And Klaus Kohl’s Forth Book Collection where this list is as well on Forth-ev.de

File: update v2 April 2018 Juergen Pintaske ExMark

and a few books more now in 2019 like Professor Dr. Karl Meinzer's IPS

And what have you achieved for Forth, Hugh?

Except probably a long list of insults against most people here.

[dxforth]

To quote you 'we've had this discussion before'. Were the 10 or
so instances of ANS CASE you employ in LowDraw.4th the result of
you not having anything better - or nothing better was warranted?

[hughag...@gmail.com]

LowDraw.4th was my first-ever ANS-Forth program,
written in maybe 2007 --- I didn't have the novice-package then.
Later on I slightly upgraded LowDraw.4th to use a few
NOVICE.4TH features so it could go in the novice-package,
but that was in 2010 and I didn't have <SWITCH yet.
ANS-Forth is so feature-bereft that I have to write everything
myself, so this takes time.

<SWITCH is always faster than CASE is.
It may not be convenient though because it has the restriction
of generating a colon word, rather than being inside of a
colon word (like the C SWITCH is inside of a function) ---
because of this, the associated actions can't share local variables ---
they have to use global variables for shared data.

[dxforth]

Here is the simplest application of 'case' that I know:

variable ROW
16 value #ROWS

: -ROW ( -- ) row @ 0 of #rows then 1- row ! ;

If it can't be bettered then there exists a window where CASE is
preferable to all other methods (including in this instance FM/MOD).

[Mark William Humphries]

: -row ( -- ) row @ 1- 0 max row ! ;

[Mark William Humphries]

Sorry wrong, misunderstood your intent.

[Anton Ertl]

Mark William Humphries <mark.willia...@gmail.com> writes:
>Le dimanche 1 septembre 2019 14:20:59 UTC+8, dxforth a =C3=A9crit=C2=A0:

>> Here is the simplest application of 'case' that I know:

>>=20

>> variable ROW
>> 16 value #ROWS

>>=20

>> : -ROW ( -- ) row @ 0 of #rows then 1- row ! ;

>>=20

>> If it can't be bettered then there exists a window where CASE is
>> preferable to all other methods (including in this instance FM/MOD).
>
>: -row ( -- ) row @ 1- 0 max row ! ;

Not quite, but on the right track:

: -row ( -- ) row @ 1- #rows umin row ! ;

[Anton Ertl]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Mark William Humphries <mark.willia...@gmail.com> writes:
>>Le dimanche 1 septembre 2019 14:20:59 UTC+8, dxforth a =C3=A9crit=C2=A0:
>>> Here is the simplest application of 'case' that I know:
>>>=20
>>> variable ROW
>>> 16 value #ROWS
>>>=20
>>> : -ROW ( -- ) row @ 0 of #rows then 1- row ! ;
>>>=20
>>> If it can't be bettered then there exists a window where CASE is
>>> preferable to all other methods (including in this instance FM/MOD).
>>
>>: -row ( -- ) row @ 1- 0 max row ! ;
>
>Not quite, but on the right track:
>
>: -row ( -- ) row @ 1- #rows umin row ! ;

Still not right. Next attempt:

: -row ( -- ) row @ 1- #rows 1- umin row ! ;

[Mark William Humphries]

Not quite :)

: -row ( -- ) row @ 1- [ #rows 1- ] literal umin row ! ;

[dxforth]

That may be construed as overkill but I concede this function
could have been better written in other ways. My purpose however
was to illustrate that there will be more enough instances where
an IF/ELSE based Case simply makes more sense.

Clearly OF works best where an equality test is needed. You may
find the following examples more convincing. Given Case is largely
'syntax sugar' anyway I make no apology using it where straight
coding methods would have produced similar results.

\ Example from dpANS
: EKEY ( -- u )
DOS-KEY-FUNCTION-8 ?DUP 0= IF
DOS-KEY-FUNCTION-7 DUP 3 = IF
DROP 0 ELSE 256 +
THEN
THEN ;

\ END aka EXIT THEN
: EKEY ( -- u )
dos-key-function-8 0 of
dos-key-function-7
3 of 0 end 256 +
then ;

\ SPACE key pause/resumes
: HALT? ( -- f )
key? true of
key bl of key then
bl <>
then ;

[dxforth]

On Monday, 2 September 2019 11:40:18 UTC+10, dxforth wrote:
> ...
> My purpose however
> was to illustrate that there will be more [than] enough instances where an
> IF/ELSE based Case simply makes more sense [than one based on tables et al].

[Mark William Humphries]

Assuming I've understood your ekey correctly, this is how I would normally code it:

: ekey ( -- u )
dos-key-function-8 ?dup ?;
dos-key-function-7 256 or 259 cancel ;

[Mark William Humphries]

Here's CANCEL in case you don't have something similar:

cancel Cancel (i.e. zero out) on equal, return zero if <x1>
equals <x2>, otherwise return <x1>.

: cancel ( {x1 x2}|{x1 x1} -- x1|0 ) over <> and ;inline