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

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

POSTPONE behaviour

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

Contents

  POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-24 21:18 -0800
    Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-24 22:00 -0800
      Re: POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-24 22:15 -0800
        Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-24 22:54 -0800
          Re: POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-24 23:09 -0800
          Re: POSTPONE behaviour Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 08:15 +0100
            Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-24 23:38 -0800
              Re: POSTPONE behaviour Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-25 08:46 +0100
                Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 00:04 -0800
              Re: POSTPONE behaviour rickman <gnuarm@gmail.com> - 2015-11-25 03:01 -0500
                Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 00:09 -0800
                  Re: POSTPONE behaviour rickman <gnuarm@gmail.com> - 2015-11-25 03:23 -0500
                    Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 01:09 -0800
                      Re: POSTPONE behaviour rickman <gnuarm@gmail.com> - 2015-11-25 10:49 -0500
                        Re: POSTPONE behaviour "Elizabeth D. Rather" <erather@forth.com> - 2015-11-25 09:10 -1000
                  Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-25 09:18 +0000
                    Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 02:21 -0800
                      Re: POSTPONE behaviour Mark Wills <markwills1970@gmail.com> - 2015-11-25 02:47 -0800
                      Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-25 13:58 +0000
                        Re: POSTPONE behaviour Mark Wills <markwills1970@gmail.com> - 2015-11-25 06:35 -0800
                          Re: POSTPONE behaviour Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-25 18:45 +0100
                        Re: POSTPONE behaviour Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-11-25 22:11 -0800
                          Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-26 07:42 +0000
                            Re: POSTPONE behaviour "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-26 05:20 -0500
                              Re: POSTPONE behaviour anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-26 16:50 +0000
                              Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-26 17:59 +0000
                                Re: POSTPONE behaviour Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-27 19:07 +0100
                                  Re: POSTPONE behaviour anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-28 11:24 +0000
                      Re: POSTPONE behaviour hughaguilar96@gmail.com - 2015-11-26 12:29 -0800
                        Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-27 09:53 +0000
                          Re: POSTPONE behaviour hughaguilar96@gmail.com - 2015-11-29 21:48 -0800
                            Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-30 12:18 +0000
                              Re: POSTPONE behaviour Lars Brinkhoff <lars.spam@nocrew.org> - 2015-11-30 13:41 +0100
                              Re: POSTPONE behaviour hughaguilar96@gmail.com - 2015-11-30 19:56 -0800
                                Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-01 09:59 +0000
                                  Re: POSTPONE behaviour hughaguilar96@gmail.com - 2015-12-01 22:46 -0800
                                    Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-12-02 07:50 +0000
                Re: POSTPONE behaviour anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-11-25 13:45 +0000
                  Re: POSTPONE behaviour rickman <gnuarm@gmail.com> - 2015-11-25 10:54 -0500
          Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-25 07:39 +0000
            Re: POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-24 23:48 -0800
              Re: POSTPONE behaviour Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-11-25 08:03 +0000
      Re: POSTPONE behaviour Bernd Paysan <bernd.paysan@gmx.de> - 2015-11-25 18:37 +0100
    Re: POSTPONE behaviour "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-11-25 01:27 -0500
      Re: POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-24 22:51 -0800
    Re: POSTPONE behaviour Aliaksei Chapyzhenka <alex.drom@gmail.com> - 2015-11-25 21:19 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#43765

Mark Wills wrote:
> It is, yes. But if it (un-intentionally) leads to portability issues
> due to the standard being too permissive, then further work is needed
> to the standrd to be to be more presciptive.

Yes, and in this case, POSTPONE is actually the solution.  In Forth-83, you 
knew which words were immediate, and which weren't.  There were some 
problems with LEAVE (AFAIK non-immediate in Forth-83, but many systems had 
an immediate LEAVE which just compiled a branch out of the loop).  That 
probably was just a mistake, copied over from Forth-79 (where LEAVE was 
doing something different).

And more problems came later, like EXIT needing to remove the locals and 
things like that.  So the TC decided not to specify which word is immediate 
and which isn't, and in order to still be able to compile these words in 
macros, POSTPONE was added. POSTPONE for non-immediate is equal to Forth-83 
COMPILE, and for immediate is equal to Forth-83 [COMPILE].  So as a result, 
you don't need to know if a system has an immediate LEAVE or IF, it just 
works.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#43799

> When the compiler encounters POSTPONE IF in a definition it doesn't 
> cause the compilation semantics of IF to be executed, it compiles some 
> code that causes the compilation semantics of IF (i.e. IF's special 
> compilation semantics) to be executed when its enclosing definition is 
> called in a later definition.
> 
> When the compiler encounters POSTPONE DROP in a definition it doesn't 
> cause the compilation semantics of DROP to be executed, it compiles some 
> code that causes the compilation semantics of DROP (i.e. default 
> compilation semantics) to be executed when its enclosing definition is 
> called in a later definition.
> 
> Apart from the bit in parentheses and the words IF and DROP, what's the 
>   difference?

The big difference is that postpone postpones the EXECUTION of immediate
words and postpones the COMPILATION of non-immediate words.

Just trying to implement postpone and you will get the big difference.
Postponing EXECUTION of immediate words is very simple, just compile the
word like it is non-immediate. Postponing the COMPILATION of a word is not
like that.

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

#43809

On 26/11/2015 06:11, Raimond Dragomir wrote:
>> When the compiler encounters POSTPONE IF in a definition it doesn't
>> cause the compilation semantics of IF to be executed, it compiles some
>> code that causes the compilation semantics of IF (i.e. IF's special
>> compilation semantics) to be executed when its enclosing definition is
>> called in a later definition.
>>
>> When the compiler encounters POSTPONE DROP in a definition it doesn't
>> cause the compilation semantics of DROP to be executed, it compiles some
>> code that causes the compilation semantics of DROP (i.e. default
>> compilation semantics) to be executed when its enclosing definition is
>> called in a later definition.
>>
>> Apart from the bit in parentheses and the words IF and DROP, what's the
>>    difference?
>
> The big difference is that postpone postpones the EXECUTION of immediate
> words and postpones the COMPILATION of non-immediate words.
>
> Just trying to implement postpone and you will get the big difference.
> Postponing EXECUTION of immediate words is very simple, just compile the
> word like it is non-immediate. Postponing the COMPILATION of a word is not
> like that.
>

That's the system implementer's problem. The user doesn't care when 
postponing words, that's what I'm talking about. Look at Bernd Paysan's 
examples.

-- 
Gerry

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

#43823

On Thu, 26 Nov 2015 02:42:48 -0500, Gerry Jackson <gerry@jackson9000.fsnet.co.uk> wrote:
> On 26/11/2015 06:11, Raimond Dragomir wrote:

>>> When the compiler encounters POSTPONE IF in a definition it doesn't
>>> cause the compilation semantics of IF to be executed, it compiles some
>>> code that causes the compilation semantics of IF (i.e. IF's special
>>> compilation semantics) to be executed when its enclosing definition is
>>> called in a later definition.
>>>
>>> When the compiler encounters POSTPONE DROP in a definition it doesn't
>>> cause the compilation semantics of DROP to be executed, it compiles some
>>> code that causes the compilation semantics of DROP (i.e. default
>>> compilation semantics) to be executed when its enclosing definition is
>>> called in a later definition.
>>>
>>> Apart from the bit in parentheses and the words IF and DROP, what's the
>>>    difference?
>>
>> The big difference is that postpone postpones the EXECUTION of immediate
>> words and postpones the COMPILATION of non-immediate words.
>>
>> Just trying to implement postpone and you will get the big difference.
>> Postponing EXECUTION of immediate words is very simple, just compile the
>> word like it is non-immediate. Postponing the COMPILATION of a word is not
>> like that.
>>
>
> That's the system implementer's problem. The user doesn't care when
> postponing words, that's what I'm talking about. Look at Bernd Paysan's
> examples.
>

Programmers need to understand what something does to use it.
Without understanding immediacy in an interpreted Forth, and
what COMPILE and [COMPILE] do, and seeing an implementation
of POSTPONE, you probably won't grasp that POSTPONE is a
poorly named, universal compile.  How else does someone
grasp the duality of POSTPONE without understanding immediacy?
Without the background, POSTPONE is a magical black box.
If all you know about is POSTPONE , then what would do you do
for the rare few instances where POSTPONE won't work?  I think
the established Forth programmers probably have a solid foundation
to work from based on history, whereas newer programmers don't.


Rod Pemberton


-- 
How to kill Facebook.  Tell a bunch of fourth graders that
only old people use Facebook.  Wait eight years.

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

#43834

"Rod Pemberton" <boo@fasdfrewar.cdm> writes:
>Programmers need to understand what something does to use it.
>Without understanding immediacy in an interpreted Forth, and
>what COMPILE and [COMPILE] do, and seeing an implementation
>of POSTPONE, you probably won't grasp that POSTPONE is a
>poorly named, universal compile.

No, programmers don't need to know the exact hash function used in
order to use a hash table, nor whether the hash table uses external
chaining or open addressing, or whether it's a hash table at all, or
just a linked list.  Programmers can abstract from such implementation
details, when using the lookup table.

They can also abstract from whether a word is implemented as immediate
word when using POSTPONE.  When I write

: bla ... if exit then ... ;

the text interpreter performs the compilation semantics of IF, EXIT,
and THEN, whether EXIT is immediate (as in Gforth 0.7) or not (as in
the current development version of Gforth).

When I want to package these words into a macro ?EXIT, I can do so with

: ?exit 
   postpone if
   postpone exit
   postpone then ; immediate

And that's also independent of whether exit is immediate or not.

>  How else does someone
>grasp the duality of POSTPONE without understanding immediacy?

In the example above, it's unnecessary to understand immediacy; it's
just necessary to understand compilation semantics.

>Without the background, POSTPONE is a magical black box.

Sure, that's the power of abstraction.

>If all you know about is POSTPONE , then what would do you do
>for the rare few instances where POSTPONE won't work?

Such as?

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43836

On 26/11/2015 10:20, Rod Pemberton wrote:
> On Thu, 26 Nov 2015 02:42:48 -0500, Gerry Jackson
> <gerry@jackson9000.fsnet.co.uk> wrote:
>> On 26/11/2015 06:11, Raimond Dragomir wrote:
>
>>>> When the compiler encounters POSTPONE IF in a definition it doesn't
>>>> cause the compilation semantics of IF to be executed, it compiles some
>>>> code that causes the compilation semantics of IF (i.e. IF's special
>>>> compilation semantics) to be executed when its enclosing definition is
>>>> called in a later definition.
>>>>
>>>> When the compiler encounters POSTPONE DROP in a definition it doesn't
>>>> cause the compilation semantics of DROP to be executed, it compiles
>>>> some
>>>> code that causes the compilation semantics of DROP (i.e. default
>>>> compilation semantics) to be executed when its enclosing definition is
>>>> called in a later definition.
>>>>
>>>> Apart from the bit in parentheses and the words IF and DROP, what's the
>>>>    difference?
>>>
>>> The big difference is that postpone postpones the EXECUTION of immediate
>>> words and postpones the COMPILATION of non-immediate words.
>>>
>>> Just trying to implement postpone and you will get the big difference.
>>> Postponing EXECUTION of immediate words is very simple, just compile the
>>> word like it is non-immediate. Postponing the COMPILATION of a word
>>> is not
>>> like that.
>>>
>>
>> That's the system implementer's problem. The user doesn't care when
>> postponing words, that's what I'm talking about. Look at Bernd Paysan's
>> examples.
>>
>
> Programmers need to understand what something does to use it.
> Without understanding immediacy in an interpreted Forth, and
> what COMPILE and [COMPILE] do, and seeing an implementation
> of POSTPONE, you probably won't grasp that POSTPONE is a
> poorly named, universal compile.

I think POSTPONE is a good name as it postpones compilation of a word. 
What else is better? Note that COMPILE and [COMPILE] the first of which 
never made its way into ANS Forth, and the second is designated obsolete 
in Forth 2012.

   How else does someone
> grasp the duality of POSTPONE without understanding immediacy?
> Without the background, POSTPONE is a magical black box.
> If all you know about is POSTPONE , then what would do you do
> for the rare few instances where POSTPONE won't work?

Where doesn't POSTPONE work? Are you referring to the words that cannot 
be POSTPONEd i.e. result in an ambiguous condition. A quick search of 
Forth 2012 gives these as TO ACTION-OF IS [IF] and local names. Sure 
some of these restrictions can be irritating but all but [IF] can't be 
[COMPILE]'d either. I'm rather puzzled why [IF] can't be postponed, it 
seems to in both my system and GForth perhaps Anton can comment.

   I think
> the established Forth programmers probably have a solid foundation
> to work from based on history, whereas newer programmers don't.

That's true of many aspects of Forth and probably other programming 
languages as well.


-- 
Gerry

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

#43876

Gerry Jackson wrote:
> I think POSTPONE is a good name as it postpones compilation of a word.
> What else is better?

COMPILE.  It just says what it does: compile it.  The problem was that in 
the previous standard, COMPILE was defined differently.

But I now think postpone mode (or call it compile mode) ]] ... [[ is even 
better.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#43897

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Gerry Jackson wrote:
>> I think POSTPONE is a good name as it postpones compilation of a word.
>> What else is better?
>
>COMPILE.  It just says what it does: compile it.  The problem was that in 
>the previous standard, COMPILE was defined differently.
>
>But I now think postpone mode (or call it compile mode) ]] ... [[ is even 
>better.

We already have interpret state and compile state; calling the
postpone state "compile mode" would be confusing.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43842

On Wednesday, November 25, 2015 at 3:21:22 AM UTC-7, Raimond Dragomir wrote:
> > I think the ANS standard specification for POSTPONE is precise and 
> > concise - a good thing in a standard. As immediacy is irrelevant it 
> > doesn't have to mention it. The fact that you came to it with 
> > pre-conceived notions about immediacy and misunderstood it is not the 
> > fault of the standard and no reason to blame it.
> > 
> > > As for me personally I don't have a postpone word in my system. It is so
> > > much mis-understood and hard to understand
> > 
> > What's so hard to understand about ... POSTPONE DROP ... in a definition 
> > for example. It simply defers compilation of DROP. Similarly ... 
> > POSTPONE IF ... defers compilation of IF. That seems straightforward enough.
> 
> POSTPONE IF just compiles IF, that's the big difference. The compilation of IF
> is not deffered. OTOH the compilation of DROP is deffered indeed.
> 
> For me these are two entirely different things, that should have been treated
> separately and not under the same umbrella of a word.

In Forth-83 we had COMPILE for postponing non-immediate words and [COMPILE] for postponing immediate words. POSTPONE just checks the word to find out if it is immediate or not (FIND provides this information) and then does COMPILE or [COMPILE] appropriately. A lot of people, including myself, wrote POSTPONE in Forth-83 (it had a variety of names though because there was no standard to give us consistency) --- this was convenient because the programmer didn't have to know if the word was immediate or non-immediate.

Nowadays in ANS-Forth, we don't have COMPILE anymore, but we do have [COMPILE] --- why one but not the other?

Also, ANS-Forth was sabotaged to prevent cross-compilers from being written. In gForth, FIND crashes on some words (such as IF etc.), but in VFX FIND returns an xt for these words and the xt crashes when it is executed. Both systems are considered to be ANS-Forth compliant. Also, words are not defined to be either immediate or non-immediate, but this is left implementation dependent (WTF?) so there isn't any consistency between the systems.

POSTPONE was not sabotaged however! Because of this loophole, it is possible to work-around the sabotage to make ANS-Forth behave consistently from one system to another. This is done with my disambiguifiers:

: if  state @ 0= abort" *** no interpretation semantics for: IF ***"  postpone if  ;  immediate 

If the programmer writes disambiguifiers for all of the special-case words (such as IF etc.) in ANS-Forth, then all ANS-Forth systems will behave consistently. Also, they will behave in a manner that makes sense --- words that were immediate in Forth-83 and in every other Forth system in the world except ANS-Forth, will be immediate in ANS-Forth. 

It really blew my mind when I found IF to be non-immediate in some ANS-Forth systems (VFX) --- the disambiguifiers get rid of this weirdness so everything makes sense again.

In a cross-compiler, you want to write your own outer-interpreter. For this to be done, FIND must work. The disambiguifiers cause FIND to work. The only reason why anybody would want FIND to not work, is because they want to prevent cross-compilers from being written --- MPE and Forth Inc. both make money selling cross-compilers, and they want to prevent the common ANS-Forth programmers from writing their own cross-compilers --- my disambiguifiers defeat MPE and Forth Inc. however, by giving the common ANS-Forth programmer a FIND that works.

> I don't think I have some weird view of immediacy or anything else. I think
> the standard just tries to accomodate EVERY system in the world (including
> those with dual xts, special words (a third species of words that aren't 
> immediate nor non-immediate) and who knows what else). Or if not "every"
> maybe "too many".

I don't think that Raimond has a "weird view of immediacy" --- the concept of immediate and non-immediate words has been in Forth since the very beginning, and it is pretty straightforward (I understood the concept completely when I was 18 years old) --- only ANS-Forth screwed up this simple idea, making it soooooo complicated and baffling that nobody can figure it out --- ANS-Forth makes everything complicated for no purpose, and Forth-200x is an order of magnitude worse.

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

#43858

On 26/11/2015 20:29, hughaguilar96@gmail.com wrote:
> Also, ANS-Forth was sabotaged to prevent cross-compilers from
 > being written.. In gForth, FIND crashes on some words (such as
> IF etc.), but in VFX FIND returns an xt for these words and
> the xt crashes when it is executed. Both systems are considered
> to be ANS-Forth compliant. Also, words are not defined to be
> either immediate or non-immediate, but this is left implementation
> dependent (WTF?) so there isn't any consistency between the systems.
>
> POSTPONE was not sabotaged however! Because of this loophole,
>  it is possible to work-around the sabotage to make ANS-Forth
> behave consistently from one system to another. This is done with
> my disambiguifiers:
>
> : if  state @ 0= abort" *** no interpretation semantics for:
> IF ***"  postpone if  ;  immediate

When I developed my system some 10 years ago I was ignorant of the fact 
that the perpetrators of ANS Forth had sabotaged it so that cross 
compilers couldn't be written in ANS Forth. So I developed my system  in 
ANS Forth as a cross compiler, albeit with the same target as the host, 
without recourse to the anti-sabotage counter measures using POSTPONE 
that you describe and without writing my own outer interpreter. So 
either the saboteurs failed or I have dreamed that my cross compiler 
actually works - it must be the latter.

Thank you for enlightening me, I was so ignorant, please forgive me - I 
live in my dream world so I'll destroy my system before the legions of 
ANS Forth police send out the assassination squads. We cannot be too 
careful!

-- 
Gerry

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

#43956

On Friday, November 27, 2015 at 2:52:54 AM UTC-7, Gerry wrote:
> On 26/11/2015 20:29, hughaguilar96@gmail.com wrote:
> > Also, ANS-Forth was sabotaged to prevent cross-compilers from
>  > being written.. In gForth, FIND crashes on some words (such as
> > IF etc.), but in VFX FIND returns an xt for these words and
> > the xt crashes when it is executed. Both systems are considered
> > to be ANS-Forth compliant. Also, words are not defined to be
> > either immediate or non-immediate, but this is left implementation
> > dependent (WTF?) so there isn't any consistency between the systems.
> >
> > POSTPONE was not sabotaged however! Because of this loophole,
> >  it is possible to work-around the sabotage to make ANS-Forth
> > behave consistently from one system to another. This is done with
> > my disambiguifiers:
> >
> > : if  state @ 0= abort" *** no interpretation semantics for:
> > IF ***"  postpone if  ;  immediate
> 
> When I developed my system some 10 years ago I was ignorant of the fact 
> that the perpetrators of ANS Forth had sabotaged it so that cross 
> compilers couldn't be written in ANS Forth. So I developed my system  in 
> ANS Forth as a cross compiler, albeit with the same target as the host, 
> without recourse to the anti-sabotage counter measures using POSTPONE 
> that you describe and without writing my own outer interpreter. So 
> either the saboteurs failed or I have dreamed that my cross compiler 
> actually works - it must be the latter.
> 
> Thank you for enlightening me, I was so ignorant, please forgive me - I 
> live in my dream world so I'll destroy my system before the legions of 
> ANS Forth police send out the assassination squads. We cannot be too 
> careful!
> 
> -- 
> Gerry

My MFX didn't involve writing my own outer-interpreter --- I used the built-in outer-interpreter. The problem with this technique is that numbers don't work because ?NUMBER isn't vectored and it can't be rewritten to cross-compile numbers rather than do what it normally does with numbers. Because of this MFX required the user to write code like this:

: test [ 123 ] literal ;

or like this (a shortcut that did the same thing):
: test  [ 123 ]L ;

rather than like this:

: test 123 ;

?NUMBER isn't vectored in ANS-Forth (actually, ?NUMBER isn't even defined in ANS-Forth, although it is presumably there as part of the outer-interpreter). Without being able to revector ?NUMBER you have to write your own cross-compiler, but this is problematic because FIND doesn't necessarily work.

You didn't say which ANS-Forth system you used. On some ANS-Forth systems (SwiftForth), FIND does work, but on others (VFX and gForth) FIND does not work, and how it fails is different from VFX to gForth.

You say that you wrote a cross-compiler in ANS-Forth, but it was not ANS-Forth in the sense that it would work under any ANS-Forth compiler --- it was specific to a particular ANS-Forth system --- this is pretty common, that somebody gets a program to work under a particular ANS-Forth system and they think that their program is ANS-Forth, but it actually only works under that system. The ANS-Forth standard is so flexible that almost any Forth system can claim to be ANS-Forth, but programs are not portable between all of these ANS-Forth systems (or even between two of them).

BTW: Since when do you take recourse in sarcasm? Are you turning into a troll now? This business of FIND and tick not working in some ANS-Forth systems, but these systems still be allowed to be considered ANS-Forth, is not defensible --- if you think that you can defend this as being a "feature" then you are going to fail --- this is not a feature; this is blatant sabotage. FIND and tick always worked prior to the ANS-Forth standard --- only ANS-Forth allows them to not work. Also, ?NUMBER should have been defined, and it should have been defined as being vectored so the outer-interpreter could be used but ?NUMBER used by the outer-interpreter changed to cross-compile. 

I think that it is obvious that ANS-Forth was sabotaged to prevent cross-compilers from being written in portable ANS-Forth code --- the ANS-Forth document goes out of its way to prevent this --- some ANS-Forth systems do work around this sabotage however, and you presumably used one of them.

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

#43969

On 30/11/2015 05:48, hughaguilar96@gmail.com wrote:
> On Friday, November 27, 2015 at 2:52:54 AM UTC-7, Gerry wrote:
>> On 26/11/2015 20:29, hughaguilar96@gmail.com wrote:
>>> Also, ANS-Forth was sabotaged to prevent cross-compilers from
>>   > being written.. In gForth, FIND crashes on some words (such as
>>> IF etc.), but in VFX FIND returns an xt for these words and
>>> the xt crashes when it is executed. Both systems are considered
>>> to be ANS-Forth compliant. Also, words are not defined to be
>>> either immediate or non-immediate, but this is left implementation
>>> dependent (WTF?) so there isn't any consistency between the systems.
>>>
>>> POSTPONE was not sabotaged however! Because of this loophole,
>>>   it is possible to work-around the sabotage to make ANS-Forth
>>> behave consistently from one system to another. This is done with
>>> my disambiguifiers:
>>>
>>> : if  state @ 0= abort" *** no interpretation semantics for:
>>> IF ***"  postpone if  ;  immediate
>>
>> When I developed my system some 10 years ago I was ignorant of the fact
>> that the perpetrators of ANS Forth had sabotaged it so that cross
>> compilers couldn't be written in ANS Forth. So I developed my system  in
>> ANS Forth as a cross compiler, albeit with the same target as the host,
>> without recourse to the anti-sabotage counter measures using POSTPONE
>> that you describe and without writing my own outer interpreter. So
>> either the saboteurs failed or I have dreamed that my cross compiler
>> actually works - it must be the latter.
>>
>> Thank you for enlightening me, I was so ignorant, please forgive me - I
>> live in my dream world so I'll destroy my system before the legions of
>> ANS Forth police send out the assassination squads. We cannot be too
>> careful!
>>
>
> My MFX didn't involve writing my own outer-interpreter --- I used the
> built-in outer-interpreter. The problem with this technique is that
> numbers don't work because ?NUMBER isn't vectored and it can't be
> rewritten to cross-compile numbers rather than do what it normally
> does with numbers. Because of this MFX required the user to write
> code like this:
>
> : test [ 123 ] literal ;
>

Yes that's exactly what I did, not nice but usable. Of course if 
recognisers are introduced into the Forth 20XX standard that problem 
will disappear.

> ?NUMBER isn't vectored in ANS-Forth (actually, ?NUMBER isn't even
> defined in ANS-Forth, although it is presumably there as part of
> the outer-interpreter). Without being able to revector ?NUMBER
> you have to write your own cross-compiler, but this is
> problematic because FIND doesn't necessarily work.

No see below.

>
> You didn't say which ANS-Forth system you used. On some ANS-Forth
>systems (SwiftForth), FIND does work, but on others (VFX and gForth)
> FIND does not work, and how it fails is different from VFX to gForth.

I used and continue to use my own system which I claim is ANS Forth in 
the sense that it passes the test suite I maintain, which is more than 
can be said for some other systems I've tested in theh past that claim 
compliance.

Why do you keep on about FIND in the context of cross compilers? My 
outer interpreter, and hence the cross compiler, don't use FIND but a 
factor of it that is used by SEARCH-WORDLIST ' etc.

>
> You say that you wrote a cross-compiler in ANS-Forth, but it was not
> ANS-Forth in the sense that it would work under any ANS-Forth
> compiler

How do you know that?

  --- it was specific to a particular ANS-Forth system ---

or that? An earlier version ran under GForth, I haven't tried it in 
recent years but I see no reason why it wouldn't now, perhaps with a few 
tweaks here and there.

> this is pretty common, that somebody gets a program to work under
> a particular ANS-Forth system and they think that their program
> is ANS-Forth, but it actually only works under that system.
> The ANS-Forth standard is so flexible that almost any Forth
> system can claim to be ANS-Forth, but programs are not portable
> between all of these ANS-Forth systems (or even between two of them).
>

I've written three significant programs (at least to me they are) in 
addition to the cross compiler, four if the test suite is included. Each 
of them has been tested with six Forth systems (including mine) and 
work. I agree you have to work at it and avoid certain pitfalls but it 
is possible and like any techncal discipline becomes much easier with 
practice. I can't say that not being able to tick IF (or any other word 
lacking interpretation semantics) has ever caused me any problems, I've 
never needed to do that. I've wanted to POSTPONE TO which is forbidden 
and found that an irritation.

> BTW: Since when do you take recourse in sarcasm? Are you turning
> into a troll now?

No I hope not. I apologise and shouldn't do it but couldn't resist it in 
this case. You shouldn't keep on about ANS Forth being sabotaged etc so 
that it can't be used for cross-compilers when I know it can.

> This business of FIND and tick not working in some ANS-Forth
> systems, but these systems still be allowed to be considered
>  ANS-Forth, is not defensible

I'm not going to defend FIND, as I pointed out recently in another 
discussion SEARCH-WORDLIST isn't crippled like FIND. FIND should be 
removed from the standard. There are several aspects of ANS Forth I 
dislike, mostly due to having to accomodate legacy systems and to stick 
to Forth traditions. I actually agree with you on several of these issues.

> --- if you think that you can defend
> this as being a "feature" then you are going to fail --- this is
> not a feature; this is blatant sabotage.. FIND and tick always
> worked prior to the ANS-Forth standard --- only ANS-Forth allows
> them to not work. Also, ?NUMBER should have been defined, and it
> should have been defined as being vectored so the outer-interpreter
> could be used but ?NUMBER used by the outer-interpreter changed
> to cross-compile.

As above, recognizers will remove that problem.

>
> I think that it is obviousthat ANS-Forth was sabotaged to prevent
> cross-compilers from being written in portable ANS-Forth code

It's not obvious to me. According to the ANS Forth standard document 
there were 22 people from different organisations listed as being 
members of the Technical Committee developing the standard. In addition 
there are 31 individuals listed as contributing. It is beyond belief 
that they all, or even a mojority, got together and said something like 
"right guys, how are we going to sabotage this standard so that none of 
us can write a cross compiler or write portable programs"
. Also when do more than a few Forth people ever agree on anything 
without a lot of much compromises - hence the number of ambiguous 
conditions?


 > --- the ANS-Forth document goes out of its way to prevent this ---
 > some ANS-Forth systems do work around this sabotage however, and you 
 > presumably used one of them.
 >

No I didn't work around it, I used similar techniques to those described 
in the paper at www.nimblemachines.com/-/XCpaper.pdf. It's called 
designing a cross compiler not working around ANS Forth shortcomings. (I 
predict you'll hate that paper)

-- 
Gerry

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

#43971

Gerry Jackson wrote:
> Hugh Aguilar wrote:
>> My MFX didn't involve writing my own outer-interpreter --- I used the
>> built-in outer-interpreter. The problem with this technique is that
>> numbers don't work because ?NUMBER isn't vectored and it can't be
>> rewritten to cross-compile numbers rather than do what it normally
>> does with numbers. Because of this MFX required the user to write
>> code like this:
>>
>> : test [ 123 ] literal ;
>
> Yes that's exactly what I did, not nice but usable.

A common variation on that is to have d# (and possibly h# etc) which
parses a decimal number and compiles a literal.  E.g.

: test d# 123 ;

Not a vast improvement, but slightly shorter.

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

#43993

On Monday, November 30, 2015 at 5:18:48 AM UTC-7, Gerry wrote:
> On 30/11/2015 05:48, hughaguilar96@gmail.com wrote:
> > My MFX didn't involve writing my own outer-interpreter --- I used the
> > built-in outer-interpreter. The problem with this technique is that
> > numbers don't work because ?NUMBER isn't vectored and it can't be
> > rewritten to cross-compile numbers rather than do what it normally
> > does with numbers. Because of this MFX required the user to write
> > code like this:
> >
> > : test [ 123 ] literal ;
> >
> 
> Yes that's exactly what I did, not nice but usable. Of course if 
> recognisers are introduced into the Forth 20XX standard that problem 
> will disappear.

If ANS-Forth doesn't allow numbers to be used in colon words in a cross-compiler, then ANS-Forth doesn't allow cross-compilers. Duh!

What I had in MFX (that you snipped from my message) was this:

: test [ 123 ]L ;

This resulted in less bloated source-code than this:

: test [ 123 ] literal ;

Either way it is ugly though --- this is not really Forth code at all.

I got away with that ugly solution at Testra in my MFX because those guys were very focused on getting their motion-control program to work and they were willing to use ugly hacks such as this. Also, they used CONSTANT for most constant values, rather than put magic numbers in colon words as literals, so the issue didn't come up very much. I would not consider this to be adequate quality to be made public however. Imagine explaining that to a customer --- you would look like an incompetent clown. You were dreaming when you said that you wrote a cross-compiler in ANS-Forth --- and you will wake up abruptly when your customer sees your ugly hack and says: "You call this a cross-compiler? I want my money back!"

> I'm not going to defend FIND, as I pointed out recently in another 
> discussion SEARCH-WORDLIST isn't crippled like FIND. FIND should be 
> removed from the standard. There are several aspects of ANS Forth I 
> dislike, mostly due to having to accomodate legacy systems and to stick 
> to Forth traditions. I actually agree with you on several of these issues.

We are discussing ANS-Forth, not Forth-200x --- you are dodging the issue when you use Forth-200x words such as SEARCH-WORDLIST to support your claim that ANS-Forth is capable of being used to write a cross-compiler.
 
> > --- if you think that you can defend
> > this as being a "feature" then you are going to fail --- this is
> > not a feature; this is blatant sabotage.. FIND and tick always
> > worked prior to the ANS-Forth standard --- only ANS-Forth allows
> > them to not work. Also, ?NUMBER should have been defined, and it
> > should have been defined as being vectored so the outer-interpreter
> > could be used but ?NUMBER used by the outer-interpreter changed
> > to cross-compile.
> 
> As above, recognizers will remove that problem.

Actually, I don't think that either a vectored NUMBER? (in VFX it is called NUMBER? rather than ?NUMBER and it is vectored) or recognizers will remove that problem. NUMBER? and recognizers just recognize the number and return it, but the number is still getting compiled into the wrong place by the outer-interpreter. What is needed is for LITERAL and COMPILE, to be vectored because they do the compiling (of numbers and xts respectively) --- this way the built-in outer-interpreter (that uses LITERAL and COMPILE, internally) can be used in the cross-compiler.

If the built-in outer-interpreter can't be used in a cross-compiler, then the obvious solution is for the cross-compiler to have its own custom outer-interpreter that uses its own LITERAL and COMPILE, that are vectored. For this to work however, FIND has to work. Anton Ertl has repeatedly and stridently stated that it is legal ANS-Forth to have FIND fail on over 50 of the words in the standard (such as IF etc.), and that gForth is fully ANS-Forth although FIND and tick don't work.

This is why I say that ANS-Forth was sabotaged to prevent cross-compilers from being written in ANS-Forth. There is no good reason for FIND and tick to not work --- this is blatant sabotage.

My disambiguifiers undo the sabotage however! If you use my disambiguifiers, FIND and tick will start working correctly (on any ANS-Forth system), including ANS-Forth systems such as VFX and gForth on which FIND and tick were sabotaged to not work correctly.

Rewrite your cross-compiler to use my disambiguifiers and to use a custom outer-interpreter rather than the built-in outer-interpreter. If you do this, you can get rid of that ugly hack that you described earlier. Finally you will have an actual cross-compiler written in ANS-Forth --- you won't have to fake it anymore.

> > BTW: Since when do you take recourse in sarcasm? Are you turning
> > into a troll now?
> 
> No I hope not. I apologise and shouldn't do it but couldn't resist it in 
> this case. You shouldn't keep on about ANS Forth being sabotaged etc so 
> that it can't be used for cross-compilers when I know it can.

I will accept your apology. I got pretty tired of Passaniti and later Alex McDonald talking to me like that; I wouldn't want you to start.

BTW: I've noticed that Alex McDonald has disappeared. I'm not complaining of course; I'm glad to see the last of him. Elizabeth Rather had Passaniti as her little attack poodle and she praised him to the sky as a Forth programmer, but then Passaniti left. Bernd Paysan had Alex McDonald has his little attack poodle and he praised him to the sky as a Forth programmer (he even let Alex write the RfD for the fake quotations, although it was his "assignment" and he wrote the code), but then Alex left. The Forth-200x committee rely heavily on attack poodles to bite at my ankles and keep me away, but they can't maintain the loyalty of their attack poodles --- maybe they should pay more.

> > I think that it is obvious that ANS-Forth was sabotaged to prevent
> > cross-compilers from being written in portable ANS-Forth code
> 
> It's not obvious to me. According to the ANS Forth standard document 
> there were 22 people from different organisations listed as being 
> members of the Technical Committee developing the standard. In addition 
> there are 31 individuals listed as contributing. It is beyond belief 
> that they all, or even a mojority, got together and said something like 
> "right guys, how are we going to sabotage this standard so that none of 
> us can write a cross compiler or write portable programs"
> . Also when do more than a few Forth people ever agree on anything 
> without a lot of much compromises - hence the number of ambiguous 
> conditions?

Elizabeth Rather is a name-dropper. Examples that I've mentioned before are her claims that she hob-nobs with multiple Nobel Peace Prize winners and hob-nobs with Barrack Obama's family in Hawaii. She habitually claims to have support from people who don't actually support her. She lists Charles Moore and Ray Duncan as supporters of ANS-Forth in the ANS-Forth document --- they don't support ANS-Forth --- I suspect that none of the people listed in the ANS-Forth document as supporters actually support ANS-Forth.

Elizabeth Rather is a name-dropper and a pathological liar --- anybody who believes anything that she says is making a fool out of himself --- the reason why I describe ANS-Forth as a cult is that her followers turn a blind eye to all of their leader's obvious lies, which is the hallmark of a cult (this is called: "drinking the kool-aid").

>  > --- the ANS-Forth document goes out of its way to prevent this ---
>  > some ANS-Forth systems do work around this sabotage however, and you 
>  > presumably used one of them.
>  >
> 
> No I didn't work around it, I used similar techniques to those described 
> in the paper at www.nimblemachines.com/-/XCpaper.pdf. It's called 
> designing a cross compiler not working around ANS Forth shortcomings. (I 
> predict you'll hate that paper)

You obviously did work around the problem of ANS-Forth not supporting cross-compilers that have numbers in colon words --- that is why you don't have numbers in your colon words --- you used the same ugly hack in your cross-compiler that I used in MFX to work around the problem in the Forth standards (ANS-Forth for you and Forth-83 for me).

I won't hate that paper because I won't read it. I've never read anything about Forth cross-compilation and I have no intention of ever doing so --- I figure everything out for myself --- I don't think anybody can teach me anything about Forth.

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

#44002

On 01/12/2015 03:56, hughaguilar96@gmail.com wrote:
> On Monday, November 30, 2015 at 5:18:48 AM UTC-7, Gerry wrote:
>> On 30/11/2015 05:48, hughaguilar96@gmail.com wrote:
>>> My MFX didn't involve writing my own outer-interpreter --- I used the
>>> built-in outer-interpreter. The problem with this technique is that
>>> numbers don't work because ?NUMBER isn't vectored and it can't be
>>> rewritten to cross-compile numbers rather than do what it normally
>>> does with numbers. Because of this MFX required the user to write
>>> code like this:
>>>
>>> : test [ 123 ] literal ;
>>>
>>
>> Yes that's exactly what I did, not nice but usable. Of course if
>> recognisers are introduced into the Forth 20XX standard that problem
>> will disappear.
>
> If ANS-Forth doesn't allow numbers to be used in colon words in a
> cross-compiler, then ANS-Forth doesn't allow cross-compilers. Duh!
>

That's not true. You've moved the goalposts from saying "it can't be 
done in ANS Forth" to "it can't be done in pretty ANS Forth".

> What I had in MFX (that you snipped from my message) was this:
>
> : test [ 123 ]L ;
>
> This resulted in less bloated source-code than this:
>
> : test [ 123 ] literal ;
>
> Either way it is ugly though --- this is not really Forth code at all.
>

Well it looks like valid Forth code to me and Forth compilers. Anyway 
Lars Brinkhoff pointed out an alternative - define a word called D# and 
use e.g.       d# 123
Is that an ugly hack?

> I got away with that ugly solution at Testra in my MFX because those
>  guys were very focused on getting their motion-control program to
> work and they were willing to use ugly hacks such as this. Also,
> they used CONSTANT for most constant values, rather than put magic
> numbers in colon words as literals, so the issue didn't come up very
> much.

Nor for me either, it was just a few single digit numbers where it 
wasn't worth defining a constant which I could have done of course. But 
then you would say that was a workaround even if it did look a bit prettier.

  I would not consider this to be adequate quality to be made
> public however. Imagine explaining that to a customer --- you
> would look like an incompetent clown. You were dreaming when you
> said that you wrote a cross-compiler in ANS-Forth --- and you
> will wake up abruptly when your customer sees your ugly hack
> and says: "You call this a cross-compiler? I want my money back!"

Well as I am my own customer, ...

>
>> I'm not going to defend FIND, as I pointed out recently in another
>> discussion SEARCH-WORDLIST isn't crippled like FIND. FIND should be
>> removed from the standard. There are several aspects of ANS Forth I
>> dislike, mostly due to having to accomodate legacy systems and to stick
>> to Forth traditions. I actually agree with you on several of these issues..
>
> We are discussing ANS-Forth, not Forth-200x --- you are dodging the
> issue when you use Forth-200x words such as SEARCH-WORDLIST to
> support your claim that ANS-Forth is capable of being used to
> write a cross-compiler.

Before you criticise ANS Forth you really ought to know it. 
SEARCH-WORDLIST is in ANS Forth section 16.6.1.2192 and has therefore 
existed since 1994. I expect that you will ignore this if you reply again.

>
>>> --- if you think that you can defend
>>> this as being a "feature" then you are going to fail --- this is
>>> not a feature; this is blatant sabotage.. FIND and tick always
>>> worked prior to the ANS-Forth standard --- only ANS-Forth allows
>>> them to not work. Also, ?NUMBER should have been defined, and it
>>> should have been defined as being vectored so the outer-interpreter
>>> could be used but ?NUMBER used by the outer-interpreter changed
>>> to cross-compile.
>>
>> As above, recognizers will remove that problem.
>
> Actually, I don't think that either a vectored NUMBER? (in VFX it
> is called NUMBER? rather than ?NUMBER and it is vectored) or
> recognizers will remove that problem. NUMBER? and recognizers
> just recognize the number and return it,

That just shows you don't understand or haven't thought about 
recognisers. An integer recogniser would get the integer *and* compile 
it as a literal into the target code. It wouldn't return anything other 
than a 'success' code to the outer interpreter.

> but the number is still
> getting compiled into the wrong place by the outer-interpreter.

No. When target code is being compiled the host doesn't enter 
compilation mode, it searches for the word (the search order is 
acompilation wordlist then a target wordlist - all part of the host 
system). If found it is executed to take the appropriate compiling 
action, if not found then there's an error. So the outer interpreter 
never compiles anything itself into target code, it is permanently in 
interpretation mode once the host system is compiled.

> What is needed is for LITERAL and COMPILE, to be vectored because
> they do the compiling (of numbers and xts respectively)
> --- this way the built-in outer-interpreter (that uses LITERAL
> and COMPILE, internally) can be used in the cross-compiler.

That's another way of doing it.

>
> If the built-in outer-interpreter can't be used in a
> cross-compiler,

It can so the rest of your paragraph is an alternative not necessarily 
the obvious solution, so I've snipped it and the sabotage bit.

> My disambiguifiers undo the sabotage however! If you use my
> disambiguifiers, FIND and tick will start working correctly
> (on any ANS-Forth system), including ANS-Forth systems such
> as VFX and gForth on which FIND and tick were sabotaged to
> not work correctly.
>
> Rewrite your cross-compiler to use my disambiguifiers and
> to use a custom outer-interpreter rather than the built-in
> outer-interpreter. If you do this, you can get rid of that
> ugly hack that you described earlier. Finally you will have
> an actual cross-compiler written in ANS-Forth --- you won't
> have to fake it anymore.
>

Some would regard the disambiguifiers as an ugly hack. By the way once 
you mention Elizabeth Rather and enter into one of your diatribes 
against her I usually stop reading your posts as do most others I 
suspect. Not only are they unnecessarily rude to and about her but 
repetitious and ultimately boring. Please stop doing it.

>>   > --- the ANS-Forth document goes out of its way to prevent this ---
>>   > some ANS-Forth systems do work around this sabotage however, and you
>>   > presumably used one of them.
>>   >
>>
>> No I didn't work around it, I used similar techniques to those described
>> in the paper at www.nimblemachines.com/-/XCpaper.pdf. It's called
>> designing a cross compiler not working around ANS Forth shortcomings. (I
>> predict you'll hate that paper)
>
> You obviously did work around the problem of ANS-Forth not supporting
> cross-compilers that have numbers in colon words --- that is why you
> don't have numbers in your colon words --- you used the same ugly hack
> in your cross-compiler that I used in MFX to work around the problem
> in the Forth standards (ANS-Forth for you and Forth-83 for me).
>
> I won't hate that paper because I won't read it.

You will if you look at the title page.

> I've never read
> anything about Forth cross-compilation and I have no intention of
> ever doing so --- I figure everything out for myself --- I don't
> think anybody can teach me anything about Forth.
>

Well then my explanations above were a waste of time.


-- 
Gerry

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

#44035

On Tuesday, December 1, 2015 at 2:59:03 AM UTC-7, Gerry wrote:
> On 01/12/2015 03:56, hughaguilar96@gmail.com wrote:
> > If ANS-Forth doesn't allow numbers to be used in colon words in a
> > cross-compiler, then ANS-Forth doesn't allow cross-compilers. Duh!
> 
> That's not true. You've moved the goalposts from saying "it can't be 
> done in ANS Forth" to "it can't be done in pretty ANS Forth".
> 
> > What I had in MFX (that you snipped from my message) was this:
> >
> > : test [ 123 ]L ;
> >
> > This resulted in less bloated source-code than this:
> >
> > : test [ 123 ] literal ;
> >
> > Either way it is ugly though --- this is not really Forth code at all.
> >
> 
> Well it looks like valid Forth code to me and Forth compilers. Anyway 
> Lars Brinkhoff pointed out an alternative - define a word called D# and 
> use e.g.       d# 123
> Is that an ugly hack?

Yes, that is an ugly hack! This is Forth code:

: test 123 ;

If you can't do this in ANS-Forth, and you can't, then ANS-Forth doesn't support cross-compiling. You can't take an arbitrary Forth program and compile it under the cross-compiler because it will fail if there are any literal numbers used anywhere, and nobody writing a Forth program would have expected that numbers would be problematic, so there are likely to be numbers in the program.

Imagine if somebody wrote a C cross-compiler and then said: "This is a C compiler, except that numbers aren't allowed." How many customers would he have? None! His cross-compiler would be taken as a joke.

I was well aware of this problem in Forth-83 when I wrote MFX. I considered what I did to be an ugly hack. I expected a new standard to fix the problem, but ANS-Forth was no better than Forth-83. Now, 20 years later you have decided that the solution is to remain 100% faithful to ANS-Forth, but to claim that what was an ugly hack 20 years ago is now perfectly adequate, and that all legacy code that contains numbers needs to be rewritten to use some ugly hack for representing numbers so it will compile under a cross-compiler.

I don't understand why people feel compelled to be faithful to ANS-Forth. What has ANS-Forth ever done for the Forth community? Nothing! I knew that ANS-Forth was a failure way back in the late 1990s when I bought SwiftForth and saw how bad it was. What is the purpose of leaving ANS-Forth floating for 20 years? Why not just press the flush lever and get rid of it?

> > I got away with that ugly solution at Testra in my MFX because those
> >  guys were very focused on getting their motion-control program to
> > work and they were willing to use ugly hacks such as this. Also,
> > they used CONSTANT for most constant values, rather than put magic
> > numbers in colon words as literals, so the issue didn't come up very
> > much.
> 
> Nor for me either, it was just a few single digit numbers where it 
> wasn't worth defining a constant which I could have done of course. But 
> then you would say that was a workaround even if it did look a bit prettier.
> 
>   I would not consider this to be adequate quality to be made
> > public however. Imagine explaining that to a customer --- you
> > would look like an incompetent clown. You were dreaming when you
> > said that you wrote a cross-compiler in ANS-Forth --- and you
> > will wake up abruptly when your customer sees your ugly hack
> > and says: "You call this a cross-compiler? I want my money back!"
> 
> Well as I am my own customer, ...
> 
> >
> >> I'm not going to defend FIND, as I pointed out recently in another
> >> discussion SEARCH-WORDLIST isn't crippled like FIND. FIND should be
> >> removed from the standard. There are several aspects of ANS Forth I
> >> dislike, mostly due to having to accomodate legacy systems and to stick
> >> to Forth traditions. I actually agree with you on several of these issues..
> >
> > We are discussing ANS-Forth, not Forth-200x --- you are dodging the
> > issue when you use Forth-200x words such as SEARCH-WORDLIST to
> > support your claim that ANS-Forth is capable of being used to
> > write a cross-compiler.
> 
> Before you criticise ANS Forth you really ought to know it. 
> SEARCH-WORDLIST is in ANS Forth section 16.6.1.2192 and has therefore 
> existed since 1994. I expect that you will ignore this if you reply again.

Okay, I looked it up and it is in ANS-Forth (I was mixing this up with TRAVERSE-WORDLIST). I actually already know about ANS-Forth wordlists because I had to fix them. See this thread (Ray Duncan describes ANS-Forth's wordlists as being "brain damaged" and I provide code to make them work in a way that is usable):
https://groups.google.com/forum/#!topic/comp.lang.forth/olO-VHXJa1Q%5B1-25%5D

Anyway, what makes you think that SEARCH-WORDLIST is not sabotaged? The ANS-Forth document (section 4.1.2) defines an ambiguous condition as: 
"attempting to obtain the execution token, (e.g., with 6.1.0070 ', 6.1.1550 FIND, etc.) of a definition with undefined interpretation semantics."
I think the "etc." includes SEARCH-WORDLIST. An ANS-Forth compiler could make SEARCH-WORDLIST fail on IF and the other special-case words and it would still be ANS-Forth --- you would be denounced by Anton Ertl for being wrong to believe that it is possible to obtain the execution token of IF and the other special-case words (just has he denounced me for being wrong to believ that FIND or tick could be used to obtain execution tokens).

> > Actually, I don't think that either a vectored NUMBER? (in VFX it
> > is called NUMBER? rather than ?NUMBER and it is vectored) or
> > recognizers will remove that problem. NUMBER? and recognizers
> > just recognize the number and return it,
> 
> That just shows you don't understand or haven't thought about 
> recognisers. An integer recogniser would get the integer *and* compile 
> it as a literal into the target code. It wouldn't return anything other 
> than a 'success' code to the outer interpreter.
> 
> > but the number is still
> > getting compiled into the wrong place by the outer-interpreter.
> 
> No. When target code is being compiled the host doesn't enter 
> compilation mode, it searches for the word (the search order is 
> acompilation wordlist then a target wordlist - all part of the host 
> system). If found it is executed to take the appropriate compiling 
> action, if not found then there's an error. So the outer interpreter 
> never compiles anything itself into target code, it is permanently in 
> interpretation mode once the host system is compiled.

Why are they called "recognizers" if they compile code? I wouldn't have expected that. If they do compile code though, then they can be used in a cross-compiler where the issue is that they have to compile into the target processor's memory-image rather than into the host processor's code memory.

This is definitely Forth-200x though, not ANS-Forth --- so, you are using Forth-200x to defend ANS-Forth.

> > What is needed is for LITERAL and COMPILE, to be vectored because
> > they do the compiling (of numbers and xts respectively)
> > --- this way the built-in outer-interpreter (that uses LITERAL
> > and COMPILE, internally) can be used in the cross-compiler.
> 
> That's another way of doing it.
> 
> >
> > If the built-in outer-interpreter can't be used in a
> > cross-compiler,
> 
> It can so the rest of your paragraph is an alternative not necessarily 
> the obvious solution, so I've snipped it and the sabotage bit.

I know the built-in outer-interpreter can be used in a cross-compiler, because that is how MFX worked 20 years ago. But it can't be used in a cross-compiler that supports numbers, so it is not much of a cross-compiler.
 
> > My disambiguifiers undo the sabotage however! If you use my
> > disambiguifiers, FIND and tick will start working correctly
> > (on any ANS-Forth system), including ANS-Forth systems such
> > as VFX and gForth on which FIND and tick were sabotaged to
> > not work correctly.
> >
> > Rewrite your cross-compiler to use my disambiguifiers and
> > to use a custom outer-interpreter rather than the built-in
> > outer-interpreter. If you do this, you can get rid of that
> > ugly hack that you described earlier. Finally you will have
> > an actual cross-compiler written in ANS-Forth --- you won't
> > have to fake it anymore.
> >
> 
> Some would regard the disambiguifiers as an ugly hack. 

That makes no sense! The disambiguifiers are part of the cross-compiler, so the user doesn't have to write them. All the user needs to know is that FIND and tick suddenly begin to work in the way that they should work.

By comparison, it is an ugly hack to force the user to write code like this:

: test [ 123 ] literal ;

or like this:

: test s# 123 ;

This dumps the failure of ANS-Forth directly into the user's lap --- makes it his problem.

> By the way once 
> you mention Elizabeth Rather and enter into one of your diatribes 
> against her I usually stop reading your posts as do most others I 
> suspect. Not only are they unnecessarily rude to and about her but 
> repetitious and ultimately boring. Please stop doing it.

Elizabeth Rather says that I'm not a Forth programmer, and she says that MFX didn't work. She will never back down from this. As far as she is concerned, she dismissed me from the Forth community in 2009 and that was that. When you say, "Please stop doing it," what you are saying is "Please stop programming in Forth." --- this is what Elizabeth Rather effectively said in 2009 and any support for Elizabeth Rather from you or anybody else is support for this --- I either have to quit programming in Forth, or continue pointing out that Elizabeth Rather is a salesperson not a programmer, but there is no other way for me to be a Forth programmer because she and I can't both be Forth programmers after she has said that I'm not a Forth programmer. I'm never going to quit programming in Forth --- Forth is something that I care about --- do you want me to quit programming in Forth? Passaniti repeatedly said that there was no alternative for me except to quit programming in Forth because Elizabeth Rather's decision was final, but now he is gone, so apparently he didn't care very much about Forth and just quit (or, more likely, Elizabeth Rather stopped paying him after Jeff Fox died because harassing Jeff Fox was his primary purpose).

Why do you get to claim to be a cross-compiler writer, but I don't? As far as I can tell, our cross-compilers both used the same ugly hack for numbers, so they are pretty comparable. Are you telling me that MFX wasn't a cross-compiler because it didn't support numbers except with an ugly hack? If so, you wouldn't be the first to say that.

> > I've never read
> > anything about Forth cross-compilation and I have no intention of
> > ever doing so --- I figure everything out for myself --- I don't
> > think anybody can teach me anything about Forth.
> 
> Well then my explanations above were a waste of time.

You didn't explain anything to me that I wasn't well aware of in 1994. ANS-Forth is no better than Forth-83 that I used to write MFX in 1994/1995 --- ANS-Forth is worse, because FIND and tick don't work in ANS-Forth, whereas they did work in Forth-83.

This sounds a lot like Stephen Pelc telling me to RTFM in regard to SYNONYM --- but he failed to write SYNONYM in ANS-Forth, whereas I succeeded --- now, about a year later, we have Bernd Paysan saying that SYNONYM can't be written in ANS-Forth, although he is well aware that I succeeded using my disambiguifiers.

I'm really sick of the Forth-200x committee --- all they do is tell Forth programmers what they can't do --- and they insult everybody by saying that they are the teachers and we are the grasshopper that must learn from them.

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

#44037

On 02/12/2015 06:46, hughaguilar96@gmail.com wrote:
> On Tuesday, December 1, 2015 at 2:59:03 AM UTC-7, Gerry wrote:
>> On 01/12/2015 03:56, hughaguilar96@gmail.com wrote:
>>> If ANS-Forth doesn't allow numbers to be used in colon words in a
>>> cross-compiler, then ANS-Forth doesn't allow cross-compilers. Duh!
>>
>> That's not true. You've moved the goalposts from saying "it can't be
>> done in ANS Forth" to "it can't be done in pretty ANS Forth".
>>
>>> What I had in MFX (that you snipped from my message) was this:
>>>
>>> : test [ 123 ]L ;
>>>
>>> This resulted in less bloated source-code than this:
>>>
>>> : test [ 123 ] literal ;
>>>
>>> Either way it is ugly though --- this is not really Forth code at all.
>>>
>>
>> Well it looks like valid Forth code to me and Forth compilers. Anyway
>> Lars Brinkhoff pointed out an alternative - define a word called D# and
>> use e.g.       d# 123
>> Is that an ugly hack?
>
> Yes, that is an ugly hack! This is Forth code:
>
> : test 123 ;
>

I see no point in continuing this discussion. Neither of us will 
convince the other.

[...]

>> By the way once
>> you mention Elizabeth Rather and enter into one of your diatribes
>> against her I usually stop reading your posts as do most others I
>> suspect. Not only are they unnecessarily rude to and about her but
>> repetitious and ultimately boring. Please stop doing it.
>
> Elizabeth Rather

I stopped reading here because I know a rant will follow.


-- 
Gerry

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

#43756

rickman <gnuarm@gmail.com> writes:
>On 11/25/2015 2:38 AM, Raimond Dragomir wrote:
>> miercuri, 25 noiembrie 2015, 09:15:35 UTC+2, Lars Brinkhoff a scris:
>>> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>>>>> But failing in this case:
>>>>> T{ : GT1 123 ; -> }T
>>>>> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
>>>>> T{ : GT5 GT4 ; -> }T
>>>>> T{ GT5 -> 123 }T
>>>>
>>>> Well, think about it: GT4 is immediate. It is executed directly when
>>>> you define GT5. When executed it will call GT1 which leaves 123 on the
>>>> data stack.
>>>
>>> No, in an ANS Forth, GT4 should not call GT1.
>>
>> And do what else?
>> GT4 has GT1 compiled in it. When GT4 is executed, it executes GT1.
>> When GT4 is executed (not compiled). And this happens when GT5 is defined
>> because GT4 is immediate.
>
>This wasn't clear to me until I read these sections of the standard... 
>well, the 2012 standard.  Is any of this different from the 94 standard 
>that seems to be the one under discussion?

The 2012 standard is the same in these areas, but what Raimond
Dragomir writes here is wrong.

>6.1.2033 POSTPONE CORE
>Interpretation: Interpretation semantics for this word are undefined.
>Compilation: ( “(spaces)name” -- )
>Skip leading space delimiters. Parse name delimited by a space. Find 
>name. Append the compilation semantics of name to the current 
>definition. An ambiguous condition exists if name is not found.
>
>3.4.3.3 Compilation semantics
>Unless otherwise specified in a “ Compilation: ” section of the glossary 
>entry, the compilation semantics of a Forth definition shall be to 
>append its execution semantics to the execution semantics of the current 
>definition.
>
>So postponing a word that is not immediate does nothing special, right? 
>  In essence, for a non-immediate word POSTPONE is a noop.

Wrong.

GT1 is a word with default compilation semantics (i.e., you get them
from Section 3.4.3.3 cited above.  POSTPONE GT1 appends the
*compilation* semantics of GT1 to GT4, whereas just writing GT1 would
append the *execution* semantics of GT1 to GT4.  Or, in other words,
POSTPONE GT1 appends the appending of the execution semantics of GT1
to GT4.  When GT4 is performed in the next line, it appends the
execution semantics of GT1 to GT5.  And when GT5 is performed in the
next line, it performs the execution semantics of GT1 and pushes 123
on the stack.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#43760

On 11/25/2015 8:45 AM, Anton Ertl wrote:
> rickman <gnuarm@gmail.com> writes:
>> On 11/25/2015 2:38 AM, Raimond Dragomir wrote:
>>> miercuri, 25 noiembrie 2015, 09:15:35 UTC+2, Lars Brinkhoff a scris:
>>>> Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>>>>>> But failing in this case:
>>>>>> T{ : GT1 123 ; -> }T
>>>>>> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
>>>>>> T{ : GT5 GT4 ; -> }T
>>>>>> T{ GT5 -> 123 }T
>>>>>
>>>>> Well, think about it: GT4 is immediate. It is executed directly when
>>>>> you define GT5. When executed it will call GT1 which leaves 123 on the
>>>>> data stack.
>>>>
>>>> No, in an ANS Forth, GT4 should not call GT1.
>>>
>>> And do what else?
>>> GT4 has GT1 compiled in it. When GT4 is executed, it executes GT1.
>>> When GT4 is executed (not compiled). And this happens when GT5 is defined
>>> because GT4 is immediate.
>>
>> This wasn't clear to me until I read these sections of the standard...
>> well, the 2012 standard.  Is any of this different from the 94 standard
>> that seems to be the one under discussion?
>
> The 2012 standard is the same in these areas, but what Raimond
> Dragomir writes here is wrong.
>
>> 6.1.2033 POSTPONE CORE
>> Interpretation: Interpretation semantics for this word are undefined.
>> Compilation: ( “(spaces)name” -- )
>> Skip leading space delimiters. Parse name delimited by a space. Find
>> name. Append the compilation semantics of name to the current
>> definition. An ambiguous condition exists if name is not found.
>>
>> 3.4.3.3 Compilation semantics
>> Unless otherwise specified in a “ Compilation: ” section of the glossary
>> entry, the compilation semantics of a Forth definition shall be to
>> append its execution semantics to the execution semantics of the current
>> definition.
>>
>> So postponing a word that is not immediate does nothing special, right?
>>   In essence, for a non-immediate word POSTPONE is a noop.
>
> Wrong.
>
> GT1 is a word with default compilation semantics (i.e., you get them
> from Section 3.4.3.3 cited above.  POSTPONE GT1 appends the
> *compilation* semantics of GT1 to GT4, whereas just writing GT1 would
> append the *execution* semantics of GT1 to GT4.  Or, in other words,
> POSTPONE GT1 appends the appending of the execution semantics of GT1
> to GT4.  When GT4 is performed in the next line, it appends the
> execution semantics of GT1 to GT5.  And when GT5 is performed in the
> next line, it performs the execution semantics of GT1 and pushes 123
> on the stack.

Yes, on rereading the standard along with the various comments I get 
that now.  Thanks.  The whole thing is a bit trippy really.

If GT1 is postponed into a non-immediate work the compilation of GT1 is 
delayed until one of these words is actually executed.  One of those 
mind expanding things about Forth.  I think I've seen this and not fully 
understood it before.  I need to hang out here more often.  lol

-- 

Rick

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

#43735

On 25/11/2015 06:54, Raimond Dragomir wrote:
>> But failing in this case:
>> T{ : GT1 123 ; -> }T
>> T{ : GT4 POSTPONE GT1 ; IMMEDIATE -> }T
>> T{ : GT5 GT4 ; -> }T
>> T{ GT5 -> 123 }T
>
> Well, think about it: GT4 is immediate. It is executed directly when you
> define GT5. When executed it will call GT1 which leaves 123 on the data stack.
>
> So you already have 123 on the stack after GT5 definition.
> Also, GT5 body is just a nop, because you compiled nothing (GT4 just
> executed at compile time).
> So when you lastly execute GT5 it will leave nothing (but you expect 123)
>
> Hope it helps
>
No, you're wrong. If you try it in GForth

: GT1 123 ;  ok
: GT4 POSTPONE GT1 ; IMMEDIATE  ok
: GT5 GT4 ;  ok
gt5 . 123  ok
see gt5
: GT5
   GT1 ; ok

GT4 compiles GT1 into the definition of GT5

 From your other post:

 > If the word postponed is not immediate, then postpone is redundant.
 > .... FOO ... and
 > .... POSTPONE FOO ... is the same thing if the FOO is not immediate.

is wrong too, POSTPONE is used for macros e.g.

: RDROP POSTPONE R> POSTPONE DROP ;
: FOO RDROP ;  ok
see RDROP
: RDROP  [']
   r> >comp ['] drop >comp ; immediate ok
see FOO
: FOO
   r> drop ; ok

Read the ANS spec for POSTPONE carefully

-- 
Gerry

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web