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 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#20508

On Sunday, March 10, 2013 9:51:33 AM UTC+1, Paul Rubin wrote:
> Howerd <how....@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!  :-)

Hi Paul,

Yes, "wow" indeed :-)

My understanding of the way Chuck uses the macro wordlist is that you need somewhere to put words that you are building that create other words, so that the "macro" words do not get mixed up with the words being built by the "macros".

I hope someone will correct me if I am wrong.

Jonesforth is a noble attempt at creating a Forth, but some of the design decisions, aparently, were not in keeping with the latest Forth thinking.

Again, my understanding ( which is neccessarily limited ) is that Chuck always creates a "Problem Oriented Language". The original Forth, MicroForth, and polyForth suit the problem domain of creating a programming environment that has a serial terminal and text display, wheras colorForth suits a graphical environment that has no text stream as such.
Stepping one level higher, I think that Chuck advocates *always* solving the exact problem, rather than creating a generic tool to solve potential problems.
I have found this to be the best way to achieve results too.

Seen in this light, JonesForth solves the problem of "how do I write my own Forth that follows the Fig83 ( or whatever ) standard" - this has little to do with writing applications in Forth.

One of the other extremely clever things about colorForth is the way (almost) everything is a 32 bit "token". The token "colour" ( it doesn't have to be an actual colour ) indicates what different parts of the system should do with it. For example a "red" token is displayed in red by the editor, and acts like : in the compiler. This combined with the fact that each token has its own compressed name allows some interesting simplifications.

BTW GreenArrays' version of colorForth, arrayForth, has removed the continuous updating of the display by a background task - colorForth used this to display chip designs and simulations changing in "real time", wheras arrayForth just has to compile code - different problems, so different langauges.

> A pure, self-reproducing Forth with essentially no infrastructure 
> for that purpose is too perfect to let go
AFAIK colorForth is not self-reproducing - Jeff Fox had some code to create a boot sector which could be extended, but the sources are in NASM or similar assembler. arrayForth as shipped by GreenArrays does not reproduce itself - I would interested to hear if GA have code to do this...

Best regards,
Howerd

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

#20403

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>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.

There are ways to fix this, but with a fix here and a fix there, this
approach becomes more complex than other approaches, so it has not
caught on.

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

#20221

Lars Brinkhoff 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?

Andrew has described one problem, the problem of redefinitions.  We assume 
that new definitions override old ones; in cmForth, this isn't guaranteed.

The other problem cmForth has is the common problem of all dual-xt Forths 
(where words can have more than one xt): It depends on the state you are in 
what FIND will return.  This can also be nasty, as FIND turns into a state-
smart word, and now may return a different xt as '.

>> [...] 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?

"smart compile," means that each word has a field somewhere in the header or 
alike, which describes what the word should do when COMPILE, is used.

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

Yeah, it is hard to google for stuff with ','.  We promise to invent more 
words which can't be googled.  You better look for "header" discussions.

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

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

#20263

On 03.03.2013 22:49, Bernd Paysan wrote:
> Lars Brinkhoff 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?
>
> Andrew has described one problem, the problem of redefinitions.  We assume
> that new definitions override old ones; in cmForth, this isn't guaranteed.
>
> The other problem cmForth has is the common problem of all dual-xt Forths
> (where words can have more than one xt): It depends on the state you are in
> what FIND will return.  This can also be nasty, as FIND turns into a state-
> smart word, and now may return a different xt as '.

Not necessarily. In our dual-xt system FIND is not affected by STATE, 
only the INTERPRET loop is.

And INTERPRET has become just slightly more complicated as it now uses a 
cousin to FIND that returns both xts.

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

#20268

A. K. <akk@nospam.org> wrote:
> On 03.03.2013 22:49, Bernd Paysan wrote:
>> The other problem cmForth has is the common problem of all dual-xt Forths
>> (where words can have more than one xt): It depends on the state you are in
>> what FIND will return.  This can also be nasty, as FIND turns into a state-
>> smart word, and now may return a different xt as '.
> 
> Not necessarily. In our dual-xt system FIND is not affected by STATE, 
> only the INTERPRET loop is.

Right, but that's just as bad if not worse: the interpreter now has a
different lookup behaviour from a simple FIND .  Either way it's
nasty.

Andrew.

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

#20249 — intelligent COMPILE, and smart COMPILE,

Lars Brinkhoff <lars.spam@nocrew.org> writes:
>How does smart compile (or compile,) work?

I called the original idea "intelligent compile,", and that idea was
to implement optimization knowledge through "COMPILE,".  E.g., consider the following code

5 constant foo
: bar foo ;

In a classic threaded-code system the compiler just takes the xt of
FOO and ,s it into BAR.  Now with more sophisticated code generation,
say you want the system to generate code equivalent to

: bar [ 5 ] literal ;

(and what gets generated may be some native code, but the following
discussion is equally applicable to threaded code.)

Now some people have done horrible things to achieve that, like making
all constants STATE-smart (which is non-standard and breaks standard
code).  The idea of the "intelligent compile," is to access the
optimization smarts through COMPILE, instead of at some other level.
This is conceptually cleaner, because all compilation goes through
COMPILE, but not necessarily through other parts of the Forth system
where one might consider putting this stuff (e.g., not all compilation
goes through the text interpreter in compilation state).

There can be different implementations of this concept.  One not very
elegant one is implemented in Gforth 0.7.0: COMPILE, is a big case
that checks the word type of the xt and generates code accordingly
(e.g., it generates a literal for a constant).

It's more elegant if each word has a field that contains the xt of the
COMPILE, action; each constant would have the xt of CONST-COMPILE, in
that field:

: const-compile, ( xt -- )
  execute            \ get the value of the constant
  POSTPONE literal ; \ and compile it

Up to now the intelligent COMPILE, is just an implementation technique
for "COMPILE,".  I.e., the system implementor is responsible for
implementing COMPILE, correctly, i.e., in a way that (apart from
performance) is equivalent to

: compile, ( xt -- )
  postpone literal postpone execute ;

Onwards to Bernd Paysan's "smart COMPILE,":

With the smart COMPILE, the equivalence above no longer holds true for
all words.  With that, if you COMPILE, the xt of a word, what happens
is that the compilation semantics of the word are performed.

The difference between the intelligent and the smart COMPILE, is in
the xt that the system designer has put in the comp field: with the
"intelligent COMPILE," it compiles the interpretation/execution
semantics represented by the xt.  With the "smart COMPILE," it
performs the compilation semantics.  For many words, there is no
difference, but for words like S" and TO, there is.

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

#20266 — Re: intelligent COMPILE, and smart COMPILE,

Anton Ertl wrote:
> The difference between the intelligent and the smart COMPILE, is in
> the xt that the system designer has put in the comp field: with the
> "intelligent COMPILE," it compiles the interpretation/execution
> semantics represented by the xt.  With the "smart COMPILE," it
> performs the compilation semantics.  For many words, there is no
> difference, but for words like S" and TO, there is.

Yes, and the argument I have is that words like S" and TO haven't been 
considered when writing the glossary for COMPILE,.  There is a reason why 
most of these words "can't be ticked" in ANS Forth (and those who can are 
just an oversight).

The idea to make COMPILE, smart is not my idea, it's Stephen Pelc's idea - 
MPE at one point in time didn't have a single immediate word in VFX Forth, 
because they liked comp: so much.  But actually, some ANS Forth words are 
deliberately specified as "this is an immediate word", so you better set the 
immediate flag on them when you implement a Forth system.

And for immediate words, the comp field is pointing to the default 
compilation method, so COMPILE, does just what Anton wants it to do.

If we really need Anton's thing dearly, we should have INTERP, and [INTERP] 
<name> (maybe better without those brackets, we don't have them on POSTPONE) 
as compagnion for COMPILE, and POSTPONE (POSTPONE should have been called 
COMPILE - as COMPILE did only work for non-immediate words, and extending it 
for immediate words wouldn't have required a name-change).

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

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

#20285 — Re: intelligent COMPILE, and smart COMPILE,

On Tue, 05 Mar 2013 00:49:15 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>The idea to make COMPILE, smart is not my idea, it's Stephen Pelc's idea - 

I don't think that it's my idea at all. The original VFX kernel was 
not written by me, and the separate compilation xt and use of it by
COMPILE, was in the 1998 version of VFX. The VFX kernel was a group
effort and took inspiration from a wide range of sources.

>MPE at one point in time didn't have a single immediate word in VFX Forth, 
>because they liked comp: so much.  But actually, some ANS Forth words are 
>deliberately specified as "this is an immediate word", so you better set the 
>immediate flag on them when you implement a Forth system.

True. We made some words IMMEDIATE in order to be standards compliant.
IMHO, the standard's relationship with IMMEDIATE is just a set of
weasel words as a historical legacy. All it actually means is that
the interpretation and compilation actions are the same.

In modern Forth compilers, especially those with optimisers, many
words have different interpretation and compilation actions.

>If we really need Anton's thing dearly, we should have INTERP, and [INTERP] 
><name> (maybe better without those brackets, we don't have them on POSTPONE) 

[INTERP] is just the parallel to [COMPILE].

Stephen

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

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

#20193

In article <2013Mar2.185555@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>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).

[That is not hard, as few things in Forth are. It is totally
system-dependant of course. You must not try to implement things
like this as standard ISO-FORTH code.]

Assuming you can do SWAP-DP to go to a separate compilation area:

>R in this simple Forth can be user to begin interpretation form
a starting point

 8 \ While compiling, T[ just throws away the state pushed by T].
 9 \ Interpreting:
10 \ Start compiling at temporary place : return START and STATE.
11 : T] STATE @ 0= IF SWAP-DP HERE THEN STATE @ ] ;
12 \ Execute code at START dropping STATE, restore dictionary.
13 : T[ 0= IF POSTPONE (;) SWAP-DP POSTPONE [ >R THEN ; IMMEDIATE

3 :  IF           T] POSTPONE IF                    ; IMMEDIATE
7 :  THEN            POSTPONE THEN      POSTPONE T[ ; IMMEDIATE



>
>- anton
>--

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]

#20183

Rob Sciuk <rob@controlq.com> writes:
>How might one describe a standardized language similar to Forth in such a 
>way as to avoid the run-time/compile-time semantics, but still allow 
>create/does type extensibility?  Am I missing something obvious?

CREATE/DOES> has very little to do with that.

The issue is that you write

1 2 +

and can then wrap it in a colon def

: foo 1 2 + ;

and you write exactly the same sequence "1 2 +".  You can also extract
sequences from colon definitions and run them in the text interpreter.

But that does not work for all code.  One part where it breaks down is
parsing words like "'".  If you put

' + execute

in a colon definition, you don't get the same behaviour.  Some people,
like Andrew Haley and Elizabeth Rather, just accept that and say that
everybody should accept that.  Other people try to keep this property
even for parsing and control-flow words; one of the techniques used is
STATE-smart words, but they lead to problems, because they do not
always check STATE when the text interpreter sees them.  There are
three approaches to that

1) Some take it as a confirmation of their view that we should just
forget about that desired property and be happy with ' ['] and .( .".

2) Some say that the problems of STATE-smart words do not happen in
(their) practice, so we should not worry about them.

3) Some look for (and have found) better solutions that allow
implementing words like S" without getting the problems of STATE-smart
words.

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

#20225

"Anton Ertl" <anton@mips.complang.tuwien.ac.at> wrote in message
news:2013Mar2.183709@mips.complang.tuwien.ac.at...


> The issue is that you write
>
> 1 2 +
>
> and can then wrap it in a colon def
>
> : foo 1 2 + ;
>
> and you write exactly the same sequence "1 2 +".  You can also
> extract sequences from colon definitions and run them in the
> text interpreter.
>
> But that does not work for all code.  One part where it breaks
> down is parsing words like "'".  If you put
>
> ' + execute
>
> in a colon definition, you don't get the same behaviour.  Some
> people, like Andrew Haley and Elizabeth Rather, just accept that
> and say that everybody should accept that.  Other people try to
> keep this property even for parsing and control-flow words; one
> of the techniques used is STATE-smart words, but they lead to
> problems, because they do not always check STATE when the text
> interpreter sees them.  [...]

What's wrong with a set of words that can select the needed
behavior prior to the word being used?

E.g., .I .C .P

  .I CHAR   \ immediate behavior
  .C CHAR  \ compile behavior
  .P CHAR  \ etc.

Of course, each mode would be the default for that mode.  Who
wants to type them all the time?


Rod Pemberton

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

#20448

"Rod Pemberton" <do_not_have@notemailnotz.cnm> writes:
>What's wrong with a set of words that can select the needed
>behavior prior to the word being used?
>
>E.g., .I .C .P
>
>  .I CHAR   \ immediate behavior
>  .C CHAR  \ compile behavior
>  .P CHAR  \ etc.
>
>Of course, each mode would be the default for that mode.  Who
>wants to type them all the time?

I once did an experiment with prefixes "[", "_" and "]" for
interpretation compilation, and postponeing, inspired by colorForth:

[5 [constant row-size
[row-size [cells [constant row-byte-size

[: gen-innerproduct [( a[row][*] -- xt )
[\ xt is of type ( b[*][column] -- n )
[\ this would be a candidate for using ]] ... [[
 _>r _:noname _r>
 ]0 ]SWAP
 _row-size _0 [do
   ]dup ]@
   _dup _@ _literal ]* ]under+
   ]cell+ _row-byte-size _+
  [loop
  _drop
 ]drop _;
[;

It was surprisingly easy to change Gforth to accept that.

Disadvantage: You cannot just copy and paste between interpreted and
compiled code.

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

#20274

On Thursday, February 28, 2013 8:35:32 PM UTC+4, Rob Sciuk wrote:
> How might one describe a standardized language similar to Forth in such a 
> way as to avoid the run-time/compile-time semantics, but still allow 
> create/does type extensibility?  Am I missing something obvious?

You can get rid of the variable STATE , but you will introduce something 
that 1) will not be less complex 2) will be incompatible with the language
the other people use. (I mean, unless you invent something completely new,
in which case you probably will have only '2').

Multiple approaches have been made, one of them was getting rid of the interpretation mode. Finally, they had two compilation modes, compilation to a definition and compilation to a temporary buffer, which is also a state. (But a variation of this approach was very good for umbilical targets: compile-send-execute and no need for an interpreter.)

There have been attempts to eliminate STATE by using two text interpreters and/or two search orders (one for compilation and one for interpretation) but having the current interpreter or the current search order is still a state.

Hmmm... in fact, STATE is not needed at all:

: _: : postpone [ ;
: _; ] postpone ; ;
: _ ] ' compile, postpone [ ;
: n, ] postpone literal postpone [ ;

\ the following definition is created in *interpretation* state
_: test 2 n, 3 n, _ + _ . _;  ok
.s <0>  ok 
test 5  ok
.s <0>  ok

( The only disadvantage of this approach is that the code is not human-readable :)

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

#20293

On Mon, 4 Mar 2013, Michael L Gassanenko wrote:

> Date: Mon, 4 Mar 2013 23:08:12 -0800 (PST)
> From: Michael L Gassanenko <m_l_g3@yahoo.com>
> To: comp.lang.forth@googlegroups.com
> Cc: rob@controlq.com
> Newsgroups: comp.lang.forth
> Subject: Re: State and the standard ...
> 
> On Thursday, February 28, 2013 8:35:32 PM UTC+4, Rob Sciuk wrote:
>> How might one describe a standardized language similar to Forth in such a
>> way as to avoid the run-time/compile-time semantics, but still allow
>> create/does type extensibility?  Am I missing something obvious?
>
> You can get rid of the variable STATE , but you will introduce something
> that 1) will not be less complex 2) will be incompatible with the language
> the other people use. (I mean, unless you invent something completely new,
> in which case you probably will have only '2').

State, as indicated by a state variable is the simplest approach to the 
problem, and in that regard, was the first solution hit upon.  Not 
necessarily a bad one, but one which introduced the necessity of 
recognizing state, and manipulating it, which requires an understanding of 
multiple (compile/run time) semantics.

>
> Multiple approaches have been made, one of them was getting rid of the 
> interpretation mode. Finally, they had two compilation modes, 
> compilation to a definition and compilation to a temporary buffer, which 
> is also a state. (But a variation of this approach was very good for 
> umbilical targets: compile-send-execute and no need for an interpreter.)
>
> There have been attempts to eliminate STATE by using two text 
> interpreters and/or two search orders (one for compilation and one for 
> interpretation) but having the current interpreter or the current search 
> order is still a state.

Interpretation is a boon, IMHO, and ridding Forth proper of interpretation 
is retrograde, notwithstanding that X-Development (umbilical) systems 
don't necessarily require it.


> Hmmm... in fact, STATE is not needed at all:
>
> : _: : postpone [ ;
> : _; ] postpone ; ;
> : _ ] ' compile, postpone [ ;
> : n, ] postpone literal postpone [ ;
>
> \ the following definition is created in *interpretation* state
> _: test 2 n, 3 n, _ + _ . _;  ok
> .s <0>  ok
> test 5  ok
> .s <0>  ok
>
> ( The only disadvantage of this approach is that the code is not human-readable :)

My question was intended to open a discussion (which seems to have worked) 
to question some long held truths, and in hopes of improving Forth rather 
than to damage it.  I believe that the approach above is exactly the kind 
of thing I'd hoped to avoid -- confuscation is never good.

Just as Esparanto was created as a "normalized" human language, with no 
"irregular" verb conjugations (as compared to English, or any of the Latin 
based languages), I was wondering if Forth could be made entirely 
consistent, without "classes" of defining words.

I don't think this thread has caused any harm, but I have yet to see a 
conclusive way that Forth might be improved (at least not without some 
inelegant tradeoffs).  Perhaps we just leave it alone, and accept these 
minor "blemishes", or come to understand that the exceptions simply add to 
the CHARM of the language 8-).

Cheers,
Rob.

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

#20306

On 3/5/13 5:47 AM, Rob Sciuk wrote:
...
> Just as Esparanto was created as a "normalized" human language, with no
> "irregular" verb conjugations (as compared to English, or any of the
> Latin based languages), I was wondering if Forth could be made entirely
> consistent, without "classes" of defining words.

And we can all see how popular it's been, as a result, yes? Right up 
there with Klingon and Elvish.

> I don't think this thread has caused any harm, but I have yet to see a
> conclusive way that Forth might be improved (at least not without some
> inelegant tradeoffs).  Perhaps we just leave it alone, and accept these
> minor "blemishes", or come to understand that the exceptions simply add
> to the CHARM of the language 8-).

A lot of very challenging projects have been successfully completed with 
this language, blemishes and all. There are actually reasons for most of 
its "quirks". Beware lest the cure be worse than the disease.

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]

#20309

On Tue, 5 Mar 2013, Elizabeth D. Rather wrote:

> Date: Tue, 05 Mar 2013 08:11:56 -1000
> From: Elizabeth D. Rather <erather@forth.com>
> Newsgroups: comp.lang.forth
> Subject: Re: State and the standard ...
> 
> On 3/5/13 5:47 AM, Rob Sciuk wrote:
> ...
>> Just as Esparanto was created as a "normalized" human language, with no
>> "irregular" verb conjugations (as compared to English, or any of the
>> Latin based languages), I was wondering if Forth could be made entirely
>> consistent, without "classes" of defining words.
>
> And we can all see how popular it's been, as a result, yes? Right up there 
> with Klingon and Elvish.

Touche' 8-)

Still, an orthagonal vocabulary might be considered a useful trait, 
helpful mostly in the uptake (removing adoption impediments for newbies) 
rather than for the black-belt Forth-Fu artists (such as yourself).

>
>> I don't think this thread has caused any harm, but I have yet to see a
>> conclusive way that Forth might be improved (at least not without some
>> inelegant tradeoffs).  Perhaps we just leave it alone, and accept these
>> minor "blemishes", or come to understand that the exceptions simply add
>> to the CHARM of the language 8-).
>
> A lot of very challenging projects have been successfully completed with this 
> language, blemishes and all. There are actually reasons for most of its 
> "quirks". Beware lest the cure be worse than the disease.
>

My intent was not to bash Forth, but rather to ask a question, to which 
the answers were very informative, and yet unsatisfactory.  State and 
immediacy appear to be fundamental, and apparently anything else would not 
be Forth.

I'm ok with that, and again, I think the resulting introspection was 
healthy ... if only to shake loose some historical approaches, and 
proposals which as you say, are worse than the disease.  I understand your 
defense of the status quo, but I hope that such discussions are not 
unwelcome.

Cheers,
Rob.

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

#20314

On 3/5/13 8:44 AM, Rob Sciuk wrote:
> On Tue, 5 Mar 2013, Elizabeth D. Rather wrote:
...
>> A lot of very challenging projects have been successfully completed
>> with this language, blemishes and all. There are actually reasons for
>> most of its "quirks". Beware lest the cure be worse than the disease.
>>
>
> My intent was not to bash Forth, but rather to ask a question, to which
> the answers were very informative, and yet unsatisfactory.  State and
> immediacy appear to be fundamental, and apparently anything else would
> not be Forth.
>
> I'm ok with that, and again, I think the resulting introspection was
> healthy ... if only to shake loose some historical approaches, and
> proposals which as you say, are worse than the disease.  I understand
> your defense of the status quo, but I hope that such discussions are not
> unwelcome.

I'm not blindly defending the status quo... there have been many 
improvements to Forth over the years, mostly along the lines of added 
capabilities, improvements in performance, etc. I'm just highly 
suspicious of "improvements" intended to make Forth more like other 
languages simply because people are resistant to accepting Forth's 
inherent style, in which lies much of its strength. I also resist adding 
features whose utility in Forth hasn't been demonstrated. If someone can 
show why a feature is valuable beyond "Language X has it, and it's 
really cool!" I'm all for it.

This particular discussion about STATE and interpreter loops is annoying 
to me because making state-smart (note lower case) words is really 
rarely something of value to users -- it's something that people want to 
do because their "expectations" of how things work are incorrect. Rod 
asked (legitimately, IMO) how often DOES> is actually used, and the 
answer is that it's incredibly valuable, particularly in application 
code (which is difficult to appreciate if you're only interested in 
writing yet another Forth kernel). But I would argue that writing 
state-smart words is *rarely* useful in application code, and therefor 
not something worth fussing about.

I share Stephen's view, that Forth is not about writing kernels, it's 
about writing applications to get work done. Forth is to *use*. I have 
no problem with people writing their own kernels for fun, but resist 
changing the language to facilitate kernel writing instead of 
emphasizing useful application capabilities.

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]

#20390

On Tuesday, March 5, 2013 11:26:16 PM UTC+4, Elizabeth D. Rather wrote:
> On 3/5/13 8:44 AM, Rob Sciuk wrote:
> I'm not blindly defending the status quo... there have been many 
> improvements to Forth over the years, mostly along the lines of added 
> capabilities, improvements in performance, etc. I'm just highly 
> suspicious of "improvements" intended to make Forth more like other 
> languages simply because people are resistant to accepting Forth's 
> inherent style, in which lies much of its strength.

It should be noted that many (if not most if not all) books about
object-oriented design state in the introduction that object-oriented
decomposition is better than functional decomposition.

OO design answers the question:
what class is responsible for what functionality?

And the problems for the programmer look like:
"We want you to reuse this (or this) and implement this".

There is not much room for Forth programming in this world.

Probably, because Forth is not very good at reusing libraries and concepts created for other languages.

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

#20394

On 3/7/13 7:24 AM, Michael L Gassanenko wrote:
> On Tuesday, March 5, 2013 11:26:16 PM UTC+4, Elizabeth D. Rather wrote:
>> On 3/5/13 8:44 AM, Rob Sciuk wrote:
>> I'm not blindly defending the status quo... there have been many
>> improvements to Forth over the years, mostly along the lines of added
>> capabilities, improvements in performance, etc. I'm just highly
>> suspicious of "improvements" intended to make Forth more like other
>> languages simply because people are resistant to accepting Forth's
>> inherent style, in which lies much of its strength.
>
> It should be noted that many (if not most if not all) books about
> object-oriented design state in the introduction that object-oriented
> decomposition is better than functional decomposition.
>
> OO design answers the question:
> what class is responsible for what functionality?
>
> And the problems for the programmer look like:
> "We want you to reuse this (or this) and implement this".
>
> There is not much room for Forth programming in this world.

My experience has been OOP in Forth works quite nicely.  But perhaps I 
mis-understand your issue(s).  Especially for "We want you to reuse this 
(or this) and implement this" situations.

> Probably, because Forth is not very good at reusing libraries and concepts created for other languages.

Actually, I've looked at Smalltalk to get ideas for Forth OOP classes 
and methods.  The translation has not been hard.  Ordered-collections 
and the like.

-Doug

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

#20405

On 3/7/13 2:24 AM, Michael L Gassanenko wrote:
> On Tuesday, March 5, 2013 11:26:16 PM UTC+4, Elizabeth D. Rather wrote:
>> On 3/5/13 8:44 AM, Rob Sciuk wrote:
>> I'm not blindly defending the status quo... there have been many
>> improvements to Forth over the years, mostly along the lines of added
>> capabilities, improvements in performance, etc. I'm just highly
>> suspicious of "improvements" intended to make Forth more like other
>> languages simply because people are resistant to accepting Forth's
>> inherent style, in which lies much of its strength.
>
> It should be noted that many (if not most if not all) books about
> object-oriented design state in the introduction that object-oriented
> decomposition is better than functional decomposition.
>
> OO design answers the question:
> what class is responsible for what functionality?

As Doug points out, OOP is readily implemented in Forth, and a number of 
Forths have extensive OOP support, although an implementation consensus 
has not emerged.

However, althugh OOP is applicable to many application areas, it is not 
a panacea for all programming. Many projects are inherently procedural 
(especially in embedded systems), and forcing an OOP paradigm just adds 
a layer of complexity and obfuscation.

> And the problems for the programmer look like:
> "We want you to reuse this (or this) and implement this".
>
> There is not much room for Forth programming in this world.
>
> Probably, because Forth is not very good at reusing libraries and concepts created for other languages.

Forth is good at reusing libraries, but "concepts created for other 
languages" are usually naturally designed for those languages and 
inappropriate for Forth, while concepts in Forth may be equally 
inappropriate for other languages.

The library issue in Forth has two aspects: first, the most extensive 
Forth programming is done in commercial projects where the organization 
paying for the project owns the code, so it is not sharable. 
Nonetheless, companies doing such work, such as FORTH, Inc., usually 
offer generic versions of capabilities developed for such projects in 
libraries with their systems.

Second, many academic and free-lance Forth programmers devote their 
energies to developing kernels, rather than writing sharable application 
code.

The current Forth standards make it possible to share and reuse code. 
It's the choice of the programmers whether they want to make use of this 
capability.

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]

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

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

csiph-web