Rosetta Code: Catamorphism

[WJ]

> Reduce is a function or method that is used to take the values
> in an array or a list and apply a function to successive
> members of the list to produce (or reduce them to), a single
> value.
>
> Show how reduce (or foldl or foldr etc), work (or would be
> implemented) in your language.

Ruby:

["eeny-meeny", 'teeny-tiny', 'flip-flop', 'willy-nilly', "about-face",
'well-worn', "mass-produced", 'in-basket'].
reduce([[[],[]],[[],[]]]){|result,word|
result.zip([:min,:max]).map{|a_b,method|
a_b.zip(word.split("-")).map{|s1,s2| [*s1,s2].send(method)}}
}.map{|array| array.join "-"}

==>["about-basket", "willy-worn"]

In Forth?

--
[T]he broadcast media ... create a separate and caustic virtual reality, then
broadcast that ideologically driven reality into the homes of millions of
people.... theoccidentalobserver.net/authors/Connelly-Gaza2.html

[Julian Fondren]

https://rosettacode.org/wiki/Catamorphism#Forth

[Anton Ertl]

Julian Fondren <julian....@gmail.com> writes:
>https://rosettacode.org/wiki/Catamorphism#Forth

Do you want to say anything?

The discussion is fine, but it's probably better to illustrate the
points with examples right away. I have used smaller examples for
this kind of stuff in the Gforth tutorial, and I think that smaller
examples are better, because the additional stuff in the longer
example obscures the point.

E.g., higher-order words (map-array)
<https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Execution-Tokens-Tutorial.html>:

: map-array ( ... addr u xt -- ... )
\ executes xt ( ... x -- ... ) for every element of the array starting
\ at addr and containing u elements
{ xt }
cells over + swap ?do
i @ xt execute
1 cells +loop ;

create a 3 , 4 , 2 , -1 , 4 ,
a 5 ' . map-array .s
0 a 5 ' + map-array .
s" max-n" environment? drop .s
a 5 ' min map-array .

Macros (slide 5 of
<https://www.complang.tuwien.ac.at/anton/lvas/stack-sprachen/slides.pdf>).

: (map) ( a n -- a a') cells over + swap ;
: map< ( -- ) postpone (map) postpone ?do postpone i postpone @ ; immediate
: >map ( -- ) 1 cells postpone literal postpone +loop ; immediate

: .array ( addr u -- )
map< . >map ;

: sum-array ( addr u -- n )
0 rot rot map< + >map ;

I leave it to you to do the corresponding example for an explicit loop.

- 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 2016: http://www.euroforth.org/ef16/

[Julian Fondren]

On Thursday, August 25, 2016 at 5:12:50 AM UTC-5, Anton Ertl wrote:
> Julian Fondren <julian....@gmail.com> writes:
> >https://rosettacode.org/wiki/Catamorphism#Forth
>
> Do you want to say anything?

Alright, WJ's hit a new low, pointing out such omissions is just
noise.

Of that RC page:

In other languages, a catamorphism requires a zoo of similar
functions with subtle differences. Do you want to thread a value
through things? How about multiple values? Or no values, as you're
only interested in side effects? Would you like to populate a new
list with each value?

In other languages: reduce, reduce2, foreach, map.

In Forth you only need one 'function'. And it's not because you're
choosing to wear a hair shirt, or because some linguistic feature is
lost in translation, but because the data stack removes the
distinctions between these functions that matter so much to other
languages. Additionally, the data stack makes it much easier to
*think* about what's going on, especially vs. folds.

Forth is a nice language but this is a rare moment of Forth
supremacy. Forth calls snow 'snow' and plows it effortlessly into
piles wherever it's found; poverty demands that other languages have
15 different words for 'snow' because they need to know whether to
bring salt, their hands in mittens, a hand shovel, a long shovel, a
horse-drawn plow, a flamethrower, etc., to deal with the snow
deposit's precise conditions. "Oh no, I brought a flamethrower but
this is actually *medium-thick snow on grass*, so I need to go back
to the shed and get a *flat-head broad long-shovel*."

> : (map) ( a n -- a a') cells over + swap ;
> : map< ( -- ) postpone (map) postpone ?do postpone i postpone @ ; immediate
> : >map ( -- ) 1 cells postpone literal postpone +loop ; immediate
>
> : .array ( addr u -- )
> map< . >map ;
>
> : sum-array ( addr u -- n )
> 0 rot rot map< + >map ;

The avoidance of BOUNDS and -ROT and ]] ... [[ make me think that
this is tutorial code. That's fine, but Rosetta Code isn't a
tutorial. Idiomatic code is better, even if a listing must then
have several sub-listings due to competing idioms.

-- Julian

[Andrew Haley]

Julian Fondren <julian....@gmail.com> wrote:
>
> The avoidance of BOUNDS and -ROT and ]] ... [[ make me think that
> this is tutorial code.

FWIW, I wouldn't use any of those words either. I like
OVER + SWAP. :-)

Andrew.

[foxaudio...@gmail.com]

And arguably one needs to be a little more tutorial with Forth on Rosetta since for most viewers it is already incomprehensible.

BF

[Anton Ertl]

Julian Fondren <julian....@gmail.com> writes:
>On Thursday, August 25, 2016 at 5:12:50 AM UTC-5, Anton Ertl wrote:
>> Julian Fondren <julian....@gmail.com> writes:
>> >https://rosettacode.org/wiki/Catamorphism#Forth
>>
>> Do you want to say anything?
>
>Alright, WJ's hit a new low, pointing out such omissions is just
>noise.

I still don't get it. Ah, after trying "Goto Parent" another time,
despite the posting looking like a thread-opening posting (no "Re:",
no cited text), I actually find that it is a followup to a WJ posting.

>In other languages: reduce, reduce2, foreach, map.
>
>In Forth you only need one 'function'.

Yes, mostly. One exception: If you want to update the entries, you
probably want another one that gives the address of the entry instead
of the value.

>> : (map) ( a n -- a a') cells over + swap ;
>> : map< ( -- ) postpone (map) postpone ?do postpone i postpone @ ; immediate
>> : >map ( -- ) 1 cells postpone literal postpone +loop ; immediate
>>
>> : .array ( addr u -- )
>> map< . >map ;
>>
>> : sum-array ( addr u -- n )
>> 0 rot rot map< + >map ;
>
>The avoidance of BOUNDS and -ROT and ]] ... [[ make me think that
>this is tutorial code.

Yes, it's from my lecture notes. It's also standard code.

>That's fine, but Rosetta Code isn't a
>tutorial. Idiomatic code is better, even if a listing must then
>have several sub-listings due to competing idioms.

I guess "Works with Gforth" is enough if you want to use these
features. If you update the entry, it's up to you what you use.

My take on these things is this:

* For people who don't know Forth, and don't want to learn it, I guess
the shorter versions are more impressive (one more reason to avoid
weighing down the example with unrelated stuff).

* For people who don't know Forth, and for which you want to explain
it, it depends on what you want to explain to them (standard code in
the example above).

* For people who know Forth, it depends on what they know. POSTPONE
might be wider known than ]]...[[. However, I find it interesting
that you consider ]]...[[ more idiomatic. That may well be the
case: The Forth community seems to be divided into two groups: Those
who write this kind of macros, and I guess that many of us use
]]...[[; those who write EVALUATE-based macros, so no POSTPONE,
either; and those who think that macros are for gurus, and they
don't use POSTPONE, either.

Anyway, let's see what the code above looks like with ]]...[[ and BOUNDS:

: map< ( -- ) ]] cells bounds ?do i @ [[ ; immediate
: >map ( -- ) ]] 1 +loop [[ ; immediate
\ .array and sum-array look the same

[HAA]

You are assuming non-Forthers are going to be interested enough to read it.
That's unlikely.

Unlike the artifact from which it took its name, Rosetta Code doesn't say
'translate this psuedo-code into your language'. It says 'get this result'.
So it becomes a contest of languages where the object is to win (or at
least be in the game). A comparison or educational tool requires you to
explain the steps, whereas a contest only requires you to play by the rules.

[Andrew Haley]

HAA <som...@microsoft.com> wrote:

> foxaudio...@gmail.com wrote:
>> And arguably one needs to be a little more tutorial with Forth on
>> Rosetta since for most viewers it is already incomprehensible.
>

> You are assuming non-Forthers are going to be interested enough to
> read it. That's unlikely.

No it isn't. I know that because I am interested in what other
lanaguages' code looks like, and it would be extraordinary if it
didn't work that way for all languages.

Andrew.

[hughag...@gmail.com]

On Saturday, August 27, 2016 at 3:53:59 AM UTC-7, Anton Ertl wrote:
> Anyway, let's see what the code above looks like with ]]...[[ and BOUNDS:
>
> : map< ( -- ) ]] cells bounds ?do i @ [[ ; immediate
> : >map ( -- ) ]] 1 +loop [[ ; immediate

This is how they look with MACRO: from the novice-package (it is ANS-Forth, as is everything in the novice-package):

macro: map< ( -- )
cells bounds ?do i @ ;

macro: >map ( -- )
1 +loop ;

Personally, I find ]] and [[ to be very hard to read, mostly because they are being used as brackets but they are backwards (pointing outward rather than pointing inward).

I'm not familiar with ]] and [[ --- are these ANS-Forth? --- or are these Forth-200x?

[hughag...@gmail.com]

On Monday, August 29, 2016 at 1:21:48 AM UTC-7, hughag...@gmail.com wrote:
> On Saturday, August 27, 2016 at 3:53:59 AM UTC-7, Anton Ertl wrote:
> > Anyway, let's see what the code above looks like with ]]...[[ and BOUNDS:
> >
> > : map< ( -- ) ]] cells bounds ?do i @ [[ ; immediate
> > : >map ( -- ) ]] 1 +loop [[ ; immediate
>
> This is how they look with MACRO: from the novice-package (it is ANS-Forth, as is everything in the novice-package):
>
> macro: map< ( -- )
> cells bounds ?do i @ ;
>
> macro: >map ( -- )
> 1 +loop ;

Actually, this is completely screwed up. Here it is again --- I think this is correct:

macro: map< ( a n -- )
cells bounds ?do I @ ;

macro: >map ( -- )

1 cells +loop ;

I haven't tested this --- you didn't test your code either though --- I'm not actually paying attention to the problem that we are supposedly solving, but I'm just showing how MACRO: works as compared to your macros.

This is a WJ thread --- just a lot of nonsense anyway.

[HAA]

As they're not standard, they could be anything. But since they're in GForth
and GForth has a presence on 200x, they may become standard :)

]] xx yy zz [[ is equivalent to POSTPONE xx POSTPONE yy POSTPONE zz

A possible implementation is

: ]] \ multiple POSTPONE handler
begin
>in @ bl word count ?dup if
s" [[" compare if
>in ! postpone postpone true
else drop false then
else 2drop refill then 0=
until ; immediate

[Bruce Axtens]

Hugh,

When is Straight Forth due? I'm not interested in ANS Forth for most of
the reasons you have outlined in many earlier posts.

[Ron Aaron]

On 08/29/2016 13:29, Bruce Axtens wrote:

> When is Straight Forth due?

Probably right after Get Bent Forth is released...

[Albert van der Horst]

In article <2016Aug2...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
<SNIP>

> don't use POSTPONE, either.
>
>Anyway, let's see what the code above looks like with ]]...[[ and BOUNDS:
>
>: map< ( -- ) ]] cells bounds ?do i @ [[ ; immediate
>: >map ( -- ) ]] 1 +loop [[ ; immediate

Probably :
: >map ( -- ) ]] 1 CELLS +loop [[ ; immediate

>\ .array and sum-array look the same
>
>- 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 2016: http://www.euroforth.org/ef16/

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Julian Fondren]

On Monday, August 29, 2016 at 3:21:48 AM UTC-5, hughag...@gmail.com wrote:
> On Saturday, August 27, 2016 at 3:53:59 AM UTC-7, Anton Ertl wrote:
> > Anyway, let's see what the code above looks like with ]]...[[ and BOUNDS:
> >
> > : map< ( -- ) ]] cells bounds ?do i @ [[ ; immediate
> > : >map ( -- ) ]] 1 +loop [[ ; immediate
>
> This is how they look with MACRO: from the novice-package (it is ANS-Forth, as is everything in the novice-package):
>
> macro: map< ( -- )
> cells bounds ?do i @ ;
>
> macro: >map ( -- )
> 1 +loop ;
>

And here's how they look with EVALUATE:

: map< ( -- ) S" CELLS BOUNDS ?DO I @" EVALUATE ; IMMEDIATE
: >map ( -- ) S" 1 CELLS +LOOP" EVALUATE ; IMMEDIATE

Which looks no worse, really, and which makes it explicit that this
word uses EVALUATE and therefore requires a certain search order to
make a certain sense.

> I'm not familiar with ]] and [[ --- are these ANS-Forth? --- or are these Forth-200x?

it's a gforth extension. I don't mind POSTPONE POSTPONE POSTPONE in
my own code, where I generally use case and extra comments, but it's
damned ugly and if I were showing Forth off it's the first thing
that'd go.

On Monday, August 29, 2016 at 3:43:57 AM UTC-5, HAA wrote:
>
> A possible implementation is
>
> : ]] \ multiple POSTPONE handler
> begin
> >in @ bl word count ?dup if
> s" [[" compare if
> >in ! postpone postpone true
> else drop false then
> else 2drop refill then 0=
> until ; immediate

Special treatment is needed for literals. If you have a recognizer
stack, this is easier to implement and will work with user-created
literals.

On Monday, August 29, 2016 at 3:36:18 AM UTC-5, hughag...@gmail.com wrote:
>
> This is a WJ thread --- just a lot of nonsense anyway.

By the way, when you mark his threads spam, you're training the filter
to consider code to be spam, and *actual* spam to be less as spammy as
before. You're abusing a public good for personal reasons, and are
making it worse, when it would be less work to avert your eyes and
less of a chore to get a real Usenet client with a kill list.

You deserve an inbox filled with penis pills and Nigerian princes.


-- Julian

[Anton Ertl]

alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <2016Aug2...@mips.complang.tuwien.ac.at>,
>Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>Anyway, let's see what the code above looks like with ]]...[[ and BOUNDS:
>>
>>: map< ( -- ) ]] cells bounds ?do i @ [[ ; immediate
>>: >map ( -- ) ]] 1 +loop [[ ; immediate
>
>Probably :
>: >map ( -- ) ]] 1 CELLS +loop [[ ; immediate

Yes. Or alternativey

: >map ( -- ) 1 cells ]] literal +loop [[ ; immediate

On less sophisticated compilers, this results in more efficient code;
it also avoids the need for ]]...[[ to deal with numbers. And it
demonstrates a benefit of ]]...[[ over defining a macro from the start
of the definition to the end: ]]...[[ allows putting parts in the word
that are executed rather than compiled when the compilation semantics
of the macro are performed.

However, for a Rosetta Code example, I would probably choose your
version, unless I want to explain the stuff I explained above.

[Anton Ertl]

Julian Fondren <ayr...@gmail.com> writes:
>And here's how they look with EVALUATE:
>
> : map< ( -- ) S" CELLS BOUNDS ?DO I @" EVALUATE ; IMMEDIATE
> : >map ( -- ) S" 1 CELLS +LOOP" EVALUATE ; IMMEDIATE
>
>Which looks no worse, really, and which makes it explicit that this
>word uses EVALUATE and therefore requires a certain search order to
>make a certain sense.

Not just a search order, but also no other definitions of these words
in these wordlists.

As for why the direction of

]]...[[

is in this direction: It's because

] ... [

switches from interpretation to compilation and back; likewise, ]]
switches from compilation to postponing and [[ switches back.

[peter....@gmail.com]

On Monday, 29 August 2016 19:24:46 UTC+2, Anton Ertl wrote:
> Julian Fondren <ayr...@gmail.com> writes:
> >And here's how they look with EVALUATE:
> >
> > : map< ( -- ) S" CELLS BOUNDS ?DO I @" EVALUATE ; IMMEDIATE
> > : >map ( -- ) S" 1 CELLS +LOOP" EVALUATE ; IMMEDIATE
> >
> >Which looks no worse, really, and which makes it explicit that this
> >word uses EVALUATE and therefore requires a certain search order to
> >make a certain sense.
>
> Not just a search order, but also no other definitions of these words
> in these wordlists.
>
> As for why the direction of
>
> ]]...[[
>
> is in this direction: It's because
>
> ] ... [
>
> switches from interpretation to compilation and back; likewise, ]]
> switches from compilation to postponing and [[ switches back.

This is why I think you got it backwards. I see it as
[ switches from compilation to interpretation and ] back to compiling

therefore

[[ should switch from compilation to postponing and ]] back to compiling

it really looks backwards now!

or it could be post[ ... ]pone for extra clarity

BR
Peter Fälth

[Anton Ertl]

peter....@gmail.com writes:
>On Monday, 29 August 2016 19:24:46 UTC+2, Anton Ertl wrote:
>> As for why the direction of

>>=20
>> ]]...[[
>>=20

>> is in this direction: It's because

>>=20
>> ] ... [
>>=20

>> switches from interpretation to compilation and back; likewise, ]]
>> switches from compilation to postponing and [[ switches back.

>=20

>This is why I think you got it backwards. I see it as
>[ switches from compilation to interpretation and ] back to compiling
>

>therefore=20

>
>[[ should switch from compilation to postponing and ]] back to compiling

>=20

If you see it as different things, and compilation as the normal mode,
you have a point.

The basic idea behind ]]...[[ is that ] switches to the next more
delaying state (from interpretation to compilation, from compilation
to postponing), and [ to the next less delaying state (from postponing
to compiling, from compiling to interpreting); however, unfortunately,
the standard specifies "]" in a way that does not allow working the
way envisioned above, so "]]" was introduced instead, and "[[" to go
with it. And the current implementation only do the switching from
compilation to postponing, and back, not the full monty.

It may be more obvious why the brackets have this direction, if you
want to have some intermediate compilation action in the middle of the
postponeing, e.g.:

: derivative { xt1 F: r -- xt2 }
:noname ]]
fdup [[ r ]] fliteral f+ [[ xt1 compile, ]] fswap [[ xt1 compile, ]] f-
[[ r ]] fliteral f/ ;
[[ ;

>it really looks backwards now!

Looking at the DERIVATIVE example, do you still think so?

>or it could be post[ ... ]pone for extra clarity

Or use that for DERIVATIVE?

- anton

[HAA]

peter....@gmail.com wrote:
> On Monday, 29 August 2016 19:24:46 UTC+2, Anton Ertl wrote:

> > ...

> > As for why the direction of
> >
> > ]]...[[
> >
> > is in this direction: It's because
> >
> > ] ... [
> >
> > switches from interpretation to compilation and back; likewise, ]]
> > switches from compilation to postponing and [[ switches back.
>
> This is why I think you got it backwards. I see it as
> [ switches from compilation to interpretation and ] back to compiling
>
> therefore
>
> [[ should switch from compilation to postponing and ]] back to compiling
>
> it really looks backwards now!
>
> or it could be post[ ... ]pone for extra clarity
>
> BR
> Peter Fälth

A solution should befit the problem. If the only problem is that POSTPONE
is too onerous to type because you need a lot of them (as in Bernd's regex)
then what's wrong with temporarily assigning another name *just for that
application* e.g.

aka POSTPONE ~

POSTPONE is a low level compiler word and most applications will never
even see it. OTOH a short-cut for VARIABLE could be tempting :)

aka VARIABLE VAR

[peter....@gmail.com]

Yes and it looks real horrible. I would have written

: derivative { xt1 F: r -- xt2 }
:noname

postpone fdup r postpone fliteral postpone f+ xt1 compile,
postpone fswap xt1 compile, postpone f-
r postpone fliteral postpone f/ postpone ;
;

> >or it could be post[ ... ]pone for extra clarity
>
> Or use that for DERIVATIVE?

make it shorter as p[ and ]p and it does look somewhat better

: derivative { xt1 F: r -- xt2 }
:noname

p[ fdup ]p r p[ fliteral f+ ]p xt1 compile, p[ fswap ]p xt1 compile,
p[ f- ]p
r p[ fliteral f/ ; p]
;

BR
Peter

[Bruce Axtens]

The way Hugh goes on, you'd think ANS Forth was the bent one.

[HAA]

Julian Fondren wrote:
> On Monday, August 29, 2016 at 3:43:57 AM UTC-5, HAA wrote:
> >
> > A possible implementation is
> >
> > : ]] \ multiple POSTPONE handler
> > begin
> > >in @ bl word count ?dup if
> > s" [[" compare if
> > >in ! postpone postpone true
> > else drop false then
> > else 2drop refill then 0=
> > until ; immediate
>
> Special treatment is needed for literals. If you have a recognizer
> stack, this is easier to implement and will work with user-created
> literals.

Ok I missed that because I never encountered the need. Where
only words need to be postponed, something simpler would do:

: POSTPONE|
begin >in @ bl word count 1- swap c@ [char] | - or
while >in ! postpone postpone repeat drop ; immediate

[HAA]

As does Chuck: "I had reservations about ANSI. I worried that it would
be a disaster and not merely a dubious advantage. All of my fears of
the standard and none of the advantages of the standard have come
to pass. Any spirit of innovation has been thoroughly quelched.
Underground Forths are still needed."

[hughag...@gmail.com]

Well, I tested your definition under VFX:

: ]] \ multiple POSTPONE handler
begin
>in @ bl word count ?dup if
s" [[" compare if
>in ! postpone postpone true
else drop false then
else 2drop refill then 0=

until ; immediate ok

: test ]] s" Howdy!" [[ ; immediate
Err# -13 ERR: Undefined word.
-> : test ]] s" Howdy!" [[ ; immediate
^
: test2 ]] 5 . [[ ; immediate ok
: test22 test2 ; ok
test22 5 ok

I predicted that TEST was not going to work.

I am baffled as to how TEST2 could work --- we are doing a POSTPONE of 5 and this works??? --- POSTPONE is defined in the ANS-Forth document (section 6.1.2033) like this:
---------------------------------------------------------------------------
Skip leading space delimiters. Parse name delimited by a space. Find name. Append the compilation semantics of name to the current definition. An ambiguous condition exists if name is not found.
---------------------------------------------------------------------------
How do you "find" a number??? That this works is just a non-standard VFX feature.

Anyway, I don't care. I have had MACRO: working since 2009 and I'm happy with it --- I think the ]] ... [[ brackets are extremely hard to read because they point outwards rather than inwards like brackets usually do, so I don't have any interest in implementing them --- I also just don't have the patience anymore to figure out ANS-Forth (if I did get ]] to work on particular ANS-Forth compilers, I wouldn't have confidence that it actually was ANS-Forth and would work on other ANS-Forth compilers).

You are right though that "GForth has a presence on 200x" (Anton Ertl is the chair-person of the Forth-200x committee, and Bernd Paysan is a committee member) --- so ]] will likely get put in Forth-200x despite being ugly --- my MACRO: has zero chance of getting put in Forth-200x because it is not "common practice" anywhere other than the novice-package where it is used routinely.

BTW: This is where I came up with the MACRO: definition:
https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53%7Csort:relevance/comp.lang.forth/wP5nw1ClzsM/E-TV9v2y9RoJ
I originally had a macro that did FIND to obtain the xt values, and saved these --- so it was early-binding --- but it didn't work because FIND was broken, so I switched over to saving the source-code which is late-binding.

I also knew that the early-binding version would have to special-case all the immediate words like S" that take data out of the input stream, and this seemed like a big hassle (this is what I had done in MFX) --- also, this doesn't work because the user may have his own words like that which aren't being special-cased.

Late-binding is problematic because the definition might change --- I've been using MACRO: for years however, and this problem hasn't stung me yet --- it is not such a big deal as some people (Anton Ertl) suppose that it is (he has criticized my MACRO: because it uses late-binding).

[Coos Haak]

Op Thu, 1 Sep 2016 23:47:37 -0700 (PDT) schreef hughag...@gmail.com:
<snip>

>
> Well, I tested your definition under VFX:
>
>: ]] \ multiple POSTPONE handler
> begin
> >in @ bl word count ?dup if
> s" [[" compare if
> >in ! postpone postpone true
> else drop false then
> else 2drop refill then 0=
> until ; immediate ok
>
>: test ]] s" Howdy!" [[ ; immediate
> Err# -13 ERR: Undefined word.
> -> : test ]] s" Howdy!" [[ ; immediate

You stupid child, in essence you do the same as
: test postpone s" Howdy!" ;
You have learned that s" is a parsing word.
You may compile it, but no real Forth programmer
expects that it will compile the following string
during the compilation of test.

groet Coos

[Anton Ertl]

Coos Haak <htr...@gmail.com> writes:
>Op Thu, 1 Sep 2016 23:47:37 -0700 (PDT) schreef hughag...@gmail.com:
><snip>

>>: test ]] s" Howdy!" [[ ; immediate
>> Err# -13 ERR: Undefined word.
>> -> : test ]] s" Howdy!" [[ ; immediate
>
>You stupid child, in essence you do the same as
>: test postpone s" Howdy!" ;
>You have learned that s" is a parsing word.
>You may compile it, but no real Forth programmer
>expects that it will compile the following string
>during the compilation of test.

Whatever a "real Forth programmer" may be.

The idea of S" is actually to behave in interpretation and compilation
state as if the string was part of the word (unlike, e.g., '). So you
can write

: foo s" abc" ;
s" abc"

and both will parse 'abc"' at parse time, and push the string
descriptor at run-time.

The idea of ]]...[[ is to provide something like a postpone state, so
ideally ]] s" abc" [[ should parse 'abc"' at parse time, and push the
descriptor at run-time, too. That does not work because of the
details of S" and ]]...[[, but ideally it would. And with the string
recognizer, it actually does (tested with the development version of
Gforth):

: test ]] "Howdy!" [[ ; immediate ok
: foo test ; ok
foo type Howdy! ok

[Coos Haak]

Op Fri, 02 Sep 2016 11:45:48 GMT schreef Anton Ertl:

My Forth does not have recognizers, but can do the same:

want ]] ok

: test ]] "Howdy!" [[ ; immediate ok
: foo test ; ok
foo type Howdy! ok

groet Coos

[Albert van der Horst]

In article <2016Sep...@mips.complang.tuwien.ac.at>,

I rejected the idea of POSTPONE ing numbers for a long time as
ridiculous, but now you make me think.

This is how POSTPONE looked like in my simple Forth
(NAME FOUND replaces BL WORD FIND )
\ ' LIT CONSTANT 'LIT ' , CONSTANT ',
: POSTPONE
NAME FOUND \ DUP 0= 15 ?ERROR
DUP >FFA @ IMM_FLAG AND 0= IF 'LIT , THEN ,
', ,
; IMMEDIATE

So the execution token is commaed in, for non-immediate words
preceded by LIT.
In the presence of denotations (numbers) I exclude
any prefixes by using PRESENT instead of FOUND
that requires that the name found and the name in the dictionary
have the same length,like so.

: PRESENT
DUP >R FOUND DUP IF
DUP >NFA @ @ R@ = AND \ Name field address
THEN RDROP ;
So prefixes give error 15 : CANNOT FIND WORD TO BE POSTPONED
Instead of forbidding, I could detect this third case in POSTPONE
and POSTPONE numbers. Crazy. Forth keeps on surprising us.

This is a bit tricky, for prefixes we need some form of EXECUTE
because (during the POSTPONE action!) it must do some parsing
that results in one or more constants.

>
>- anton

[Anton Ertl]

Coos Haak <htr...@gmail.com> writes:
>Op Fri, 02 Sep 2016 11:45:48 GMT schreef Anton Ertl:

>> And with the string
>> recognizer, it actually does (tested with the development version of
>> Gforth):
>>
>>: test ]] "Howdy!" [[ ; immediate ok
>>: foo test ; ok
>> foo type Howdy! ok
>>
>> - anton
>
>My Forth does not have recognizers, but can do the same:
>
>want ]] ok
>: test ]] "Howdy!" [[ ; immediate ok
>: foo test ; ok
>foo type Howdy! ok

Your Forth may not have user-defined recognizers (at least not in the
RfD sense), but it obviously has a string recognizer: a part of the
text interpreter that recognizes strings.

[hughag...@gmail.com]

It is pretty sad when the inventor of a programming language is opposed to the Standard for that language and encourages "underground" versions --- Forth was totally hijacked!

I suspect that there is some kind of court order prohibiting Charles Moore from competing against Forth Inc. --- it is very strange that he abandoned Forth Inc. after founding the company, and he abandoned Forth language design after inventing Forth --- people don't voluntarily abandon everything they care about and then encourage underground resistance to it.

Anyway, to answer Bruce Axtens' question about when Straight Forth will come out: not anytime soon. I am still learning. For example, knowing that ANS-Forth lacks support for text, and writing code to support text, are two different things. I wrote STRING-STACK.4TH and I will put that in Straight Forth as an extension. Similarly, I recently wrote an OOP package with the intention of putting it it Straight Forth, but I haven't experimented with it enough yet to know if it is what I want (I would have to write one or two non-trivial programs using my OOP package to know this). I have a lot to learn about language design before I feel comfortable releasing my language publicly.

I am dreading releasing my language publicly. I am going to get flamed by the ANS-Forth cult members. I will be called a "stupid child" etc.. Ugh! This is what Charles Moore was referring to when he said: "Any spirit of innovation has been thoroughly squelched." At the time that Straight Forth is released, when the ANS-Forth cult is striving mightily to squelch it, I will have difficulty in fixing any mistakes that made it into the design, because doing so will involve admitting that I was wrong about something --- it is best if I wait until I'm absolutely sure that there are no mistakes --- I should really write one or two non-trivial programs in Straight Forth before I even consider releasing it publicly.

ANS-Forth was pushed through ANSI without having a reference compiler written and hence without being tested. This lack of testing is why there are so many mistakes in ANS-Forth. Also, it was designed by a committee, which is why there is so much ambiguity in allowing contradictory features. The first ANS-Forth compiler was SwiftForth released in 1997, which was 3 years after ANS-Forth was made Standard, and SwiftForth was so bug-ridden as to be unusable (not until version-3 could you use (LOCAL) without crashing the system). I don't want to go public with Straight Forth without first doing extensive testing, or I will just be doing the same thing as was done in ANS-Forth (standardizing half-baked ideas and outright bugs).

There is no hurry. Forth-200x is now Forth-201x, and will be Forth-202x pretty soon, and will likely be Forth-203x when it is finally completed --- Forth-200x just gets more and more complicated every year! --- there are extremely bad ideas already in Forth-200x, such as recognizers and Paysan-faked quotations, and these bad ideas have already doomed Forth-200x to failure.

[Elizabeth D. Rather]

A standard isn't for the purpose of innovation, it's for the purpose of
stabilizing the results of past (and recent) innovation, to make it
available for everyone seeking to write portable programs.

"Underground" Forths are useful as innovative platforms... successful
innovations can subsequently be standardized.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Andrew Haley]

Elizabeth D. Rather <era...@forth.com> wrote:
>
> A standard isn't for the purpose of innovation, it's for the purpose of
> stabilizing the results of past (and recent) innovation, to make it
> available for everyone seeking to write portable programs.
>
> "Underground" Forths are useful as innovative platforms... successful
> innovations can subsequently be standardized.

Yes! It's really important to say this, again and again.

Andrew.

[HAA]

Elizabeth D. Rather wrote:
> ...

> A standard isn't for the purpose of innovation, it's for the purpose of
> stabilizing the results of past (and recent) innovation, to make it
> available for everyone seeking to write portable programs.

Except that 35 years on there are still no portable programs as
WJ makes clear. Standards in Forth are wasted effort. I'm not
saying there are *no* good ideas in them, but for the purpose
for which they were created they have been a failure. Chuck
appears to have more faith in Forth *users* than Forth Standards.
So do I.

[Alex]

The success or otherwise of a standard is not binary; for example C99
and the revision C11

--
Alex

[Julian Fondren]

On Saturday, September 3, 2016 at 7:47:27 AM UTC-5, HAA wrote:
>
> Except that 35 years on there are still no portable programs as
> WJ makes clear.

DOUG HOFFMAN, this man's pessimism is your fault. Why didn't you
reply to every single worthless non-program spewed out by WJ?
Couldn't you have at least replied to his last batch of "I challenge
you with Rosetta Code pages that already have Forth entries" posts?
Pretty much everything WJ posts is covered by FMS-SILib.f and a bignum
library. Why didn't you show off more? Look at this poor, crying
post here. Every one of tomorrow's newspapers will carry HAA's post
above the fold. Everyone will know that you are a monster.

> Standards in Forth are wasted effort.

The effect of standards is that when I see NOT , I don't know what it
means -- but that when I see INVERT , I *do* know what it means.

The effect of standards is that Forth, which when described to someone
who's never heard of Forth should be a language whose programs are
almost impossible to port, actually can be ported from system to
system and architecture to architecture. It's still takes effort.
All movement takes effort. It remains a verb and not the noun of
'no-effort automatic universal portability' promised to us by utopians
and Java evangelists, but it's something.

The effect of standards and of even of the quality of standards that
we have, and their 'design by committee' is that we don't have the
Python 2/3 split or the Perl 5/6 split or trivial little things like
"Rich Hickey decided yesterday that laziness was a cool thing and
implemented it; fix all of your code" don't happen.

There's nothing desirable about these things. Python3 isn't
innovative; Python2 was just poorly designed. Perl6 is such a failure
of a successor that its staunchest advocates are the first to tell you
that it's a completely different language and that Perl5 will stick
around just like other completely different languages will. I
instantly realized that I preferred Common Lisp and its awful
*standard* and its terrible lack of *innovation*, but other people
fixed their Clojure code; they would still not appreciate continued
breaking changes.

If an effect of standards is that it slightly discourages innovation
like Chuck's IF ( f -- f ) or his OR (actually XOR), good.
Innovations like that deserve discouragement. You can still use
them if you want.

Incidentally, I didn't prefer Common Lisp only because it has a
standard. If so I would have to prefer C to Perl, and I don't.
Common Lisp has a good standard; it's a good language. That it also
doesn't break your code or include stupid language-memes like lazy
evaluation, these are additional weights to be placed on the scale.

Forth also has, with ANS Forth, a good standard, both in the words it
defines and the way they're defined even in its concepts.

Forth has also seen actually bad standards - a nice contrast.

There are complaints that can be made about ANS Forth. You could also
complain about the human face by pointing out that with three nostrils
humans could inhale much faster. And golly, if Americans had flippers
then we could far better achieve our obvious by-design singular
purpose of clapping, and if FIND were slightly different then ANS
Forth could far better achieve its obvious by-design singular purpose
of letting Hugh write a cross compiler without any environmental
dependencies.

And you, HAA, exposed to a litany of idiotic complaints about your own
face, would no doubt come to agree with them if your mother didn't
whisper counter-arguments in your ear *every* *single* *time* a
complaint were raised. "No honey, with three nostrils you'd have
trouble breathing in cold weather." "But mother, hasn't WJ already
made it clear that I desperately need plastic surgery? Why can't I
cut meat with my claws?!" Even if she'd told you last week that you
were beautiful, after a week of complaints you would forget, and if
not reminded would start wearing a bag over your head. You would
refuse to cut your steak with a knife, agreeing that knives are a
'crutch' and a 'wart' in your design.


-- Julian

[Elizabeth D. Rather]

In fact, there is quite a lot of code that is easily portable, often
without effort and the rest of the time by adding a simple pre-amble
covering platform-specific issues. Moreover, as a company who frequently
needs to hire Forth programmers (as do our customers), the programmers
themselves have a more coherent and consistent experience of the
language than was possible in the "wild and woolly" days before ANS
Forth. That *is*, actually, the purpose for which all language standards
are created. I know, for example, numerous C programmers who have to be
expert in using several C compilers because C programs are rarely
portable without some effort, but the situation is far better because
there are standards.

[Stephen Pelc]

On Sat, 3 Sep 2016 22:48:06 +1000, "HAA" <som...@microsoft.com>
wrote:

>Except that 35 years on there are still no portable programs as
>WJ makes clear.

Absolute rubbish. Since the ANS standard was adopted, MPE's ability
to use other people's Forth source code has improved markedly.
We speak from experience, not from hand-waving.

Stephen

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

[hughag...@gmail.com]

On Saturday, September 3, 2016 at 3:37:26 PM UTC-7, Stephen Pelc wrote:
> On Sat, 3 Sep 2016 22:48:06 +1000, "HAA" <som...@microsoft.com>
> wrote:
>
> >Except that 35 years on there are still no portable programs as
> >WJ makes clear.
>
> Absolute rubbish. Since the ANS standard was adopted, MPE's ability
> to use other people's Forth source code has improved markedly.
> We speak from experience, not from hand-waving.

Does any of that source-code use FIND anywhere? The VFX FIND behaves completely differently from the Gforth FIND --- and the SwiftForth FIND behaves completely differently from either of those --- but my disambiguifiers (written in ANS-Forth) make FIND behave the same on all three compilers.

Why do you refuse to acknowledge the existence of the disambiguifiers?

Why do you refuse to acknowledge the many many ambiguities and bad design decisions in ANS-Forth that have to be worked around?

I'm not opposed to having a standard. I'm opposed to ANS-Forth because it is the worst standard in the history of computer programming --- Elizabeth Rather's only programming experience was in COBOL --- the ANS-Forth standard was just a marketing gimmick for Forth Inc. with no technical merit whatsoever.

Whether Charles Moore is opposed to having a standard, is unclear. It is possible to cherry-pick quotes of his that seem to imply this. He refuses to communicate with anybody in the Forth community however, so there is no way to ask him. I don't actually care anyway.

The whole point of Straight Forth is to have a standard without ambiguity and without trying to be appropriate for every processor from the 6502 up to the 64-bit x86. Straight Forth has a 64-bit cell, so it is only for desktop computers --- it is primarily intended to be the host for a cross-compiler --- the features needed for a cross-compiler are obvious and easy.

Why do you refuse to standardize the features needed for a cross-compiler? Obviously, the reason why you got involved in Forth-200x was to prevent the Forth community from writing cross-compilers in competition with MPE --- you jumped onto the bandwagon for the purpose of dragging your feet.

[Gerry Jackson]

On 03/09/2016 05:54, hughag...@gmail.com wrote:
> This is what Charles Moore was referring to when he said:
>"Any spirit of innovation has been thoroughly squelched."
> At the time that Straight Forth is released, when the
> ANS-Forth cult is striving mightily to squelch it, I will
> have difficulty in fixing any mistakes that made it into
> the design, because doing so will involve admitting that
> I was wrong about something --- it is best if I wait until
> I'm absolutely sure that there are no mistakes --- I
> should really write one or two non-trivial programs in
> Straight Forth before I even consider releasing it publicly.

Very wise, nothing kills an interest in software than finding it is
bug-ridden. However this requires more than just a couple of non-trivial
programs to be written before release, it requires a comprehensive set
of test programs which test, not only the basic features but corner
cases, and include them with the system. This is also true for
applications and libraries. Few people seem to do this even though it is
in the developers' interest to do so.

> There is no hurry. Forth-200x is now Forth-201x, and will be
> Forth-202x pretty soon, and will likely be Forth-203x when it
> is finally completed --- Forth-200x just gets more and more
> complicated every year! --- there are extremely bad ideas
> already in Forth-200x, such as recognizers and Paysan-faked
> quotations, and these bad ideas have already doomed Forth-200x
> to failure.

Aren't quotations and recognisers innovations for Forth and you are
doing your best to squelch them. It seems to me that you and others in
the anti-ANS/Forth200X brigade do the vast majority of any squelching
that is going on, without much apparent success though. I see little
squelching from the supporters of Forth 200X, they seem to mostly ignore
you, particularly the ones you regularly insult.

--
Gerry

[hughag...@gmail.com]

The Paysan-faked quotations aren't an innovation --- they are just :NONAME with syntactic sugar --- I have never used :NONAME for anything and I consider it to be pretty much useless.

Forth-200x calls these "quotations" but they aren't quotations at all, because they don't have access to the parent function's local variables. They ruin the word "quotation" by using it wrong. If I say that I have quotations, everybody will reply: "You Forth programmers' quotations aren't quotations --- they are fake --- all Forth programmers are fakes!" Then I have to struggle to show that I'm using the word correctly, but it is too late because Forth-200x has given the entire Forth community a reputation for being fakes. This is very similar to what was described in the book, "1984," in which the words' meanings was changed --- "peace" meant "war," "freedom" meant "slavery," etc. --- Forth-200x is doing the same thing here, changing the meaning of "quotation" to mean "syntactic sugar for :NONAME" --- it would really be better if you didn't fake this stuff --- just be honest and admit that you don't know how to implement quotations. Straight Forth will have quotations using a fat-xt --- this is trivial to implement --- with a 64-bit cell there is room for a 32-bit cfa and a 32-bit local-frame pointer (all addresses are 32-bit, and only 4GB is supported, despite it being a 64-bit system).

As for recognizers, that is not an innovation either --- that is an extremely bad idea. You are going to have a mish-mash of incompatible recognizers. If you have X sets of recognizers, and they all clash with each other (meaning that the order they are loaded is significant), then you have X! versions of Forth-200x syntax. The problem with ANS-Forth is too much ambiguity, but with recognizers in Forth-200x you are making the problem worse. With 5 sets of recognizers that clash with each other, you have 120 incompatible versions of Forth-200x syntax. Programs are not going to be portable, because they all expect a different syntax. Also, it will be difficult for a person reading the source-code to figure out what it does. Normally, if a person sees a word that he doesn't know, then he can look it up in the documentation. With recognizers however, the person is going to see a lot of words which are interpreted by the recognizer but which aren't in the dictionary and aren't in the documentation either, so he doesn't know what the word means without learning how the recognizers work and mentally applying the recognizer to the word that is confusing him. All in all, I think that recognizers are such a bad idea that they totally doom Forth-200x to failure --- this is really the worst idea ever --- this will kill Forth.

The name "Straight Forth" implies that it is straightforward --- recognizers aren't straightforward --- I'm really not going to allow everybody to have their own syntax.

People are going to have to find another outlet for their creativity rather than inventing their own syntax which is incompatible with everybody else's syntax. The Forth-200x crowd are not writing programs in Forth. Instead, they are spending their time dinking around with recognizers and other nonsense. This is why Forth-200x is a toy language --- inventing your own syntax is a science-fair project --- this is not useful for writing programs.

The purpose of Straight Forth is to support cross-compilers. People can apply their creativity to writing a cross-compiler for a new micro-controller. Forth-200x is squelching cross-compilers by refusing to provide the support needed. Specifically, it is necessary to be able to determine from an xt what its attributes are (what word-list it is in, immediate or not, smudged or not, smudge-ready or not) and also to change these attributes. There are some other features also needed for a cross-compiler, but everything needed for a cross-compiler is trivial to implement and straightforward to document. Forth-200x refuses to support cross-compilers because they don't want the common Forth programmer to write a cross-compiler in competition with MPE and Forth Inc..

> I see little
> squelching from the supporters of Forth 200X, they seem to mostly ignore
> you, particularly the ones you regularly insult.

Thanks for not calling me a "stupid child" as Coos Haak did earlier in this thread --- I get insulted like this routinely from the ANS-Forth cult members --- it gets on my nerves.

[hughag...@gmail.com]

On Saturday, September 3, 2016 at 11:35:44 PM UTC-7, Gerry wrote:

> On 03/09/2016 05:54, hughag...@gmail.com wrote:
> > This is what Charles Moore was referring to when he said:
> >"Any spirit of innovation has been thoroughly squelched."
> > At the time that Straight Forth is released, when the
> > ANS-Forth cult is striving mightily to squelch it, I will
> > have difficulty in fixing any mistakes that made it into
> > the design, because doing so will involve admitting that
> > I was wrong about something --- it is best if I wait until
> > I'm absolutely sure that there are no mistakes --- I
> > should really write one or two non-trivial programs in
> > Straight Forth before I even consider releasing it publicly.
>
> Very wise, nothing kills an interest in software than finding it is
> bug-ridden. However this requires more than just a couple of non-trivial
> programs to be written before release, it requires a comprehensive set
> of test programs which test, not only the basic features but corner
> cases, and include them with the system. This is also true for
> applications and libraries. Few people seem to do this even though it is
> in the developers' interest to do so.

I wasn't really worried about bugs. I generally write pretty bug-free code. I was more interested in design issues. For example, there is my OOP package:
https://groups.google.com/forum/#!topic/comp.lang.forth/cH-pGXhBCfE
This is bug-free. It is short and simple. It was easy to test.

Is it useful though? That is more difficult to determine. This is what I meant when I said that I needed to write one or two non-trivial programs using the OOP package.

I read Bernd Paysan's page discussing Mini-OOF:
https://bernd-paysan.de/mini-oof.html

He says: "Gerry Jackson wrote a larger example, LexGen. This example extends Mini-OOF slightly, but it shows that with these small changes, Mini-OOF can be used for real-world applications."

Why did you write your LexGen using Mini-OOF??? It is obvious that Mini-OOF is typical Paysan code! This is his METHOD definer:

: method ( m v -- m' v ) Create over , swap cell+ swap
DOES> ( ... o -- ... ) @ over @ + @ execute ;

That is horribly inefficient! Any code that uses CREATE DOES> is going to be inefficient. My method calls are about 10 times more efficient under SwiftForth (SwiftForth is particularly inefficient with CREATE DOES> words) and about 3 times more efficient under VFX.

So, why did you use Mini-OOF when it is obviously no good? I think that you did this because Mini-OOF was written by Bernd Paysan who is a Forth-200x committee member --- you are being loyal to Forth-200x --- you don't care about efficiency at all, but you are treating Forth as a toy language suitable only for science-fair projects.

I'm really not going to tolerate gross inefficiency in Straight Forth --- to me, a Forth standard has to support efficient code --- efficiency is necessary if anybody is going to consider Forth to be suitable for writing commercial programs.

All in all, I think that Forth-200x is doomed to failure. None of the people involved are actually Forth programmers, in the sense that they write Forth programs --- all of them are involved because they want to be big experts who set the Standard for the entire community --- they are exercising their creativity on nonsense such as recognizers that are not useful for writing programs.

[Julian Fondren]

On Sunday, September 4, 2016 at 2:41:40 AM UTC-5, hughag...@gmail.com wrote:
> On Saturday, September 3, 2016 at 11:35:44 PM UTC-7, Gerry wrote:
> > On 03/09/2016 05:54, hughag...@gmail.com wrote:
> > > There is no hurry. Forth-200x is now Forth-201x, and will be
> > > Forth-202x pretty soon, and will likely be Forth-203x when it
> > > is finally completed --- Forth-200x just gets more and more
> > > complicated every year! --- there are extremely bad ideas
> > > already in Forth-200x, such as recognizers and Paysan-faked
> > > quotations, and these bad ideas have already doomed Forth-200x
> > > to failure.
> >
> > Aren't quotations and recognisers innovations for Forth and you are
> > doing your best to squelch them. It seems to me that you and others in
> > the anti-ANS/Forth200X brigade do the vast majority of any squelching
> > that is going on, without much apparent success though.
>

> I have never used :NONAME for anything and I consider it to be pretty much useless.

1. has never written higher-order code of his own, ever (except for
painfully contrived examples where the technique is basically used
only for control flow within a definition)
2. has very strong opinions about how it should be done.
3. is not bothered by opposition from all who do write such code.

#JustHughThings

> If I say that I have quotations, everybody will reply: "You Forth
> programmers' quotations aren't quotations --- they are fake --- all
> Forth programmers are fakes!"

1. distressed over Forth's reputation and how its programmers are seen
2. "how's your language? ours has an evil plot to keep people from
writing cross compilers. Forth is a crippled language!"

#JustHughThings

> As for recognizers, that is not an innovation either --- that is an
> extremely bad idea. You are going to have a mish-mash of
> incompatible recognizers. If you have X sets of recognizers, and
> they all clash with each other (meaning that the order they are
> loaded is significant),

"wordlists are bad", the post.

> Normally, if a person sees a word that he doesn't know, then he can
> look it up in the documentation. With recognizers however, the
> person is going to see a lot of words which are interpreted by the
> recognizer but which aren't in the dictionary and aren't in the
> documentation either,

Tune in tomorrow for more of this show, "adventures of the man telling
people as they're actively doing things why what they're already
successfully doing is impossible and will lead to certain disaster."

Alternate-history Hugh:

Forth is bad! In Forth you can make a word like SD(*FSDFJSDFIJ <-
actual possible word in Forth. That's impossible to read! Thus,
Forth must be impossible to read. I bet it's all SDPO)(*DF(* and
*SDUF_-f/ and S(DF*JSDJJASIDJJ all the time, because words like that
can be used in Forth. Forth code probably turns people into stone
faster than Medusa! Forth people are idiots for using such words!

> The Forth-200x crowd are not writing programs in Forth. Instead,
> they are spending their time dinking around with recognizers and
> other nonsense. This is why Forth-200x is a toy language ---
> inventing your own syntax is a science-fair project --- this is not
> useful for writing programs.

Clearly, more useful programs should be submitted for
standardization...

> Thanks for not calling me a "stupid child" as Coos Haak did earlier
> in this thread --- I get insulted like this routinely from the
> ANS-Forth cult members --- it gets on my nerves.

What rude people--getting on your nerves, like that. You are so careful to
avoid anyone else's nerves.


-- Julian

[Gerry Jackson]

On 04/09/2016 08:41, hughag...@gmail.com wrote:
> On Saturday, September 3, 2016 at 11:35:44 PM UTC-7, Gerry wrote:
>> On 03/09/2016 05:54, hughag...@gmail.com wrote:
>>> There is no hurry. Forth-200x is now Forth-201x, and will be
>>> Forth-202x pretty soon, and will likely be Forth-203x when it
>>> is finally completed --- Forth-200x just gets more and more
>>> complicated every year! --- there are extremely bad ideas
>>> already in Forth-200x, such as recognizers and Paysan-faked
>>> quotations, and these bad ideas have already doomed Forth-200x
>>> to failure.
>>
>> Aren't quotations and recognisers innovations for Forth and you are
>> doing your best to squelch them. It seems to me that you and others in
>> the anti-ANS/Forth200X brigade do the vast majority of any squelching
>> that is going on, without much apparent success though.
>
> The Paysan-faked quotations aren't an innovation --- they are just :NONAME with syntactic sugar --- I have never used :NONAME for anything and I consider it to be pretty much useless.

Squelch 1

Quotations are an innovation in ANS Forth, they provide the first
mechanism for nesting definitions inside another definition.
So they are not "just :NONAME with syntactic sugar".


I don't use floating point, so should I be campaigning to get the
Floating Point wordset deleted from Forth 200X on the grounds that I
find it useless?

>
> Forth-200x calls these "quotations" but they aren't quotations at all, because they don't have access to the parent function's local variables. They ruin the word "quotation" by using it wrong. If I say that I have quotations, everybody will reply: "You Forth programmers' quotations aren't quotations --- they are fake --- all Forth programmers are fakes!" Then I have to struggle to show that I'm using the word correctly, but it is too late because Forth-200x has given the entire Forth community a reputation for being fakes. This is very similar to what was described in the book, "1984," in which the words' meanings was changed --- "peace" meant "war," "freedom" meant "slavery," etc. --- Forth-200x is doing the same thing here, changing the meaning of "quotation" to mean "syntactic sugar for :NONAME"

Squelch 2

Is there an industry standard definition of the term 'quotations'? I
couldn't find one.

> --- it would really be better if you didn't fake this stuff --- just be honest and admit that you don't know how to implement quotations.

But I do know how to. I remember sending you some code a year or two
back that did so, explaining how it worked and you said you liked it!

>
> As for recognizers, that is not an innovation either --- that is an extremely bad idea.

Squelch 3 part 1

Whether recognisers are a bad idea or not it's still an innovation for
Forth.

> You are going to have a mish-mash of incompatible recognizers. If you have X sets of recognizers, and they all clash with each other (meaning that the order they are loaded is significant), then you have X! versions of Forth-200x syntax.

Why should they clash with each other any more than, say, libraries or
wordlists do. If the recognisers are supplied with the system, they
shouldn't clash. if they are defined by the user and they clash, that's
the user's fault.

> The problem with ANS-Forth is too much ambiguity, but with recognizers in Forth-200x you are making the problem worse. With 5 sets of recognizers that clash with each other, you have 120 incompatible versions of Forth-200x syntax. Programs are not going to be portable, because they all expect a different syntax. Also, it will be difficult for a person reading the source-code to figure out what it does. Normally, if a person sees a word that he doesn't know, then he can look it up in the documentation. With recognizers however, the person is going to see a lot of words which are interpreted by the recognizer but which aren't in the dictionary and aren't in the documentation either, so he doesn't know what the word means without learning how the recognizers work and mentally applying the recognizer to the word that is confusing him. All in all, I think that recognizers are such a bad idea that they totally doom Forth-200x to failure --- this is really the worst idea ever --- this w
ill kill Forth.

Squelch 3 part 2

But Forth has always been able to create it's own syntax - it's one of
its strong points. You do it in your Novice package.

>
> Thanks for not calling me a "stupid child"

You're welcome, it's actually easy to not insult people, it takes less
time too.

-- +-
Gerry

[Gerry Jackson]

On 04/09/2016 09:25, hughag...@gmail.com wrote:
> On Saturday, September 3, 2016 at 11:35:44 PM UTC-7, Gerry wrote:
>> On 03/09/2016 05:54, hughag...@gmail.com wrote:
>>> This is what Charles Moore was referring to when he said:
>>> "Any spirit of innovation has been thoroughly squelched."
>>> At the time that Straight Forth is released, when the
>>> ANS-Forth cult is striving mightily to squelch it, I will
>>> have difficulty in fixing any mistakes that made it into
>>> the design, because doing so will involve admitting that
>>> I was wrong about something --- it is best if I wait until
>>> I'm absolutely sure that there are no mistakes --- I
>>> should really write one or two non-trivial programs in
>>> Straight Forth before I even consider releasing it publicly.
>>
>> Very wise, nothing kills an interest in software than finding it is
>> bug-ridden. However this requires more than just a couple of non-trivial
>> programs to be written before release, it requires a comprehensive set
>> of test programs which test, not only the basic features but corner
>> cases, and include them with the system. This is also true for
>> applications and libraries. Few people seem to do this even though it is
>> in the developers' interest to do so.
>
> I wasn't really worried about bugs.

Well you ought to be.

> I generally write pretty bug-free code. I was more interested in design issues. For example, there is my OOP package:
> https://groups.google.com/forum/#!topic/comp.lang.forth/cH-pGXhBCfE
> This is bug-free.

All programmers think that about their own software until actual users
prove them wrong.

> I read Bernd Paysan's page discussing Mini-OOF:
> https://bernd-paysan.de/mini-oof.html
>
> He says: "Gerry Jackson wrote a larger example, LexGen. This example extends Mini-OOF slightly, but it shows that with these small changes, Mini-OOF can be used for real-world applications."
>
> Why did you write your LexGen using Mini-OOF???

Because it's small and elegant, providing much power with very little code.

> It is obvious that Mini-OOF is typical Paysan code! This is his METHOD definer:
>
> : method ( m v -- m' v ) Create over , swap cell+ swap
> DOES> ( ... o -- ... ) @ over @ + @ execute ;
>
> That is horribly inefficient! Any code that uses CREATE DOES> is going to be inefficient.

So what. It's a bit slower, but if that isn't an issue it's a waste of
time to worry about optimisation. I use a desktop PC that provides
plenty of power so a few microseconds difference in execution time isn't
a problem. Anyway that tool was developed about 10 years ago and you
weren't around to educate me :)

> My method calls are about 10 times more efficient under SwiftForth (SwiftForth is particularly inefficient with CREATE DOES> words) and about 3 times more efficient under VFX.

If the code EXECUTE'd at the end of the DOES> part swamps the overhead
of reaching the EXECUTE, efficiency of the DOES> is irrelevant.

>
> So, why did you use Mini-OOF when it is obviously no good?

Slightly slower execution time doesn't make it bad per se. It's good for
what I've used it for.

> I think that you did this because Mini-OOF was written by Bernd Paysan
who is a Forth-200x committee member --- you are being loyal to
Forth-200x --- you don't care about efficiency at all, but you are
treating Forth as a toy language suitable only for science-fair projects.

Your thinking is totally wrong. Why insult me? You might think that and
I can't stop you and no argument from me will convince you otherwise.


--
Gerry

[Anton Ertl]

Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>Is there an industry standard definition of the term 'quotations'? I
>couldn't find one.

Googlintg for "quotations programming" does not bring up anything in
that direction. We have the term from Factor. Not sure where Factor
has it from. BTW, I have not heard from the Factor people in a while.
Have they abandoned Usenet?

[HAA]

Stephen Pelc wrote:
> On Sat, 3 Sep 2016 22:48:06 +1000, "HAA" <som...@microsoft.com>
> wrote:
>
> >Except that 35 years on there are still no portable programs as
> >WJ makes clear.
>
> Absolute rubbish. Since the ANS standard was adopted, MPE's ability
> to use other people's Forth source code has improved markedly.
> We speak from experience, not from hand-waving.
>
> Stephen

ANS' prime objective is stated as follows:

1.1 Purpose
The purpose of this Standard is to promote the portability of Forth programs
for use on a wide variety of computing systems, ...

If in the 22 years ANS has existed, Forth has failed to produce said portable programs
and its only use of ANS has been "to facilitate the communication of programs,
programming techniques, and ideas among Forth programmers" then it barely
needs a standard. A glossary would have sufficed.

[Coos Haak]

Op Sun, 4 Sep 2016 14:13:05 +0100 schreef Gerry Jackson:

> On 04/09/2016 09:25, hughag...@gmail.com wrote:

<snip>

>> I think that you did this because Mini-OOF was written by Bernd Paysan
>> who is a Forth-200x committee member --- you are being loyal to
>> Forth-200x --- you don't care about efficiency at all, but you are
>> treating Forth as a toy language suitable only for science-fair projects.
>>
> Your thinking is totally wrong. Why insult me? You might think that and
> I can't stop you and no argument from me will convince you otherwise.

See? That is what I call childish behavior: Insulting each and
everyone who has a tiny bit of critique of his utterings.

groet Coos

[Albert van der Horst]

You're apparently not a professional because you have the illusion of
absolute portability. Portability is more something of 2 nines (very good)
to 5 nines (almost unobtainable).

Groetjes Albert

[hughag...@gmail.com]

On Sunday, September 4, 2016 at 6:13:02 AM UTC-7, Gerry wrote:
> On 04/09/2016 09:25, hughag...@gmail.com wrote:
> > I wasn't really worried about bugs.
>
> Well you ought to be.
>
> > I generally write pretty bug-free code. I was more interested in design issues. For example, there is my OOP package:
> > https://groups.google.com/forum/#!topic/comp.lang.forth/cH-pGXhBCfE
> > This is bug-free.
>
> All programmers think that about their own software until actual users
> prove them wrong.

Show me any bug in that code.

> If the code EXECUTE'd at the end of the DOES> part swamps the overhead
> of reaching the EXECUTE, efficiency of the DOES> is irrelevant.

The reason why CREATE DOES> is slow is that constant data that was comma'd after the CREATE has to be fetched out of memory to be used. For example, consider Stephen Pelc's FIELD from his book: "Programming Forth."

: field \ offset n -- offset+n ; addr -- addr+offset
\ When defining a structure, a field of size n starts
\ at the given offset, returning the next offset. At
\ run time, the offset is added to the base address.
create
over , + \ lay offset and update
does>
@ + \ addr offset to address
;

This is grossly inefficient code! I would never put such horrible code in the novice-package! This is a disgrace to the Forth programming language --- showing novice Forth programmers such bad code will either turn them into bad Forth programmers (if they don't have any prior programming experience) or will turn them off on Forth (if they do have prior programming experience).

His code has to @ from memory at run-time to obtain the offset. This offset is a constant value that is known at compile-time --- it should be compiled as a literal (this is what I do in my FIELD in the novice-package).

Stephen Pelc's code is very slow! He is accessing memory unnecessarily. Also, he is accessing memory from the data that is after the CREATE which is by itself out there, meaning that it will have to be loaded into the data-cache. This results in data-cache thrashing which is the #2 cause of slow software on modern computers.

You say that you don't need to worry about speed because you have a modern computer. Your computer has only a 32KB cache however --- this has been true for several years, and will continue to be true for several more years --- cache thrashing is going to cause an unreasonable slow-down.

Another serious problem with Pelc's code is that he is not aligning his fields! This is horrible! Accessing unaligned data is the #1 cause of slow software on modern computers. This was actually the #1 cause of slow software on ancient computers too --- everything from the 8086 onward --- it wasn't a problem on 8-bit data-bus computers such as the 6502 and 8088 though.

Code such as Stephen Pelc presented in his book is the reason why Forth has a reputation for being a toy language.

This is my FIELD from the novice-package:

: <field> ( offset -- ) \ run-time: struct-adr -- field-adr \ stream: name
?dup if >r
: state@, if, r@ lit, postpone lit+,
else, r@ lit+, then, ;,
immediate
rdrop
else
: ;, immediate \ the first field does nothing whatsoever
then ;

: field ( offset size -- new-offset ) \ stream: name
aligned swap aligned tuck \ -- offset size offset
<field> \ -- offset size
+ ; \ -- new-offset

Stephen Pelc actually has a version of FIELD that is comparable to mine in efficiency. He teaches the readers of his book the grossly inefficient version though --- he ruins their minds with this horrible code --- what is the point of that?

> > So, why did you use Mini-OOF when it is obviously no good?
>
> Slightly slower execution time doesn't make it bad per se. It's good for
> what I've used it for.
>
> > I think that you did this because Mini-OOF was written by Bernd Paysan
> who is a Forth-200x committee member --- you are being loyal to
> Forth-200x --- you don't care about efficiency at all, but you are
> treating Forth as a toy language suitable only for science-fair projects.
>
> Your thinking is totally wrong. Why insult me? You might think that and
> I can't stop you and no argument from me will convince you otherwise.

My thinking is not "totally wrong" --- I said that you use the code from the Forth-200x committee members because you are being loyal to the Forth-200x committee --- this is the truth.

Everybody seems to be totally focused on being loyal to the Forth-200x committee. They will use horribly inefficient and badly-designed code because it has been approved by the committee, and will turn a blind eye to efficient well-designed code that has not been approved by the committee. Nobody is actually writing Forth programs --- everybody believes that being a Forth programmer consists entirely of being on the Forth-200x mailing-list and participating in setting the Standard for the Forth community --- everybody involved in Forth-200x imagines that common Forth programmers such as myself are breathlessly waiting for them to provide us with their wisdom.

[Ron Aaron]

On 09/05/2016 08:33, hughag...@gmail.com wrote:

> This is grossly inefficient code! I would never put such horrible code in the novice-package! This is a disgrace to the Forth programming language --- showing novice Forth programmers such bad code will either turn them into bad Forth programmers (if they don't have any prior programming experience) or will turn them off on Forth (if they do have prior programming experience).

Gross! Inefficient! Oh, the humanity!

Did you *measure* performance? That's the only thing that matters,
ultimately: does the user find the performance adequate or not.

> You say that you don't need to worry about speed because you have a modern computer. Your computer has only a 32KB cache however --- this has been true for several years, and will continue to be true for several more years --- cache thrashing is going to cause an unreasonable slow-down.

Total BS, as usual, Hugh.

My desktop computer (which is several years old) has an L1 cache of 128K
(only four times as big as you stated); an L2 cache of 1M and an L3 of
6M. It has three caches, the smallest of which is four times bigger
than the "only" cache you claim his computer has.

Just to bring you up to date: almost every computer sold in the past
many years has several caches, since the CPU speeds are much faster than
the RAM speeds. Even the ancient laptop I use for serving mail has an
L1 of 128K and an L2 of 256K.

You might consider reading up on the subject before opening your gob.

[hughag...@gmail.com]

The term comes from Factor.

You keep saying that I'm opposed to quotations. WTF??? I'm not opposed to quotations --- I'm the only person around who is promoting quotations --- I'm opposed to Paysan-faked quotations.

In regard to your analogy about floating-point --- if the floating-point wordset was fake (for example: using double-precision integers but faking them up to look like floats by allowing the decimal-point to be used), then you should be campaigning against the floating-point wordset --- if any feature is going to be put in the Standard, then it should be done correctly (the Paysan-faked quotations are totally fake; these aren't quotations at all).

I mean: "If it is worth doing, then it is worth doing right."

Are you aware that I wrote some code for rquotations (a slight upgrade on HumptyDumpty's rquotations implementation) that pretty-much works? This is not as good as the fat-xt implementation that will be in Straight Forth, but it does pretty-much work under VFX and SwiftForth. I say "pretty-much" because there are some limitations --- the HOF has to have locals and there can only be one HOF under the parent function --- these limitations are not restrictive however, and should not be a problem in the majority of usages.

I thought that my rquotations really killed the Paysan-faked quotations because they worked pretty well, whereas the Paysan-faked quotations didn't work at all. I just implemented the rquotations as a joke though --- I knew that the Paysan-faked quotations were destined to get accepted into Forth-200x (they were promoted by Anton Ertl, the chair-person of Forth-200x) --- it just seemed funny to provide code that works juxtaposed against Paysan's ridiculous non-working code.

> > --- it would really be better if you didn't fake this stuff --- just be honest and admit that you don't know how to implement quotations.
>
> But I do know how to. I remember sending you some code a year or two
> back that did so, explaining how it worked and you said you liked it!

I liked your code, but it was inefficient --- my rquotations are more efficient, although with some limitations --- my fat-xt in Straight Forth is also efficient, and it doesn't have any limitations.

> > As for recognizers, that is not an innovation either --- that is an extremely bad idea.
>
> Squelch 3 part 1
>
> Whether recognisers are a bad idea or not it's still an innovation for
> Forth.

There is absolutely no way that I would ever allow recognizers in Straight Forth --- the name "Straight Forth" implies that the users can't play games with changing the syntax --- recognizers are not an innovation, recognizers are the devil.

The whole idea with Straight Forth is that it is a very simple Forth (about half the size of ANS-Forth) that is very easy to understand --- Straight Forth itself is not innovative --- Straight Forth is a platform for programming, and the programs are (hopefully) innovative.

> > You are going to have a mish-mash of incompatible recognizers. If you have X sets of recognizers, and they all clash with each other (meaning that the order they are loaded is significant), then you have X! versions of Forth-200x syntax.
>
> Why should they clash with each other any more than, say, libraries or
> wordlists do. If the recognisers are supplied with the system, they
> shouldn't clash. if they are defined by the user and they clash, that's
> the user's fault.

The psychology of the Forth-200x crowd is that all of them want to be creative, but none of them have any meaningful ideas. They are wanna-be artists.

There are going to be a lot of recognizers written --- mostly late at night and fueled by alcohol --- I guarantee that you are going to have portability problems because every program specifies a mish-mash of recognizers that are used on one Forth-200x system, but which aren't used on another Forth-200x system.

It is very likely that more Forth-200x enthusiasts will write recognizers, than will write programs.

[Ron Aaron]

On 09/05/2016 09:09, hughag...@gmail.com wrote:
> There is absolutely no way that I would ever allow recognizers in Straight Forth --- the name "Straight Forth" implies that the users can't play games with changing the syntax...

Hmm. In 2011 you said, 'In case you didn't get it, I call my language
"Straight Forth" to distinguish it from Forth-200x, which I will refer
to as "Gay Forth."'. (ref:
https://groups.google.com/d/msg/comp.lang.forth/tKeVZajFD04/Gw3EhlFlE1YJ)

So what caused you to change the reason for the name?

> The whole idea with Straight Forth is that it is a very simple Forth (about half the size of ANS-Forth) that is very easy to understand --- Straight Forth itself is not innovative --- Straight Forth is a platform for programming, and the programs are (hopefully) innovative.

So, big boy, when will we finally get to see "Straight Forth" ? You've
been going on about it since 2011. That should be sufficient, even for
you, to write something useful. Five years and counting!
(ref:
https://groups.google.com/d/msg/comp.lang.forth/Vc1vLRE16t0/0SnRSBWn7_AJ)

You keep on saying "Straight Forth *is*". I don't think the word "is"
means what you think it means...

[Gerry Jackson]

On 05/09/2016 07:09, hughag...@gmail.com wrote:
> On Sunday, September 4, 2016 at 5:26:23 AM UTC-7, Gerry wrote:
>> On 04/09/2016 08:41, hughag...@gmail.com wrote:
>>> On Saturday, September 3, 2016 at 11:35:44 PM UTC-7, Gerry wrote:
>>>> On 03/09/2016 05:54, hughag...@gmail.com wrote:
>>> The Paysan-faked quotations aren't an innovation --- they are just :NONAME with syntactic sugar --- I have never used :NONAME for anything and I consider it to be pretty much useless.
>>

>> Quotations are an innovation in ANS Forth, they provide the first
>> mechanism for nesting definitions inside another definition.
>> So they are not "just :NONAME with syntactic sugar".
>>
>> I don't use floating point, so should I be campaigning to get the
>> Floating Point wordset deleted from Forth 200X on the grounds that I
>> find it useless?
>>
>>>
>>> Forth-200x calls these "quotations" but they aren't quotations at all, because they don't have access to the parent function's local variables. They ruin the word "quotation" by using it wrong. If I say that I have quotations, everybody will reply: "You Forth programmers' quotations aren't quotations --- they are fake --- all Forth programmers are fakes!" Then I have to struggle to show that I'm using the word correctly, but it is too late because Forth-200x has given the entire Forth community a reputation for being fakes. This is very similar to what was described in the book, "1984," in which the words' meanings was changed --- "peace" meant "war," "freedom" meant "slavery," etc. --- Forth-200x is doing the same thing here, changing the meaning of "quotation" to mean "syntactic sugar for :NONAME"
>>

>> Is there an industry standard definition of the term 'quotations'? I
>> couldn't find one.
>
> The term comes from Factor.

So it's not a standard software term so the Forth community is free to
define its own meaning of the word as a (possible) subset of Factor's
meaning (I don't know full details of Factor's definition). Anyway you
miss the point that Forth quotations could be extended in the future to
match your expectations should sufficient people in the Forth community
support the idea, which doesn't seem to be true at present.

>
> You keep saying that I'm opposed to quotations. WTF??? I'm not opposed to quotations

You've lost me there - I don't believe I have ever said that, I
certainly don't think it.

> --- I'm the only person around who is promoting quotations --- I'm opposed to Paysan-faked quotations.

Well it's a step in the right direction. People can then try them and if
they find them too limited, then they may come around to support an
extension. It's the incremental strategy. You miss or deliberately
ignore the point that if the Forth community does not support an idea
then there is no point in including it in the standard as it will never
be widely supported. That's why CfV's are issued.

>
> In regard to your analogy about floating-point --- if the floating-point wordset was fake (for example: using double-precision integers

But the floating point wordset, or indeed the whole standard itself,
avoids specifying implementation details like that so what you say is
inapplicable. Anyway I was using that as an ludicrous application of
your logic which seems to be - "I don't find a feature useful, therefore
it is totally useless for everybody."

> I mean: "If it is worth doing, then it is worth doing right."
>
> Are you aware that I wrote some code for rquotations (a slight upgrade on HumptyDumpty's rquotations implementation)

Yes, but as they were a joke I didn't take much notice other than to see
they relied on non-standard return stack manipulation.

> I thought that my rquotations really killed the Paysan-faked quotations because they worked pretty well, whereas the Paysan-faked quotations didn't work at all. I just implemented the rquotations as a joke though --- I knew that the Paysan-faked quotations were destined to get accepted into Forth-200x (they were promoted by Anton Ertl, the chair-person of Forth-200x) --- it just seemed funny to provide code that works juxtaposed against Paysan's ridiculous non-working code.
>

>>> As for recognizers, that is not an innovation either --- that is an extremely bad idea.
>>

>> Whether recognisers are a bad idea or not it's still an innovation for
>> Forth.
>
> There is absolutely no way that I would ever allow recognizers in Straight Forth

As the inventor of Straight Forth that's your prerogative.

> recognizers are not an innovation, recognizers are the devil.

Well then I'll be sure to use a long spoon.

> There are going to be a lot of recognizers written --- mostly late at night and fueled by alcohol --- I guarantee that you are going to have portability problems because every program specifies a mish-mash of recognizers that are used on one Forth-200x system, but which aren't used on another Forth-200x system.

But if the standard for recognisers just provides the primitives for
programmers to write their own recognisers, won't they include the
recogniser code with their programs. If that clashes with somebody
else's recognisers, then its up to the user to choose. In principle it's
the same situation with software libraries where there may be name clashes.

>
> It is very likely that more Forth-200x enthusiasts will write recognizers, than will write programs.

Sure, some people keep writing string stack libraries instead of using
existing ones, despite knowing they exist.

--
Gerry

[Anton Ertl]

peter....@gmail.com writes:
>On Monday, 29 August 2016 23:16:15 UTC+2, Anton Ertl wrote:
>> The basic idea behind ]]...[[ is that ] switches to the next more
>> delaying state (from interpretation to compilation, from compilation
>> to postponing), and [ to the next less delaying state (from postponing
>> to compiling, from compiling to interpreting); however, unfortunately,
>> the standard specifies "]" in a way that does not allow working the
>> way envisioned above, so "]]" was introduced instead, and "[[" to go
>> with it. And the current implementation only do the switching from
>> compilation to postponing, and back, not the full monty.
>>
>> It may be more obvious why the brackets have this direction, if you
>> want to have some intermediate compilation action in the middle of the
>> postponeing, e.g.:
>>
>> : derivative { xt1 F: r -- xt2 }
>> :noname ]]
>> fdup [[ r ]] fliteral f+ [[ xt1 compile, ]] fswap [[ xt1 compile, ]] f-
>> [[ r ]] fliteral f/ ;
>> [[ ;
>>
>> >it really looks backwards now!
>>
>> Looking at the DERIVATIVE example, do you still think so?
>
>Yes and it looks real horrible. I would have written
>
>: derivative { xt1 F: r -- xt2 }
> :noname
> postpone fdup r postpone fliteral postpone f+ xt1 compile,
> postpone fswap xt1 compile, postpone f-
> r postpone fliteral postpone f/ postpone ;
> ;

I find the bracketed variant much more readable. It's hard to follow
the logic with all the POSTPONEs in between.

One thing I forgot to mention: The idea is also to be able to take the
code out of the colon definition for testing. In this case this would
look like:

1e-6 fvalue r
' fsin value xt1
:noname
fdup [ r ] fliteral f+ [ xt1 compile, ] fswap [ xt1 compile, ] f-
[ r ] fliteral f/ ;

Unfortunately, we cannot use [ and ] for postpone state; what could
work is to let [[ work in compile state and ]] in interpret state,
with the meanings of [ and ] in these states, but there is no
implementation for that yet; with that we could cut and paste most of
the code from DERIVATIVE for interpretation.

The remaining difference is that we have ":noname ]]" in DERIVATIVE,
but just ":noname" interpretively; If we have a factor (say, :NONAME[)
that does not switch to compile state at its run-time, we could use
":noname[ ]]" in both cases.

[Gerry Jackson]

The condition for your initial 'If' is false so your 'then' part is not
applicable. I think you're just parroting Hugh. Even Hugh has written
portable software in ANS Forth - his Novice package, string stack.

A glossary would have sufficed.
>
>
>

A definition of Glossary

"noun, plural glossaries.
1.
a list of terms in a special subject, field, or area of usage, with
accompanying definitions.
2.
such a list at the back of a book, explaining or defining difficult or
unusual words and expressions used in the text."

Looks to me like definition 1 applies to both the ANS and Forth 2012
standards. So they are already glossaries.

--
Gerry

[Gerry Jackson]

On 05/09/2016 06:33, hughag...@gmail.com wrote:
> On Sunday, September 4, 2016 at 6:13:02 AM UTC-7, Gerry wrote:
>> On 04/09/2016 09:25, hughag...@gmail.com wrote:
>>> I wasn't really worried about bugs.
>>
>> Well you ought to be.
>>
>>> I generally write pretty bug-free code. I was more interested in design issues. For example, there is my OOP package:
>>> https://groups.google.com/forum/#!topic/comp.lang.forth/cH-pGXhBCfE
>>> This is bug-free.
>>
>> All programmers think that about their own software until actual users
>> prove them wrong.
>
> Show me any bug in that code.

There's a vast difference between a short bit of code like that and a
complete application. Even your string stack package had a few bugs that
I reported to you?

Could you post the final version of your OOP? In the link you posted
there are different versions with updates and corrections in other
threads that make it time consuming to sort out.

>
>> If the code EXECUTE'd at the end of the DOES> part swamps the overhead
>> of reaching the EXECUTE, efficiency of the DOES> is irrelevant.
>
> The reason why CREATE DOES> is slow is that constant data that was comma'd after the CREATE has to be fetched out of memory to be used. For example, consider Stephen Pelc's FIELD from his book: "Programming Forth."
>
> : field \ offset n -- offset+n ; addr -- addr+offset
> \ When defining a structure, a field of size n starts
> \ at the given offset, returning the next offset. At
> \ run time, the offset is added to the base address.
> create
> over , + \ lay offset and update
> does>
> @ + \ addr offset to address
> ;
>
> This is grossly inefficient code! I would never put such horrible code in the novice-package!

That's as may be - you haven't addressed my point. Neither do your
following paragraphs that I've snipped.

>>> So, why did you use Mini-OOF when it is obviously no good?
>>
>> Slightly slower execution time doesn't make it bad per se. It's good for
>> what I've used it for.
>>
>>> I think that you did this because Mini-OOF was written by Bernd Paysan
>> who is a Forth-200x committee member --- you are being loyal to
>> Forth-200x --- you don't care about efficiency at all, but you are
>> treating Forth as a toy language suitable only for science-fair projects.
>>
>> Your thinking is totally wrong. Why insult me? You might think that and
>> I can't stop you and no argument from me will convince you otherwise.
>
> My thinking is not "totally wrong" --- I said that you use the code from the Forth-200x committee members because you are being loyal to the Forth-200x committee --- this is the truth.

No, you're mistaken - I should know, you can only speculate. I used
mini-oof on its merits. The fact it was written by a committee member is
incidental. Who knows I might even use your OOP in the future for a new
application - your repeated rudeness wouldn't put me off. But I'm
certainly not going to re-write an existing complex tool to use your OOP
because I know wouldn't give me any significant performance improvement.
I'm not even to going to try it as an experiment - if it ain't broke
don't fix it (and it certainly ain't broke).

>
> Everybody seems to be totally focused on being loyal to the Forth-200x committee.They will use horribly inefficient and badly-designed code because it

has been approved by the committee, and will turn a blind eye to
efficient well-designed code that has not been approved by the
committee. Nobody is actually writing Forth programs --- everybody
believes that being a Forth programmer consists entirely of being on the
Forth-200x mailing-list and participating in setting the Standard for
the Forth community --- everybody involved in Forth-200x imagines that
common Forth programmers such as myself are breathlessly waiting for
them to provide us with their wisdom.
>

Sorry Hugh but I have to say that is absolute nonsense.


--
Gerry

[hughag...@gmail.com]

On Monday, September 5, 2016 at 12:41:25 AM UTC-7, Gerry wrote:
> On 04/09/2016 17:35, HAA wrote:
> > Stephen Pelc wrote:
> >> On Sat, 3 Sep 2016 22:48:06 +1000, "HAA" <som...@microsoft.com>
> >> wrote:
> >>
> >>> Except that 35 years on there are still no portable programs as
> >>> WJ makes clear.
> >>
> >> Absolute rubbish. Since the ANS standard was adopted, MPE's ability
> >> to use other people's Forth source code has improved markedly.
> >> We speak from experience, not from hand-waving.
> >>
> >> Stephen
> >
> > ANS' prime objective is stated as follows:
> >
> > 1.1 Purpose
> > The purpose of this Standard is to promote the portability of Forth programs
> > for use on a wide variety of computing systems, ...
> >
> > If in the 22 years ANS has existed, Forth has failed to produce said portable programs
> > and its only use of ANS has been "to facilitate the communication of programs,
> > programming techniques, and ideas among Forth programmers" then it barely
> > needs a standard.
>
> The condition for your initial 'If' is false so your 'then' part is not
> applicable. I think you're just parroting Hugh. Even Hugh has written
> portable software in ANS Forth - his Novice package, string stack.

All of my novice-package is ANS-Forth and should be portable to any ANS-Forth system --- but doing this was a major hassle as I had to work around the problems in ANS-Forth --- I know more about ANS-Forth than most, and I consider ANS-Forth to be the worst language standard ever; this opinion does not come from ignorance as is commonly presumed.

The main problem with ANS-Forth is that it is rife with ambiguity. It is possible for different ANS-Forth systems, all of which have support for their claim of ANS-Forth compliance in the ANS-Forth document, to be incompatible with each other in fundamental ways.

Another problem with ANS-Forth is that it lacks support for quotations. Consequently, it is difficult to implement general-purpose data-structures. You end up with pseudo-quotations, such as I used in the novice-package. If you don't have general-purpose data-structures then your new programs will use cut-and-paste-and-modify of old programs --- this also is a failure to support portability --- you want to have portable code-libraries so when you port a program you can find the same code-libraries available on the new system as you had on the old system, and all you have to port is your own code which is fairly small.

Another problem with ANS-Forth is that it lacks a lot of basic features. These features often require assembly-language to implement, so they are necessarily not portable. Also, there is no standard way to implement them, so there may be subtle differences from one implementation to another.

Another problem with ANS-Forth is that it has too many features, many of which are redundant. This doesn't cause portability problems, but it does make the language difficult to learn, and overly complicated to use. The goal with Straight Forth is that it should not only be twice as powerful as ANS-Forth, but also half the size.

P.S. for HAA --- it has only been 22 years since ANS-Forth came out, not 35 --- maybe you were thinking of Forth-83 which was 33 years ago (Forth-79, Forth-83 and ANS-Forth were all screwed up by Forth Inc., and Forth-200x will also be screwed up by Forth Inc.).

[Anton Ertl]

Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>On 04/09/2016 09:25, hughag...@gmail.com wrote:
>> Why did you write your LexGen using Mini-OOF???
>
>Because it's small and elegant, providing much power with very little code.
>
>> It is obvious that Mini-OOF is typical Paysan code! This is his METHOD definer:
>>
>> : method ( m v -- m' v ) Create over , swap cell+ swap
>> DOES> ( ... o -- ... ) @ over @ + @ execute ;
>>
>> That is horribly inefficient! Any code that uses CREATE DOES> is going to be inefficient.
>
>So what. It's a bit slower, but if that isn't an issue it's a waste of
>time to worry about optimisation. I use a desktop PC that provides
>plenty of power so a few microseconds difference in execution time isn't
>a problem. Anyway that tool was developed about 10 years ago and you
>weren't around to educate me :)
>
>> My method calls are about 10 times more efficient under SwiftForth (SwiftForth is particularly inefficient with CREATE DOES> words) and about 3 times more efficient under VFX.

Let's see how much speedup we get from eliminating the memory access
caused by CREATE DOES> in LexGen, when using VFX. Here's the code:

0 [if]
synonym set-optimizer drop

: var ( m v size "<spaces>name" -- m v' )
create over , +
does> @ +
;
[else]
synonym set-optimizer set-compiler

synonym var +field
[then]

: opt-method ( xt -- )
>body @ postpone literal postpone over postpone @ postpone + postpone @ postpone execute ;

: method ( m v "<spaces>name" -- m' v )
create over , swap cell+ swap
['] opt-method set-optimizer
does>

@ over @ + @ execute
;

\ further down

: opt-class-var ( xt -- )
>body @ postpone literal postpone + ;

: class-var ( m v size "<spaces>name" -- m' v )
aligned 2>r
create dup ,
r> + r> ( -- m' v )
['] opt-class-var set-optimizer
does> ( class -- addr )
@ +
;

\ Class method - accessed via the class name, equivalent to
\ static methods

: opt-class-method ( xt -- )
>body @ postpone literal postpone over postpone + postpone @ postpone execute ;

: class-method ( m v "<spaces>name" -- m' v )
create
over , >r cell+ r>
['] opt-class-method set-optimizer
does> ( class -- ? )
@ over + @ execute
;

With the plain create-does> code, I get (9 runs, results in seconds
CPU time on a Core i7-6700K at 4GHz (no turbo)):

[1.884 1.892 1.916 1.920 1.920 1.920 1.924 1.924 1.928 ] lexex

With the optimized code, I get:

[1.896 1.896 1.900 1.900 1.904 1.908 1.908 1.908 1.908 ] lexex

A speedup by a whopping factor of 1.008 for the median result.

[hughag...@gmail.com]

On Monday, September 5, 2016 at 1:20:04 AM UTC-7, Gerry wrote:
> On 05/09/2016 06:33, hughag...@gmail.com wrote:
> > On Sunday, September 4, 2016 at 6:13:02 AM UTC-7, Gerry wrote:
> >> On 04/09/2016 09:25, hughag...@gmail.com wrote:
> >>> I wasn't really worried about bugs.
> >>
> >> Well you ought to be.
> >>
> >>> I generally write pretty bug-free code. I was more interested in design issues. For example, there is my OOP package:
> >>> https://groups.google.com/forum/#!topic/comp.lang.forth/cH-pGXhBCfE
> >>> This is bug-free.
> >>
> >> All programmers think that about their own software until actual users
> >> prove them wrong.
> >
> > Show me any bug in that code.
>
> There's a vast difference between a short bit of code like that and a
> complete application. Even your string stack package had a few bugs that
> I reported to you?
>
> Could you post the final version of your OOP? In the link you posted
> there are different versions with updates and corrections in other
> threads that make it time consuming to sort out.

The August 19 post of mine had the final version.
https://groups.google.com/forum/#!topic/comp.lang.forth/cH-pGXhBCfE

I can email a new novice-package to you, if you like, which will have the OOP package in it. I also intend to post the novice package on GIT or on Mark's website pretty soon, so it can be downloaded.

The OOP package is tentative. I haven't written any programs to use it, so I don't know if it is useful. I'm still thinking about writing that book Cecil suggested, and it would be based on this OOP package, but I would need to have an example program for the book which I haven't thought up yet. I'm still interested in Ido parsing, so maybe I will delve into that.

[Gerry Jackson]

Many thanks.
I was minded to try something similar and you've saved me the trouble.

Disclaimer for Hugh: despite appearances to the contrary, do not
interpret the above as me being a lickspittle to a member of the Forth
200X committee, I deny it. :)

--
Gerry

[hughag...@gmail.com]

This is just a big steaming pile of "choseness" a.k.a. bullshit.

The L1 data-cache and L1 code-cache are each 32KB (64-byte cache-line) --- this has been true since 2003 and will likely continue to be true for many more years.

You are the same lying pig who claimed that Israel is not using white-phosphorous on civilian targets and that the Palestinian burn-victims are faking their injuries --- you Israelis are no different from the Nazis --- I have no respect for you whatsoever!

[Ron Aaron]

On 07/09/2016 09:23, hughag...@gmail.com wrote:
> On Sunday, September 4, 2016 at 11:03:54 PM UTC-7, Ron Aaron wrote:
>> On 09/05/2016 08:33, hughag...@gmail.com wrote:
>>> You say that you don't need to worry about speed because you have a modern computer. Your computer has only a 32KB cache however --- this has been true for several years, and will continue to be true for several more years --- cache thrashing is going to cause an unreasonable slow-down.
>>
>> Total BS, as usual, Hugh.
>>
>> My desktop computer (which is several years old) has an L1 cache of 128K
>> (only four times as big as you stated); an L2 cache of 1M and an L3 of
>> 6M. It has three caches, the smallest of which is four times bigger
>> than the "only" cache you claim his computer has.
>>
>> Just to bring you up to date: almost every computer sold in the past
>> many years has several caches, since the CPU speeds are much faster than
>> the RAM speeds. Even the ancient laptop I use for serving mail has an
>> L1 of 128K and an L2 of 256K.
>>
>> You might consider reading up on the subject before opening your gob.
>
> This is just a big steaming pile of "choseness" a.k.a. bullshit.

You really are a complete dickhead, you know? But to the point:

> The L1 data-cache and L1 code-cache are each 32KB (64-byte cache-line) --- this has been true since 2003 and will likely continue to be true for many more years.

Stick it up your ass, pendejo:

http://www.cpu-world.com/CPUs/K8/AMD-Turion%2064%20X2%20Mobile%20technology%20TL-60%20-%20TMDTL60HAX5DM.html

That's my desktop processor, it has 128K of L1. Do some research and
learn, you ridiculous twat.

And L1 isn't the only cache...

> You are the same lying pig who claimed that Israel is not using white-phosphorous on civilian targets and that the Palestinian burn-victims are faking their injuries --- you Israelis are no different from the Nazis --- I have no respect for you whatsoever!

Ok, Ramon Raton. Info-in, drivel-out is your MO.

So: when can the world expect the premier of "Straight Forth"? I'm
getting goosebumps in anticipation.

[hughag...@gmail.com]

On Wednesday, September 7, 2016 at 12:14:46 AM UTC-7, Ron Aaron wrote:
> Stick it up your ass, pendejo:

You're being racist against me because I have a Spanish surname --- you dipshit; I don't even speak Spanish --- your effort to push my buttons didn't work because I don't care about ethnicity.

I'm not racist --- I am well aware that there is no significant difference between the races from a genetic standpoint --- I am not prejudiced against people based on race, and I don't use racist epitaphs.

I am prejudiced against juggalos, jews, homosexuals and drug fiends --- this isn't genetics --- it was your *choice* to live a life of depravity.

Also, the Israeli's use of white-phosphorous against civilian targets is a violation of the Geneva Convention --- and it was grossly offensive of you personally to lie about this and say that the Palestinian burn victims were faking their injuries --- you're a typical lying jew-pig.

Also, the L1 code-cache and L1 data-cache are 32KB each --- who do you think you are fooling? --- this is a programming forum; everybody here is familiar with the x86.

[Ron Aaron]

On 07/09/2016 11:01, hughag...@gmail.com wrote:

> You're being racist against me because I have a Spanish surname --- you dipshit; I don't even speak Spanish --- your effort to push my buttons didn't work because I don't care about ethnicity.

I'm not being racist against you. I happen to be a Spanish speaker
(among other things), and "pendejo" just fits you like a glove. But
push your buttons? That's not a difficult task...


> I'm not racist...

> I am prejudiced against juggalos, jews, homosexuals and drug fiends --- this isn't genetics --- it was your *choice* to live a life of depravity.

I've no idea what a 'juggalo' is. Is it like a "gigolo"? In which case
it's something you likely picked up on a street-corner somewhere.
Probably along with the syphilis which has clearly eaten away at your brain.

I'll confess to being a Jew, so I do fit at least one of the categories
of people you are prejudiced against. Good for you, mouth-breather. At
least you're honest enough to say you're against "Jews" and not
"Israelis". Good for you, you anti-Semitic prick.

> Also, the Israeli's use of white-phosphorous against civilian targets is a violation of the Geneva Convention --- and it was grossly offensive of you personally to lie about this and say that the Palestinian burn victims were faking their injuries --- you're a typical lying jew-pig.

<sigh> Since you refuse to follow links to factual statements (which I
have posted in the past), suffice it to say you're full of feces (as
usual). The Israeli army did not and does not use WP as a munition
against civilian targets. It does use WP (as does every other army) for
smoke-screens. That's a fact, it's documented, and I posted the docs in
the past.

The picture of "civilians burned by WP" was a fake, and documented as
such, you troglodytic imbecile.

So no, I did not "lie about this". You, in your extraordinary ignorance
and bigotry, continue to post lies and misinformation. So be it.

> Also, the L1 code-cache and L1 data-cache are 32KB each --- who do you think you are fooling? --- this is a programming forum; everybody here is familiar with the x86.

Were you to follow the link I posted, you would see that you are
factually incorrect. But hey, you don't like to let facts stand in your
way, do you, sunshine?

So when *is* Straight Farce making it's debut?

[Cecil Bayona]

On 9/7/2016 3:01 AM, hughag...@gmail.com wrote:
> Also, the L1 code-cache and L1 data-cache are 32KB each --- who do you think you are fooling? --- this is a programming forum; everybody here is familiar with the x86.

My Medium age machines from 2012 uses the I7-960, and I7-950 CPUs, they
have 4x32K 4 way cache for code, 4x32K 8 way cache for data, 1MB 4 way
L2 cache, and 8MB 16 way L3 cache. Yes they are organized as 32K chunks
for management but the L1 cache for code on that CPU is 128K a small
Forth can fit in it's entirety inside the code cache.

Another set of machine use the I7-2600 chip and it is similar to the
I7-960 except the cache is more finely divided.

This machine I'm on right now uses an I7-930 from 2010 and the cache is
just like the I7-960

All these machines use 32K cache buffers for data organization, but
there are multiple of them for a total of 128K of L1 cache for code, the
data cache has a similar arrangement.

All these I7-9xx machines are quite old but they use 3 memory channels
with matched memory (24 GB) so they are quite fast and I have not seen
the need to update them. They can run Windows 10, Linux, or OS X quite
well, and since I don't have a lot of money available it's fortuitous
that they do not need to be upgraded.

You guys need to take it down several notches, as this conversation if
it can be called that has spiraled way out control.


--
Cecil - k5nwa

[HAA]

Albert van der Horst wrote:
> In article <nqhifo$1kbj$1...@gioia.aioe.org>, HAA <som...@microsoft.com> wrote:
> >Stephen Pelc wrote:
> >> On Sat, 3 Sep 2016 22:48:06 +1000, "HAA" <som...@microsoft.com>
> >> wrote:
> >>
> >> >Except that 35 years on there are still no portable programs as
> >> >WJ makes clear.
> >>
> >> Absolute rubbish. Since the ANS standard was adopted, MPE's ability
> >> to use other people's Forth source code has improved markedly.
> >> We speak from experience, not from hand-waving.
> >>
> >> Stephen
> >
> >ANS' prime objective is stated as follows:
> >
> > 1.1 Purpose
> > The purpose of this Standard is to promote the portability of Forth programs
> > for use on a wide variety of computing systems, ...
> >
> >If in the 22 years ANS has existed, Forth has failed to produce said portable programs
> >and its only use of ANS has been "to facilitate the communication of programs,
> >programming techniques, and ideas among Forth programmers" then it barely
> >needs a standard. A glossary would have sufficed.
>
> You're apparently not a professional because you have the illusion of
> absolute portability. Portability is more something of 2 nines (very good)
> to 5 nines (almost unobtainable).
>
> Groetjes Albert

ANS does not require a program to have "absolute portability". What it does
require is that non-portabilities be documented. Despite the low bar ANS has
placed on program portability, there has been very little interest in writing them.
That includes me. You can ask why it is, but the fact of it cannot be denied.

[Paul Rubin]

"HAA" <som...@microsoft.com> writes:
> ANS does not require a program to have "absolute portability". What
> it does require is that non-portabilities be documented. Despite the
> low bar ANS has placed on program portability, there has been very
> little interest in writing them. That includes me. You can ask why
> it is, but the fact of it cannot be denied.

Forth is unusual among programming languages in that its target
environments very often involve special hardware. For such programs the
concept of portability doesn't apply since there is nothing to port to.

I've thought of ANS as providing a common word set for programmers to
expect to work on multiple systems, but in general they will expect to
add target-specific code for their own application environment. An
example of something ANS standardizes is that OR means inclusive or.
There are some non-standard systems where it means exclusive or.

ANS just means there is a base wordset that does what you expect it to
do. It doesn't claim to give you everything you need. You are on your
own for stuff that's not in the standard.

[HAA]

When the realization occurs that ANS hasn't, and 200x won't, deliver the
promised world of portable programs, then a forther is free. Free to think for
himself. To make decisions based on his needs - not the needs, compromises
and ideas of others. Free to make mistakes, correct them and move on -
unlike standards which require constant defending. Free to take the best
from standards and ignore the rest.

[Paul Rubin]

"HAA" <som...@microsoft.com> writes:
> When the realization occurs that ANS hasn't, and 200x won't, deliver
> the promised world of portable programs, then a forther is free.

What promised world of portable programs? I've never seen a portable C
program (one with no system-dependent #ifdef's) of any size. Even Java
("write once, debug everywhere") is less portable than some like to think.

> Free to take the best from standards and ignore the rest.

If the standard describes a workable way to do something and there's not
a substantial concrete benefit from doing something different, I don't
see good reason to depart from it. The standard envisages a fairly
traditional approach to implementation though. If you want to use a
very different approach (like Oforth in one direction, or Colorforth in
another) then ignoring the standard except as a distant source of
inspiration is more likely the way to go.

[hughag...@gmail.com]

On Thursday, September 8, 2016 at 12:41:35 PM UTC-7, Paul Rubin wrote:
> "HAA" <som...@microsoft.com> writes:
> > ANS does not require a program to have "absolute portability". What
> > it does require is that non-portabilities be documented. Despite the
> > low bar ANS has placed on program portability, there has been very
> > little interest in writing them. That includes me. You can ask why
> > it is, but the fact of it cannot be denied.
>
> Forth is unusual among programming languages in that its target
> environments very often involve special hardware. For such programs the
> concept of portability doesn't apply since there is nothing to port to.

Straight Forth is only for desktop computers. It has a 64-bit cell, so obviously it can't be used on micro-controllers. My goal here is a Forth that allows portability among programs that run on desktop computers. AFAIK, that is all that HAA is asking for too --- it is somewhat unrealistic to expect to port programs between the AVR and the ARM.

I'm dubious of the need for a standard for micro-controller Forth because the programs aren't going to be portable anyway, due to hardware dependencies. It might be possible to have a standard though. I'll leave that to Raimond --- he has a more experience in micro-controllers than I have --- Mark Wills thinks that common I/O can be standardized, and he may be right; he is someone else with more experience in micro-controllers than I have.

Straight Forth is intended to be the host for a cross-compiler, so it should be able to cross-compile any Forth for any micro-controller.

I don't know why everybody hates the idea of Straight Forth --- the need for a standard Forth for desktop computers is obvious --- way back in the late 1980s it was obvious that Forth-83 had serious problems, but I was told that there would soon be a Forth standard that fixed these problems and made sense.

[HAA]

Paul Rubin wrote:
> "HAA" <som...@microsoft.com> writes:
> > When the realization occurs that ANS hasn't, and 200x won't, deliver
> > the promised world of portable programs, then a forther is free.
>
> What promised world of portable programs?

> 1.1 Purpose
> The purpose of this Standard is to promote the portability of Forth programs
> for use on a wide variety of computing systems, ...
>

> I've never seen a portable C
> program (one with no system-dependent #ifdef's) of any size. Even Java
> ("write once, debug everywhere") is less portable than some like to think.
>
> > Free to take the best from standards and ignore the rest.
>
> If the standard describes a workable way to do something and there's not
> a substantial concrete benefit from doing something different, I don't
> see good reason to depart from it. The standard envisages a fairly
> traditional approach to implementation though.

Really? Since when are five words to handle defers traditional? 200x hasn't
been shy breaking tradition. ANS says floats on the data stack is traditional
and permitted it. 200x says floats must have a separate stack. ANS voted for
LOCALS|. 200x says its hideous and wants you to use {: :}. ANS says one
interpreted S" string is sufficient. 200x says two is necessary. ANS says use
CHAR and [CHAR]. 200x tells you to use something else. And so on.

The only choice Forth users have is whether to follow all this 'to and fro'ing
by TC's. I can't think of any good reason to - particularly when portability is
discounted as you did above.

[Anton Ertl]

"HAA" <som...@microsoft.com> writes:
>Since when are five words to handle defers traditional?

Traditional are DEFER and IS. Traditionally, carnal knowledge was
used when people wanted to do the things that Forth-2012 programs can
do with DEFER@ and DEFER!, but since we did not want to standardize
(uncarnalize) the carnal knowledge, we standardized DEFER@ and DEFER!.
Finally, someone wanted ACTION-OF as a parsing variant of DEFER@ (just
like we have IS as a parsing variant of DEFER!), and that's how we got
ACTION-OF.

>200x hasn't
>been shy breaking tradition. ANS says floats on the data stack is traditional
>and permitted it. 200x says floats must have a separate stack.

Yes, so Forth-2012 has standardized an aspect of floating-point that
Forth-94 has not standardized. That's based on common practice:
Hardly any programs that used FP were actually Forth-94 compliant and
would run on both kinds of systems; most programs depended on a
separate FP stack, so that's what we standardized.

> ANS voted for
>LOCALS|. 200x says its hideous and wants you to use {: :}.

Most programmers who used locals found the locals order of LOCALS|
unacceptable, and used the { ... } syntax with the other order
instead. That became {: ... :} on standardization to avoid a conflict
with a SwiftForth feature. LOCALS| is in Forth-2012, but obsolescent,
so the recommendation is to change it to {: ... :} at some point in
the future. But if you prefer LOCALS| and want to keep using it, you
can define it with (LOCAL).

> ANS says one
>interpreted S" string is sufficient. 200x says two is necessary.

Wow, Forth-2012 is a horrible tradition-breaking monster! It gives
more guarantees to programs than Forth-94! The horror!

>ANS says use
>CHAR and [CHAR]. 200x tells you to use something else.

You can still use CHAR and [CHAR]; they are not obsolescent. Now you
can also write 'a', and cut-and-paste it between interpretation and
compilation (a tradition-breaking change if ever there was one!).

[HAA]

With possible exception of the first, all these changes boil down to personal
preference - not need.

If somebody chooses to break tradition and implement DEFER in a manner
that requires five words where previously two sufficed, it shouldn't become
my problem or Forth's. I could not justify three new words for a rarely used
feature that I could access in traditional ways.