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

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

State and the standard ...

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

Contents

  State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-02-28 11:35 -0500
    Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 20:46 -0500
      Re: State and the standard ... Elizabeth D Rather <erather@forth.com> - 2013-03-01 19:33 -1000
      Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-02 03:33 -0600
        Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-03 18:09 -0500
          Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-03 15:01 -1000
          Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 03:06 -0600
          Re: State and the standard ... Lars Brinkhoff <lars.spam@nocrew.org> - 2013-03-04 11:38 +0100
    Re: State and the standard ... stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-02 11:34 +0000
      Re: State and the standard ... "A. K." <akk@nospam.org> - 2013-03-02 13:47 +0100
      Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-02 14:07 +0100
      Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-02 12:38 -0500
        Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-02 15:50 -0600
          Re: State and the standard ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-02 22:11 +0000
            Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-03 02:51 +0100
              Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:56 +0000
                Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-03 22:42 +0100
                  Re: State and the standard ... stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-03 22:02 +0000
                  Re: State and the standard ... Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-04 00:19 -0800
                    Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-05 00:14 +0100
                    Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 16:34 +0000
                  Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-07 18:04 +0000
                    Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-08 01:31 +0100
                      Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 14:41 +0000
                        Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-09 17:04 +0100
                    Re: State and the standard ... Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-08 02:19 -0800
                      Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 04:25 -0600
                        Re: State and the standard ... Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-08 03:35 -0800
                          Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 06:58 -0600
                      Re: State and the standard ... Coos Haak <chforth@hccnet.nl> - 2013-03-08 20:57 +0100
            Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-03 11:25 -0500
              Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-03 15:13 -0600
                Re: State and the standard ... Coos Haak <chforth@hccnet.nl> - 2013-03-04 20:55 +0100
                  Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 15:17 -0600
                    Re: State and the standard ... Coos Haak <chforth@hccnet.nl> - 2013-03-05 00:27 +0100
                      Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 18:41 -0600
                        Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-04 20:49 -0500
                          Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-05 02:59 -0600
                            Re: State and the standard ... Alex McDonald <blog@rivadpm.com> - 2013-03-05 06:58 -0800
        Re: State and the standard ... Howerd <howerdo@yahoo.co.uk> - 2013-03-02 14:50 -0800
          Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-03 11:06 -0500
        Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:17 +0000
      Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 17:55 +0000
        Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-02 20:24 +0100
          Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:25 +0000
          Re: State and the standard ... Lars Brinkhoff <lars.spam@nocrew.org> - 2013-03-03 16:27 +0100
            Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-03 15:15 -0600
              Re: State and the standard ... Howerd <howerdo@yahoo.co.uk> - 2013-03-03 13:41 -0800
                Re: State and the standard ... Paul Rubin <no.email@nospam.invalid> - 2013-03-10 00:51 -0800
                  Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-10 04:35 -0500
                    Re: State and the standard ... Paul Rubin <no.email@nospam.invalid> - 2013-03-10 20:56 -0700
                      Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-11 03:47 -0500
                        Re: State and the standard ... Paul Rubin <no.email@nospam.invalid> - 2013-03-13 23:48 -0700
                          Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-13 21:01 -1000
                            Re: State and the standard ... Paul Rubin <no.email@nospam.invalid> - 2013-03-14 00:23 -0700
                            Re: State and the standard ... Lars Brinkhoff <lars.spam@nocrew.org> - 2013-03-14 09:18 +0100
                            Re: State and the standard ... Lars Brinkhoff <lars.spam@nocrew.org> - 2013-11-21 14:26 +0100
                          Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-14 03:34 -0500
                          Re: State and the standard ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-14 11:25 +0000
                      Re: State and the standard ... Mark Wills <forthfreak@gmail.com> - 2013-03-11 01:51 -0700
                  Re: State and the standard ... Howerd <howerdo@yahoo.co.uk> - 2013-03-10 03:03 -0700
              Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-07 18:00 +0000
            Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-03 22:49 +0100
              Re: State and the standard ... "A. K." <akk@nospam.org> - 2013-03-05 00:18 +0100
                Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 18:44 -0600
            intelligent COMPILE, and smart COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-04 17:52 +0000
              Re: intelligent COMPILE, and smart COMPILE, Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-05 00:49 +0100
                Re: intelligent COMPILE, and smart COMPILE, stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-05 10:55 +0000
        Re: State and the standard ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-02 22:22 +0000
    Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 17:37 +0000
      Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-03 18:08 -0500
        Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 16:26 +0000
    Re: State and the standard ... Michael L Gassanenko <m_l_g3@yahoo.com> - 2013-03-04 23:08 -0800
      Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-05 10:47 -0500
        Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-05 08:11 -1000
          Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-05 13:44 -0500
            Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-05 09:26 -1000
              Re: State and the standard ... Michael L Gassanenko <m_l_g3@yahoo.com> - 2013-03-07 04:24 -0800
                Re: State and the standard ... Doug Hoffman <glidedog@gmail.com> - 2013-03-07 09:42 -0500
                Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-07 08:16 -1000
                  Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:14 +0000
                    Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-08 08:57 -1000
                      Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-09 17:31 +0100
                        Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-09 12:28 -0600
                          Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-09 21:41 +0100
            Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-06 17:51 -0500
              Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 13:13 -1000
          Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-06 17:51 -0500
            Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 13:12 -1000
        Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-05 18:18 -0600
          Re: State and the standard ... Brad Eckert <hwfwguy@gmail.com> - 2013-03-06 08:22 -0800
        Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-06 17:49 -0500
          Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-06 17:56 -0500
          Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-06 18:17 -0500
            Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-08 04:22 -0500

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

#20211

On Sat, 2 Mar 2013, Howerd wrote:

> Hi Rob,
>
>> ... an alternative implementation where such differentiation is
>> unnecessary and all words simply do the right thing in any context???
> I think colorForth is just such an implementation :-)
>
> Best regards,
> Howerd

count on Chuck to get it right 8-)

Cheers,
Rob.

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

#20205

Rob Sciuk <rob@controlq.com> writes:
>Take the word ascii, which looks ahead to the next word on the input 
>stream and pushes the value of the ascii character to the stack.  To work 
>properly in a compilation, it must be immediate, and aware of state, and 
>in addition to its runtime semantics, must also compile the (literal) 
>runtime semantics, along with the constant.  My implementation looks like 
>this:
>
>void ascii(){
>   Str_t p ;
>
>   word() ;
>   p = (Str_t) pop() ;
>   push( (Cell_t) *p ) ;
>   if( state == state_Compiling ){
>     push( (Cell_t) lookup( "(literal)" ) ) ;
>     comma();
>     comma();
>   }
>}
>
>And it behaves as expected ...

Try:

: execute1 ] execute postpone [ ;

' char execute a .
' char execute1 a .

' ascii execute a .
' ascii execute1 a .

Does ASCII really behave as expected?

More importantly, can it be used without too many worries in a
reliable program?  I don't think so.

- 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 2013: http://www.euroforth.org/ef13/

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

#20184

stephenXXX@mpeforth.com (Stephen Pelc) writes:
>: (.")          \ --
>\ Runtime action of ."
>  r> count  2dup + aligned >r  type
>;
>
>: ."            \ "ccc<quote>"  --
>\ Output the text up to the closing double-quotes character.
>  [char] " word $.
>;
>comp: ( xt -- )  drop  ['] (.") compile,  ",  ;
>
>Note that ." is not IMMEDIATE - it just has separate interpretation
>and compilation behaviours. The problem is just to standardise the
>notation.

A notation for defining combined words is certainly an improvement
over STATE-smart words, and if we cannot reach consensus on anything
better, we should go for that.

However, I wonder whether the problem should not be attacked at a
different level, by providing an attractive alternative to parsting
words (e.g., through recognizers); admittedly that would only solve
the problem for parsing words, not for control-flow words.  But
parsing words seems to be the most common cause for STATE-smartness,
people seem to be more ready to accept the difference between
interpretation and compilation for control-flow (or maybe it's just
because that's harder to implement).

- 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 2013: http://www.euroforth.org/ef13/

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

#20186

Anton Ertl wrote:
> A notation for defining combined words is certainly an improvement
> over STATE-smart words, and if we cannot reach consensus on anything
> better, we should go for that.
> 
> However, I wonder whether the problem should not be attacked at a
> different level, by providing an attractive alternative to parsting
> words (e.g., through recognizers); admittedly that would only solve
> the problem for parsing words, not for control-flow words.  But
> parsing words seems to be the most common cause for STATE-smartness,
> people seem to be more ready to accept the difference between
> interpretation and compilation for control-flow (or maybe it's just
> because that's harder to implement).

Is it really harder to implement?  We have a whole bunch of interactive 
control flow structures in Gforth, all with [] around their names.

They would work just as well if they were "smart" IFs and THENs.

IMHO, state+immediate was an ad hoc solution for this kind of problem, and 
it turned out to be a bit too simple, and even Chuck realized that.  The 
next approach at solving this problems was cmForth with different 
vocabularies for compilation and interpretation, and it again is too simple.  
Your approach was dual-Xts for these special compilation semantics, and it 
had some similar deficits.  The next approach is smart compile, and the only 
issue it has are compatibility problems with the state+immediate approach 
(it can't model the deficiencies, and for some applications, bugs are 
actually features ;-), so a Forth like VFX or Gforth 0.8 system needs to 
support both.

Chucks pretty much sidestepped the problem in ColorForth, where the colors 
are the only tokens which parse, and everything else has a more passive 
role.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

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

#20206

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> A notation for defining combined words is certainly an improvement
>> over STATE-smart words, and if we cannot reach consensus on anything
>> better, we should go for that.
>> 
>> However, I wonder whether the problem should not be attacked at a
>> different level, by providing an attractive alternative to parsting
>> words (e.g., through recognizers); admittedly that would only solve
>> the problem for parsing words, not for control-flow words.  But
>> parsing words seems to be the most common cause for STATE-smartness,
>> people seem to be more ready to accept the difference between
>> interpretation and compilation for control-flow (or maybe it's just
>> because that's harder to implement).
>
>Is it really harder to implement?  We have a whole bunch of interactive 
>control flow structures in Gforth, all with [] around their names.

Take a look how they are implemented (and what would be necessary for
portability) and then compare it to something like ASCII.  Yes, it's
harder.

>The 
>next approach at solving this problems was cmForth with different 
>vocabularies for compilation and interpretation, and it again is too simple.  

I think it's ok.  It just does not combine well with the search order.
Why do you think it's too simple?

>Your approach was dual-Xts for these special compilation semantics, and it 
>had some similar deficits.

It combines well with the search order.  What "similar deficits" do
you have in mind?

- 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 2013: http://www.euroforth.org/ef13/

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

#20210

Bernd Paysan wrote:
> IMHO, state+immediate was an ad hoc solution [...], and it turned
> out to be a bit too simple, and even Chuck realized that.  The next
> approach at solving this problems was cmForth with different
> vocabularies for compilation and interpretation, and it again is too
> simple.

What is the problem with the cmForth approach?

> [...] The next approach is smart compile, and the only issue it has
> are compatibility problems with the state+immediate approach

How does smart compile (or compile,) work?

(I'm trying to find the answers by searching previous comp.lang.forth
discussions, but it's not easy.)

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

#20217

Lars Brinkhoff <lars.spam@nocrew.org> wrote:
> Bernd Paysan wrote:
>> IMHO, state+immediate was an ad hoc solution [...], and it turned
>> out to be a bit too simple, and even Chuck realized that.  The next
>> approach at solving this problems was cmForth with different
>> vocabularies for compilation and interpretation, and it again is too
>> simple.
> 
> What is the problem with the cmForth approach?

If you define X where there is a previous IMMEDIATE defintion of X,
your new definition of X is not found in compilation state.  This is a
nasty bug: you't be expected to know that some previous code has
defined X in this way.

Andrew.

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

#20218

On Sunday, March 3, 2013 10:15:26 PM UTC+1, Andrew Haley wrote:
> Lars Brinkhoff <lars.spam@nocrew.org> wrote:
> 
> > Bernd Paysan wrote:
> 
> >> IMHO, state+immediate was an ad hoc solution [...], and it turned
> 
> >> out to be a bit too simple, and even Chuck realized that.  The next
> 
> >> approach at solving this problems was cmForth with different
> 
> >> vocabularies for compilation and interpretation, and it again is too
> 
> >> simple.
> 
> > 
> 
> > What is the problem with the cmForth approach?
> 
> 
> 
> If you define X where there is a previous IMMEDIATE defintion of X,
> 
> your new definition of X is not found in compilation state.  This is a
> 
> nasty bug: you't be expected to know that some previous code has
> 
> defined X in this way.
> 
> 
> 
> Andrew.

Hi Andrew,

Assuming cmForth is like colorForth in his respect, it easy to know which 'X' you are using - it depends on whether you are in "macro" or "forth" wordlist.

The "macro" wordlist is used to compile new defining words, which are then used to compile new words in the "forth" wordlist.

Just to add to the confusion by way of clarification, "macro" words are cyan, "immediate" are yellow and "compilish" words are green.

I get the feeling that "immediate" and "compilation" states in conventional Forth, and the use of the "macro" and "forth" wordlists don't map well to each other. 

Also to add to the mix, colorForth programs tend to be compiled from EMPTY every time they are used - the definitions of "dump" for example is "42 load" .
This removes a lot of complexity about which version of a word you are using, because it will be the one on the screen you are loading ;-)

Best regards,
Howerd

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

#20505

Howerd <howerdo@yahoo.co.uk> writes:
>> >> [Andrew:] approach at solving this problems was cmForth with
>> >> different vocabularies for compilation and interpretation, and it
>> >> again is too simple....
> Assuming cmForth is like colorForth in his respect, it easy to know
> which 'X' you are using - it depends on whether you are in "macro" or
> "forth" wordlist.

I'm getting a maybe-wrong, halfway understanding of something from this,
namely that the separate vocabularies seems to be required to make
cmforth's beautifully simple and diabolically clever 2-line metacompiler
work.  For someone like Chuck, I could imagine it being worth changing
almost everything else in Forth to be able to build like that.  It might
even go some way toward explaining his rage against ANS Forth.  A pure,
self-reproducing Forth with essentially no infrastructure for that
purpose is too perfect to let go.  Anything like Jonesforth of course is
a near-abomination from that perspective.  This makes me want to look
into Colorforth more closely.  Wow!  :-)

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

#20507

Paul Rubin <no.email@nospam.invalid> wrote:
> Howerd <howerdo@yahoo.co.uk> writes:
>>> >> [Andrew:] approach at solving this problems was cmForth with
>>> >> different vocabularies for compilation and interpretation, and it
>>> >> again is too simple....
>> Assuming cmForth is like colorForth in his respect, it easy to know
>> which 'X' you are using - it depends on whether you are in "macro" or
>> "forth" wordlist.
> 
> I'm getting a maybe-wrong, halfway understanding of something from
> this, namely that the separate vocabularies seems to be required to
> make cmforth's beautifully simple and diabolically clever 2-line
> metacompiler work.

I don't think so: there's no reason a dual-xt-per-word scheme wouldn't
work just as well.

Which two lines, anyway?  The compiler is much longer than that.

Andrew.

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

#20527

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> make cmforth's beautifully simple and diabolically clever 2-line
>> metacompiler
> I don't think so: there's no reason a dual-xt-per-word scheme wouldn't
> work just as well.

I'm not sure I see how to do this, but there's already some parts
of the picture that I'm missing.

> Which two lines, anyway?  The compiler is much longer than that.

The { and } words that switch the metacompiler and target dictionary
pointers.  The idea is you start with a fully loaded interpreter, then
set up the pointers so the compiled dictionary is an empty area of
memory, and then you can use all the interpreter features (including an
assembler or whatever) to make a new, possibly modified copy of the
whole system in the empty memory.  All that without needing special
versions of CREATE, COMMA (,), etc.

There's a cool article called something like "The Demise of the
Metacompiler in Cmforth" by Jay Melvin, that describes it.  I've only
briefly looked at cmforth itself and didn't find it very comprehensible,
unfortunately.

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

#20530

Paul Rubin <no.email@nospam.invalid> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> make cmforth's beautifully simple and diabolically clever 2-line
>>> metacompiler
>> I don't think so: there's no reason a dual-xt-per-word scheme wouldn't
>> work just as well.
> 
> I'm not sure I see how to do this, but there's already some parts
> of the picture that I'm missing.
> 
>> Which two lines, anyway?  The compiler is much longer than that.
> 
> The { and } words that switch the metacompiler and target dictionary
> pointers.  The idea is you start with a fully loaded interpreter,
> then set up the pointers so the compiled dictionary is an empty area
> of memory, and then you can use all the interpreter features
> (including an assembler or whatever) to make a new, possibly
> modified copy of the whole system in the empty memory.  All that
> without needing special versions of CREATE, COMMA (,), etc.

Sure, but people were doing very similar thing before cmFORTH.  I can
remember fig-FORTH being bootstrapped that way.  But I don't see how
that actually requires separate wordlists for COMPILER words.

> There's a cool article called something like "The Demise of the
> Metacompiler in Cmforth" by Jay Melvin, that describes it.  I've only
> briefly looked at cmforth itself and didn't find it very comprehensible,
> unfortunately.

cmFORTH isn't so bad.  It's much easier to read with shadow blocks.

Andrew.

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

#20652

>> The { and } words that switch the metacompiler and target dictionary
>> pointers...
>> without needing special versions of CREATE, COMMA (,), etc.
> Sure, but people were doing very similar thing before cmFORTH.  I can
> remember fig-FORTH being bootstrapped that way.

The Figforths that I've seen had the primitives defined in assembler
(maybe MASM) but that code may have been produced somehow from
metacompiler output.  I remember Jeff Fox complaining about that.  But,
I thought that the usual approach to metacompilation was defining
special versions of words like COMMA to operate on the target space.  I
did look briefly at the Eforth metacompiler and it's also rather big and
complicated.  The Cmforth approach as I understand it starts with the
compilation dictionary completely empty, so you can populate it using
normal interpreter commands.

> But I don't see how that actually requires separate wordlists for
> COMPILER words.

I wonder if I misunderstand the terminology "COMPILER word".  I just
mean when you say

  : SQUARE DUP * ;

the word DUP gets looked up in a wordlist, that is not necessarily the
same wordlist that would be used if you typed DUP into the interpreter.

> cmFORTH isn't so bad.  It's much easier to read with shadow blocks.

Any idea where a copy of that is available?  I saw a mention that such a
thing existed, but the version I saw didn't have any comments to speak
of.

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

#20653

On 3/13/13 8:48 PM, Paul Rubin wrote:
>>> The { and } words that switch the metacompiler and target dictionary
>>> pointers...
>>> without needing special versions of CREATE, COMMA (,), etc.
>> Sure, but people were doing very similar thing before cmFORTH.  I can
>> remember fig-FORTH being bootstrapped that way.
>
> The Figforths that I've seen had the primitives defined in assembler
> (maybe MASM) but that code may have been produced somehow from
> metacompiler output.  I remember Jeff Fox complaining about that.  But,
> I thought that the usual approach to metacompilation was defining
> special versions of words like COMMA to operate on the target space.  I
> did look briefly at the Eforth metacompiler and it's also rather big and
> complicated.  The Cmforth approach as I understand it starts with the
> compilation dictionary completely empty, so you can populate it using
> normal interpreter commands.

That's characteristic of all Forth meta-compilers. I haven't read up on 
cmForth, but from what folks are saying here it sounds as though it's 
just swapping a bunch of pointers.

The current proposed cross-compiler strategy (which includes 
meta-compilers) is to have different words building the target 
dictionary, but one could do it by swapping a bunch of pointers *if* the 
target is basically the same (e.g., cell-size, etc.) as the host. If 
it's not, more intervention is necessary.

>> But I don't see how that actually requires separate wordlists for
>> COMPILER words.
>
> I wonder if I misunderstand the terminology "COMPILER word".  I just
> mean when you say
>
>    : SQUARE DUP * ;
>
> the word DUP gets looked up in a wordlist, that is not necessarily the
> same wordlist that would be used if you typed DUP into the interpreter.

In current terminology (per the proposed Cross Compiler wordset) 
COMPILER refers to words that are only executed during compilation, such 
as IF etc. TARGET is the term for a version of SQUARE that goes in the 
target dictionary.

>> cmFORTH isn't so bad.  It's much easier to read with shadow blocks.
>
> Any idea where a copy of that is available?  I saw a mention that such a
> thing existed, but the version I saw didn't have any comments to speak
> of.

Cheers,
Elizabeth

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

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

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

#20654

> That's characteristic of all Forth meta-compilers. I haven't read up
> on cmForth, but from what folks are saying here it sounds as though
> it's just swapping a bunch of pointers.

It swaps just one pair of pointers, and one pair of offsets.  I.e. two
cells get swapped with another two cells, in a one-liner.  The "unswap"
operation is of course the same as the swap operation (it just swaps the
same things again).

> *if* the target is basically the same (e.g., cell-size, etc.) as the
> host. If it's not, more intervention is necessary.

Not an issue for cmforth which is not a cross-compiler afaik.  It only
metacompiles itself.

I wonder why eforth's metacompiler is so messy.  The interpreter itself
is (mostly) beautiful.

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

#20655

Elizabeth D. Rather wrote:
> I haven't read up on cmForth, but from what folks are saying here it
> sounds as though it's just swapping a bunch of pointers.

From "Demise of the metacompiler in cmForth":

  : {   dA @  HERE  H' 2@ H !  dA !  H' 2! ;
  : }   { ;

So it loos like HERE and dA (I don't know what that is) is being swapped.

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

#26893

Elizabeth D. Rather wrote:
> Paul Rubin wrote:
> > Eforth metacompiler and it's also rather big and complicated.  The
> > Cmforth approach as I understand it starts with the compilation
> > dictionary completely empty, so you can populate it using normal
> > interpreter commands.
> That's characteristic of all Forth meta-compilers. I haven't read up
> on cmForth, but from what folks are saying here it sounds as though
> it's just swapping a bunch of pointers.

Forth Dimensions volume 12 issue 6 has an article which describes the
Pygmy Forth metacompiler, which seems similar to the one in cmFORTH.

> > Any idea where a copy of that is available?  I saw a mention that
> > such a thing existed, but the version I saw didn't have any
> > comments to speak of.

The pygmy17.zip file at http://pygmy.utoh.org/pygmyforth.html
seems to have a copy of cmFORTH.  And also lots of other goodies.

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

#20656

Paul Rubin <no.email@nospam.invalid> wrote:
>>> The { and } words that switch the metacompiler and target dictionary
>>> pointers...
>>> without needing special versions of CREATE, COMMA (,), etc.
>>
>> Sure, but people were doing very similar thing before cmFORTH.  I can
>> remember fig-FORTH being bootstrapped that way.
> 
> The Figforths that I've seen had the primitives defined in assembler
> (maybe MASM) but that code may have been produced somehow from
> metacompiler output.

It was originally produced by a Forth, Inc cross-compiler, but you
could recompile the sources without cross-compiling.

> I remember Jeff Fox complaining about that.  But, I thought that the
> usual approach to metacompilation was defining special versions of
> words like COMMA to operate on the target space.

It was, yes.

> I did look briefly at the Eforth metacompiler and it's also rather
> big and complicated.  The Cmforth approach as I understand it starts
> with the compilation dictionary completely empty, so you can
> populate it using normal interpreter commands.

That's right.

Andrew.

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

#20661

In article <7x1ubijx3o.fsf@ruckus.brouhaha.com>,
Paul Rubin  <no.email@nospam.invalid> wrote:
>>> The { and } words that switch the metacompiler and target dictionary
>>> pointers...
>>> without needing special versions of CREATE, COMMA (,), etc.
>> Sure, but people were doing very similar thing before cmFORTH.  I can
>> remember fig-FORTH being bootstrapped that way.
>
>The Figforths that I've seen had the primitives defined in assembler
>(maybe MASM) but that code may have been produced somehow from
>metacompiler output.  I remember Jeff Fox complaining about that.  But,
>I thought that the usual approach to metacompilation was defining
>special versions of words like COMMA to operate on the target space.  I
>did look briefly at the Eforth metacompiler and it's also rather big and
>complicated.  The Cmforth approach as I understand it starts with the
>compilation dictionary completely empty, so you can populate it using
>normal interpreter commands.

What is metacompilaton? I have the source of lina 4.0.5 disassembled
with my ciasdis tool, then reassemble it with a Forth assembler
in the same tool. Not metacompilation as I understand it, but the
only tool to generate a new lina is lina itself.

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

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

#20532

On Mar 11, 3:56 am, Paul Rubin <no.em...@nospam.invalid> wrote:
> Andrew Haley <andre...@littlepinkcloud.invalid> writes:
> >> make cmforth's beautifully simple and diabolically clever 2-line
> >> metacompiler
> > I don't think so: there's no reason a dual-xt-per-word scheme wouldn't
> > work just as well.
>
> I'm not sure I see how to do this, but there's already some parts
> of the picture that I'm missing.
>
> > Which two lines, anyway?  The compiler is much longer than that.
>
> The { and } words that switch the metacompiler and target dictionary
> pointers.  The idea is you start with a fully loaded interpreter, then
> set up the pointers so the compiled dictionary is an empty area of
> memory, and then you can use all the interpreter features (including an
> assembler or whatever) to make a new, possibly modified copy of the
> whole system in the empty memory.  All that without needing special
> versions of CREATE, COMMA (,), etc.
>
> There's a cool article called something like "The Demise of the
> Metacompiler in Cmforth" by Jay Melvin, that describes it.  I've only
> briefly looked at cmforth itself and didn't find it very comprehensible,
> unfortunately.

Also, this might be useful/interesting:

http://www.ultratechnology.com/mmeta.html

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

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

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

csiph-web