"Hello world" using Hughs novice package

[Alexander Wegel]

The following code prints "hello world" and uhm-exits forth.

\ the marvels of late binding
s" novice.4th" included
: w ." hello world" cr ;
0 allocation
at this point the program already did its thing and uhm-exited!

[Andrew Haley]

Can you explain a little more?

Andrew.

[Julian Fondren]

see allocation
: allocation
s\" ( adr -- size ) \\ unsigned" evaluate s\" <allocation>
abs " evaluate ; immediate ok
see <allocation>
: <allocation>
s\" ( adr -- size ) \\ signed \\ negative means it is a concrete
node" evaluate s\" w - @ " evaluate ; immediate ok

That definition of W changes ALLOCATION's behavior.

[Alexander Wegel]

Andrew Haley <andr...@littlepinkcloud.invalid> wrote:

> Alexander Wegel <awe...@arcor.de> wrote:
> > The following code prints "hello world" and uhm-exits forth.
> >
> > \ the marvels of late binding

Correction: \ the marvels of "late binding"

> > s" novice.4th" included
> > : w ." hello world" cr ;
> > 0 allocation
> > at this point the program already did its thing and uhm-exited!
>
> Can you explain a little more?

Well, Hugh was sad that nobody reads his code, so i had a look at it.

Merry christmas!

[hughag...@gmail.com]

I originally wrote MACRO to use early-binding. This was under UR/Forth and was part of MFX. I later upgraded this to ANS-Forth, but I got criticized for that here:
https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D
The problem was that FIND is ambiguous, so while my early-binding MACRO worked under SwiftForth, it didn't work under Gforth. Anton Ertl said this:

On Thursday, November 26, 2009 at 3:24:06 AM UTC-7, Anton Ertl wrote:
> Hugh Aguilar <hugoa...@rosycrew.com> writes:
> >On Nov 25, 4:14=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >wrote:
> >> >On Nov 25, 8:57=3DA0am, Hugh Aguilar <hugoagui...@rosycrew.com> wrote:
> >> >> I don't use gforth. What does that error message mean? What is a
> >> >> "compile-only word?"
> >>
> >> A word without interpretation semantics.
> >>
> >> >It doesn't like you taking the address of ";" , though I don't
> >> >understand why.
> >>
> >> Because ";" has no execution or interpretation semantics. =A0The
> >> execution token returned by ['] represents the execution semantics,
> >> but since ";" does not have that ...
> >
> >I don't understand how a word can not have execution semantics.
>
> That's quite simple: By not defining execution semantics in the
> definition of the word in the standard document. Look up the
> definition of ";" in the standard, and you will see that there is no
> "Execution:" section there; and there are other labeled sections
> there, so the "omitted label" sentence of 3.4.3.1 does not apply.
>
> >For immediate words (IF, ;, etc.)
>
> IF and ";" are not immediate words in the standard. A system can
> implement them as immediate words, but a program cannot rely on their
> immediacy.
>
> >I looked up ['] in the ANS-Forth document and it says:
> >
> >"Place name's execution token xt on the stack."
>
> What's the execution token of a word that has no execution semantics.
>
> Hmm, since you think that ";" is immediate, I guess you want an
> execution token that, when executed, performs the compilation
> semantics. You can get that as follows. Before the rest of the
> program, define:
>
> : ; postpone ; ; immediate
>
> Now you have an immediate ";" with an execution semantics that's the
> same as the compilation semantics, and you can tick it.
>
> >What I am saying is that I didn't have any warning that what I was
> >doing in MACRO: was going to be a problem.
>
> A system that would tell us all non-standard usages would be nice, but
> we don't have that. For now the solution is to test on as many
> systems as possible.
>
> - anton

He described how to write disambiguifiers. At the time however, what I did was just switch over to late-binding. Now I have disambiguifiers in the novice-package (to be released in a few days). So, I rewrote MACRO: to use early-binding (note that LATE-MACRO: is the old late-binding MACRO: that I have been using all these years):
---------------------------------------------------------------------------

true value early? \ should we compile early-binding (otherwise late-binding)

: parse? ( char -- adr cnt more? ) \ the flag is true if more parsing is needed
>in @ >r
parse \ -- adr cnt
>in @ r> - \ -- adr cnt consumed
over = ; \ -- adr cnt ? \ if char found, it won't be in the string

: sure-word ( char -- str ) \ like WORD except won't return an empty string if at the end of a line
locals| char |
begin char word dup c@ 0= while
drop
refill 0= abort" *** SURE-WORD ran out of source-code ***"
repeat ;

: late-macro: ( -- )
:
begin
[char] ; parse? >r
postpone sliteral postpone evaluate
r> while
refill 0= abort" *** MACRO: never found a semicolon ***"
repeat
postpone ; immediate ;

\ LATE-MACRO: just does string expansion.
\ If any words get recompiled, the old macro will use the new word rather than the old word.
\ Note also that LATE-MACRO: searches for the ; as a string.
\ If ; is part of a word name, is in a comment, is used after POSTPONE, etc.,
\ then chaos will result. I don't know of any way to avoid this bug.

\ Another way to create chaos is to define a macro for a redefinition of an old word,
\ and to use that old word in the macro. This is possible in a colon word because colon
\ smudges the new word and semi-colon unsmudges it, so the old word is referenced within.
\ MACRO: doesn't smudge however, so this would result in recursion of the macro.

\ LATE-MACRO: words can be used interpretively.
\ If they contain code that can't be used interpretively, they will crash.
\ For example, RR@ below can't be used interpretively because of the 2R@ in it.

early? [if]

variable 'special-macro:

: special-macro: ( xt -- xt | 0 ) \ returns 0 if xt was special-cased
case
['] \ of postpone \ 0 exit endof
['] ( of postpone ( 0 exit endof
['] [char] of postpone [char] postpone lit, 0 exit endof
exit endcase ; \ -- xt \ EXIT with xt if it was never special-cased

' special-macro: 'special-macro: !

\ Note that SPECIAL-MACRO: doesn't special-case C" and S" yet, so those shouldn't be used until they are added on.
\ C" S" and S| will be written later in the novice-package.

: <macro:> ( -- )
begin
bl sure-word find \ -- str 0 | xt 1 | xt -1 \ the 1 means immediate, -1 means non-immediate
?dup if
-1 = if
postpone literal postpone compile,
else
dup ['] ; = if drop exit then
'special-macro: @ execute ?dup if postpone literal postpone execute then
then
else
count str>num
dup #invalid = if drop true abort" *** MACRO: didn't recognize the string ***" then
dup #single = if drop postpone literal postpone lit, then
dup #double = if drop postpone 2literal postpone dlit, then
dup #float = if drop postpone fliteral postpone flit, then
then
again ;

: macro: ( -- )
: <macro:> postpone ; immediate ;

[else]

: macro: ( -- )
postpone late-macro: ;

[then]

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

There are some complications:

1.) The words defined with MACRO: can't be used interpretively. You'll get an error-message. This can be fixed by wrapping the macro in a colon word and then using the colon word interpretively.

2.) I used STR>NUM to convert strings to numbers in MACRO: --- this works, but it is not compatible with the ANS-Forth outer-interpreter. For example, a float such as 2e is illegal for STR>NUM and has to be converted to 2. or 2.e1 which are both legal. A double such as 2. would be interpreted as a float by STR>NUM and has to be converted to ,2 which is legal.

3.) If the MACRO: word accesses local variables in a colon word that isn't defined yet, then LATE-MACRO: has to be used --- I had to do this for all the macros used by SORT --- words like SORT were originally written using global variables and sub-functions, then later converted to use local variables and macros in order to be reentrant.

4.) The words defined with MACRO: can't be ticked and the xt used at run-time, because they are immediate --- this was true of the late-binding MACRO: words too --- this isn't generally a problem because MACRO: is only used for low-level words that wouldn't normally be ticked.

5.) The MACRO: words can contain both non-immediate and immediate words. Any immediate word that extracts data from the input stream (with WORD or PARSE) has to be special-cased. If it isn't, then you get an error-message. Special-casing these words is easy though, so users can do this themselves if necessary, even if they don't understand how MACRO: works.

In the code above, I special-cased ( \ and [CHAR] --- but I didn't special-case C" and S" that are also problematic. Later in the novice-package I write my own C" and S" to fix some bugs in ANS-Forth (only one S" is allowed interpretively, and C" isn't allowed interpretively at all). So, after writing these, it was necessary to special-case them. This is easy:
---------------------------------------------------------------------------

: special-macro: ( xt -- xt | 0 ) \ returns 0 if xt was special-cased
[ 'special-macro: @ ] literal execute dup 0= if exit then
case
['] s| of postpone s| postpone dlit, 0 exit endof
['] s" of postpone s" postpone dlit, 0 exit endof
['] c" of postpone c" postpone lit, 0 exit endof
exit endcase ; \ -- xt \ EXIT with xt if it was never special-cased

' special-macro: 'special-macro: !

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

So, the whole novice-package is now early-binding. Woo hoo! As a practical matter, the late-binding was never a problem for me. I'm not going to write a word like:

: w ." hello world" cr ;

I am well aware that W is a defined word, as I have been using W going way back to my MFX days. Also, I'm not going to write code like:

0 allocation

That is nonsense, because ALLOCATION is supposed to return the size of memory-blocks provided by ALLOCATE etc. --- there is no memory block at address zero --- Alex doesn't know what any of this code does, and I doubt that he is capable of learning.

The biggest problem with my new-and-improved MACRO: is that it uses STR>NUM which isn't compatible with the ANS-Forth outer-interpreter string-to-number conversion code (which weirdly isn't exposed to the ANS-Forth user). Some literal numbers may need to be modified to work with STR>NUM rules --- this is only an issue for doubles and floats.

I don't have the patience to write another STR>NUM function that is compatible with the bizarre numeric conventions of ANS-Forth --- using the '.' to indicate a double-precision integer is just bizarre --- an 'e' without a number after it is also bizarre.

There are very few people on comp.lang.forth who are capable of writing a STR>NUM function. I will leave this as a New Year's challenge though --- if anybody does this, and it works with the bizarre numeric conventions of the ANS-Forth outer-interpreter, I will use it in MACRO: rather than my current STR>NUM that uses my own numeric conventions.

[Alexander Wegel]

<hughag...@gmail.com> wrote:

> Alex doesn't know what any of this code does,

If you think

[Alexander Wegel]

<hughag...@gmail.com> wrote:

> So, the whole novice-package is now early-binding. Woo hoo! As a
> practical matter, the late-binding was never a problem for me.

Maybe - but in order to write anything worthwhile for others (you're not
the only novice out there), only thinking of yourself won't cut it - i
guess that's where you totally fail.

Your so called "late binding" kludge spoiled the whole forth experience
(normally in forth words don't fall apart for no good reason after
they're defined).

This was problematic, and it was sloppy and lazy (or rather: unsavvy)
programming of your part, and you knew it (it only took someone to poke
your nose into it to finally make you fix it).

> I'm not going to write a word like:
>
> : w ." hello world" cr ;
>
> I am well aware that W is a defined word, as I have been using W
> going way back to my MFX days.

Well - this is just an example. It's not only W, there's also F and
potentially *every* word being used in *any* of your macros.

Add to this that only half of the words in the package are defined using
macro (because you only added "macro:" in order to abuse it as an
inlining facility), in the end half of the words are changing behavior,
while the rest doesn't. LOL.

You don't even have to call a definition W: Having a local variable of
that name also breaks the package. Eg:

: chksz {: m w h -- :} w h * m allocation > ;

would bomb too (it won't print hello world though, so it's not as funny
as the first example).

Also, any definition of a W or F or ... that happens to be in the search
order (above the package words) at the time a macro is being used(!)
will have the same effect.

> Also, I'm not going to write code like:
>
> 0 allocation
>
> That is nonsense, because ALLOCATION is supposed to return the size of
> memory-blocks provided by ALLOCATE etc. --- there is no memory block
> at address zero ---

Man - you're so smart.
Now try it with an allocated block and tell me the difference.
(Spoiler: None!)

BTW: If you really think that allocation is the only affected word,
then i doubt that you are smart enough for plumbing (let alone
programming).

> Alex doesn't know what any of this code does, and I doubt that he is
> capable of learning.

In the end, the problem isn't just the crappiness of the software, but
mostly that of its author.

A tip: Whenever you think bad about someone, because he doesn't
"brown-nose" you or because what he writes doesn't seem to make sense to
you immediately, the first thing you need to check is your head!

Now go fix your crappage, i'm (not) waiting for more than half a decade
now (remember "alien alphabet"? your packages inflexibility kept you
from solving it - LOL).

[Alexander Wegel]

Plesae ignore this unfinished post.

[HAA]

Alexander Wegel wrote:
> <hughag...@gmail.com> wrote:
>
> > So, the whole novice-package is now early-binding. Woo hoo! As a
> > practical matter, the late-binding was never a problem for me.
>
> Maybe - but in order to write anything worthwhile for others (you're not
> the only novice out there), only thinking of yourself won't cut it - i
> guess that's where you totally fail.

> ...

I don't agree. All that's been demonstrated is that it's difficult to write a
non-trivial ANS portable program that will tick all the boxes. As for your
experience, the system informed you (or should have) that a redefinition
had taken place. If you ignored it whose fault was that?
Forthers typically write their own code and knowing what's in it avoid
potential problems. Use another's code blindly and the responsibility
is all yours.

[Paul Rubin]

"HAA" <som...@microsoft.com> writes:
> the system informed you (or should have) that a redefinition
> had taken place. If you ignored it whose fault was that?

It's easy to miss those messages in an interactive session where the
interpreter intersperses them with the whole body of the source code as
it compiles.

[Alexander Wegel]

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

> Alexander Wegel wrote:
> > <hughag...@gmail.com> wrote:
> >
> > > So, the whole novice-package is now early-binding. Woo hoo! As a
> > > practical matter, the late-binding was never a problem for me.
> >
> > Maybe - but in order to write anything worthwhile for others (you're not
> > the only novice out there), only thinking of yourself won't cut it - i
> > guess that's where you totally fail.
> > ...
>
> I don't agree. All that's been demonstrated is that it's difficult to write a
> non-trivial ANS portable program that will tick all the boxes.

I think that in this respect it has been demonstrated that writing a
non-trivial program is a non-trivial task, especially if you don't
really (want to?) know your platform.
And it has been demonstrated that bugs don't fix themselves, even if
someone told you how to do it easily 5 years ago.

I think that now with the finally-fixed-binding, the whole thing will
become a magnitude less ugly - which doesn't say a lot, just look at a
monster like this:

see exchange

: exchange
s\" ( adrX adrY size -- ) \\ the size of the record must be a
multiple of W
" evaluate s\" begin dup while \\ -- adrX adrY
remain
ing" evaluate s\" over @ fourth @ \\ -- adrX
adrY rem
aining Y X" evaluate s\" fourth ! fourth ! \\ --
adrX a
drY remaining" evaluate s\" rot w + rot w + rot w - "
evaluate
s\" repeat" evaluate s\" 3drop " evaluate ; immediate

> As for your
> experience, the system informed you (or should have) that a redefinition
> had taken place. If you ignored it whose fault was that?

~/novice.4th:208: warning: redefined macro:
~/novice.4th:226: warning: redefined rdrop
~/novice.4th:229: warning: redefined 2rdrop
~/novice.4th:295: warning: redefined aligned
~/novice.4th:306: warning: redefined align
~/novice.4th:404: warning: redefined +,
~/novice.4th:449: warning: redefined lit,
~/novice.4th:483: warning: redefined allocate
~/novice.4th:513: warning: redefined resize
~/novice.4th:518: warning: redefined free
~/novice.4th:549: warning: redefined bounds
~/novice.4th:554: warning: redefined try
~/novice.4th:577: warning: redefined s>f
~/novice.4th:602: warning: redefined <=
~/novice.4th:606: warning: redefined >=
~/novice.4th:610: warning: redefined u>=
~/novice.4th:619: warning: redefined d>=
~/novice.4th:623: warning: redefined d<=
~/novice.4th:627: warning: redefined d>
~/novice.4th:631: warning: redefined 2tuck
~/novice.4th:649: warning: redefined NIL with nil
~/novice.4th:782: warning: redefined concat
~/novice.4th:793: warning: redefined ,"
~/novice.4th:863: warning: redefined field
~/novice.4th:963: warning: redefined {
~/novice.4th:1033: warning: redefined Defer with defer
~/novice.4th:1041: warning: redefined IS with is
~/novice.4th:1243: warning: redefined d-
~/novice.4th:1431: warning: redefined b.
~/novice.4th:1490: warning: redefined s"
~/novice.4th:1497: warning: redefined C" with c"
~/novice.4th:1518: warning: redefined 2nip
~/novice.4th:1533: warning: redefined fnip
~/novice.4th:1572: warning: redefined f>=
~/novice.4th:1606: warning: redefined 0>=
~/novice.4th:1609: warning: redefined ftuck
~/novice.4th:1612: warning: redefined f0>=
~/novice.4th:1615: warning: redefined f2*
~/novice.4th:1618: warning: redefined f2/
~/novice.4th:1651: warning: redefined fsinh
~/novice.4th:1655: warning: redefined fcosh
~/novice.4th:1658: warning: redefined ftanh
~/novice.4th:1661: warning: redefined pi
~/skrewice.fs:5: warning: redefined w

Hmmm.. pardon, what was the question?

Anyway the same can happen without issuing a warning, for example when
it's the name of a local variable that clashes, or when there was a
change in the search order.

No, it's this crappy workaround that needed to go, the clearest sign of
which being that apparently Hugh fixed it now right away, after
announcing he wouldn't.

> Forthers typically write their own code and knowing what's in it avoid
> potential problems. Use another's code blindly and the responsibility
> is all yours.

Sure, but this is supposed to be used by "novices" that can hardly write
their own code, let alone evaluate someone elses voluminous code for
potential pitfalls, right?

[hughag...@gmail.com]

On Tuesday, December 27, 2016 at 9:39:35 PM UTC-7, Alexander Wegel wrote:
> I think that now with the finally-fixed-binding, the whole thing will
> become a magnitude less ugly - which doesn't say a lot, just look at a
> monster like this:
>
> see exchange
>
> : exchange
> s\" ( adrX adrY size -- ) \\ the size of the record must be a
> multiple of W
> " evaluate s\" begin dup while \\ -- adrX adrY
> remain
> ing" evaluate s\" over @ fourth @ \\ -- adrX
> adrY rem
> aining Y X" evaluate s\" fourth ! fourth ! \\ --
> adrX a
> drY remaining" evaluate s\" rot w + rot w + rot w - "
> evaluate
> s\" repeat" evaluate s\" 3drop " evaluate ; immediate

You're purposely obfuscating my code by inserting line-breaks at random places --- it won't even compile when the words are broken like that --- you are a very dishonest person!

This is my EXCHANGE function as I wrote it:

SwiftForth? [if]

icode exchange ( adrX adrY size -- ) \ the size of the record must be a multiple of W
0 [ebp] eax mov w [ebp] ecx mov \ EAX<>ECX, with EBX being the size
begin non-zero? while
0 [eax] push
0 [ecx] edx mov edx 0 [eax] mov
0 [ecx] pop
w # eax add w # ecx add
w # ebx sub repeat
w 2 * [ebp] ebx mov
w 3 * # ebp add ret end-code

[else]

macro: exchange ( adrX adrY size -- ) \ the size of the record must be a multiple of W

begin dup while \ -- adrX adrY remaining

over @ fourth @ \ -- adrX adrY remaining Y X

fourth ! fourth ! \ -- adrX adrY remaining

rot w + rot w + rot w -

repeat
3drop ;

[then]

I wrote multiple versions of EXCHANGE and compared the generated code to determine which would be the fastest --- VFX seems to prefer stack-juggling to using the return-stack, and even more so to using local variables --- that is why this version made the cut.

\ If FIELD is used to define records, the size of the records will be a multiple of W, as required by EXCHANGE.

The redefinitions in NOVICE.4TH are irrelevant because the user isn't making modifications to NOVICE.4TH --- the user is writing his own source-file --- there shouldn't be any redefinition warnings when he compiles his own source-file, and if there is then he should fix that potential bug that he has introduced.

In UR/Forth, when I wrote MFX, I had code (written in assembly-language using carnal knowledge of UR/Forth) in which each file was treated as a module. The word LOCAL could be put after a definition and it would mark that definition as smudge-ready. The word END-MODULE was put at the end of the file and it would traverse the entire dictionary to find smudge-ready words --- for each, it would turn off the smudge-ready flag and turn on the smudge flag --- so all the words local to that module disappeared from the search. This system helps a lot with preventing name-space pollution --- only the API words in the module are exposed --- it is possible to use generic names such as SIZE and LIMIT in multiple modules and not get redefinition warnings because they are local to each module. This also is self-documenting because a person reading the source-code for the module can focus on learning the words that are not local (and hence must be the API) and not waste time on learning words that aren't really useful to him but were just factored out to help the original programmer (me) test the module.

> Anyway the same can happen without issuing a warning, for example when
> it's the name of a local variable that clashes, or when there was a
> change in the search order.
>
> No, it's this crappy workaround that needed to go, the clearest sign of
> which being that apparently Hugh fixed it now right away, after
> announcing he wouldn't.

It turned out to be easier than I expected --- I can't always predict the difficulty level of code until I delve into it --- I had expected this to be a bear, but it was pretty straight-forward and I had it done in one day.

[hughag...@gmail.com]

On Tuesday, December 27, 2016 at 9:39:35 PM UTC-7, Alexander Wegel wrote:

> HAA <som...@microsoft.com> wrote:
>
> > Alexander Wegel wrote:
> > > <hughag...@gmail.com> wrote:
> > >
> > > > So, the whole novice-package is now early-binding. Woo hoo! As a
> > > > practical matter, the late-binding was never a problem for me.
> > >
> > > Maybe - but in order to write anything worthwhile for others (you're not
> > > the only novice out there), only thinking of yourself won't cut it - i
> > > guess that's where you totally fail.
> > > ...
> >
> > I don't agree. All that's been demonstrated is that it's difficult to write a
> > non-trivial ANS portable program that will tick all the boxes.
>
> I think that in this respect it has been demonstrated that writing a
> non-trivial program is a non-trivial task, especially if you don't
> really (want to?) know your platform.
> And it has been demonstrated that bugs don't fix themselves, even if
> someone told you how to do it easily 5 years ago.

So, during that 5 years a lot of ANS-Forth programmers wrote a MACRO: function that did early-binding? No, none of them did. The late-binding version is much simpler, so perhaps they wrote that instead? No, none of them did. Maybe they are not so skilled at writing non-trivial Forth code --- maybe they are primarily skilled at flinging insults at those who do write non-trivial code --- you're the expert on ANS-Forth, so please tell us your thoughts on this mystery... LOL

[hughag...@gmail.com]

On Tuesday, December 27, 2016 at 6:27:58 AM UTC-7, Alexander Wegel wrote:
> In the end, the problem isn't just the crappiness of the software, but
> mostly that of its author.
>
> A tip: Whenever you think bad about someone, because he doesn't
> "brown-nose" you or because what he writes doesn't seem to make sense to
> you immediately, the first thing you need to check is your head!

I don't think bad about people because they don't brown-nose me. I would never allow anybody to brown-nose me, and I would also never allow a homosexual to touch me --- for the same reason --- because it is profoundly disgusting and would make me feel dirty.

I think bad about people who brown-nose, because they are disgusting ---Elizabeth Rather demands that all ANS-Forth programmers brown-nose her --- that is meta-disgusting!

> Now go fix your crappage, i'm (not) waiting for more than half a decade
> now (remember "alien alphabet"? your packages inflexibility kept you
> from solving it - LOL).

This is a reference to this thread:
https://groups.google.com/forum/#!searchin/comp.lang.forth/Codejam%7Csort:relevance/comp.lang.forth/3Y4w_MdYl0k/kV-Cy3lwxMMJ

I used my SEQ lists in my first solution. This worked for some of the versions of the problem, but didn't work for others because the SEQ strings are limited to 255 chars (I posted the code without testing it on all versions of the problem, so I didn't realize that some of the latter versions had strings over 255 chars). I then implemented SSEQ lists in LIST.4TH that allowed unlimited sized strings, and rewrote my program to use SSEQ rather than SEQ --- that worked for all versions of the problem. You said that my package's inflexibility kept me from solving the problem --- that is not true --- you are a very dishonest person!

The two kinds of data that ANS-Forth is weak at, are numbers and strings. I've already discussed some of ANS-Forth's problems with numbers in this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/uGAKvs8baQk%5B126-150%5D
Strings are also poorly supported. For one thing, we have two representations of strings:
1.) a pointer to a counted string as provided by C"
2.) an address and count pair as provided by S"

This is redundant.
It is easy to convert #1 into #2 with COUNT but complicated and inefficient to convert #2 into #1.
Which are we supposed to use? Some words such as WORD return #1 and some words such as PARSE return #2. Which are we supposed to use? Some words such as FIND take #1 and some words such as EVALUATE take #2. So confusing! So complicated! I don't blame ANS-Forth students for not being able to learn this stuff (I still have to look everything up in the ANS-Forth document to remember which is which).

In the novice package, I mostly went with #1 (because most strings in most programs are <= 255 chars in length), but I sometimes went with #2. My SEQ used #1 which is what Alex Wegel is criticizing. As a practical matter, #2 is a big pain in the butt because having two items on the data-stack introduces a lot of stack-juggling. If you are working with two strings, you have 4 items on the data-stack, but it is well-known that 3 is the most you want lest that your stack-juggling makes your code unreadable.

My STRING-STACK.4TH largely fixes the problem. The strings are #2 internally, so they can be any size (not limited to 255 chars). None of the strings are on the data-stack though, so there is no stack-juggling --- the strings are on the string-stack! --- how obvious is this solution? This solution is very obvious! Of course, implementing STRING-STACK.4TH took me something like 2 or 3 weeks --- just because a solution is obvious doesn't mean that it is trivial to implement --- this is some of my best Forth programming!

Anyway, I don't think it is fair to criticize me because my SEQ used #1 and this was limited to 255 char strings --- I didn't invent ANS-Forth with its complicated and feature-bereft string support --- why not criticize the person who is guilty of pinching this loaf?

This was Alex Wegel's solution to the "alien alphabet" CodeJAM problem:

On Tuesday, May 1, 2012 at 5:29:10 PM UTC-7, Alex Wegel wrote:
> <..x.nl> wrote:
>
> > awe..cor.de (Alex Wegel) writes Re: Google CodeJam?
> >
> > > As i said, it's another ugly solution - my "philosophy" was to leave
> > > everything out that wasn't really needed for the question. (This way,
> > > there's also less space for bugs to hide.)
> >
> > > I didn't put comments into the code (quel surprise!), but the basic
> > > concept is: The alien digits are already ordered (1,0,2,3,4,5,...), so
> > > it's easy to build a table for translating them. After the table has
> > > been built, the alien number-base is known, and i can feed the
> > > transliterated alien numeral to forth to get the numerical value.
> >
> > So why not add the above small explanation and some stack comments
> > to your code? I almost suspect that you deliberately deleted them :-)
>
> Actually i think i had 2 of them at some point in time, but that was
> about it, and then they went stale. They not so interesting anyway :-)
> See:
>
> #! /usr/local/bin/gforth-fast
> 0 value hi \ highest digit-value found so far
> create d 36 allot \ digit string containing all alien digits
> : wipe ( ) d 36 erase 0 to hi ; \ housekeeping
> : +dig ( c) d hi + c! 1 hi + to hi ; \ add newly learned digit to d
> : >dig? ( c -- +n true|c false) \ lookup alien digit
> hi begin dup while
> 1 - 2dup d + c@ = if nip true exit then
> repeat drop false ;
> : twiddle ( ca) dup >r c@ r@ char+ c@ r@ c! r> char+ c! ; \ exch 2 bytes
> : pars ( ca u) \ read alien numeral to determine digits & number base
> bounds do
> i c@ >dig? if drop else +dig then
> loop d twiddle hi 2 max to hi ;
> : dig> (+n--c) dup 9 > if 7 + then [char] 0 + ; \ convert 1 dig to text
> : eval ( ca u) \ evaluate alien number string
> 2dup pars 2dup bounds do i c@ >dig? drop dig> i c! loop
> hi base ! s>unumber? drop decimal ;
> : getl pad dup 64 stdin read-line throw drop ;
> : .. ." Case #" 1 .r ." : " 1 ud.r cr ;
> : app getl evaluate 0 do getl eval i 1+ .. wipe loop ;
> ' noop is bootmessage
> app bye
>
> Main thing to remember when reading the source is that in bottom up
> programming, the top is down.

Note that I didn't modify this code to make it obfuscated (the way that he modified my EXCHANGE function to make it obfuscated). I showed this code exactly as he wrote it.

I said this:

On Tuesday, May 1, 2012 at 8:45:08 PM UTC-7, Hugh Aguilar wrote:
> Your "plain Forth" would more accurately be called "obfuscated Forth"
> --- I've never written that in my life --- and I never will.
>
> I don't think that I could write a Forth program without stack-picture
> comments, as I would confuse myself. I think that you used stack-
> picture comments just like everybody else when you wrote your program,
> but then removed them afterward to obfuscate your code.
>
> We've been quoting poetry in this thread --- here is what another
> German said on the subject:
> "Nor are poets clean enough for me --- they muddy the water to make it
> appear deep."

[Andrew Haley]

HAA <som...@microsoft.com> wrote:
> Alexander Wegel wrote:
>> <hughag...@gmail.com> wrote:
>>
>> > So, the whole novice-package is now early-binding. Woo hoo! As a
>> > practical matter, the late-binding was never a problem for me.
>>
>> Maybe - but in order to write anything worthwhile for others (you're not
>> the only novice out there), only thinking of yourself won't cut it - i
>> guess that's where you totally fail.
>> ...
>
> I don't agree. All that's been demonstrated is that it's difficult
> to write a non-trivial ANS portable program that will tick all the
> boxes.

Umm, what? How does it demonstrate that? IMO all it demonstrates is
that if you program in an tricky way in Forth (and in any other
sufficiently powerful language) you can tie your own shoelaces
together.

Andrew.

[crc]

On Wednesday, December 28, 2016 at 1:37:05 AM UTC-5, hughag...@gmail.com wrote:
> On Tuesday, December 27, 2016 at 9:39:35 PM UTC-7, Alexander Wegel wrote:
> > I think that now with the finally-fixed-binding, the whole thing will
> > become a magnitude less ugly - which doesn't say a lot, just look at a
> > monster like this:
> >
> > see exchange
> >
> > : exchange
> > s\" ( adrX adrY size -- ) \\ the size of the record must be a
> > multiple of W
> > " evaluate s\" begin dup while \\ -- adrX adrY
> > remain
> > ing" evaluate s\" over @ fourth @ \\ -- adrX
> > adrY rem
> > aining Y X" evaluate s\" fourth ! fourth ! \\ --
> > adrX a
> > drY remaining" evaluate s\" rot w + rot w + rot w - "
> > evaluate
> > s\" repeat" evaluate s\" 3drop " evaluate ; immediate
>
> You're purposely obfuscating my code by inserting line-breaks at random places --- it won't even compile when the words are broken like that --- you are a very dishonest person!

I see almost identical output when using 'see' under gforth.

[Anton Ertl]

"HAA" <som...@microsoft.com> writes:
>I don't agree. All that's been demonstrated is that it's difficult to write a
>non-trivial ANS portable program that will tick all the boxes.

How has that been demonstrated?

>As for your
>experience, the system informed you (or should have) that a redefinition
>had taken place. If you ignored it whose fault was that?

A feature of Forth is that redefinitions don't change what earlier
words do. If you define W and see such a warning, it just tells you
that you cannot call the earlier W by name anymore, nothing else; at
least the way Forth works normally. So the fault is with the person
who wrote a late-binding word using W, not with the person who
redefined W.

>Forthers typically write their own code and knowing what's in it avoid
>potential problems. Use another's code blindly and the responsibility
>is all yours.

The consequence of this attitude is to not use other people's code,
and there are a number of people here that actually preach that. At
least it's consistent with the attitude above.

The other attitude is that libraries give certain guarantees, and that
any deviation from that behaviour is a bug in the library, and is
therefore the library author's responsibility. This means that,
instead of understanding and checking the whole code of the library,
you just need to understand the guarantees of the library words you
use. That attitude is necessary to make libraries practical.

And then there are some that want to pick an attitude that's
convenient for them: When they write a library, they don't document
it, except by providing some example usage, and they claim that that
is enough for using the library. And that avoiding corner cases is
the responsibility of the library user, who should read the source
code of the library for determining them. Essentially, this is your
attitude, except that they believe in using libraries. I am thinking
of one specific person here, whose first name is not Hugh, but the
relatively frequent counter "[That behaviour] was never a problem for
me" when pointing out undocumented corner cases indicates that he is
not alone with that attitude.

- 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/

[HAA]

It's also easy to insert PAGE at the point your code begins or
turn WARNING off around the sections that don't matter.

[hughag...@gmail.com]

Well, then, maybe Gforth's SEE has a bug in it? Do ya think???

ANS-Forth is a cult! Your software isn't any good! You blame people like me for this --- here we have Alex Wegel calling my code "ugly" and a "monster" --- all of the loyal cult members nod sagely...

My novice-package is in the public-domain. He must have downloaded it and compiled it, so he has the source-code --- why not post the source-code? --- why post this garbled mess that Gforth's SEE generates?

This, once again, is my source-code:

macro: exchange ( adrX adrY size -- ) \ the size of the record must be a multiple of W

begin dup while \ -- adrX adrY remaining

over @ fourth @ \ -- adrX adrY remaining Y X

fourth ! fourth ! \ -- adrX adrY remaining

rot w + rot w + rot w -

repeat
3drop ;

EXCHANGE is one of my better-written functions. Alex Wegel has obviously spent only one minute looking at my novice-package, or he would have found some functions that really are ugly monsters (like <6ARRAY> for example, which has now been obsoleted by <ARY> that is much less ugly and monstrous).

The entire minute that Alex Wegel did invest, was spent entirely focused on finding something that he could complain about. This thread reminds me of another one:
https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53%7Csort:relevance/comp.lang.forth/qqlp1gZnVic/kjeAwWCaR1MJ

ANS-Forth is a cult! Elizabeth Rather is a pathological liar. She has made a career out of claiming that her association with Charles Moore in the 1970s makes her our "leading expert" forever, and she has never posted any code on comp.lang.forth that she didn't copy directly out of the "Starting Forth" book (all of that code presumably was written by Charles Moore). She attracts jerks --- Alex Wegel, Alex McDonald, John Passaniti, Julien Fondren, Rickman... --- and, lets not forget Bernd Paysan and Andrew Haley, who she appointed to the Forth-200x committee.

I said previously that I wasn't going to bother to write an early-binding version of MACRO:

On Friday, December 23, 2016 at 7:22:33 PM UTC-7, hughag...@gmail.com wrote:
> So, the disambiguifiers are well known --- my only contribution was the catchy "disambiguifier" name --- but everybody hates the word "disambiguifier" because it shines a spotlight on the fact that ANS-Forth is ambiguous.
>
> Getting back to Alex Wegel's criticism of my MACRO: using late-binding --- now that I have the disambiguifiers I could theoretically rewrite MACRO: to use early-binding.
>
> I'm not going to do that this upcoming release of the novice package (most likely this weekend). I may not do it at all. It is pointless for me to program in ANS-Forth when I can't ever become an ANS-Forth programmer --- no matter what I do, one or the other Alex will say that it is "crap."
>
> Programming in ANS-Forth is a waste of time --- I need to just focus on getting Straight Forth implemented --- ANS-Forth needs to be flushed; it is a hopeless mess of ambiguity and idiocy.
>
> Straight Forth doesn't need disambiguifiers because it is not ambiguous.

My MACRO: is somewhat complicated --- I have POSTPONE of words that themselves do a POSTPONE of another word --- I consider that to be at least intermediate-level Forth programming. A much simpler technique is to just compile the word like normal, then hold on to the generated executable code, which can later be pasted into the code being generated. This is how inlining was done in most of the Forth-83 systems. This is how "optimization" is done in SwiftForth with its ICODE words. This works so long as the code is relocatable, and Charles Moore defined BRANCH and 0BRANCH to use relative offsets, so he was obviously aware of this inlining technique way back in the 1970s when he invented Forth.

When I said previously that I didn't need to write an early-binding MACRO: for ANS-Forth because it wasn't needed for Straight Forth, I was assuming that I would use this ancient technique for inlining instead, so I wouldn't need the complicated jumble of POSTPONE that is needed in ANS-Forth. Now, however, I realize that my early-binding MACRO: that I just wrote may actually have to be used in Straight Forth in order to support macros such as this:
----------------------------------------------------------------------------

SwiftForth? [if]

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

[else]

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

[then]

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

macro: ]each
r> repeat drop ;

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

So, writing the early-binding version of MACRO: wasn't a total waste of time. Posting the code on comp.lang.forth was arguably a waste of time though --- none of the ANS-Forth "programmers" are interested --- stirring up the ANS-Forth cult is like poking a hornets nest with a stick; nothing good comes of this...

[hughag...@gmail.com]

On Wednesday, December 28, 2016 at 7:25:04 AM UTC-7, Anton Ertl wrote:
> "HAA" <som...@microsoft.com> writes:
> >I don't agree. All that's been demonstrated is that it's difficult to write a
> >non-trivial ANS portable program that will tick all the boxes.
>
> How has that been demonstrated?

You yourself have said:
> A system that would tell us all non-standard usages would be nice, but
> we don't have that. For now the solution is to test on as many
> systems as possible.

This was in this thread:
https://groups.google.com/forum/#!topic/comp.lang.forth/wP5nw1ClzsM%5B1-25%5D

I already mentioned this in our current thread --- I'm just repeating myself now --- I have also repeatedly shown how ANS-Forth is infested with ambiguity and all of the ANS-Forth compilers are contradictory to each other because they interpret these ambiguous requirements differently.

This is why I say that ANS-Forth is a cult --- you guys tell the same lies over and over again --- no matter how many times somebody points out that what you are saying is not true, you just blithely continue.

BTW: lest that somebody accuse me of quoting you out of context, this was your full quote:

[hughag...@gmail.com]

On Monday, December 26, 2016 at 7:16:29 PM UTC-7, hughag...@gmail.com wrote:
> There are some complications:
> ...

> 2.) I used STR>NUM to convert strings to numbers in MACRO: --- this works, but it is not compatible with the ANS-Forth outer-interpreter. For example, a float such as 2e is illegal for STR>NUM and has to be converted to 2. or 2.e1 which are both legal. A double such as 2. would be interpreted as a float by STR>NUM and has to be converted to ,2 which is legal.

> ...

> The biggest problem with my new-and-improved MACRO: is that it uses STR>NUM which isn't compatible with the ANS-Forth outer-interpreter string-to-number conversion code (which weirdly isn't exposed to the ANS-Forth user). Some literal numbers may need to be modified to work with STR>NUM rules --- this is only an issue for doubles and floats.
>
> I don't have the patience to write another STR>NUM function that is compatible with the bizarre numeric conventions of ANS-Forth --- using the '.' to indicate a double-precision integer is just bizarre --- an 'e' without a number after it is also bizarre.
>
> There are very few people on comp.lang.forth who are capable of writing a STR>NUM function. I will leave this as a New Year's challenge though --- if anybody does this, and it works with the bizarre numeric conventions of the ANS-Forth outer-interpreter, I will use it in MACRO: rather than my current STR>NUM that uses my own numeric conventions.

As an example of this, in the novice-package I had this:

macro: ftanh ( -- ) \ float: n -- tanh(n)
f2* fexpm1 fdup 2e f+ f/ ;

When I compiled I got this:

FTANH is redefined *** MACRO: didn't recognize the string ***
Source: "novice.4th" on line 2596
-> f2* fexpm1 fdup 2e f+ f/ ;
^

So I changed to this:

macro: ftanh ( -- ) \ float: n -- tanh(n)
f2* fexpm1 fdup 2e1 f+ f/ ;

This worked. I could have also done this, which also works:

macro: ftanh ( -- ) \ float: n -- tanh(n)
f2* fexpm1 fdup 2. f+ f/ ;

It is a hassle to make these changes. Also, if I convert FTANH from a MACRO: to a : definition later, it won't work under the ANS-Forth outer-interpreter, and will have to be changed back again.

I think that I will upgrade STR>NUM so that it will accept a float with an 'e' but with no exponent (it will just assume a 1 as the exponent if the exponent is missing). I think this is a goofy numeric convention --- nobody else in the world does this --- it is obviously just a kludge to allow the '.' to continue to be used to indicate a double-precision integer.

I hate wasting time writing ANS-Forth code, but I'm already this far, so I might as well continue. This will allow macros to have float constants and be compatible between STR>NUM (used in the MACRO: definer) and ANS-Forth's code used in the outer-interpreter. It will still be necessary to change any double-precision integer constants though --- STR>NUM allows commas anywhere throughout, but assumes that a comma at the front indicates double-precision

I'm not aware of any ANS-Forth compiler that is actually in compliance with ANS-Forth in regard to double-precision constants. This is what the ANS-Forth document says:
---------------------------------------------------------------------------
3.4.1.3 Text interpreter input number conversion
When converting input numbers, the text interpreter shall recognize both
positive and negative numbers, with a negative number represented by a
single minus sign, the character “-”, preceding the digits. The
value in BASE is the radix for number conversion.
---------------------------------------------------------------------------

Also, we have this:
---------------------------------------------------------------------------
8.3.2 Text interpreter input number conversion
When the text interpreter processes a number that is immediately followed by
a decimal point and is not found as a definition name, the text interpreter
shall convert it to a double-cell number.
For example, entering DECIMAL 1234 leaves the single-cell number 1234 on the stack,
and entering DECIMAL 1234. leaves the double-cell number 1234 0 on the stack.
See: 3.4.1.3 Text interpreter input number conversion.
---------------------------------------------------------------------------

The document clearly states that only a '.' immediately after a number indicates that the number is double-precision. SwiftForth allows either a '.' or a ',' or a ':' anywhere in the number to indicated that it is double-precision. VFX is the same except doesn't allow the ':' at all. I just figured this out from experimentation --- there may be other weird ways to indicate a double-precision constant --- maybe this is documented in the
compilers' own manuals, but I didn't bother to RTFM because I don't really care.

ANS-Forth is the standard where "anything is possible" --- an ANS-Forth compiler can do pretty much anything, in contradiction with other ANS-Forth compilers, and programs won't port --- but so long as the compiler-writer brown-noses Elizabeth Rather, then his compiler gets to be declared to be ANS-Forth compliant.

As a practical matter, I don't actually have any macros that have double-precision integer literal values --- this may be rare for everybody --- macros with float literal values are quite common however.

Anyway, the next novice-package release will be in a few days --- if anybody wants a copy now for testing, I will email it --- I want it tested thoroughly before I release it.

[Elizabeth D. Rather]

The Forths I'm familiar with don't have a lot of output at compile time
except for warnings or error messages, all of which need to be looked
at. The "whole body of the source code" is being processed, but not
displayed.

Cheers,
Elizabeth

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

[HAA]

hughag...@gmail.com wrote:
> > ...

> > I don't have the patience to write another STR>NUM function that is compatible with
> > the bizarre numeric conventions of ANS-Forth --- using the '.' to indicate a
> > double-precision integer is just bizarre --- an 'e' without a number after it is also
> > bizarre.
> >
> > There are very few people on comp.lang.forth who are capable of writing a STR>NUM
> > function. I will leave this as a New Year's challenge though --- if anybody does
> > this, and it works with the bizarre numeric conventions of the ANS-Forth
> > outer-interpreter, I will use it in MACRO: rather than my current STR>NUM that uses
> > my own numeric conventions.

Anyone who has written their own forth can do this but it won't be a one-liner as it
represents a major part of INTERPRET. If you define NUMBER? and assume
>FLOAT then you should be half-way there. Would I want to duplicate what the
forth interpreter already does? Probably not, but then it's not my project.

[hughag...@gmail.com]

There are two ways to write a cross-compiler:
1.) Use the built-in outer-interpreter.
2.) Write your own outer-interpreter.

In ANS-Forth:

#1 doesn't work because LITERAL is not vectored so you can't have literal numbers in your TARG code --- you have to explicitly use LITERAL (and it will be your own LITERAL not the built-in LITERAL that the outer-interpreter uses) --- this is doable (I did this in MFX) but it results in ugly code that isn't really Forth at all.

#2 doesn't work because FIND is broken (but my disambiguifiers fix this) and because there is no STR>NUM function exposed to the programmer (but I've written one now). Also, #2 doesn't work very well because QUIT is not vectored, so every time you get an abort you end up in the built-in outer-interpreter rather than in your own outer-interpreter.

#1 is a lot easier than #1, with much less work required. I think that the ANS-Forth committee refused to make LITERAL vectored for the purpose of sabotaging cross-compiler writers. I notice that VFX has a lot of vectored words, but LITERAL isn't one of them. Stephen Pelc is trying to prevent people from using VFX to write cross-compilers --- he did vector QUIT though, so #2 is possible in VFX, although this is a lot more work than #1 --- I have actually done a lot of the work already though, by writing STR>NUM and making it publicly available.

[hughag...@gmail.com]

On Thursday, December 29, 2016 at 8:05:28 PM UTC-7, hughag...@gmail.com wrote:
> #1 is a lot easier than #1, with much less work required.

Typo --- I meant:
#1 is a lot easier than #2, with much less work required.

[HAA]

Perhaps because I tend to write straight apps and/or can hack my own compiler as
required, I don't run into these issues. Since you made STR>NUM a New Year's
challenge (!) I'll start the ball rolling. Not sure what is the spec for STR>NUM and
took a guess based on a previous post.

\ cut/paste from public domain code. needs testing. use at own risk

forth definitions decimal

0 dup constant #invalid
1+ dup constant #single
1+ dup constant #double
1+ constant #float

( user) variable dpl

\ trailing decimal pt sets DPL=0
: number? ( c-addr u -- d true | false )
over c@ [char] - = over 0> and dup >r
1 and /string over c@ [char] . > and
0 0 2swap ?dup if
>number -1 dpl ! dup if
1- over c@ [char] . - or 0 dpl !
then
while then
r> 2drop 2drop false
else
drop r> if dnegate then true
then ;

: escan ( c-addr u1 -- u2 ) \ 'E' or 'e'
begin dup while over c@ 32 or [char] e -
while 1 /string repeat then nip ;

: STR>NUM ( c-addr u -- number code | false )
\ base @ >r over c@ case
\ [char] % of binary 1 endof
\ [char] $ of hex 1 endof
\ [char] # of decimal 1 endof
\ 0 swap
\ endcase /string
2dup number? if
2nip dpl @ 0< if drop #single else #double then
else
2dup escan base @ 10 = and if
>float dup if drop #float then
else 2drop 0 then
then
\ r> base !
;

\\ testing
: t ( "string" )
bl word count ." >>> " str>num case
#invalid of ." not a number" endof
#single of ." single integer " . endof
#double of ." double integer " d. endof
#float of ." float " fs. endof
1 abort" should never get here!"
endcase ;

[Anton Ertl]

hughag...@gmail.com writes:
>macro: ftanh ( -- ) \ float: n -- tanh(n)
> f2* fexpm1 fdup 2e f+ f/ ;
>
>When I compiled I got this:
>
>FTANH is redefined *** MACRO: didn't recognize the string ***

> Source: "novice.4th" on line 2596=20

> -> f2* fexpm1 fdup 2e f+ f/ ;
> ^
>
>So I changed to this:
>
>macro: ftanh ( -- ) \ float: n -- tanh(n)
> f2* fexpm1 fdup 2e1 f+ f/ ;

2e f. 2. ok
2e1 f. 20. ok

[Gerry Jackson]

On 28/12/2016 00:35, HAA wrote:
> Alexander Wegel wrote:
>> <hughag...@gmail.com> wrote:
>>
>>> So, the whole novice-package is now early-binding. Woo hoo! As a
>>> practical matter, the late-binding was never a problem for me.
>> Maybe - but in order to write anything worthwhile for others (you're not
>> the only novice out there), only thinking of yourself won't cut it - i
>> guess that's where you totally fail.
>> ...
> I don't agree. All that's been demonstrated is that it's difficult to write a
> non-trivial ANS portable program that will tick all the boxes.

Lots of things in programming are difficult if the programmer hasn't
acquired the requisite knowledge and skills, and that includes writing
portable programs. If a programmer is too lazy to read the ANS Forth
standard and avoid using ambiguous conditions that is the programmer's
fault, not the standard's fault. Most moaning seems to be about
ambiguous conditions, these are listed in section 4.1.2 of the standard
with equivalent sections in each optional wordlist - how difficult is it
to read them?

Note that I am not defending all the ambiguous conditions in the
standard, on the contrary I think it would be better to remove some of them.

--
Gerry

[Albert van der Horst]

In article <955f42cb-6a57-45d4...@googlegroups.com>,
<hughag...@gmail.com> wrote:
>
>There are very few people on comp.lang.forth who are capable of writing a S=
>TR>NUM function. I will leave this as a New Year's challenge though --- if =
>anybody does this, and it works with the bizarre numeric conventions of the=
> ANS-Forth outer-interpreter, I will use it in MACRO: rather than my curren=

>t STR>NUM that uses my own numeric conventions.

My answer to that challenge is: "mu". As far as ciforth is concerned.

There is no good reason to stick to the Brodie picture of parting the
input string into words, that are then machined.
Instead I've a PARSE-INT that gets the characters directly from the input
stream. Note that we need such a mechanism anyway, otherwise we could not
handle strings with spaces, even if if the word that does that is followed
by a space.
I don't care about vectoring. In an indirect threaded Forth all words can be
vectored.

Adding floating point parsing in hindsight goes like this
(EPL is the place of the exponent sign).
This is to replace the old (NUMBER) by revectoring.
: (NUMBER) NULL EPL !
'PARSE-INT CATCH DUP
10 = IF \ Error 10 means : not a digit according to BASE.
PP @ 1- C@ XC = AND IF \ one char back, is it an exponent sign?
PP @ 1- EPL ! PARSE-FLOAT
( ELSE leave error code)
THEN
THEN THROW ;

Now PARSE-FLOAT parses backwards from the exponent sign, which is very
convenient. Any excess digits fall over the edge like so
repeat (leaving out detection of the decimal point)
parse one digit backwards
Add the digit to the fp number
Divide by 10

For the exponent it uses PARSE-INT again.

So bottom line: very modular. No STR>NUM in sight.

: SDFLITERAL
EPL @ IF POSTPONE FLITERAL EXIT THEN
DPL @ IF POSTPONE DLITERAL EXIT THEN
LITERAL ;

One remark: the only reason numbers are intertwined is that they all
start the same: with a digit.

In the Dutch Forth Chapter I meet a strong advocate of separate prefixes
like FX for floating point numbers. That has something going for it, but
will be hated by anyone thinking that Forth must mimic notations from
other languages.

Groetjes Albert
--
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

[john]

In article <o45rd9$4r3$1...@dont-email.me>, ge...@jackson9000.fsnet.co.uk
says...

>
> Note that I am not defending all the ambiguous conditions in the
> standard, on the contrary I think it would be better to remove some of them.
>
> --
> Gerry
>

A little exposure to first order predicate logic would teach you just
how difficult it is not to be ambiguous about anything.

I would consider every stack diagram ever produced as ambiguous.
I don't see calls to ban them - much less replace them with something better.
(in those terms; just to remove some ambiguiy from the statement)

--

john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/

=========================

[Gerry Jackson]

On 30/12/2016 03:05, hughag...@gmail.com wrote:
> There are two ways to write a cross-compiler:
> 1.) Use the built-in outer-interpreter.
> 2.) Write your own outer-interpreter.
>
> In ANS-Forth:
>
> #1 doesn't work because LITERAL is not vectored so you can't have
> literal numbers in your TARG code --- you have to explicitly use
> LITERAL (and it will be your own LITERAL not the built-in LITERAL
> that the outer-interpreter uses) --- this is doable (I did this in
> MFX) but it results in ugly code that isn't really Forth at all.

Aren't you contradicting yourself by saying "this is doable" by using
something like [ 1234 ] LITERAL inside a colon definition. If that is
true, and it is, then #1 does work. The fact that it is ugly code is
irrelevant - it is ANS Forth and works.

>
> #2 doesn't work because FIND is broken (but my disambiguifiers fix
> this) and because there is no STR>NUM function exposed to the
> programmer (but I've written one now).

So #2 can work because you have provided a way for it to work, people
can use your solution - problem resolved - the world should thank you, I
would but I went for method #1.

> Also, #2 doesn't work very
> well because QUIT is not vectored, so every time you get an abort
> you end up in the built-in outer-interpreter rather than in your
> own outer-interpreter.
>

Two things
1. When cross compiling, if something fails why would you want to stay
in the custom outer interpreter (I've asked this before and never
received a reply)?

2. In the cross compiler when an error occurs use ABORT or ABORT" or
THROW so that an exception is thrown and do something like this to stay
in my-outer-interpreter:

: some-action-that-may-fail
...
some-error? if abort ... then
...
;

: my-outer-interpreter
...
['] some-action-that-may-fail catch
?dup if ( an exception was thrown )
( so do whatever recovery you can )
then
...
;

--
Gerry

[Anton Ertl]

Gerry Jackson <ge...@jackson9000.fsnet.co.uk> writes:
>On 28/12/2016 00:35, HAA wrote:
>> Alexander Wegel wrote:
>>> <hughag...@gmail.com> wrote:
>>>
>>>> So, the whole novice-package is now early-binding. Woo hoo! As a
>>>> practical matter, the late-binding was never a problem for me.
>>> Maybe - but in order to write anything worthwhile for others (you're not
>>> the only novice out there), only thinking of yourself won't cut it - i
>>> guess that's where you totally fail.
>>> ...
>> I don't agree. All that's been demonstrated is that it's difficult to write a
>> non-trivial ANS portable program that will tick all the boxes.
>
>Lots of things in programming are difficult if the programmer hasn't
>acquired the requisite knowledge and skills, and that includes writing
>portable programs. If a programmer is too lazy to read the ANS Forth
>standard and avoid using ambiguous conditions that is the programmer's
>fault, not the standard's fault.

That's debatable, but is not the issue at hand here. Hugh Aguilar
used EVALUATE-based macros extensively, despite their known and
well-publicized pitfalls
<https://www.complang.tuwien.ac.at/forth/why-evaluate-is-bad>. No
ambiguous condition is involved here; his program, including pitfalls,
is portable between systems, and you can portably fall into these
pitfalls on every standard system with the code posted by Alexander
Wegel.

So what has been demonstrated is that you can shoot your user in the
foot in ANS Forth, or, using another figure of speech, ANS Forth gives
you enough rope to hang your user, but that's what I expect from a
Forth standard: the programmer is responsible. The fact that many in
the Forth community neglect to take that responsibility serious, and
just say "it has never been a problem for me/my paying customers", and
think that's good enough, is, however, cause for worry.

[Gerry Jackson]

On 28/12/2016 11:23, Anton Ertl wrote:
> The other attitude is that libraries give certain guarantees, and that
> any deviation from that behaviour is a bug in the library, and is
> therefore the library author's responsibility. This means that,
> instead of understanding and checking the whole code of the library,
> you just need to understand the guarantees of the library words you
> use. That attitude is necessary to make libraries practical.

To back up any guarantees given by a library, my view is that the
library download should include a comprehensive test file, including
corner cases, with the advantages:
- a user can have confidence that the library has been tested
- it provides examples of usage to support any documentation
- the user can easily test it on the Forth system to be used (the author
cannot always do this)
- if the author updates the library he has a regression test to help
verify bugs haven't been introduced

After all if the author hasn't such a test program available it raises
the question of how thoroughly a system has been tested.

--
Gerry

[Gerry Jackson]

On 30/12/2016 15:57, john wrote:
> In article <o45rd9$4r3$1...@dont-email.me>, ge...@jackson9000.fsnet.co.uk
> says...
>>
>> Note that I am not defending all the ambiguous conditions in the
>> standard, on the contrary I think it would be better to remove some of them.
>>

>

> A little exposure to first order predicate logic would teach you just
> how difficult it is not to be ambiguous about anything.

I was referring to the list(s) of specified ambiguous conditions e.g.
section 4.1.2 in the standard, not removing any ambiguities that may
exist in the text of the standard.

>
> I would consider every stack diagram ever produced as ambiguous.

To take an example, given the description of the stack notation in
section 2.2.2 of the standard and the definition of x in section 3.1
what is ambiguous in the stack diagram for DROP ( x -- ) ?

> I don't see calls to ban them - much less replace them with something better.

Perhaps that's because people find them useful enough as they are.

> (in those terms; just to remove some ambiguiy from the statement)

??

--
Gerry

[Alexander Wegel]

<hughag...@gmail.com> wrote:

> > Now go fix your crappage, i'm (not) waiting for more than half a decade
> > now (remember "alien alphabet"? your packages inflexibility kept you
> > from solving it - LOL).
>
> This is a reference to this thread:
> https://groups.google.com/forum/#!searchin/comp.lang.forth
/Codejam%7Csort:relevance/comp.lang.forth/3Y4w_MdYl0k/kV-Cy3lwxMMJ
>
> I used my SEQ lists in my first solution. This worked for some of the
> versions of the problem, but didn't work for others
> because the SEQ strings are limited to 255 chars (I posted the code
> without testing it on all versions of the problem, so I didn't realize
> that some of the latter versions had strings over 255 chars).

There were only two versions - a small and a big one: you are a
dishonest person.

> I then implemented SSEQ lists in LIST.4TH that allowed unlimited sized
> strings,

So, you had to implement a new datatype because the ones built into your
package couldn't be adapted.

> and rewrote my program to use SSEQ rather than SEQ --- that worked for all
> versions of the problem. You said that my package's inflexibility kept me
> from solving the problem --- that is not true --- you are a very dishonest
> person!

Wow - kudos from the master!

OK, the packages shortcomings didn't completely stop you, but they did
keep you from solving the full problem in time, and i fathom that
without cut & paste programming, it would have taken you even longer.

BTW: The SSEQ type is still not in the package (as it is publicized), so
technically, the package is still not usable for your alien-language
solution, (and we have to trust your word that you *really* implemented
SSEQ, or did i miss sth?).

> Anyway, I don't think it is fair to criticize me because my SEQ used
> #1 and this was limited to 255 char strings --- I didn't invent
> ANS-Forth with its complicated and feature-bereft string support
> --- why not criticize the person who is guilty of pinching this loaf?

I criticize you because it's you who claims he can do this and that,
then doesn't deliver because he missed something (which is always
someone elses fault) or skimped somewhere.

Me either.

You threatened to include it in your package, so i dropped the idea of
producing a hugh-legible version.

> (the way that he modified my EXCHANGE function to make it obfuscated).

Next thing you write is that i peed in your pants. Dishonest moron.

> I showed this code exactly as he wrote it.

I appreciate this.

> I said this:
>
> On Tuesday, May 1, 2012 at 8:45:08 PM UTC-7, Hugh Aguilar wrote:
> > Your "plain Forth" would more accurately be called "obfuscated Forth"
> > --- I've never written that in my life --- and I never will.
> >
> > I don't think that I could write a Forth program without stack-picture
> > comments, as I would confuse myself. I think that you used stack-
> > picture comments just like everybody else when you wrote your program,
> > but then removed them afterward to obfuscate your code.

So - i hope you see the stack picture comments. Can you read it now?

[Alexander Wegel]

<hughag...@gmail.com> wrote:

> On Wednesday, December 28, 2016 at 6:40:01 AM UTC-7, crc wrote:
> > On Wednesday, December 28, 2016 at 1:37:05 AM UTC-5, hughag...@gmail.com wr

> > > On Tuesday, December 27, 2016 at 9:39:35 PM UTC-7, Alexander Wegel wrote:
> > > > I think that now with the finally-fixed-binding, the whole thing will
> > > > become a magnitude less ugly - which doesn't say a lot, just look at a
> > > > monster like this:
> > > >
> > > > see exchange
> > > >
> > > > : exchange
> > > > s\" ( adrX adrY size -- ) \\ the size of the record must be a
> > > > multiple of W
> > > > " evaluate s\" begin dup while \\ -- adrX adrY
> > > > remain
> > > > ing" evaluate s\" over @ fourth @ \\ -- adrX
> > > > adrY rem
> > > > aining Y X" evaluate s\" fourth ! fourth ! \\ --
> > > > adrX a
> > > > drY remaining" evaluate s\" rot w + rot w + rot w - "
> > > > evaluate
> > > > s\" repeat" evaluate s\" 3drop " evaluate ; immediate
> > >
> > > You're purposely obfuscating my code by inserting line-breaks at random
> > > places --- it won't even compile when the words are broken like that ---

Line-breaks is something you obviously don't know anything about: I had to break
the lines of your post for you.

> > > you are a very dishonest person!

Had some trumps for breakfast?

> > I see almost identical output when using 'see' under gforth.
>
> Well, then, maybe Gforth's SEE has a bug in it? Do ya think???

The line-breaks get deleted by your "macro:", because it works line-by-line. If
you really want to call this a bug, then it's yours alone.

> This, once again, is my source-code:
>
> macro: exchange ( adrX adrY size -- ) \ the size of the record must be a mul
> tiple of W
> begin dup while \ -- adrX adrY remaining
> over @ fourth @ \ -- adrX adrY remaining Y X
> fourth ! fourth ! \ -- adrX adrY remaining
> rot w + rot w + rot w -
> repeat
> 3drop ;
>
> EXCHANGE is one of my better-written functions.

The definition itself is a bit clumsy (with all those "fourth"s and the
juggling), but passable.

Though, defining it as a macro didn't make it run faster by any measure, but
bloated both the definition of exchange itself (stored string literals, even
including the comments), and its users (by compiling the whole loop into their
body).
Additionally it broke its interpretation/execution semantics: now it's
impossible to use exchange interpretively or to execute its xt in interpretation
state.

So why the hell did you make this a macro? Speed gain? Size gain? Secret powers
of late-binding? More compile time?

> Alex Wegel has obviously spent only one minute looking at my novice-package,
> or he would have found some functions that really are ugly monsters
> (like <6ARRAY> for example, which has now been obsoleted by <ARY> that
> is much less ugly and monstrous).

I don't really want to find *all* the monsters, bears or platypusses that lurk
in your package, surely not this year.

> ANS-Forth is a cult! Elizabeth Rather is a pathological liar.

Why don't you use capital letters for this - it looks much louder then.
You don't realize that it's you who lies routinely, do you? How about a lying
break?

> She attracts jerks

Like you? Please cut the crap.

> I said previously that I wasn't going to bother to write an early-binding
> version of MACRO:

Happy to have "convinced" you of the opposite.

[Alexander Wegel]

<hughag...@gmail.com> wrote:

> On Tuesday, December 27, 2016 at 9:39:35 PM UTC-7, Alexander Wegel wrote:
> > HAA <som...@microsoft.com> wrote:
> >
> > > Alexander Wegel wrote:
> > > > <hughag...@gmail.com> wrote:
> > > >
> > > > > So, the whole novice-package is now early-binding. Woo hoo! As a
> > > > > practical matter, the late-binding was never a problem for me.
> > > >
> > > > Maybe - but in order to write anything worthwhile for others (you're not
> > > > the only novice out there), only thinking of yourself won't cut it - i
> > > > guess that's where you totally fail.
> > > > ...
> > >
> > > I don't agree. All that's been demonstrated is that it's difficult to
> > > write a
> > > non-trivial ANS portable program that will tick all the boxes.
> >
> > I think that in this respect it has been demonstrated that writing a
> > non-trivial program is a non-trivial task, especially if you don't
> > really (want to?) know your platform.
> > And it has been demonstrated that bugs don't fix themselves, even if
> > someone told you how to do it easily 5 years ago.
>
> So, during that 5 years a lot of ANS-Forth programmers wrote a MACRO: function
> that did early-binding?

Why should they?

It's you who wanted it for the package.
It's you who asked for and got help (from Anton).
It's you who then just didn't go on, but preferred jumping up and down
c.l.f crying "BEAR" and insulting people.

Others just use postpone, or ]], or maybe just don't admit that they
wrote a macro function.

[David N. Williams]

Amen, Gerry!

-- David W.

[hughag...@gmail.com]

On Friday, December 30, 2016 at 12:28:26 AM UTC-7, Anton Ertl wrote:
> hughag...@gmail.com writes:
> >macro: ftanh ( -- ) \ float: n -- tanh(n)
> > f2* fexpm1 fdup 2e f+ f/ ;
> >
> >When I compiled I got this:
> >
> >FTANH is redefined *** MACRO: didn't recognize the string ***
> > Source: "novice.4th" on line 2596=20
> > -> f2* fexpm1 fdup 2e f+ f/ ;
> > ^
> >
> >So I changed to this:
> >
> >macro: ftanh ( -- ) \ float: n -- tanh(n)
> > f2* fexpm1 fdup 2e1 f+ f/ ;
>
> 2e f. 2. ok
> 2e1 f. 20. ok

Right! I realized that later.

Anyway, I upgraded STR>NUM so that it now accepts 2e as an equivalent to 2e0 (note that 3 is the code for a float, whereas 1 and 2 are codes for single and double integers, and 0 is a code for invalid):

s" 2e" str>num . 3 ok F:-1
f. 2. ok
s" 2e0" str>num . 3 ok F:-1
f. 2. ok
s" 2." str>num . 3 ok F:-1
f. 2. ok

The macros that contain floats have been changed back to how they were:

macro: ftanh ( -- ) \ float: n -- tanh(n)
f2* fexpm1 fdup 2e f+ f/ ;

All the macros can now be compiled with either the early-binding or late-binding version of MACRO: --- this is because none of them contain any double-precision integer literals --- doubles will still screw everything up.

As I said before though, none of the ANS-Forth compilers are compatible with each other in regard to how they handle doubles. The ANS-Forth standard says that a double is indicated by a '.' at the right end --- all of them ANS-Forth compilers accept various other indicators --- programs that contain double literals that use any indicator other than the '.' at the right are not going to be portable to other ANS-Forth compilers because this is non-standard vendor-specific code.

[Alex]

On 12/30/2016 17:19, Gerry Jackson wrote:
> On 30/12/2016 15:57, john wrote:

>>
>> I would consider every stack diagram ever produced as ambiguous.
>
> To take an example, given the description of the stack notation in
> section 2.2.2 of the standard and the definition of x in section 3.1
> what is ambiguous in the stack diagram for DROP ( x -- ) ?

Perhaps John means it should be

( depth if " x -- " else "see section A.3.2.3" then )

There comes a point when ambiguity is not the right word (or concept),
and I fear we are, courtesy of Hugh Aguilar's banging on about FIND et
al's "ambiguities" and ANS Forth's liberal use of the term, well into a
rabbit hole, and we need to extricate ourselves.

A.3.2.3 (which calls stack underflow a "hard reality") should be
considered as, in the defining words of the standard, implementation
dependent.

ANS Forth says:

ambiguous condition: A circumstance for which this Standard does not
prescribe a specific behavior for Forth systems and programs. Ambiguous
conditions include such things as the absence of a needed delimiter
while parsing, attempted access to a nonexistent file, or attempted use
of a nonexistent word. An ambiguous condition also exists when a
Standard word is passed values that are improper or out of range.

implementation defined: Denotes system behaviors or features that must
be provided and documented by a system but whose further details are not
prescribed by this Standard.

implementation dependent: Denotes system behaviors or features that
must be provided by a system but whose further details are not
prescribed by this Standard [which is the same as IMPLEMENTATION DEFINED
but does not require to be documented].

There are 140 (!) uses of AMBIGUOUS CONDITION in the ANS 94 text, 63 of
UNDEFINED, and 17 of IMPLEMENTATION DEPENDENT, 22 of IMPLEMENTATION DEFINED.

UNDEFINED is undefined; uses of the word seem to be as a synonym of
IMPLEMENTATION DEFINED or DEPENDENT.

It would help if there were fewer of these definitions, but it would
help more if we used the right term. Ambiguous is being used as a catch
all, and that's just confusing everyone.

--
Alex

[Alex]

On 12/30/2016 20:50, hughag...@gmail.com wrote:

>
> As I said before though, none of the ANS-Forth compilers are
> compatible with each other in regard to how they handle doubles. The
> ANS-Forth standard says that a double is indicated by a '.' at the
> right end --- all of them ANS-Forth compilers accept various other
> indicators --- programs that contain double literals that use any
> indicator other than the '.' at the right are not going to be
> portable to other ANS-Forth compilers because this is non-standard
> vendor-specific code.
>

You are wrong when you say they are incompatible with each other. They
all recognise numbers with a '.' as the last character as a double. They
are all compatible with the standard.

You are right when you note other techniques are not portable because
they're non-standard. That's because, to state the bleedin' obvious, the
other techniques are not in the standard.


--
Alex

[hughag...@gmail.com]

On Friday, December 30, 2016 at 9:01:45 AM UTC-7, Gerry wrote:
> On 30/12/2016 03:05, hughag...@gmail.com wrote:
> > There are two ways to write a cross-compiler:
> > 1.) Use the built-in outer-interpreter.
> > 2.) Write your own outer-interpreter.
> >
> > In ANS-Forth:
> >
> > #1 doesn't work because LITERAL is not vectored so you can't have
> > literal numbers in your TARG code --- you have to explicitly use
> > LITERAL (and it will be your own LITERAL not the built-in LITERAL
> > that the outer-interpreter uses) --- this is doable (I did this in
> > MFX) but it results in ugly code that isn't really Forth at all.
>
> Aren't you contradicting yourself by saying "this is doable" by using
> something like [ 1234 ] LITERAL inside a colon definition. If that is
> true, and it is, then #1 does work. The fact that it is ugly code is
> irrelevant - it is ANS Forth and works.

What??? You can't write a cross-compiler in ANS-Forth that cross-compiles ANS-Forth code. These are both examples of ANS-Forth functions:

: testA 1234 + ;

: testB [ 1234 ] literal + ;

The cross-compiler isn't going to be able to cross-compile testA --- the cross-compiler has failed to cross-compile a simple Forth function.

Using code like testB is "doable" but it requires the user to write his code in an ugly and restrictive manner. If the user has existing ANS-Forth code that he wants to cross-compile, he will have to manually modify it to conform to the pointless restriction of not having any literal numbers.

This is extremely unprofessional! If you tell the user that he can't have literal numbers in his source-code, he will likely say:
"Why not? I can cross-compile C programs that have literal numbers in the source-code. You Forth programmers are clowns --- you struggle with basic concepts such as literal integers --- I will just go back to programming in C again."

When I wrote MFX at Testra, I told them about the restriction of not having literal numbers, and they didn't fire me. They just said that they would put up with the hassle. They were primarily focused on getting their motion-control program ported over to the MiniForth, and they were willing to manually modify the source-code as necessary to conform to the the cross-compiler's restrictions. AFAIK, the motion-control program is the only program that has ever been written in MFX. Also, AFAIK, nobody outside of Testra has ever programmed in MFX. If your cross-compiler is going to be purely in-house, then "doable" is good enough --- this is not commercial quality however.

Straight Forth isn't going to be exactly compatible with any micro-controller Forth that is being cross-compiled. It is going to be reasonably close though. Simple functions such as this should compile under either:

: testA 1234 + ;

These won't compile under the micro-controller cross-compiler though:

: testC 5/9 * ;

: testD 3.1415926535897932385 * ;

Both of these functions will have to be manually modified to use */ instead. Here is one that won't work because it is a single precision integer in Straight Forth (which is 64-bit) but would need to be a double precision integer in any micro-controller Forth (presumably 32-bit):

: testE 5,000,000,000 + ;

> > #2 doesn't work because FIND is broken (but my disambiguifiers fix
> > this) and because there is no STR>NUM function exposed to the
> > programmer (but I've written one now).

Anton Ertl told me how to write disambiguifiers back in 2009. It wasn't until years later when I discovered them on my own and remembered that I had been told about them before, that I also realized that disambiguifiers are the key to solving quite a lot of problems in ANS-Forth. The good news is that ANS-Forth is not as badly screwed up as I had previously believed (having FIND broken is pretty badly screwed up) --- the broken FIND can be fixed with disambiguifiers.

Ironically however, the committee members (Anton Ertl, Bernd Paysan and Stephen Pelc) now refuse to acknowledge the existence of the disambiguifiers --- accepting the disambiguifiers requires them to admit that ANS-Forth is ambiguous --- this is a common human failing: to become over-attached to some technology and then refuse to admit that it has problems, even to the point of refusing to fix the problems when a solution is known.

> So #2 can work because you have provided a way for it to work, people
> can use your solution - problem resolved - the world should thank you, I
> would but I went for method #1.
>
> > Also, #2 doesn't work very
> > well because QUIT is not vectored, so every time you get an abort
> > you end up in the built-in outer-interpreter rather than in your
> > own outer-interpreter.
>
> Two things
> 1. When cross compiling, if something fails why would you want to stay
> in the custom outer interpreter (I've asked this before and never
> received a reply)?

I don't recall you asking this before.

It seems obvious though. Switching back and forth between two outer-interpreters would be very confusing. The user is going to end up back in the built-in outer-interpreter and then the cross-compiler is no longer working and he wonders why, then he realizes that he has to manually get back into the correct outer-interpreter so that things will start working again. Ugh! Unprofessional!

> 2. In the cross compiler when an error occurs use ABORT or ABORT" or
> THROW so that an exception is thrown and do something like this to stay
> in my-outer-interpreter:
>
> : some-action-that-may-fail
> ...
> some-error? if abort ... then
> ...
> ;
>
> : my-outer-interpreter
> ...
> ['] some-action-that-may-fail catch
> ?dup if ( an exception was thrown )
> ( so do whatever recovery you can )
> then
> ...
> ;

Certainly, if you are going to manually use ABORT or ABORT" or THROW then these will be your own that you wrote yourself and which go back to your own outer-interpreter. Isn't it true though, that there are built-in functions that use ABORT or ABORT" or THROW internally? These are going to go back to the built-in outer-interpreter

I think #2 will work. Even though QUIT isn't vectored, this may not matter (it would only matter if built-in words can abort). So, for the most part, #2 is the only solution that will work. The problem though is that writing your own cross-compiler is a lot of work. The amount of work involved here is comparable to the amount of work involved in writing your own Forth system from scratch. The outer-interpreter is the heart of any Forth system, so writing it yourself is pretty much the same as writing your own Forth system entirely.

Solution #1, using the built-in outer-interpreter, is much much easier! This is pretty easy. I did this at Testra. If I had told them that I needed to write my own outer-interpreter, they would have likely balked, because they didn't have the time or the money for such a large project. Using the built-in outer-interpreter is significantly simpler and is the obvious solution. ANS-Forth however, is crippled because LITERAL is not vectored, which prevents the built-in outer-interpreter from being used (except in the ugly hacky way described above) --- ANS-Forth was purposely crippled to make the built-in outer-interpreter unusable for cross-compilers --- Elizabeth Rather sabotaged both Forth-83 and ANS-Forth to prevent common Forth programmers from writing cross-compilers in competition with Forth Inc..

[hughag...@gmail.com]

BTW: How many ANS-Forth programmers know that this is not ANS-Forth?

2e

The ANS-Forth Standard only allows 'E' to be used and not 'e' --- almost all ANS-Forth programs use literal floats with 'e' though --- so, none of them are actually ANS-Forth programs.

[Elizabeth D. Rather]

On 12/30/16 11:10 AM, Alex wrote:
> On 12/30/2016 17:19, Gerry Jackson wrote:
>> On 30/12/2016 15:57, john wrote:
>
>>>
>>> I would consider every stack diagram ever produced as ambiguous.
>>
>> To take an example, given the description of the stack notation in
>> section 2.2.2 of the standard and the definition of x in section 3.1
>> what is ambiguous in the stack diagram for DROP ( x -- ) ?
>
> Perhaps John means it should be
>
> ( depth if " x -- " else "see section A.3.2.3" then )

Since the appendices are explicitly non-normative, I don't think it's
appropriate to reference them. The text definition for DROP says,
"Remove x from the stack." What's ambiguous about this?

The ambiguous condition here is a potential stack underflow, which is
not a property of DROP or its responsibility, but an appropriate concern
of the programmer. It is globally the responsibility of a Forth
programmer to provide appropriate stack items to definitions.

The common synonym for "ambiguous condition" is "error" or "exception".
In the development of ANS Forth arguments broke out as to which of those
words should be used in various instances, as they have both formal and
informal meanings in computing. Haskell.org, for example, warns, "There
has been confusion about the distinction between errors and exceptions
for a long time, repeated threads in Haskell-Cafe and more and more
packages that handle errors and exceptions or something between.
Although both terms are related and sometimes hard to distinguish, it is
important to do it carefully." After that debate had raged in the Forth
TC for some years, the TC finally decided to punt, and replaced all
instances of either with "ambiguous condition." We also added the
requirement that a compliant system should document its response to
certain of them.

> It would help if there were fewer of these definitions, but it would
> help more if we used the right term. Ambiguous is being used as a catch
> all, and that's just confusing everyone.

If you or someone would like to undertake going through the current
document and propose replacing all reference to "ambiguous condition"
with either "error" or "exception" that might or might not be helpful,
and would certainly give the committee something to talk about for many
years. Meanwhile, programmers should just interpret any possibility of
an "ambiguous condition" as something to take steps to avoid.

[john]

In article <o46idt$4en$1...@dont-email.me>, al...@rivadpm.com says...

> Perhaps John means it should be
>
> ( depth if " x -- " else "see section A.3.2.3" then )
>
> There comes a point when ambiguity is not the right word (or concept),
> and I fear we are, courtesy of Hugh Aguilar's banging on about FIND et
> al's "ambiguities" and ANS Forth's liberal use of the term, well into a
> rabbit hole, and we need to extricate ourselves.
>

Precisely.

a stack diagram is a mechanics tool not a specification nor documentation.
It's useful but must be used with care when transporting code.
Assumptions must be made - ambiguity is the norm - on the surface.

A standard can say the letter 'u' stands for a 4 byte unsigned integer but unless
it also says what a byte is you have ambiguity. There are always limits.

Specifications exist to resolve ambiguity - standards have another job.
More wobbly bridges are built across rivers because people don't understand the
difference between a standard and a specification than for many other reasons I
suspect.

A standard isn't there to be totally unambigous - it's there to point
the way towards compatibility - ( "standard n : defn. a rallying point" )
following it means your code "should"
"mostly" work elsewhere but always prepare for issues.

Ambiguous use of the word ambiguous is unhelpful also I agree.

[hughag...@gmail.com]

Here Gerry is parroting the same fake argument that Alex McDonald has used in the past --- that is, to claim that section 4.1.2. lists all of the ambiguous conditions in ANS-Forth --- that is totally untrue; the entire document is infested with ambiguous conditions from top to bottom.

This is the thread where I figured out that disambiguifiers can be used to fix the broken FIND in ANS-Forth. Here we have a quote showing Alex McDonald using the bogus argument that section 4.1.2. lists all of the ambiguous conditions in ANS-Forth:

On Friday, June 19, 2015 at 7:56:27 PM UTC-7, hughag...@gmail.com wrote:
> On Thursday, June 18, 2015 at 11:58:39 PM UTC-7, Raimond Dragomir wrote:
> > > > If you take out all ambiguities what does remain? How much of it? I
> > > > said there are TOO MANY ambiguities.
> > >
> > > Section "4.1.2 Ambiguous conditions" covers them all. Which ones would
> > > you make unambiguous?
> > >
> > TOO MANY. I don't have the time here to fix the standard. I also don't
> > trust you that you really want this answer from me. I also don't believe
> > that anybody that could really have the power to modify the standard
> > will ever listen to me. Stephen Pelc said that clearly.
>
> Raimond, that was a trick question and you didn't notice.
>
> Section 4.1.2 "Ambiguous Conditions" doesn't cover all the ambiguous conditions. For example, in section 3.2.3.2 we have this: "The control-flow stack may, but need not, physically exist in an implementation. If it does exist, it may be, but need not be, implemented using the data stack." That is pretty ambiguous --- the whole standard is corrupted with ambiguity such as this --- ambiguity is not limited to section 4.1.2.
> ...
> This thread has run for over 200 posts now, and Stephen Pelc has yet to say: "Thanks for fixing that bug in VFX; I'll put your disambiguifiers in my next VFX release." Apparently writing portable code isn't an entirely egoless discipline, but there are in fact some quite large egos involved who can't bring themselves to admit a mistake even after it has become abundantly obvious.

[hughag...@gmail.com]

On Friday, December 30, 2016 at 3:44:53 PM UTC-7, Elizabeth D. Rather wrote:
> ...programmers should just interpret any possibility of

> an "ambiguous condition" as something to take steps to avoid.

In 1994 when ANS-Forth came out, approximately 99% of the Forth community noticed that ANS-Forth was infested with ambiguous conditions and so they "took steps to avoid" --- they migrated to C --- that was the only way they knew how to avoid the ambiguous conditions in ANS-Forth.

I think that you were totally focused on being the "leading expert" of Forth --- you didn't care if the Forth community was reduced in size to 1% of its former population --- you only cared about being the queen bee, even if you retained only 20 unthinking drones out of the previous population of 2000 intelligent programmers.

I would estimate that today there are maybe 20 ANS-Forth programmers in the world. ANS-Forth is a failure!

My goal with Straight Forth is much different. I want to save Forth --- make Forth a viable language again. I will accept decisions that are contrary to my own opinion --- I will require that decisions be made though --- it is better to make a bad decision than no decision at all. I won't compromise by making an ambiguous condition in which two contradictory decisions are both accepted as standard, so that everybody can be happy, but ultimately everybody is unhappy because their programs aren't portable which was the whole point of having a standard.

As an example, I think that TRUE should be 1 --- Ilya Tarasov thinks that TRUE should be -1 (at least we do agree that FALSE should be 0) --- he suggested having a switch so that the end-user could decide, but I said that that is a terrible idea because programs won't be portable; it is better to just make a decision one way or the other and stick with it (half the people will be unhappy, but they will get over it; this isn't kindergarten where everybody demands that things are done their way or they will cry).

[Alex]

On 12/30/2016 22:44, Elizabeth D. Rather wrote:
> On 12/30/16 11:10 AM, Alex wrote:
>> On 12/30/2016 17:19, Gerry Jackson wrote:
>>> On 30/12/2016 15:57, john wrote:
>>
>>>>
>>>> I would consider every stack diagram ever produced as ambiguous.
>>>
>>> To take an example, given the description of the stack notation in
>>> section 2.2.2 of the standard and the definition of x in section 3.1
>>> what is ambiguous in the stack diagram for DROP ( x -- ) ?
>>
>> Perhaps John means it should be
>>
>> ( depth if " x -- " else "see section A.3.2.3" then )
>
> Since the appendices are explicitly non-normative, I don't think it's
> appropriate to reference them. The text definition for DROP says,
> "Remove x from the stack." What's ambiguous about this?
>

Nothing, and that's my point below.

> The ambiguous condition here is a potential stack underflow, which is
> not a property of DROP or its responsibility, but an appropriate concern
> of the programmer. It is globally the responsibility of a Forth
> programmer to provide appropriate stack items to definitions.

Yes. I was only using it as an illustration of John's argument.

>
>> There comes a point when ambiguity is not the right word (or concept),
>> and I fear we are, courtesy of Hugh Aguilar's banging on about FIND et
>> al's "ambiguities" and ANS Forth's liberal use of the term, well into a
>> rabbit hole, and we need to extricate ourselves.

See point above.

I disagree with the characterisation of "ambiguous condition" as error
or exception; rather it is an unclassified *state*. It's the ultimate
"here be dragons". The section 3.4.4 talks of *actions* on an ambiguous
condition, but declines to rule out anything; that's a different issue.

===
3.4.4 Possible actions on an ambiguous condition

When an ambiguous condition exists, a system may take one or more of the
following actions:

ignore and continue;
display a message;
execute a particular word;
set interpretation state and begin text interpretation;
take other implementation-defined actions;
take implementation-dependent actions.

The response to a particular ambiguous condition need not be the same
under all circumstances.
===

>
>> It would help if there were fewer of these definitions, but it would
>> help more if we used the right term. Ambiguous is being used as a catch
>> all, and that's just confusing everyone.
>
> If you or someone would like to undertake going through the current
> document and propose replacing all reference to "ambiguous condition"
> with either "error" or "exception" that might or might not be helpful,

As above, it's not what's required. Calling everything "ambiguous" is
not helpful, and Hugh is doing it (again) on another thread in reference
to the lack of specificity in relation to the control stack.

> and would certainly give the committee something to talk about for many
> years. Meanwhile, programmers should just interpret any possibility of
> an "ambiguous condition" as something to take steps to avoid.

It will not prevent Hugh's indignation.

>
> Cheers,
> Elizabeth
>


--
Alex

[Alex]

It's not an "ambiguous condition", since the definition of ambiguous
condition only talks about *dynamic state*. 3.2.3.2 is talking about
implementation specification, and telling you explcitly that there are
many ways of implementing the control stack; the standard doesn't
exclude any. The same warning about implementation also applies to FIND.

ambiguous condition: A circumstance for which this Standard does not
prescribe a specific behavior for Forth systems and programs. Ambiguous
conditions include such things as the absence of a needed delimiter
while parsing, attempted access to a nonexistent file, or attempted use
of a nonexistent word. An ambiguous condition also exists when a
Standard word is passed values that are improper or out of range.

--
Alex

[HAA]

Removing choice is of course what standards do. Standards are an ever
narrowing jail that ultimately chokes on itself. 47 years of Forth standards,
23 years since ANS, 10 years since 200x and no programs or users to
speak of. That's what standards in Forth have achieved.

[Elizabeth D. Rather]

On the contrary, there are a number of standard systems available, and
quite a few programmers using them. They have been the basis of some
major projects, many of which I have referenced here over the years. The
advent of ANS Forth liberated Forth system developers from the
constraints of implementation specifications in Forth83, making possible
the era of optimizing compilers and other advances that have led to
faster, more powerful systems. It has brought freedom, not jail.

Every significant language has standards, and all of them have their
critics, just as Forth Standards do. But they are widely respected and
influential, even in systems that do not choose to follow them rigorously.

[hughag...@gmail.com]

On Friday, December 30, 2016 at 5:48:49 PM UTC-7, HAA wrote:
> Removing choice is of course what standards do. Standards are an ever
> narrowing jail that ultimately chokes on itself. 47 years of Forth standards,
> 23 years since ANS, 10 years since 200x and no programs or users to
> speak of. That's what standards in Forth have achieved.

Charles Moore left Forth Inc. in 1982 --- both the Forth-83 and ANS-Forth standards came from Elizabeth Rather --- that is why they were no good and there are now "no programs or users to speak of.

I disagree though, that: "Standards are an ever narrowing jail that ultimately chokes on itself." Having a standard allows programs to be portable --- a standard has nothing to do with making educational classes easier to teach as Elizabeth Rather claims --- the *only* purpose of a standard is to allow programs to be portable between different vendors' compilers.

I am not saying that Straight Forth is the end-all of Forth. For one thing, it doesn't directly run on micro-controllers (it can be used to cross-compile for micro-controllers though) --- it is only for desktop computers --- for another thing, it doesn't compete directly against Factor and Oforth, which will continue to be used. It is not a "jail" --- programmers are free to use non-compliant systems, but they lose portability when they do that. Straight Forth is mostly for numerical programming and cross-compilation, whereas Factor is mostly for web-servers, and I don't know what Oforth is for (it is possible that Franck doesn't know either; he doesn't really have a "killer app" that I'm aware of).

I want Forth to be taken seriously. For this to happen, you have to have code-libraries that are portable between different vendors' compilers, Nobody is going to accept vendor lock-in; there is no vendor in the Forth world that is big enough to rule the way that MicroSoft does. If Forth is going to succeed, there has to be a standard that allows multiple vendors to thrive, with programmers moving back and forth between them.

In her own stupid way, Elizabeth Rather understands that the lack of code-libraries is what killed ANS-Forth:

On Thursday, December 29, 2016 at 6:04:07 PM UTC-7, Elizabeth D. Rather wrote:
> On 12/28/16 3:12 PM, HAA wrote:
> > Nobody writing a substantive
> > application for SwiftForth expects the code to compile and run on VFX.
>
> Not the whole application, certainly, but consider the never-ending
> whine about libraries: the ability to write a bunch of functions (or
> even adapt a useful function from an adapted form used in an
> application) depends on standards.

Notice that she still believes that the only way to write new programs is cut-and-paste-and-tweak of old programs ("adapt a useful function from an adapted form used in an application") --- she still doesn't understand the concept of a general-purpose data-structure --- she continues to fight against code-libraries tooth and nail because she doesn't understand the concept.

[Alexander Wegel]

<hughag...@gmail.com> wrote:

> In her own stupid way, Elizabeth Rather understands that the lack of
> code-libraries is what killed ANS-Forth:
>
> On Thursday, December 29, 2016 at 6:04:07 PM UTC-7, Elizabeth D. Rather wrote:
> > On 12/28/16 3:12 PM, HAA wrote:
> > > Nobody writing a substantive
> > > application for SwiftForth expects the code to compile and run on VFX.
> >
> > Not the whole application, certainly, but consider the never-ending
> > whine about libraries: the ability to write a bunch of functions (or
> > even adapt a useful function from an adapted form used in an
> > application) depends on standards.
>
> Notice that she still believes that the only way to write new programs is
> cut-and-paste-and-tweak of old programs ("adapt a useful function from
> an adapted form used in an application") --- she still doesn't understand
> the concept of a general-purpose data-structure --- she continues to
> fight against code-libraries tooth and nail because she doesn't
> understand the concept.

Your problem seems to be that you don't even understand what people
write. In this case (i removed the confusing part from the sentence, so
maybe you have a chance to understand it):

about libraries: the ability to write a bunch of functions depends on
standards.

What you make out of this is just a grotesque misinterpretation.

[Andrew Haley]

Gerry Jackson <ge...@jackson9000.fsnet.co.uk> wrote:
>
> I was referring to the list(s) of specified ambiguous conditions e.g.
> section 4.1.2 in the standard, not removing any ambiguities that may
> exist in the text of the standard.

There are some which should be very easy to remove, and some which are
hard. Some wouldn't be very hard to remove, but would impose a
runtime overhead. In some, removing an ambiguous condition would
significantly increase the complexity of a small system.

I don't think it makes sense to talk about ambiguous conditions in the
abstract. Each one has its own meaning and they don't have very much
to do with one another. It makes more sense to say "Let's remove this
ambiguous condition. Here's how."

Andrew.

[Alex]

On 12/31/2016 00:49, HAA wrote:

>
> Removing choice is of course what standards do. Standards are an
> ever narrowing jail that ultimately chokes on itself. 47 years of
> Forth standards, 23 years since ANS, 10 years since 200x and no
> programs or users to speak of. That's what standards in Forth have
> achieved.
>

Since I take that "of course" to mean that your assertion is true and
widely accepted, can you demonstrate a specific case where a software
standard has removed choice?

--
Alex

[Alex]

On 12/30/2016 22:38, hughag...@gmail.com wrote:

>
> BTW: How many ANS-Forth programmers know that this is not ANS-Forth?
>
> 2e
>
> The ANS-Forth Standard only allows 'E' to be used and not 'e' ---
> almost all ANS-Forth programs use literal floats with 'e' though ---
> so, none of them are actually ANS-Forth programs.
>

Correct. But that's standards for you; don't follow them at your peril.
I'd support a change to the text interpreter to recognise { D | d | E |
e } as in >FLOAT. Would you like to propose this change?


--
Alex

[hughag...@gmail.com]

How bizarre is this??? Alex McDonald is asking me if I want to propose a change --- write an RfD for Forth-200x --- this is despite the fact that I left Forth-200x and slammed the door behind me.

In this thread I wrote an early-binding version of MACRO: --- if I do say so myself, this is pretty awesome code --- this is comparable to my rquotations in awesomeness!

I enjoy writing Forth code and it is something that I take pride in. Elizabeth Rather hates me for this. She herself has never posted any code on comp.lang.forth that she didn't copy directly out of the "Starting Forth" book. The Forth-200x mailing list is full of people who, like her, never write Forth code and don't understand the concept of taking pride in code that they write themselves. They just want to be big Forth experts --- by writing RfDs and getting them accepted, they get to claim that they help to write the Standard --- they get to claim that mere Forth programmers such as myself are entirely dependent upon their genius for guidance.

The proposal that Alex McDonald is suggesting is trivial. Any Forth programmer with at least one week of experience could write this RfD. Also, the RfD is guaranteed to be accepted. Leon Wagner decides if an RfD is accepted or not, and these are his criteria:
1.) Implementing the code must take less than 10 minutes of his time.
2.) Documenting it must take only one or two sentences and should be understandable by anybody with one week of Forth experience.
3.) It must not have any affect whatsoever on existing SwiftForth code, or on possible future SwiftForth code that is written according to typical Forth Inc. style.
The proposal that Alex McDonald is suggesting that I put my name on, fits all of these criteria, so it is pretty much guaranteed to be accepted by Leon Wagner.

The only purpose of the Forth-200x mailing list is so Elizabeth Rather can collect names of Forth programmers and list them in the document as supporters. If I put my name on this proposal, then I have essentially sold my soul to Forth Inc.. I won't be able to complain when they list my name as a "contributor" because I did in fact contribute an RfD and got it accepted. The Forth-200x committee will have bought my soul and paid me essentially nothing --- they can spend the rest of forever telling the world that I am one of their little sycophants --- they will totally own me!

So, no, I'm not going to write a Forth-200x RfD for your proposal --- to sell my soul, I would want an infinitely higher price than you are offering --- at least one penny...

[hughag...@gmail.com]

On Saturday, December 31, 2016 at 8:04:53 AM UTC-7, hughag...@gmail.com wrote:
> On Saturday, December 31, 2016 at 3:31:09 AM UTC-7, Alex wrote:
> > On 12/30/2016 22:38, hughag...@gmail.com wrote:
> >
> > >
> > > BTW: How many ANS-Forth programmers know that this is not ANS-Forth?
> > >
> > > 2e
> > >
> > > The ANS-Forth Standard only allows 'E' to be used and not 'e' ---
> > > almost all ANS-Forth programs use literal floats with 'e' though ---
> > > so, none of them are actually ANS-Forth programs.
> > >
> >
> > Correct. But that's standards for you; don't follow them at your peril.
> > I'd support a change to the text interpreter to recognise { D | d | E |
> > e } as in >FLOAT. Would you like to propose this change?
> >
> >
> > --
> > Alex
>

> So, no, I'm not going to write a Forth-200x RfD for your proposal --- to sell my soul, I would want an infinitely higher price than you are offering --- at least one penny...

I forgot to mention --- this proposal is stupid anyway --- no language other than ANS-Forth uses 'd' or 'D' as an indicator for exponents. LOL

[Julian Fondren]

On Saturday, December 31, 2016 at 4:31:09 AM UTC-6, Alex wrote:
> On 12/30/2016 22:38, hughag...@gmail.com wrote:
>
> >
> > BTW: How many ANS-Forth programmers know that this is not ANS-Forth?
> >
> > 2e
> >
> > The ANS-Forth Standard only allows 'E' to be used and not 'e' ---
> > almost all ANS-Forth programs use literal floats with 'e' though ---
> > so, none of them are actually ANS-Forth programs.
> >
>
> Correct. But that's standards for you; don't follow them at your peril.

Rather, they're ANS Forth programs with an environmental dependency
on lowercase 'e' being acceptable in that notation. This dependency
is broadly satisfied in practice and would be easy to deal with when
it isn't. Outside of Java, portability is not a binary condition but
a statement about how much and what kind of effort it would take to
port some software. I have plenty of substantial Perl written that
depends on cPanel and CentOS which would need significant porting
effort were it to need to run under Plesk, for example. The existence
of ANS Forth *allows* descriptions of portability more professional
and precise than "it works, right now, on these systems". If such
descriptions seem scarce, so do professional Forth programmers.

The only thing Hugh has added to clf in his entire time here is an
awareness that CREATE ... DOES> with constant data is less optimal
than could be. Possibly some people have also benefited by having
been encouraged to get real Usenet clients or subscriptions--so as to
avoid him. All of his other contributions have been negative. We are
actually stupider because of him--people have stopped coming by, that
brightened things up; people who know better don't bother voicing
response #1929 to the same iterated complaint from Hugh that was
stupid and baseless the first time it provoked a response.

And of course, instead of Forth discussion, you get the occasional
admissions like mine that moderators can be nice to have, that the
problems they exhibit shouldn't be solved by doing away with them.
At one point I would've defended to the death Hugh's right to
fantasize grossly about people going to hell, as the saying goes, and
now I would just shrug and say he had it coming were jack-booted
thugs to black-bag him and remove him from society.

[hughag...@gmail.com]

On Saturday, December 31, 2016 at 8:46:15 AM UTC-7, Julian Fondren wrote:
> ...I would just shrug and say he had it coming were jack-booted

> thugs to black-bag him and remove him from society.

This isn't the first death threat that I've received. This was sent in private email:
-----------------------------------------------------------------------------
On Wed, Jun 8, 2016 at 2:29 PM, Alex McDonald <al...@rivadpm.com> wrote:
On 01/06/16 16:20, hughag...@gmail.com wrote:
> The RfD was going to be a slam-dunk from a ladder for Alex McDonald > --- but then Alex McDonald disappeared --- now the RfD is left in
> limbo while Anton and Bernd search for a new pocket-boy who will put
> his name on the RfD.

Then the Forth-200x committee had Alex McDonald pretending to represent
>the "Forth community," but Alex "I do standards for a living" McDonald
> disappeared. This is a chronic problem for the Forth-200x committee
> --- their pocket boys disappear --- then they have to find new
> pocket boys to put their names on the RfDs.

Unfortunately, you're still here, and I suspect you won't do me the tremendous favour of fucking off or dieing any time soon. Ah well.

I still occasionally read clf. Personal reasons and your continued existence have stopped me being an active contributor. I'll continue to lurk for the moment.

--
Alex "I still do standards for a living" McDonald
-----------------------------------------------------------------------------

I think Forth-200x is essentially dead --- the Forth-200x committee have embraced Alex McDonald and Julien Fondren --- by doing this, they ruin their own reputation.

I predict that everybody on the Forth-200x mailing list will opt out because they don't want to be involved in a cult anymore --- they don't want to associate with people who make death threats --- even by the low standards of the modern-day internet, death threats are still considered to be unacceptable.

I also predict that the Forth-200x committee will continue to list their names on the Forth-200x document as "contributors" because they were on the mailing list at least for a while --- the Forth-200x document will be released with a long list of contributors and will appear to have full support from the Forth community to the casual observer --- the Forth-200x committee will spend the rest of forever braying about how they alone determine what Standard Forth is, and how the entire Forth community is fully supportive of them and entirely dependent upon them for leadership.

I furthermore predict that the real world will totally ignore Forth-200x --- just like the real world has totally ignored ANS-Forth beginning in 1994 when it was released and continuing until today --- Elizabeth Rather attracts jerks like Alex McDonald and Julien Fondren, but decent folk avoid her like the plague.

Well, tomorrow is New Years Day --- it is traditional to make predictions for the new year --- yet another prediction is that Stephen Pelc and his employee Peter Knaggs will both resign from the Forth-200x committee in 2017, and Elizabeth Rather will appoint one or more of the following to the Forth-200x committee in their place:
Alex McDonald (if they can afford him; he does "do standards for a living")
Julien Fondren (the second most likely candidate)
Alex Wegel (the most likely candidate)
Rickman (if he agrees to reveal his real name)
John Passaniti (if they can find him)

[HAA]

Elizabeth D. Rather wrote:
> ...

> Every significant language has standards, and all of them have their
> critics, just as Forth Standards do. But they are widely respected and
> influential, even in systems that do not choose to follow them rigorously.

Respected by whom? Addiction and lethargy has been the effect of
standards in Forth. ANS - the most comprehensive and controlling
of them all - has cast a long shadow. Nobody wants to do anything
in Forth except imbibe on standards. No sooner do they have one,
they're looking for the next. Like a bar tender, 200x has no plans to
stop supply so now it's one long party. If Forth isn't dead, the only
sign of life has been the noise and revelry coming from comp.lang.forth.
It may be a new year but for Forth it will be no different than the
previous twenty-three. Cheers.

[Alex]

Well, don't use them then. No-one is forcing you too (unless you get the
kind of contract to provide code for money, when companies are very
interested in standards).

I mystified as to why you and more especially Hugh get so exercised
about something that you both claim doesn't affect you. Why the acid tongue?

--
Alex

[Ilya Tarasov]

> Well, don't use them then. No-one is forcing you too (unless you get the
> kind of contract to provide code for money, when companies are very
> interested in standards).
>
> I mystified as to why you and more especially Hugh get so exercised
> about something that you both claim doesn't affect you. Why the acid tongue?

I don't want to use 'acid tongue' as well, but understand Hugh's position.

Ok, let's start from a distance. Imagine a man who claims he is a real magician and can spell fireballs and predict the future, but can't show any of his magic right now because you don't believe him or evil magician is prevents his magic to action. This looks like madness or at least as attempt to deceive.

Not so mad and clear example - a man who has a rare hobby and don't want to explain does he skilled or not. Because of rarity, it is hard to prove and you are not sure is he deceiveer or it is just he's hobby features (for example, fails in 9 attempts of 10...).

In the case of hobby you can just forget him, but if he comes with commercial proposal, you need to estimate risks. How you can did it when hearing 'this is Forth way!' and having no further explanation except links to 20-years old documents? Since Forth is a real language and some practical programmers know it, this is not only a question of close club of ANS committee followers. From my point of view, the principal feature of Forth is it's unique programming model. We can't just ignore zero-operand syntax and postfix notation because it is a mathematics too, not just a caprice of a small team of programmers. Sooner or later, when we will summarize programming language approaches and models, we will include Forth, Lisp, Prolog and C as an examples of different styles of PL basics.

Unfortunately, small communities and rare hobby-like languages are attractive for peoples who wants to looks like 'magicians who can't prove his magic right now'. You can't do this with C++ because many programmers can test your code, but with Forth you can try to convince others it is just your 'Forth way'. Eliminate both commercial and scientific components (i.e. organize a parody to scientific conference every year), and nobody will be able to setup a objective scores for your Forth translators and programs.

This is a problem as I can see. In Russian Forth community we fight against this whenever possible. There are enough programmers comes to RuFIG to hide from real programming problems. They want to see libraries, standards, IDE, ForthOS (a favourite toy in RuFIG), optimizing compilers etc, but has a lack of real programs to write. Again, there is a similar 'holy cow' - SP-Forth with 20+ years history and slogan 'SP-Forth is a standard de-facto for Russia'. Also, 'don't use it' and 'no-one is forcing you' appears each time you try to ask 'why don't improve something in SP-Forth' :)

There is a significant difference in overall strategy. I don't have a plans to just get a benefits from 'Forth' brand and involve followers to write code for free. I'm not a looser who seeks a safe place in Forth, but want to improve a language methodology and bring Forth to practical programming. So the same position is welcome, and attempts to suppress practical initiatives are not. It is a time to forget someone is a kind of guru ;)

[hughag...@gmail.com]

I don't agree with either of you.

HAA says: "Removing choice is of course what standards do." (true)
And he says: "Standards are an ever narrowing jail that ultimately chokes on itself." (not true).

A standard does remove choice, obviously, because the programmer is restrained by the rules (there should be rules; not ambiguity like ANS-Forth has). There is no reason for the rules to be "ever narrowing" though --- you adopt your standard and then you stick with it --- also, the point of the standard is portability of software (mostly code-libraries), so if people want to have code-libraries available then they voluntarily accept the rules (it is not a jail).

E.R. says: "The advent of ANS Forth liberated Forth system developers from the constraints of implementation specifications in Forth83, making possible the era of optimizing compilers and other advances that have led to
faster, more powerful systems."

This lie made Jeff Fox so mad! I would say that Elizabeth Rather falsely taking credit for making Forth optimizing compilers possible, was a major contributor to his death.

ANS-Forth is such a screwed up standard that any significant work in ANS-Forth is primarily involved in working around the idiotic problems of ANS-Forth, rather than solving the problem itself. For example, my early-binding MACRO: was written in UR/Forth initially and was Forth-83 compliant (almost all of MFX was Forth-83 compliant). In ANS-Forth my early-binding MACRO: had to wait until I had disambiguifiers available because FIND is broken in ANS-Forth. This is why it didn't get written until 2016. I knew about the disambiguifiers in 2010 and could have written the early-binding MACRO: then, but this had to wait until I wrote STR>NUM which I did in 2016. Even something trivial such as an early-binding MACRO:, which was easy in Forth-83, is difficult in ANS-Forth.

My MACRO: (both the late-binding and early-binding versions) do inlining. Inlining is a pretty easy optimization, and this was commonly done in Forth-83. For the most part, inlining is the only optimization being done in SwiftForth today.

: init-list 0 over ! ; ok

see over
405C5F 4 # EBP SUB 83ED04
405C62 EBX 0 [EBP] MOV 895D00
405C65 4 [EBP] EBX MOV 8B5D04
405C68 RET C3 ok

see !
40572F 0 [EBP] EAX MOV 8B4500
405732 EAX 0 [EBX] MOV 8903
405734 4 [EBP] EBX MOV 8B5D04
405737 8 # EBP ADD 83C508
40573A RET C3 ok

Notice how OVER and ! are just being pasted in unchanged:

see init-list
478F0F 4 # EBP SUB 83ED04
478F12 EBX 0 [EBP] MOV 895D00
478F15 0 # EBX MOV BB00000000 \ 0 ends here
478F1A 4 # EBP SUB 83ED04
478F1D EBX 0 [EBP] MOV 895D00
478F20 4 [EBP] EBX MOV 8B5D04 \ OVER ends here
478F23 0 [EBP] EAX MOV 8B4500
478F26 EAX 0 [EBX] MOV 8903
478F28 4 [EBP] EBX MOV 8B5D04
478F2B 8 # EBP ADD 83C508 \ ! ends here
478F2E RET C3 ok

So, how exactly did ANS-Forth make optimizing compilers possible? This is the same kind of optimization that was done in Forth-83. Also, this isn't really optimization --- all it does is get rid of the CALL/RET for each sub-function, but this has very little effect because the modern x86 does CALL/RET prediction anyway --- SwiftForth is still moving data on and off the data-stack needlessly, and all of this memory access is the major speed killer (optimization involves holding data in registers).

This is VFX:

see init-list
INIT-LIST
( 004E1030 C70300000000 ) MOV DWord Ptr 0 [EBX], 00000000
( 004E1036 C3 ) NEXT,
( 7 bytes, 2 instructions )
ok

For the most part, the point of having a standard is to support code-libraries. Elizabeth Rather has fought tooth and nail against code-libraries her entire career though. She refers to the call for code-libraries to be an "endless whine" --- that is grossly offensive! --- that is also abysmally ignorant. This is the primary reason why Forth has become obscure --- nobody is going to use a language that doesn't support code-libraries.

Straight Forth doesn't support parallelization, so Oforth would be a better choice for programs that need this. Oforth and Factor don't support cross-compilers though, so Straight Forth would be a better choice for that. Other than cross-compilers, Straight Forth is mostly for numeric programs --- Straight Forth does have a string-stack though, so it would be better than ANS-Forth (or C) for text handling.

Straight Forth has quotations, which C lacks, so Straight Forth is primarily competing against C --- competing against ANS-Forth is nonsense, because nobody uses ANS-Forth --- Straight Forth is not competing against all of the Scheme/Lisp derived languages such as Ruby, Python, Factor, etc. which are widely used for script-writing and web-servers.

I'm not saying that Straight Forth is the end-all of Forth. I'm just saying that Straight Forth would support code-libraries, so it would be an actual Standard, rather than just another toy Forth system like ANS-Forth or JonesForth. Straight Forth has quotations using the fat-xt method, so it supports general-purpose data-structures. Here is a snippet from my StraightForth.txt document (note that PTR and CNT are user-registers):
---------------------------------------------------------------------------

subsection 1.3.3. --- HOFs for chains
=====================================

A "chain" is a data-structure that is ordered by a key which is a string. A chain can be used as an association, which is like an array indexed by strings, although it is not going to be as fast as a hash-table (if this is a problem, I may implement hash-tables at some time in the future, but Straight Forth isn't competing against Lua so this may never be an issue). A chain is ordered, and it is expected that the key will typically be the string representation of a number (the strings should all be the same length and have the decimal point in the same position, so they compare the same as numbers would compare). In a cross-compiler, for example, the keys would be line-numbers --- also, numeric programs may use chains for sparse arrays.

In a chain, a pointer to a node indicates that this is the current node that we are interested in. This is not necessarily the head (left-most) or tail (right-most) in the chain.

|FULL-RITE ( xt -- ) needs PTR = current-node
Execute xt for each node in the entire list starting at the head-node and moving right.
When the xt function executes, PTR points to the current node.

|FULL-LEFT ( xt -- ) needs PTR = current-node
Execute xt for each node in the entire list starting at the tail-node and moving left.
When the xt function executes, PTR points to the current node.

|EACH-RITE ( xt -- ) needs PTR = current-node
Execute xt for each node starting at PTR@ and moving right.
When the xt function executes, PTR points to the current node.

|EACH-LEFT ( xt -- ) needs PTR = current-node
Execute xt for each node starting at PTR@ and moving left.
When the xt function executes, PTR points to the current node.

|FULL-RITE-UNTIL ( xt -- false | node true ) needs PTR = current-node --- sets PTR= node right of found-node
Execute xt for each node in the entire list starting at the head-node and moving right.
When the xt function executes, PTR points to the current node.
The xt function must return a flag. If the FLAG is TRUE then early-exit.
Return the node that caused the early-exit if there was an early-exit.
PTR is set to the node right of found-node (NIL if found-node was the right-most node).
PTR is restored if there was no early-exit.

|FULL-LEFT-UNTIL ( xt -- false | node true ) needs PTR = current-node --- sets PTR= node left of found-node
Execute xt for each node in the entire list starting at the tail-node and moving left.
When the xt function executes, PTR points to the current node.
The xt function must return a flag. If the FLAG is TRUE then early-exit.
Return the node that caused the early-exit if there was an early-exit.
PTR is set to the node left of found-node (NIL if found-node was the left-most node).
PTR is restored if there was no early-exit.

|EACH-RITE-UNTIL ( xt -- false | node true ) needs PTR = current-node --- sets PTR= node right of found-node
Execute xt for each node starting at PTR@ and moving right.
When the xt function executes, PTR points to the current node.
The xt function must return a flag. If the FLAG is TRUE then early-exit.
Return the node that caused the early-exit if there was an early-exit.
PTR is set to the node right of found-node (NIL if found-node was the right-most node).
PTR is restored if there was no early-exit.

|EACH-LEFT-UNTIL ( xt -- false | node true ) needs PTR = current-node --- sets PTR= node left of found-node
Execute xt for each node starting at PTR@ and moving left.
When the xt function executes, PTR points to the current node.
The xt function must return a flag. If the FLAG is TRUE then early-exit.
Return the node that caused the early-exit if there was an early-exit.
PTR is set to the node left of found-node (NIL if found-node was the left-most node).
PTR is restored if there was no early-exit.

The following aren't HOFs, but are just some functions for chains:

LEFT-LENGTH ( -- n ) needs PTR = current-node
Returns the number of nodes to the left of PTR@.

RITE-LENGTH ( -- n ) needs PTR = current-node
Returns the number of nodes to the right of PTR@.

LENGTH ( -- n ) needs PTR = current-node
Returns the total number of nodes in the chain.

HEAD ( -- flag ) needs PTR = current-node --- sets PTR= head-node
Returns TRUE if PTR@ was already the head-node, or FALSE if PTR was changed.

TAIL ( -- flag ) needs PTR = current-node --- sets PTR= tail-node
Returns TRUE if PTR@ was already the tail-node, or FALSE if PTR was changed.

LEFT ( -- flag ) needs PTR = current-node --- sets PTR= left-of-current-node
Returns TRUE if PTR changed, or FALSE if PTR@ was already the left-most node.
PTR is set to the node left of the current-node if possible.
PTR is restored if it is already the left-most node.

RITE ( -- flag ) needs PTR = current-node --- sets PTR= rite-of-current-node
Returns TRUE if PTR changed, or FALSE if PTR@ was already the right-most node.
PTR is set to the node right of the current-node if possible.
PTR is restored if it is already the right-most node.

INSERT-WEAK ( chain -- clash-chain ) needs PTR = current-node
Abort if CHAIN is already in the current chain.
Insert CHAIN into the current chain.
If any of CHAIN's nodes clash (have the same key as a node in the current chain),
then no insertion is done and the clashing node is inserted into CLASH-CHAIN instead.

INSERT-STRONG ( chain -- clash-chain ) needs PTR = current-node
Abort if CHAIN is already in the current chain.
Insert CHAIN into the current chain.
If any of CHAIN's nodes clash (have the same key as a node in the current chain),
then the insertion is done, but first the old node is removed and inserted into CLASH-CHAIN.

It is illegal to have multiple nodes in a chain with the same key. INSERT-WEAK and INSERT-STRONG remove the nodes with duplicate keys rather than mix them together in the same chain, and these duplicates are all put in a new clash-chain. Normally the clash-chain should be empty (returned as a NIL node) --- if any nodes get put in the clash-chain, this usually means that there is a bug in the program.

SAFE-REMOVE ( node -- ) needs PTR = current-node --- sets PTR= head-node
Remove NODE from the list.
Set PTR to the head-node (not necessarily the same as the previous head-node).

REMOVE ( node -- ) needs PTR = current-node
Abort if NODE = PTR@.
Remove NODE from the list.

Removing a node is problematic because you have to be careful not to remove the only node in the chain that you have a pointer for. SAFE-REMOVE solves this problem by setting PTR to a valid node, but you lose track of which node is your current-node. If you are sure that your current-node is not the node that you are removing (you usually are) then REMOVE lets you keep your current-node in PTR.

DELINK-LEFT ( -- left-chain ) needs PTR = current-node
Split the chain to the left of PTR@ so PTR@ becomes the head of the current chain.
Return LEFT-CHAIN as the tail of a new chain.

DELINK-RITE ( -- rite-chain ) needs PTR = current-node
Split the chain to the right of PTR@ so PTR@ becomes the tail of the current chain.
Return RITE-CHAIN as the head of a new chain.

SEARCH ( -- false | node true ) s( str -- ) needs PTR = current-node
Search the current chain for a node with STR as its key.
Return the found node, or FALSE if nothing was found.

OPTIMIZE-SEARCH ( -- ) needs PTR = current-node
Make the chain more efficient for future calls to SEARCH.
The programmer shouldn't bother with this unless he has reason to believe that it will improve his program's speed.
Overuse of this may degrade a program's speed, so it should be used judiciously

Straight Forth standardizes behavior, not implementation, so the programmer shouldn't rely on any assumptions about implementation. Just to satisfy curiosity though, I will mention that I'm implementing chains as AVL trees. Each node has three pointers, which are left-down, rite-down and up. The up-pointer is needed so LEFT and RITE will work, as PTR does not necessarily point to the root node. Each node also keeps track of its weight which is used by the AVL self-balancing algorithm. OPTIMIZE-SEARCH doesn't do anything at all. I used the name "chain" rather than "tree" (my original name) because binary-trees aren't the only reasonable way that chains could be implemented --- doubly linked lists would also work and would save some memory --- different implementations of Straight Forth may have different implementations of chains.

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

[hughag...@gmail.com]

On Sunday, January 1, 2017 at 8:55:47 PM UTC-7, hughag...@gmail.com wrote:
> E.R. says: "The advent of ANS Forth liberated Forth system developers from the constraints of implementation specifications in Forth83, making possible the era of optimizing compilers and other advances that have led to
> faster, more powerful systems."
>
> This lie made Jeff Fox so mad! I would say that Elizabeth Rather falsely taking credit for making Forth optimizing compilers possible, was a major contributor to his death.

Jeff Fox was very proud of his work in Forth and every time that Elizabeth Rather tells a lie about how none of his work exists and/or that she deserves credit for everything that anybody has ever been written in Forth, it was like stabbing him through the heart with a big knife.

I don't have much experience with F83 --- IIRC, it did inlining --- it had something similar to my early-binding MACRO: or maybe it just inlined the compiled code similar to ICODE in SwiftForth.

There were several Forth-83 systems that went beyond simple inlining. I used TCOM (written by Tom Zimmer) and ForthCMP (written by Tom Almy). Both of these were cross-compilers. There was also FPC from Tom Zimmer that was a more traditional interactive system --- I don't have much experience with FPC, though.

I mostly used UR/Forth. That was the primary Forth-83 system for professional work in MS-DOS days. To get a job as a Forth programmer, it was primarily necessary to know UR/Forth --- the others were much less used. UR/Forth was interactive, so was easy to work with. There were cross-compilers available from LMI for it though, to a variety of targets, from the 80186 to the 80c320. Testra used their 80c320 cross-compiler for their motion-control program. Later though, I wrote MFX in UR/Forth to target the MiniForth processor which was much more powerful than the 80c320.

There is nothing about Forth-83 that prevents optimizing compilers from being written. ANS-Forth's FIND is broken, so it can't be used for optimizing compilers, at least not until the disambiguifiers are made available. Why do Elizabeth Rather's sycophants hate the disambiguifiers? It seems obvious that they want FIND to remain broken in order to prevent common Forth programmers from writing code such as my early-binding MACRO: that do optimization (you can't do any optimization unless you can obtain xt values). ANS-Forth is a cult --- it is all about preventing common Forth programmers from writing code --- simultaneously, there is a great deal of braying about "freedom" from Elizabeth Rather.

[Elizabeth D. Rather]

Language standards in general are respected by the programmers whose
work life depends on those languages. This is because it's easier for
those programmers to get employment and to move from one project to
another. They are also respected by software project managers who know
they aren't as dependent on "the only person in the world who
understands this particular compiler."

Some other signs Forth isn't dead: companies like FORTH, Inc. and MPE
keep getting contracts, and Forth is still considered for new projects.
Standards make this possible.

[Elizabeth D. Rather]

That is certainly a different experience from the one we see in the US.
When we are talking with a prospective customer we can point to other
significant project in related industries in which Forth has been
successful, and people respect that.

[Alex]

Your complaint seems to be addressed to individuals who claim expertise
but can't demonstrate it, or are in an area where expertise is so
limited it looks like they're claiming to be magicians.

I'm talking about HAA and Hugh's railing against a standard they don't
like.

--
Alex

[Alex]

On 1/2/2017 03:55, hughag...@gmail.com wrote:

>
> A "chain" is a data-structure that is ordered by a key which is a string.

AKA a wordlist.

--
Alex

[Ilya Tarasov]

> That is certainly a different experience from the one we see in the US.
> When we are talking with a prospective customer we can point to other
> significant project in related industries in which Forth has been
> successful, and people respect that.

Such a surprise from the blessed land of light elves! :) So do you really think Russians start bears fighting, drink vodka or obey Putin's orders while evaluate project perspectives? This is very simple thing indeed.
1. Show features.
2. Prove you can achieve the desired result with resource you are asking for.
You are talking about step #2 - "we can complete this project because we did the same before". Ok than, but features you are talking about looks obsolete and for internal use of your club. This is why trolls annoying you with HDMI and USB 3.0 - can anybody even explain why this questions are pure trolling?

[Ilya Tarasov]

> Your complaint seems to be addressed to individuals who claim expertise
> but can't demonstrate it, or are in an area where expertise is so
> limited it looks like they're claiming to be magicians.

I'm not complaining. You need to learn this very good. I wonder if there is a signle product from ANS-group interesting for me. In their situation they should ASK and ASK again to make a step from their swamp.

[foxaudio...@gmail.com]

For the record on optimizing Forth compilers, Hs/Forth 1992 or so could do this:

: BOUNDS OPT" OVER + SWAP" ;

and it created in-lined code with push/pop optimizations and a few other substitutions as well. Speed up was about 4 to 10 times vs the normal ITC code.

Funnily enough Jim Calihan didn't like Forth 83 so he stuck with 79. :)
But he provided a Forth 83 Harness that worked correctly.

For the historians.

RIP Jim Calihan

BF

[Alex]

On 1/2/2017 15:01, Ilya Tarasov wrote:
>
>> Your complaint seems to be addressed to individuals who claim
>> expertise but can't demonstrate it, or are in an area where
>> expertise is so limited it looks like they're claiming to be
>> magicians.
>
> I'm not complaining. You need to learn this very good. I wonder if

I mean complaint in this sense: "a statement that something is
unsatisfactory or unacceptable", not in the sense of a grievance.

> there is a signle product from ANS-group interesting for me. In their
> situation they should ASK and ASK again to make a step from their
> swamp.
>

Swamp? My question remains; why do those who claim they have no use for
it, and no interest in employing it, complain so loudly about the ANS
standard, attack it and its proponents so regularly, and why do they
(and you) employ such emotive language?

--
Alex

[john]

In article <o4dshc$cst$1...@dont-email.me>, al...@rivadpm.com says...

>
> Swamp? My question remains; why do those who claim they have no use for
> it, and no interest in employing it, complain so loudly about the ANS
> standard, attack it and its proponents so regularly, and why do they
> (and you) employ such emotive language?
>
> --
> Alex
>
>

Fundamental rule of acoustics - empty vessels make the most noise.

--

john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/

=========================

[Elizabeth D. Rather]

Sure, one *could* make optimizing compilers at any time, but they would
be in direct violation of Forth 83 (as well as Forth 79) since both
mandated 16-bit ITC.

Cheers,
Elizabeth

> Funnily enough Jim Calihan didn't like Forth 83 so he stuck with 79. :)
> But he provided a Forth 83 Harness that worked correctly.
>
> For the historians.
>
> RIP Jim Calihan
>
> BF
>

[Anton Ertl]

"HAA" <som...@microsoft.com> writes:
>Removing choice is of course what standards do. Standards are an ever
>narrowing jail that ultimately chokes on itself.

First of all, you have the choice of complying with a standard or
not; standards don't remove that choice.

Ok, let's look at the case when you want to comply with a Forth
standard. There is is important to understand that a Forth standard
specifies an interface between a Forth system and a Forth program.
Removing choices of standard-system implementors adds choices for
standard-program writers and vice versa. E.g., at the 2015 meeting
the Forth200x committee decided to standardize 2s-complement
arithmetics and overflow behaviour, allowing Forth programmers to
write stuff like cryptographic functions without contorting
themselves, but of course also removing the standard-system
implementor's choice to use the native signed addition for + on
ones-complement hardware.

>47 years of Forth standards,
>23 years since ANS, 10 years since 200x and no programs or users to
>speak of.

Well, it's sufficient to support two commercial vendors of standard
systems, plus some more of non-standard systems. I don't think that
there are many languages left with that amount of commercial activity;
ok, that has to do with implementations of other languages often
having other business models, but in any case, it shows that the state
of Forth is not as dire as you want to make us believe.

- 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/

[Ilya Tarasov]

> Swamp? My question remains; why do those who claim they have no use for
> it, and no interest in employing it, complain so loudly about the ANS
> standard, attack it and its proponents so regularly, and why do they
> (and you) employ such emotive language?

I don't know about them and can't be responsible about Forth-haters. I use Forth for more than 20 years, wrote several compilers for PC, starting from MS-DOS, and ~10 for different MCUs. Also I usually use my own FPGA-based Forth-processors for commercial projects, from high-end FPGA to low-cost devices sold worldwide. For my life, I feel no need of ANS-compatibility. What I'm do wrong? Tell me why we can collect 5+ forthers together in the same lab, but blessed and civilized light elves can't agreed how to name a words?Do you want to claim I can significantly raise my productivity when became someone's follower? Please name that leader and explain why I must listen him/her irrevocably. If you want to stay with your illusions, it is only you problem, even if you prefer to not to accept the reality. There are many skilled programmers in the world, and many of them can propose some useful for Forth, but sitting in close club means a kind of swamp for me.

[Ilya Tarasov]

> Fundamental rule of acoustics - empty vessels make the most noise.

I can tell you much more about acoustics :))) It was a target domain where Forth was a winning technology for me in mid 90-th. A large ultraacoustic measurement complex was controlled by my Forth, running in 32-bit protected mode under MS-DOS extender, with floating point support, SVGA graphics etc. It was also a first time to hear 'your Forth is not ANS-compatible!' :)

So, my full vessel, tell me, why light elves dreams about past and miltipliy numbers, like junior students in a lab, when crude stupid Russian orks so wonder why just a rumor of commercial project driven by Forth is a reason to celebrate. Where YOU use Forth? How many lines of code YOU wrote last year? What part of you total income was a result of your Forth activity?

[Alex]

On 1/2/2017 18:06, Ilya Tarasov wrote:

> Do you want to claim I can significantly raise my productivity when
> became someone's follower? Please name that leader and explain why I
> must listen him/her irrevocably.

What does the ANS standard have to do with a leader?

--
Alex

[Coos Haak]

Op Fri, 30 Dec 2016 20:54:10 +0100 schreef Alexander Wegel:

> <hughag...@gmail.com> wrote:
>> This, once again, is my source-code:
>>
>> macro: exchange ( adrX adrY size -- ) \ the size of the record must be a mul
>> tiple of W
>> begin dup while \ -- adrX adrY remaining
>> over @ fourth @ \ -- adrX adrY remaining Y X
>> fourth ! fourth ! \ -- adrX adrY remaining
>> rot w + rot w + rot w -
>> repeat
>> 3drop ;
>>
>> EXCHANGE is one of my better-written functions.
>
> The definition itself is a bit clumsy (with all those "fourth"s and the
> juggling), but passable.

It surely is clumsy. He can't program in Forth.

: exchange ( addr1 addr2 size -- )
begin dup
while >r 2dup over @ over @ >r swap ! r> swap !
cell+ swap cell+ swap r> 1+
repeat
drop 2drop ;

No ROT no FOURTH no MACRO
All standard Forth. No words invented by some taxidriver.

groet Coos

[m...@iae.nl]

On Monday, January 2, 2017 at 8:17:33 PM UTC+1, Coos Haak wrote:
[..]

> >> macro: exchange ( adrX adrY size -- ) \ the size of the record must

> >> \ be a multiple of W

> >> begin dup while \ -- adrX adrY remaining
> >> over @ fourth @ \ -- adrX adrY remaining Y X
> >> fourth ! fourth ! \ -- adrX adrY remaining
> >> rot w + rot w + rot w -
> >> repeat
> >> 3drop ;

[..]

> It surely is clumsy. He can't program in Forth.
>
> : exchange ( addr1 addr2 size -- )
> begin dup
> while >r 2dup over @ over @ >r swap ! r> swap !
> cell+ swap cell+ swap r> 1+
> repeat
> drop 2drop ;
>
> No ROT no FOURTH no MACRO
> All standard Forth. No words invented by some taxidriver.
>
> groet Coos

And not too bad with an ancient compiler:

FORTH> : tex $1000 $2000 3 exchange .s ; ok
FORTH> see tex
Flags: ANSI
$01324E00 : tex
$01324E0A push $00001000 d#
$01324E0F mov rcx, $00002000 d#
$01324E16 mov rbx, 3 d#
$01324E1D mov rax, rax
$01324E20 cmp rbx, 0 b#
$01324E24 push rcx
$01324E25 je $01324E4D offset NEAR
$01324E2B pop rdi
$01324E2C pop rax
$01324E2D mov rdx, [rax] qword
$01324E30 mov r9, [rdi] qword
$01324E33 mov [edi] dword, rdx
$01324E36 mov [rax] qword, r9
$01324E39 lea rax, [rax 8 +] qword
$01324E3D push rax
$01324E3E lea rdi, [rdi 8 +] qword
$01324E42 push rdi
$01324E43 lea rbx, [rbx 1 +] qword
$01324E47 pop rcx
$01324E48 jmp $01324E20 offset SHORT
$01324E4A push rcx
$01324E4B push rbx
$01324E4C pop rbx
$01324E4D pop rbx
$01324E4E pop rdi
$01324E4F jmp .S+10 ( $012AC522 ) offset NEAR
$01324E54 ;

-marcel

[Alexander Wegel]

Coos Haak <htr...@gmail.com> wrote:

> Op Fri, 30 Dec 2016 20:54:10 +0100 schreef Alexander Wegel:
>
> > <hughag...@gmail.com> wrote:
> >> This, once again, is my source-code:
> >>

> >> macro: exchange ( adrX adrY size -- ) \ the size of the record mu..

> >> tiple of W
> >> begin dup while \ -- adrX adrY remaining
> >> over @ fourth @ \ -- adrX adrY remaining Y X
> >> fourth ! fourth ! \ -- adrX adrY remaining
> >> rot w + rot w + rot w -
> >> repeat
> >> 3drop ;
> >>
> >> EXCHANGE is one of my better-written functions.
> >
> > The definition itself is a bit clumsy (with all those "fourth"s and the

> > juggling), but passable.f

>
> It surely is clumsy. He can't program in Forth.
>
> : exchange ( addr1 addr2 size -- )
> begin dup
> while >r 2dup over @ over @ >r swap ! r> swap !
> cell+ swap cell+ swap r> 1+
> repeat
> drop 2drop ;

Well, the 1+ is a bug. A fix would either be:

: exchange ( addr1 addr2 size -- )
begin dup
while >r 2dup over @ over @ >r swap ! r> swap !

cell+ swap cell+ swap r> 1-
repeat
drop 2drop ;

or (to keep using a potentially fast 1+):

: exchange ( addr1 addr2 size -- )

negate begin dup

while >r 2dup over @ over @ >r swap ! r> swap !
cell+ swap cell+ swap r> 1+
repeat
drop 2drop ;

(BTW: A "plug-in" compatible version would use cell+)

> No ROT no FOURTH no MACRO

My own take (with better use of forth control structures) is:

: exchange ( a1 a2 u -- )
bounds ?do
i @ over @
i ! over !
cell +
cell +loop drop
;

But anyway - when you know the size of the block to be moved
at compile time, and the block is small (one or a few cells),
having any kind of loop is overkill already.

I wrote a benchmark program to roughly measure various versions
of exchange (including yours now). It's attached below (including
the results) and demonstrates that
- inlining didn't help
- vfx optimizes a lot away
- your version is roughly as fast as hughs :)

1 cells constant w

: exchange-ha \ Hughs version (as generated by his macro: word)
s" ( adrX adrY size -- ) \ ..." evaluate
s" begin dup while \ -- adrX adrY remaining" evaluate
s" over @ 3 pick @ \ -- adrX adrY remaining Y X" evaluate
s" 3 pick ! 3 pick ! \ -- adrX adrY remaining" evaluate
s" rot w + rot w + rot w - " evaluate
s" repeat" evaluate
s" 2drop drop " evaluate
; immediate

: exchange-call \ Hughs version, not inlined
( adrX adrY size -- ) \ the size of the record must be a multiple of

W
begin dup while \ -- adrX adrY remaining

over @ 3 pick @ \ -- adrX adrY remaining Y X
3 pick ! 3 pick ! \ -- adrX adrY remaining

rot w + rot w + rot w -
repeat

2drop drop
;

: exchange-aw ( a1 a2 u -- ) \ my version
bounds ?do
i @ over @
i ! over !
cell +
cell +loop drop
;

\ some non-looping versions for fixed sizes
: exch1 ( a1 a2 -- ) 2dup 2>r @ swap @ r> ! r> ! ;
: exch2 ( a1 a2 -- ) 2dup 2>r 2@ rot 2@ r> 2! r> 2! ;
: exch4 ( a1 a2 -- ) 2dup [ w 2* dup ] 2literal d+ exch2 exch2 ;

\ version using the single-word exch1 from above
: exch1a ( a1 a2 u -- ) bounds do dup i exch1 w + w +loop drop ;

\ similar, using begin..until
: exch1b ( a1 a2 u -- )
begin >r
2dup >r >r exch1
r> w + r> w +
r> w - dup 0=
until drop 2drop ;

\ similar, but using a small trick for incrementing addresses
: exch1c ( a1 a2 u -- )
begin >r
2dup exch1
[ w w ] 2literal d+
r> w - dup 0=
until drop 2drop ;

\ version for exchanging multiples of four cells
\ (could be extended to work for any size by adding another
\ loop that handles remaining 1-3 cells):
: exch4a ( a1 a2 u -- )
[ w 4 * ] literal /
0 ?do
2dup exch4
[ w 4 * dup ] 2literal d+
loop 2drop
;

\ version by coos haak (slightly adapted for compat.)
: exchange-coos ( addr1 addr2 size -- )
negate begin dup

while >r 2dup over @ over @ >r swap ! r> swap !

cell+ swap cell+ swap r> cell+
repeat
drop 2drop ;

\ the test procs

create a 256 cells allot
create b 256 cells allot
w value n
1000000 value m

: t-0 m 0 do a b n 2drop drop loop ;
: t-exch1 m 0 do a b exch1 loop ;
: t-exch2 m 0 do a b exch2 loop ;
: t-exch4 m 0 do a b exch4 loop ;
: t-exch4a m 0 do a b n exch4a loop ;
: t-exch1a m 0 do a b n exch1a loop ;
: t-exch1b m 0 do a b n exch1b loop ;
: t-exch1c m 0 do a b n exch1c loop ;
: t-ha m 0 do a b n exchange-ha loop ;
: t-call m 0 do a b n exchange-call loop ;
: t-aw m 0 do a b n exchange-aw loop ;
: t-coos m 0 do a b n exchange-coos loop ;

\ ticks counts in millisecs (vfx)
[undefined] ticks [if] : ticks utime 1000 um/mod nip ; [then]

\ benchmarking functions

: t. 1000000 m */ . ." ns " ;
\ : .name >name .id space ;
: timex ticks >r execute ticks r> - ;
: meas dup >r timex r@ timex min r> timex min ;
: t dup cr >name .name meas t. ;
: ttbl: begin ['] ' catch 0= while t repeat cr ;

\ the benchmarks

cr .( exchange 1 word)
w to n
ttbl: t-0 t-ha t-call t-aw t-exch1a t-exch1b t-exch1c t-exch1 t-coos

cr .( exchange 2 words)
w 2 * to n
ttbl: t-0 t-ha t-call t-aw t-exch1a t-exch1b t-exch1c t-exch2 t-coos

cr .( exchange 4 words)
w 4 * to n
ttbl: t-0 t-ha t-call t-aw t-exch1a t-exch1b t-exch1c t-exch4a t-exch4
t-coos

cr .( exchange 256 words)
100000 to m
w 256 * to n
ttbl: t-0 t-ha t-call t-aw t-exch1a t-exch1b t-exch1c t-exch4a t-coos

cr

?csp

\ machine: macmini i5-3210m @ 2.5GHz
\
\ gforth-fast:
\
\ exchange 1 word
\ t-0 12 ns
\ t-ha 40 ns
\ t-call 40 ns
\ t-aw 32 ns
\ t-exch1a 36 ns
\ t-exch1b 48 ns
\ t-exch1c 42 ns
\ t-exch1 18 ns
\ t-coos 37 ns
\
\ exchange 2 words
\ t-0 12 ns
\ t-ha 64 ns
\ t-call 63 ns
\ t-aw 48 ns
\ t-exch1a 58 ns
\ t-exch1b 91 ns
\ t-exch1c 76 ns
\ t-exch2 22 ns
\ t-coos 64 ns
\
\ exchange 4 words
\ t-0 13 ns
\ t-ha 117 ns
\ t-call 114 ns
\ t-aw 81 ns
\ t-exch1a 97 ns
\ t-exch1b 162 ns
\ t-exch1c 136 ns
\ t-exch4a 88 ns
\ t-exch4 56 ns
\ t-coos 104 ns
\
\ exchange 256 words
\ t-0 20 ns
\ t-ha 6330 ns
\ t-call 6190 ns
\ t-aw 4390 ns
\ t-exch1a 5430 ns
\ t-exch1b 9840 ns
\ t-exch1c 8250 ns
\ t-exch4a 4020 ns
\ t-coos 5910 ns
\
\ vfx-win:
\
\ exchange 1 word
\ T-0 2 ns
\ T-HA 4 ns
\ T-CALL 3 ns
\ T-AW 4 ns
\ T-EXCH1A 4 ns
\ T-EXCH1B 5 ns
\ T-EXCH1C 5 ns
\ T-EXCH1 2 ns
\ T-COOS 4 ns
\
\ exchange 2 words
\ T-0 2 ns
\ T-HA 7 ns
\ T-CALL 7 ns
\ T-AW 5 ns
\ T-EXCH1A 7 ns
\ T-EXCH1B 10 ns
\ T-EXCH1C 8 ns
\ T-EXCH2 5 ns
\ T-COOS 7 ns
\
\ exchange 4 words
\ T-0 2 ns
\ T-HA 12 ns
\ T-CALL 13 ns
\ T-AW 10 ns
\ T-EXCH1A 13 ns
\ T-EXCH1B 18 ns
\ T-EXCH1C 15 ns
\ T-EXCH4A 15 ns
\ T-EXCH4 10 ns
\ T-COOS 14 ns
\
\ exchange 256 words
\ T-0 0 ns
\ T-HA 800 ns
\ T-CALL 780 ns
\ T-AW 680 ns
\ T-EXCH1A 690 ns
\ T-EXCH1B 1090 ns
\ T-EXCH1C 930 ns
\ T-EXCH4A 780 ns
\ T-COOS 800 ns

[Ilya Tarasov]

> > Do you want to claim I can significantly raise my productivity when
> > became someone's follower? Please name that leader and explain why I
> > must listen him/her irrevocably.
>
> What does the ANS standard have to do with a leader?

No? Then stop to use 'standard' as a final argument for any discussion. Tricks like 'nobody can force you to use standard' don't work. I can see here many times peoples are oppressed just because they suggesting something new. You want they tobgo away? No, because Forth is nor ANS brand neither Moore's child toy. Since Forth is became a significant event in programming, many programmers may explore the conception revealed by Moore. They can achieve better results, advance base Forth ideas etc. Why THEY must go away, just because someone already took a warm place? People comes for ideas, not for club membering, so give them ideas or YOU are about to go away.

[m...@iae.nl]

On Monday, January 2, 2017 at 11:08:19 PM UTC+1, Ilya Tarasov wrote:
> > > Do you want to claim I can significantly raise my productivity when
> > > became someone's follower? Please name that leader and explain why I
> > > must listen him/her irrevocably.
> >
> > What does the ANS standard have to do with a leader?
>

> No? Then stop to <ranting>
[..]

> People comes for ideas, not for club membering, so give them
> ideas or YOU are about to go away.

Last time I encountered that kind of logic was in Kindergarten.

-marcel

[Albert van der Horst]

In article <l9qdnfKSwpKYDPfF...@supernews.com>,
Elizabeth D. Rather <era...@forth.com> wrote:
<SNIP>

>
>Sure, one *could* make optimizing compilers at any time, but they would
>be in direct violation of Forth 83 (as well as Forth 79) since both
>mandated 16-bit ITC.

I wonder. There is a straightforward way to optimise ITC quite a bit.
Inline everything until code words remain, then replace by the code itself,
leaving out the next's, replacing branches whith machine code jumps.
Would anyone be upset?
What would be the argument that the resulting code is not Forth-83,
given that nobody argues that there can't be code words?
Those words could have been written in code to begin with.

>
>Cheers,
>Elizabeth

Groetjes Albert
--
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

[Ilya Tarasov]

> > People comes for ideas, not for club membering, so give them
> > ideas or YOU are about to go away.
>
> Last time I encountered that kind of logic was in Kindergarten.

I see no logic or responsibility here. Do you think you can start a large project and simple tell 'Oh, I don't want to work with this, forget my previous words and start to do other things, but with the same brand'? This is what happens with ANS-Forth. There is no flexibility, no methodology and no overall strategy. If my logic looks strange for you, I have a bad news - you know nothing about logic. I state very simple thing - when you call peoples to work with Forth, you must not change your project on-the-fly. Oh, I know the Geyrope politics of double standards - you are right just because you have blessing from the right source :)

[hughag...@gmail.com]

No it isn't.

A chain is a general-purpose data-structure which is expected to be used by most application programs for their data --- you snipped the entire description --- a chain could be used internally to hold word-lists, but that is irrelevant.

You don't really understand any of these subjects that you comment on.

[hughag...@gmail.com]

ANS-Forth is Elizabeth Rather's toy language --- every ANS-Forth "programmer" is a brown-noser of Elizabeth Rather.

Elizabeth Rather appoints all of the Forth-200x committee members, and all of them are totally obedient to Forth Inc..

Stephen Pelc does "joint projects" with Forth Inc. and has a financial motiviation to obey Forth Inc.. The best example of this is when Leon Wagner said that { couldn't be used to define locals because SwiftForth uses { for multi-line comments and Stephen Pelc kowtowed to him, despite the fact that { has been the de facto standard for locals since prior to ANS-Forth.

Peter Knaggs is Stephen Pelc's employee --- he does what his boss tells him to do.

Andrew Haley is a Forth Inc. employee --- he does what his boss tells him to do --- he is one of the most disgusting brown-nosers I have ever seen!

Anton Ertl kowtows to Forth Inc.. He wrote the {: word (the replacement for the { word) and screwed it up. Instead of initializing the locals to the right of | to zero, he left this "undefined" meaning that they could be initialized to different values in different compliant compilers or initialized to whatever happened to be in memory causing them to be initialized to different values from one one run to the next. When I pointed this out, he said that it wasn't a bug because his code was written according to spec. Where did the spec come from? Forth Inc. of course!

[Rod Pemberton]

On Tue, 3 Jan 2017 02:00:21 +0100 (CET)
alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:

> I wonder. There is a straightforward way to optimise ITC quite a bit.

...

> Inline everything until [only] code words remain,

Yes. Perhaps, a variant of SEE could do this?

> then replace by the code itself,

Once inlined, you might just convert them from addresses or offsets
into assembly subroutine calls.

E.g., in Forth,

DUP SWAP +!

I.e., becomes in x86 assembly,

call dup
call swap
call plus_store


The "code words" or "primitives" for dup, swap, or plus_store would
remain as assembly routines (or C etc) and simply be called.

This should be ITC converted to STC, or something very similar to it.

> leaving out the next's,

Yes.

> replacing branches whith machine code jumps.

Yes, but more likely, they'd be converted to absolute branches and
conditional branches, unless they don't have sufficient range.

> Would anyone be upset?

I don't know. There might be issues with converting certain Forth
words, such as DOES> or S" which inline data within the threaded code.
You'd need to insert branches around the data.


Rod Pemberton

[hughag...@gmail.com]

Everything in the novice package is ANS-Forth --- including FOURTH and MACRO: etc..

I tested three versions of EXCHANGE under VFX:
1.) one version used only stack juggling --- this is what I went with
2.) one version held the count on the return-stack temporarily while doing the exchange
3.) one version used a DO loop for the count

Your code doesn't work --- you didn't actually test it before you posted it on comp.lang.forth --- you made a complete jackass out of yourself!

ANS-Forth is 1970s technology, and most ANS-Forth programmers are making assumptions that haven't been valid since the 1970s. In those days, ROT was very inefficient due to an extreme lack of registers. ROT is pretty efficient under VFX though. All of the versions are unacceptably inefficient under SwiftForth --- the novice-package is full of SwiftForth-specific code hand-written in assembly-language to make up for SwiftForth's lack of optimization. This was my code:

SwiftForth? [if]

icode exchange ( adrX adrY size -- ) \ the size of the record must be a multiple of W
0 [ebp] eax mov w [ebp] ecx mov \ EAX<>ECX, with EBX being the size
begin non-zero? while
0 [eax] push
0 [ecx] edx mov edx 0 [eax] mov
0 [ecx] pop
w # eax add w # ecx add
w # ebx sub repeat
w 2 * [ebp] ebx mov
w 3 * # ebp add ret end-code

[else]

macro: exchange ( adrX adrY size -- ) \ the size of the record must be a multiple of W

begin dup while \ -- adrX adrY remaining
over @ fourth @ \ -- adrX adrY remaining Y X
fourth ! fourth ! \ -- adrX adrY remaining
rot w + rot w + rot w -
repeat
3drop ;

[then]

\ If FIELD is used to define records, the size of the records will be a multiple of W, as required by EXCHANGE.

Why am I being attacked for EXCHANGE of all things? This code works, and it is efficient. It is pretty trivial as compared to the early-binding MACRO: which I just wrote. Alex Wegel just picked EXCHANGE out at random as something to attack, because his attack on my late-binding MACRO: fizzled out after I wrote an early-binding MACRO: word. Now the other ANS-Forth cult members are attacking EXCHANGE too. You are all making jackasses out of yourselves!

[hughag...@gmail.com]

On Monday, January 2, 2017 at 5:49:56 PM UTC-7, Albert van der Horst wrote:
> In article <l9qdnfKSwpKYDPfF...@supernews.com>,
> Elizabeth D. Rather <era...@forth.com> wrote:
> <SNIP>
> >
> >Sure, one *could* make optimizing compilers at any time, but they would
> >be in direct violation of Forth 83 (as well as Forth 79) since both
> >mandated 16-bit ITC.
>
> I wonder. There is a straightforward way to optimise ITC quite a bit.
> Inline everything until code words remain, then replace by the code itself,
> leaving out the next's, replacing branches whith machine code jumps.
> Would anyone be upset?
> What would be the argument that the resulting code is not Forth-83,
> given that nobody argues that there can't be code words?
> Those words could have been written in code to begin with.

My Straight Forth initial version uses ITC and it does significant optimization. Maybe later I will delve into STC.

The idea that I am dependent upon ANS-Forth to make optimization possible, is absurd --- ANS-Forth is a purely negative contribution to the Forth world.

Also, while it is true that Forth-83 mandated ITC, it was easy to write compilers that would compile almost all Forth-83 code and yet used DTC or STC internally --- UR/Forth used DTC and generated code that was significantly faster than PolyForth and F83 etc. that used ITC --- to get portable code, the programmer had to never directly access the cfa pointer, which was theoretically allowed in Forth-83.

I agree that Forth-83 was badly designed in regard to exposing the implementation to the user, but I blame Elizabeth Rather for that, and I think that Elizabeth Rather's ANS-Forth is also badly designed. Nothing that has come from Forth Inc. after Charles Moore got kicked out has been any good.

[Elizabeth D. Rather]

Sorry, you know nothing about the ANS Forth process. Over a 6-year
period, with meetings 4x/year, we developed strategy, methodology, and
worked very hard to ensure operational compatibility with existing
Forth83 systems and applications while removing constraints (such as the
16-bit requirement) to enable implementation freedom with
application-level stability.

Cheers,
Elizabeth

[Elizabeth D. Rather]

On 1/2/17 7:13 PM, Rod Pemberton wrote:
> On Tue, 3 Jan 2017 02:00:21 +0100 (CET)
> alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) wrote:
>
>> I wonder. There is a straightforward way to optimise ITC quite a bit.
> ...
>
>> Inline everything until [only] code words remain,
>
> Yes. Perhaps, a variant of SEE could do this?
>
>> then replace by the code itself,
>
> Once inlined, you might just convert them from addresses or offsets
> into assembly subroutine calls.
>
> E.g., in Forth,
>
> DUP SWAP +!
>
> I.e., becomes in x86 assembly,
>
> call dup
> call swap
> call plus_store

Surely any compiler worth its salt would know that SWAP following DUP is
a no-op and skip it?

Cheers,
Elizabeth

[Andrew Haley]

Ilya Tarasov <ilya74....@gmail.com> wrote:
>
>> Swamp? My question remains; why do those who claim they have no use for
>> it, and no interest in employing it, complain so loudly about the ANS
>> standard, attack it and its proponents so regularly, and why do they
>> (and you) employ such emotive language?
>
> I don't know about them and can't be responsible about
> Forth-haters. I use Forth for more than 20 years, wrote several
> compilers for PC, starting from MS-DOS, and ~10 for different
> MCUs. Also I usually use my own FPGA-based Forth-processors for
> commercial projects, from high-end FPGA to low-cost devices sold
> worldwide. For my life, I feel no need of ANS-compatibility. What
> I'm do wrong?

What you're doing wrong is characterized by the long, aggressive,
rude, boring, and incoherent rants that you post here. These posts
are irredeemably negative and destructive; they are also comically
arrogant. You talk about all the great things you have done. You say
that with 20+ years of experience of Forth there is a very small
chance that you've missed anything really important. You imagine that
people want to stop you from designing your own Forth derivative, and
get angry when you think they're trying to stop you doing what you
want. All of this looks like the boasting of a frightened
six-year-old.

Andrew.

[Anton Ertl]

"Elizabeth D. Rather" <era...@forth.com> writes:
>Surely any compiler worth its salt would know that SWAP following DUP is
>a no-op and skip it?

Depends on the technology used by the compiler. For compilers that
just use peephole optimization (like SwiftForth and gforth-fast) would
need a peephole optimization rule for this combination, and since this
sequence does not occur in real-world code, the compiler maintainer is
unlikely to add this rule. Let's see:

[~:92330] sf
SwiftForth i386-Linux 3.4.4 31-Jul-2012
: x dup ; ok
: y dup swap ; ok
see x
8082ADF 4 # EBP SUB 83ED04
8082AE2 EBX 0 [EBP] MOV 895D00
8082AE5 RET C3 ok
see y
8082AFF 4 # EBP SUB 83ED04
8082B02 EBX 0 [EBP] MOV 895D00
8082B05 0 [EBP] EAX MOV 8B4500
8082B08 EBX 0 [EBP] MOV 895D00
8082B0B EAX EBX MOV 8BD8
8082B0D RET C3 ok

Is SwiftForth not worth its salt?

[Anton Ertl]

alb...@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes:
>In article <l9qdnfKSwpKYDPfF...@supernews.com>,
>Elizabeth D. Rather <era...@forth.com> wrote:
><SNIP>
>>
>>Sure, one *could* make optimizing compilers at any time, but they would
>>be in direct violation of Forth 83 (as well as Forth 79) since both
>>mandated 16-bit ITC.

I just looked into the Forth-83 standard document, and I see no
trace of that. The first mention of "threaded" is in Appendix C
"Experimental proposals", and it says there:

[The proposed header access words] can
be implemented in a FORTH system which uses any combination of
the following options for its dictionary structure:

Link fields first or second.
Fixed or variable length name fields.
Additional fields in the definitions structure.

Heads contiguous or separated from bodies.

Indirect, direct, subroutine, or token threaded code.

So at least that part does not assume indirect-threaded code.

Earlier, in the section "addressable memory", the document says:

A Standard Program may address:

1. parameter fields of words created with CREATE , VARIABLE ,
and user defined words which execute CREATE ;
[...]

A Standard Program may NOT address:
[...]
3. into a definition's parameter field if not stored by the
application.

This eliminates pretty much any use a Forth-83 program might want to
make of the knowledge about indirect-threaded code, if there was
really such a requirement/guarantee in Forth-83.

>I wonder. There is a straightforward way to optimise ITC quite a bit.
>Inline everything until code words remain, then replace by the code itself,
>leaving out the next's, replacing branches whith machine code jumps.
>Would anyone be upset?
>What would be the argument that the resulting code is not Forth-83,
>given that nobody argues that there can't be code words?
>Those words could have been written in code to begin with.

But they were not. So, if there was a guarantee that ITC is used, one
could do things like writing a decompiler, a call graph analyser, a
stepping debugger, or patch existing compiled words. These things
fail sooner or later when you deviate from ITC, e.g., in the direction
you indicated (which is not that far from what Gforth does with
dynamic native code generation). E.g., the current development
version of Gforth gives the following error when you try to use the
stepping debugger (DBG) on gforth or gforth-fast:

error: Only works on gforth-itc

[Alexander Wegel]

<hughag...@gmail.com> wrote:

> Why am I being attacked for EXCHANGE of all things? This code works,
> and it is efficient.
> It is pretty trivial as compared to the early-binding MACRO: which I
> just wrote. Alex Wegel just picked EXCHANGE out at random as something
> to attack,

Sure i picked it because it's particularly bad: Inlining it breaks and
bloats things for no perceivable gain, and by using the late-binding
macro it can even break later on. That's why i called it a monster.

> because his attack on my late-binding MACRO: fizzled out
> after I wrote an early-binding MACRO: word.

It didn't "fizzle out", but was successful in convincing you to finally
write this early-binding macro, which doesn't have (i suppose) most of
the problems of the old late-binding version.

I do think that getting away from the late-binding scheme was neccessary
for the package to get anywhere - at least this ugliness is gone now.

Rejoice!

[Robert L.]

On 1/2/2017, Coos Haak wrote:

> while >r 2dup over @ over @ >r swap ! r> swap !
> cell+ swap cell+ swap r> 1+

Absolutely unreadable and unmaintainable.
(However, Gavino thinks that it is awesome.)

Anyone who would pay anyone a cent to write code
like that is an idiot.

Forth and its slavish worshippers are execrable.

--
I don't believe in western morality, i.e. don't kill civilians or children....
The only way to fight a moral war is the Jewish way: Destroy their holy sites.
Kill men, women and children (and cattle). --- Rabbi Manis Friedman
web.archive.org/web/20090605154706/http://www.momentmag.com/Exclusive/2009/2009-06/200906-Ask_Rabbis.html
archive.org/download/DavidDukeVideo/TheZionistMatrixOfPowerddhd.ogv

[Anton Ertl]

Alex <al...@rivadpm.com> writes:
>I disagree with the characterisation of "ambiguous condition" as error
>or exception; rather it is an unclassified *state*. It's the ultimate
>"here be dragons".

In some cases it's just that different systems do different things,
and they could not agree (or saw no reason to agree) on a common
behaviour in the standards process. An example is

|An ambiguous condition exists if RECURSE appears in a definition after
|DOES>.

If you want to write a standard program, you will consider this an
error, but if you just want to run on one system and find that your
system does something you want to make use of for this condition, it's
not an error.

Of course, if a particular behaviour is considered useful by a number
of people, it may be a good idea to make it the standard behaviour
rather than just leaving is in limbo as ambiguous condition.

[Ilya Tarasov]

> Sorry, you know nothing about the ANS Forth process. Over a 6-year
> period, with meetings 4x/year, we developed strategy, methodology, and
> worked very hard to ensure operational compatibility with existing
> Forth83 systems and applications while removing constraints (such as the
> 16-bit requirement) to enable implementation freedom with
> application-level stability.

You already post it here, I remember it. When I point to disadvantages of methodology carrying on, Ertl suggest me to write an overview of current situation. This kind of document usually appears as a result of researchers team work, with at least several months of efforts and many drafts. Moreover, single man cannot overview all kinds of programming languages and cannot estimate all applicable area domains. After a proposal to write a document (of 10, 20, 50 pages, heh?) how I can believe you have a proper methodology? If Ertl pretends to be a chairman, he must at least study how these projects are carrying. Less ambitions, more questions to others, including scientists who works in mainstream Computer Science. And forget that Forth is a language for elite only.