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

#20102 — State and the standard ...

I'm wondering if, as the arguments proffered in that other thread seem to 
indicate, state-fulness is generally considered a bad thing, then perhaps 
a future Forth standard should address the issue head on???  I must 
confess that I have always found [ ] postpone and friends to be confusing.

Multiple CFA's is simplistic (and an implementation detail which should 
not be enshrined in a standard), but given the umbilical nature of modern 
Forth such an approach need not be wasteful, in the sense that code 
generated need not retain the extra header fields in run time code 
produced ... (or any headers at all for that matter).

To play Gavino's advocate for a second, and throw out a hypothetical --

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?

Cheers,
Rob.

[toc] | [next] | [standalone]

#20147

"Rob Sciuk" <rob@controlq.com> wrote in message
news:alpine.BSF.2.00.1302281120350.94888@yoko.controlq.com...
>
> I'm wondering if, as the arguments proffered in that other
> thread seem to indicate, state-fulness is generally considered a
> bad thing, then perhaps a future Forth standard should address
> the issue head on???  I must confess that I have always found
> [ ] postpone and friends to be confusing.
>

STATE seems to be critical to a number of words in ANS.  I.e., it
seems impossible to be able to implement them without STATE.

STATE also seems to be required to implement a historical Forth
interpreter.

Despite the standard recommendation to use POSTPONE , I found that
using COMPILE and [COMPILE] keeps things clearly marked in my
system definitions.  You need to know which is which in regards to
immediacy when coding a definition.  But, otherwise, I don't like
having two words for the job of one.  For user code, POSTPONE is
probably better.  It works 98% of the time without the user
knowing what type of word is being compiled.

For an interpreted Forth, [ ] just switch a Forth interpreter's
STATE variable from interpret to compile.  I.e., it tells the
inner/address interpreter to either compile or interpret/execute a
word.

For my interpreter, these set STATE:

  : ; [ ] QUIT

These check STATE:

  LITERAL S" ." C" QUIT TO
  inner_interpreter_routine_which_compiles_words
  inner_interpreter_routine_which_interprets_words

LITERAL is on my "To Do." list to have STATE removed.  But, ANS
seems to require STATE for S" ." and C" .  How does one implement
them without it?  STATE also seems to required in Forth
interpreters for QUIT : ; [ ] and the inner/address interpreter.
How does a compiled Forth implement two states, compile and
interactive, without STATE?  STATE or it's equivalent seems to be
required even for compiled Forths to implement two modes.  STATE's
use might be minimized, but it seems to still be required.

> Multiple CFA's is simplistic (and an implementation detail which
> should not be enshrined in a standard), but given the umbilical
> nature of modern Forth such an approach need not be wasteful, in
> the sense that code generated need not retain the extra header
> fields in run time code produced ... (or any headers at all for
> that matter).
>

CFA's can be completely eliminated *if* you have STATE.

However, if you decide to eliminate STATE, then you either 1) need
to break STATE-aware words apart into separate words for each mode
of operation, or 2) need multiple CFA's.

> [...]
> How might one describe a standardized language similar to Forth
> in such a way as to avoid the run-time/compile-time semantics,
[...]

_Everyone_ here is always touting Forth because it's so
interactive.  That's like one of the top ten if not the first
ranked ability of Forth.  Well, without STATE-aware words, you
can't create and use the exact same code sequence both
interactively and in a colon-definition.  That's only possible
with STATE-aware words.  It's a waste of time if you attempt it.
So, how interactive is Forth without STATE-aware words?  I.e., not
as interactive as it could be or was once...  When the use of
STATE-aware words declined, Forth words for each mode of operation
appeared, such as '(tick) and ['] or COMPILE and [COMPILE] etc.
With mode based words, to me, it's as if Forth lost much of it's
interactive "character".  Personally, I happen to like a Forth
where a Forth word works EXACTLY the same way whether used
interactively or compiled into a definition.  AIUI, that means
some STATE-aware words.  But, I don't like this because of the
interactiveness.  I like it because of the consistency.  I.e., it
works the same in both modes, and it's available in both modes.

> but still allow create/does type extensibility?  Am I missing
> something obvious?
>

How often is "create/does type extensibility" _actually_ used?  I
think that's what you're missing.  Forget that CREATE .. DOES> is
"one of the top ten ranked features of Forth" for a moment.  Let
the myth and hyperbole lie.  How often is it truly and honestly
used?  Can those situations be eliminated?  In my mind, the
answers are "very infrequently", "very infrequently", "yes".

AFAICT, CREATE .. DOES> is use a few times for certain system
definitions, and it's used occasionally for data structures, ...
It doesn't seem to be required or needed.

Someone (Alex?) posted a word count from their system for other
words recently.  Maybe, they can post the static frequency of
CREATE and DOES> also.


Rod Pemberton

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

#20154

On 3/1/2013 3:46 PM, Rod Pemberton wrote:
> "Rob Sciuk" <rob@controlq.com> wrote in message
> news:alpine.BSF.2.00.1302281120350.94888@yoko.controlq.com...
>>
>> I'm wondering if, as the arguments proffered in that other
>> thread seem to indicate, state-fulness is generally considered a
>> bad thing, then perhaps a future Forth standard should address
>> the issue head on???  I must confess that I have always found
>> [ ] postpone and friends to be confusing.
>>
>
> STATE seems to be critical to a number of words in ANS.  I.e., it
> seems impossible to be able to implement them without STATE.

The concept is important. Defining it as a variable isn't, as folks here 
have repeatedly demonstrated.

> STATE also seems to be required to implement a historical Forth
> interpreter.

Well, it was used is some old systems, but not all. FORTH, Inc. didn't 
use it from the early 80's to mid-90's, and only went back to it because 
it was in Forth94 and we wanted to be standard.

> Despite the standard recommendation to use POSTPONE , I found that
> using COMPILE and [COMPILE] keeps things clearly marked in my
> system definitions.  You need to know which is which in regards to
> immediacy when coding a definition.  But, otherwise, I don't like
> having two words for the job of one.  For user code, POSTPONE is
> probably better.  It works 98% of the time without the user
> knowing what type of word is being compiled.

Yes, POSTPONE is primarily a portability tool.

> For an interpreted Forth, [ ] just switch a Forth interpreter's
> STATE variable from interpret to compile.  I.e., it tells the
> inner/address interpreter to either compile or interpret/execute a
> word.
>
> For my interpreter, these set STATE:
>
>    : ; [ ] QUIT
>
> These check STATE:
>
>    LITERAL S" ." C" QUIT TO
>    inner_interpreter_routine_which_compiles_words
>    inner_interpreter_routine_which_interprets_words

That's a common strategy.

> LITERAL is on my "To Do." list to have STATE removed.  But, ANS
> seems to require STATE for S" ." and C" .  How does one implement
> them without it?  STATE also seems to required in Forth
> interpreters for QUIT : ; [ ] and the inner/address interpreter.
> How does a compiled Forth implement two states, compile and
> interactive, without STATE?  STATE or it's equivalent seems to be
> required even for compiled Forths to implement two modes.  STATE's
> use might be minimized, but it seems to still be required.

People here have described many alternatives, including different search 
orders during compiling and interpreting, having two different INTERPRET 
loops, many possible options.

>> Multiple CFA's is simplistic (and an implementation detail which
>> should not be enshrined in a standard), but given the umbilical
>> nature of modern Forth such an approach need not be wasteful, in
>> the sense that code generated need not retain the extra header
>> fields in run time code produced ... (or any headers at all for
>> that matter).
>>
>
> CFA's can be completely eliminated *if* you have STATE.
>
> However, if you decide to eliminate STATE, then you either 1) need
> to break STATE-aware words apart into separate words for each mode
> of operation, or 2) need multiple CFA's.

...or some other strategy.

>> [...]
>> How might one describe a standardized language similar to Forth
>> in such a way as to avoid the run-time/compile-time semantics,
> [...]

That is the important point. It's not as hard to write some code as it 
is to write normative text that is both clear and precise in describing 
this concept.

> _Everyone_ here is always touting Forth because it's so
> interactive.  That's like one of the top ten if not the first
> ranked ability of Forth.  Well, without STATE-aware words, you
> can't create and use the exact same code sequence both
> interactively and in a colon-definition.  That's only possible
> with STATE-aware words.  It's a waste of time if you attempt it.
> So, how interactive is Forth without STATE-aware words?  I.e., not
> as interactive as it could be or was once...  When the use of
> STATE-aware words declined, Forth words for each mode of operation
> appeared, such as '(tick) and ['] or COMPILE and [COMPILE] etc.
> With mode based words, to me, it's as if Forth lost much of it's
> interactive "character".  Personally, I happen to like a Forth
> where a Forth word works EXACTLY the same way whether used
> interactively or compiled into a definition.  AIUI, that means
> some STATE-aware words.  But, I don't like this because of the
> interactiveness.  I like it because of the consistency.  I.e., it
> works the same in both modes, and it's available in both modes.

The thing is, an interpreted ' and a compiled ' *do* do exactly the same 
thing, when they are executed. The point you're missing is that a 
compiled reference to ' executes when the word it's in is executed, just 
like + or DUP. Why should this come as a surprise? The word ['] is quite 
different from ' in that it compiles something, which ' does not. If it 
had the same name, *that* would be confusing.

>> but still allow create/does type extensibility?  Am I missing
>> something obvious?
>>
>
> How often is "create/does type extensibility" _actually_ used?  I
> think that's what you're missing.  Forget that CREATE .. DOES> is
> "one of the top ten ranked features of Forth" for a moment.  Let
> the myth and hyperbole lie.  How often is it truly and honestly
> used?  Can those situations be eliminated?  In my mind, the
> answers are "very infrequently", "very infrequently", "yes".
>
> AFAICT, CREATE .. DOES> is use a few times for certain system
> definitions, and it's used occasionally for data structures, ...
> It doesn't seem to be required or needed.
>
> Someone (Alex?) posted a word count from their system for other
> words recently.  Maybe, they can post the static frequency of
> CREATE and DOES> also.

Well, I just counted 38 uses of DOES> in SwiftForth (clean boot), but I 
find it used much more often in applications. Still, the magic of DOES> 
isn't in frequency of use, it's in the power that it gives you to make 
application-specific classes of words. Just a few appropriate uses can 
work wonders in cleaning up code and making it more readable.

Learning how to use DOES> effectively is part of learning to use Forth 
as Forth, rather than RPN C or some other language.

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]

#20162

Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> LITERAL is on my "To Do." list to have STATE removed.  But, ANS
> seems to require STATE for S" ." and C" .  How does one implement
> them without it?  STATE also seems to required in Forth interpreters
> for QUIT : ; [ ] and the inner/address interpreter.  How does a
> compiled Forth implement two states, compile and interactive,
> without STATE?

You have two separate loops, a compiler loop and an interpreter loop,
rather than a single loop that checks STATE on every word.  You don't
need STATE at all, but you might choose to set it in case anybody
wants to make a STATE-smart word.

> _Everyone_ here is always touting Forth because it's so interactive.
> That's like one of the top ten if not the first ranked ability of
> Forth.  Well, without STATE-aware words, you can't create and use
> the exact same code sequence both interactively and in a
> colon-definition.

No, you can't.  You can't completely do that with STATE-smart words
either.  It's of little consequence to practical Forth use.

> That's only possible with STATE-aware words.  It's a waste of time
> if you attempt it.  So, how interactive is Forth without STATE-aware
> words?  I.e., not as interactive as it could be or was once...  When
> the use of STATE-aware words declined, Forth words for each mode of
> operation appeared, such as '(tick) and ['] or COMPILE and [COMPILE]
> etc.  With mode based words, to me, it's as if Forth lost much of
> it's interactive "character".  Personally, I happen to like a Forth
> where a Forth word works EXACTLY the same way whether used
> interactively or compiled into a definition.  AIUI, that means some
> STATE-aware words.  But, I don't like this because of the
> interactiveness.  I like it because of the consistency.  I.e., it
> works the same in both modes, and it's available in both modes.

That's a mistake because STATE-smart words are very difficult to use
correctly when metaprogramming.  And metaprogramming is far more
important in application development than such niceties as having a
'(tick) that seems to work consistently in compile and interpret mode.

> How often is "create/does type extensibility" _actually_ used?

Eh?  All the time.  That's one of the key tools for defining
application data structures.  It's not much used in Forth itself, but
it's for applications.

> I think that's what you're missing.  Forget that CREATE .. DOES> is
> "one of the top ten ranked features of Forth" for a moment.  Let the
> myth and hyperbole lie.  How often is it truly and honestly used?

Like I said, all the time.

> Can those situations be eliminated?

Well, yes, if you want to dumb down Forth to reverse polish C.  But
what would be the point of that?  If you want C, use C.

Andrew.

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

#20226

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:z5-dnZku3IgfWqzMnZ2dnUVZ_g-dnZ2d@supernews.com...
> Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:

> > LITERAL is on my "To Do." list to have STATE removed.  But,
> > ANS seems to require STATE for S" ." and C" .  How does one
> > implement them without it?  STATE also seems to required in
> > Forth interpreters for QUIT : ; [ ] and the inner/address
> > interpreter.  How does a compiled Forth implement two states,
> > compile and interactive, without STATE?
>
> You have two separate loops, a compiler loop and an interpreter
> loop, rather than a single loop that checks STATE on every word.
> You don't need STATE at all, but you might choose to set it in
> case anybody wants to make a STATE-smart word.
>

1) First, my reply.

If the code is single threaded, then there is a mechanism to
selectively switch from one loop to the other, or there is a
mechanism that decides when to exit each loop and jump to the
other, etc.  That mechanism is effectively "STATE".

If the code is executed in parallel, then each loop must have
methods to both start execution and halt execution which work
together, since both can't operate on the input stream at the same
time.  That mechanism is effectively "STATE".

As long as there is a compiler loop and an interpreter loop,
I don't see how you can eliminate STATE or it's equivalent.


2) Second, I think you might be insterested.

Originally, my code was based on fig-Forth, but I structured the
inner interpreter based on your 2009 post.  You later updated that
code, which I didn't use.  I was going to restructure it to use
the exact fig-Forth method.  It seems to have fewer state
changes...  Well, I haven't done that yet or maybe never.
However, I've since re-written my code to stay in the
'interpreter' or 'compiler' until the STATE changes.  That
increased the speed of my interpreter.

Originally, I had three words like in your post: 'interpret',
'interpreter', 'compiler', basically the same.  Now, I have just
two.  My code for these is internal and  I haven't converted them
to high-level Forth yet.  It uses 'branch' and 'zbranch' instead
of high-level control-flow.  Converting absolute and conditional
branches to high-level IF-ELSE-THEN and BEGIN AGAIN loops isn't
easy since they're unstructured.  However, I basically just
patched in "STATE @ IF" sections into 'interpreter' and 'compiler'
which call each other, ping-pong style...  Both become loops,
i.e., stay in that mode until a STATE change occurs.  That allowed
'interpret' to be removed ('inter-loop' in your second post).
QUIT now calls the 'interpreter' word directly.  The visible Forth
word INTERPRET in the dictionary was redirected from 'interpret'
to 'interpreter'.

So, since my code isn't high-level and slightly different, I'll
attempt to correctly place the "STATE @ IF" sequences and looping
into your sample code from 2009.  That way you can get an idea of
what I did.

(untested, constructed)
: QUIT   ...   interpreter ...   ;

: interpreter
  begin
   find if execute state @ if compiler then else  >number  then
  again
;

 \ execute drops back to QUIT if the word is not found
 \ in the dictionary by executing a special null word...

: compiler
  begin
   find if  immediate? if  execute  else  compile,  then
     else  >number  ,literal  then state @ if 0= exit then
  again
;

  \ If I didn't do that correctly in high-level Forth, then the
  \ "state @ if 0= exit then" is supposed to exit 'compiler'
  \ if STATE is for interpret mode and return to 'interpreter'
  \ where 'compiler' was called


Your posts:
https://groups.google.com/group/comp.lang.forth/msg/68915cdba3b07323?dmode=source
https://groups.google.com/group/comp.lang.forth/msg/dd2d8e7342aa17c6?dmode=source

HTH,


Rod Pemberton

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

#20227

On 3/3/13 1:09 PM, Rod Pemberton wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:z5-dnZku3IgfWqzMnZ2dnUVZ_g-dnZ2d@supernews.com...
>> Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
>
>>> LITERAL is on my "To Do." list to have STATE removed.  But,
>>> ANS seems to require STATE for S" ." and C" .  How does one
>>> implement them without it?  STATE also seems to required in
>>> Forth interpreters for QUIT : ; [ ] and the inner/address
>>> interpreter.  How does a compiled Forth implement two states,
>>> compile and interactive, without STATE?
>>
>> You have two separate loops, a compiler loop and an interpreter
>> loop, rather than a single loop that checks STATE on every word.
>> You don't need STATE at all, but you might choose to set it in
>> case anybody wants to make a STATE-smart word.
>>
>
> 1) First, my reply.
>
> If the code is single threaded, then there is a mechanism to
> selectively switch from one loop to the other, or there is a
> mechanism that decides when to exit each loop and jump to the
> other, etc.  That mechanism is effectively "STATE".
>
> If the code is executed in parallel, then each loop must have
> methods to both start execution and halt execution which work
> together, since both can't operate on the input stream at the same
> time.  That mechanism is effectively "STATE".
>
> As long as there is a compiler loop and an interpreter loop,
> I don't see how you can eliminate STATE or it's equivalent.

The concept of state is essential. A variable with that name isn't.

Doing it with two loops rather than a variable really quite simple: the 
"compile" loop is launched by :, :NONAME, or ] and runs until exited by 
; or [ . The "interpret" loop is the outer loop, which parsed and 
executed : etc., so when the "compile" loop is finished, you drop back 
into the "interpret" loop.

The only reason a variable STATE is required is to provide portability 
for code written using a system that depended on it.

The concept of words that "must only be used inside a colon definition" 
isn't difficult. All languages have similar concepts, and in my 
experience Forth newbies accept it with no confusion. Understanding the 
correct use of words with two behaviors depending in compilation state 
is a lot more difficult, which is why it's nice to avoid them.

Implementation note: if ] is really the word that runs the compile loop, 
then : and :NONAME can simply call it when they're ready to start compiling.

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]

#20233

Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:z5-dnZku3IgfWqzMnZ2dnUVZ_g-dnZ2d@supernews.com...
>> Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> 
>> > LITERAL is on my "To Do." list to have STATE removed.  But,
>> > ANS seems to require STATE for S" ." and C" .  How does one
>> > implement them without it?  STATE also seems to required in
>> > Forth interpreters for QUIT : ; [ ] and the inner/address
>> > interpreter.  How does a compiled Forth implement two states,
>> > compile and interactive, without STATE?
>>
>> You have two separate loops, a compiler loop and an interpreter
>> loop, rather than a single loop that checks STATE on every word.
>> You don't need STATE at all, but you might choose to set it in
>> case anybody wants to make a STATE-smart word.
> 
> 1) First, my reply.
> 
> If the code is single threaded, then there is a mechanism to
> selectively switch from one loop to the other, or there is a
> mechanism that decides when to exit each loop and jump to the
> other, etc.  That mechanism is effectively "STATE".

No, it's just a call: the compiler loop is called by the interpreter
loop.  The compiler loop is just a word.

> If the code is executed in parallel, then each loop must have
> methods to both start execution and halt execution which work
> together, since both can't operate on the input stream at the same
> time.  That mechanism is effectively "STATE".
> 
> As long as there is a compiler loop and an interpreter loop,
> I don't see how you can eliminate STATE or it's equivalent.

It's really very simple: there is not STATE, no trickery.  ] is a word
that enters the compilation loop, and [ or ; exits it.  

> 2) Second, I think you might be insterested.
> 
> Originally, my code was based on fig-Forth, but I structured the
> inner interpreter based on your 2009 post.

I see.  Sure, that post more or less described the STATEful way that
Standard Forth does it.

Andrew.

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

#20237

"Rod Pemberton" <do_not_have@notemailnotz.cnm> writes:
> (untested, constructed)
> : QUIT   ...   interpreter ...   ;
>
> : interpreter
>   begin
>    find if execute state @ if compiler then else  >number  then
>   again
> ;
>
>  \ execute drops back to QUIT if the word is not found
>  \ in the dictionary by executing a special null word...
>
> : compiler
>   begin
>    find if  immediate? if  execute  else  compile,  then
>      else  >number  ,literal  then state @ if 0= exit then
>   again
> ;

My suggestion for a simplistic STATE-less interpreter would be
(also untested, but based on working code):


: finders:   create ' , ' , ' ,   does> swap 1+ cells + @ execute ;
: literal,   number postpone literal ; ( number from fig-Forth )

finders: execute-xt   execute number execute
finders: compile-xt   compile, literal, execute
defer interpret-xt

: interpret
   begin
      refill
   while
      begin source? while bl word find interpret-xt repeat
   repeat ;

: quit   ( reset return stack )
         ( reset input source )
         execute-xt is interpret-xt
         begin interpret ."  ok" cr again ;

: [   ( 0 state ! ) quit ; immediate

: ]   ( 1 state ! )
      compile-xt is interpret-xt
      begin interpret again ;

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

#20165

On Thu, 28 Feb 2013 11:35:32 -0500, Rob Sciuk <rob@controlq.com>
wrote:

>I'm wondering if, as the arguments proffered in that other thread seem to 
>indicate, state-fulness is generally considered a bad thing, then perhaps 
>a future Forth standard should address the issue head on???  I must 
>confess that I have always found [ ] postpone and friends to be confusing.

The problem is that implementing state-smart behaviour using the only
standard form available is bad. Implementing it in other ways is not.
IMHO the standard after Forth2012 should consider how to standardise
a notation to do this.

The only available standard template is

: foo
  state @ if  ...  else  ...  then
; immediate

Anton's analysis of this is correct. However, there's no standard
alternative. In addition, the proposition that there should be two
words such as CHAR and [CHAR] is not popular among application
programmers, who really like being able to use words such as
." in both compilation and interpretation modes.

Below is a slightly simplified version of ." in VFX Forth. It avoids
the problems of the classical approach above.

: (.")          \ --
\ 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.

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]

#20168

On 02.03.2013 12:34, Stephen Pelc wrote:
> On Thu, 28 Feb 2013 11:35:32 -0500, Rob Sciuk <rob@controlq.com>
> wrote:
>
>> I'm wondering if, as the arguments proffered in that other thread seem to
>> indicate, state-fulness is generally considered a bad thing, then perhaps
>> a future Forth standard should address the issue head on???  I must
>> confess that I have always found [ ] postpone and friends to be confusing.
>
> The problem is that implementing state-smart behaviour using the only
> standard form available is bad. Implementing it in other ways is not.
> IMHO the standard after Forth2012 should consider how to standardise
> a notation to do this.
>
> The only available standard template is
>
> : foo
>    state @ if  ...  else  ...  then
> ; immediate
>
> Anton's analysis of this is correct. However, there's no standard
> alternative. In addition, the proposition that there should be two
> words such as CHAR and [CHAR] is not popular among application
> programmers, who really like being able to use words such as
> ." in both compilation and interpretation modes.
>
> Below is a slightly simplified version of ." in VFX Forth. It avoids
> the problems of the classical approach above.
>
> : (.")          \ --
> \ 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.
>
> Stephen
>
>

Since long I use COMPILES> similar to DOES>

: <DUALWORD>
   <interpretation-semantics> COMPILES> <compilation-semantics> ;

The dictionary headers have two corresponding execution tokens. And I 
don't need extra flags for immediate words or compilation-only words.

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

#20169

Stephen Pelc wrote:
> The problem is that implementing state-smart behaviour using the only
> standard form available is bad. Implementing it in other ways is not.
> IMHO the standard after Forth2012 should consider how to standardise
> a notation to do this.

Yes; IMHO we are at about the point to start doing this; as some Forth 
systems have converted to a smart compile, - an approach we didn't use 
before.

> : ."            \ "ccc<quote>"  --
> \ Output the text up to the closing double-quotes character.
>   [char] " word $.
> ;
> comp: ( xt -- )  drop  ['] (.") compile,  ",  ;

Gforth's development version now has a smart compile,, too, and the syntax 
to use it is pretty similar to your comp:, so well, I should better just 
call it comp: to avoid unnecessary discussions about how it's named.  The 
semantics is identical, it gets an xt.  You can have comp: (or compile> as 
it is called now) also inside a definition, which then, like DOES>, 
overrides the compile,-method of the last definition.

This however requires that we also need to "set the words right", because 
the execution and compilation semantics as written in the standard now are 
not clear enough for this approach.  Anton at least opposes the idea that 
COMPILE, is for the compilation semantics, because now it a) isn't, and b) 
is not defined that way.

BTW: I'm *not* happy with using something like compile>/comp: inside a 
definition.  Like DOES>, it tears the definition into two parts, ending the 
first, and starting a second one, and thus means that you can't go on and 
adding e.g. a DOES>, or a TO-behavior (which we don't need to discuss here, 
but is available in Gforth-current).  Quotations are more handy for that, 
the "assing an xt to the compile, method of the last defined definition" in 
Gforth it is now !COMPILE, (preliminary), in VFX ist is SET-COMPILER (and 
there is a GET-COMPILER, which deems to be not very useful - the more 
generic, to get the compiler method of any XT, would be sufficient).

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

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

#20182

On Sat, 2 Mar 2013, Stephen Pelc wrote:

[snip]

> Note that ." is not IMMEDIATE - it just has separate interpretation
> and compilation behaviours. The problem is just to standardise the
> notation.
>
> Stephen

Stephen, thanks for your reply, in fact thanks to all, I appreciate the 
views expressed thus far.

You bring up the concept of immediacy, and it occurs that it is the 
combination of STATE and IMMEDIACY which allows the language extension 
facility.

Immediate words seem to inherently require state awareness to properly lay 
down the correct run time behaviours during compilation.

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

ok ' ascii see
-- ascii (5058e0) flg: 1 is coded in C (403060).
ok ascii x .
120 ok : z ascii x . cr ;
ok z
120
ok ' z see
-- z (507c00) word flg: 0.
50bc08  (literal) = 120
50bc18  .
50bc20  cr
50bc28  next
ok

I suppose I'm wondering if there is a more elegant mechanism to reconcile 
compiling words such that *ALL* words are equivalent, and have for lack of 
a better term, BOTH run time and compile time forks, rather than the 
current situation where some words are "special" by means of having 
immediacy (or not), and state awareness (or not).

Currently, immediacy and state awareness accrue only to certain "special" 
words.  I'm not saying that this is either good or bad, I'm just wondering 
if there is an alternative implementation where such differentiation is 
unnecessary and all words simply do the right thing in any context???

Cheers,
Rob.

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

#20191

Rob Sciuk <rob@controlq.com> wrote:

> 
> Immediate words seem to inherently require state awareness to properly lay 
> down the correct run time behaviours during compilation.

That's not true.

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

No.  The right way (IMO, YMMV, etc.) to do this is to have two words,
one immediate and one not.  The standard names for these words are
[CHAR] and CHAR.  Like this:

: char ( "name" -- char )   bl word 1+ c@ ;
: [char] ( -- )   char  postpone literal ;  immediate

It's important to separate CHAR and [CHAR] because sometimes you want
to use CHAR (the non-immediate form that parses a char and pushes it
onto the stack) inside a definition.  POSTPONE CHAR doesn't get you
the behaviour you need because when CHAR eventually executes it's
STATE-smart: whether it pushes a character onto the stack or compiles
a character depends on STATE.  You can't control it.  If you really
need the CHAR behaviour regardless of STATE, you're stuck.

Andrew.

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

#20192

In article <P-qdnRKtTO2H6a_MnZ2dnUVZ_uudnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Rob Sciuk <rob@controlq.com> wrote:
>
>>
>> Immediate words seem to inherently require state awareness to properly lay
>> down the correct run time behaviours during compilation.
>
>That's not true.
>
>> 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.
>
>No.  The right way (IMO, YMMV, etc.) to do this is to have two words,
>one immediate and one not.  The standard names for these words are
>[CHAR] and CHAR.  Like this:
>
>: char ( "name" -- char )   bl word 1+ c@ ;
>: [char] ( -- )   char  postpone literal ;  immediate
>
>It's important to separate CHAR and [CHAR] because sometimes you want
>to use CHAR (the non-immediate form that parses a char and pushes it
>onto the stack) inside a definition.  POSTPONE CHAR doesn't get you
>the behaviour you need because when CHAR eventually executes it's
>STATE-smart: whether it pushes a character onto the stack or compiles
>a character depends on STATE.  You can't control it.  If you really
>need the CHAR behaviour regardless of STATE, you're stuck.

Or use &C for a number-like thing. Nobody is tempted to do
POSTPONE &C  and if you can separate the & at all, you know you're
extending a very carnal part of the system.
Use &C as a number. No more headaches.

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

#20195

Albert van der Horst wrote:

> In article <P-qdnRKtTO2H6a_MnZ2dnUVZ_uudnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>>It's important to separate CHAR and [CHAR] because sometimes you want
>>to use CHAR (the non-immediate form that parses a char and pushes it
>>onto the stack) inside a definition.  POSTPONE CHAR doesn't get you
>>the behaviour you need because when CHAR eventually executes it's
>>STATE-smart: whether it pushes a character onto the stack or compiles
>>a character depends on STATE.  You can't control it.  If you really
>>need the CHAR behaviour regardless of STATE, you're stuck.
> 
> Or use &C for a number-like thing. Nobody is tempted to do
> POSTPONE &C

Works fine with current Gforth, the recognizers do the magic:

: test postpone &5 ;  immediate  ok
: test1 test ;  ok
see test1 
: test1  
  5 ; ok

If you have a special-compilation-word, you can access both the interpreter 
and the compiler part without troubles, too:

: foo ." Interpreting" ; comp: ( xt -- ) drop ." Compiling" ;  ok
: test1 ['] foo execute ;  ok
: test2 postpone foo ;  ok
test1 Interpreting ok
test2 Compiling ok

Note that by how the standard is written, both ['] foo execute and postpone 
foo do what they should - one is providing the interpretation semantics, the 
other the compilation semantics.  What' *not* according to the standard is 
['] foo compile, since that should add the execution semantics to the 
current definition (default compile, behavior).

Now, we are mostly fine in so far as comp: is not a standard word, and 
therefore words modified by comp: don't have to behave like standard words.  
But what about standard words that have been defined using comp:?

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

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

#20209

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Note that by how the standard is written, both ['] foo execute and postpone 
>foo do what they should - one is providing the interpretation semantics, the 
>other the compilation semantics.  What' *not* according to the standard is 
>['] foo compile, since that should add the execution semantics to the 
>current definition (default compile, behavior).
>
>Now, we are mostly fine in so far as comp: is not a standard word, and 
>therefore words modified by comp: don't have to behave like standard words.  
>But what about standard words that have been defined using comp:?

Given that these words were intended to be implementable as
STATE-smart words, and such words don't always behave as specified
when ticked and then compile,d, one might weasel out of that, too.

However, what I am worried about is that your approach breaks the
currently existing relation between EXECUTE and COMPILE,.  Currently I
know that, when I write some tool that processes xts in some way, I
can COMPILE, these xts, and when they run, they will do what they
would have done if I had EXECUTEd them right away.

Say, if I know that I want to EXECUTE a sequence of xts several times,
I can define a colon definition, COMPILE, the xts into it, and then
call the colon definition several times.  With your approach, I could
no lonmger do that; you suggested that I should replace COMPILE, with
POSTPONE LITERAL POSTPONE EXECUTE, but that's neither nice nor fast.

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

#20220

Anton Ertl wrote:
> However, what I am worried about is that your approach breaks the
> currently existing relation between EXECUTE and COMPILE,.  Currently I
> know that, when I write some tool that processes xts in some way, I
> can COMPILE, these xts, and when they run, they will do what they
> would have done if I had EXECUTEd them right away.

Not really.  Consider you start with the state-smart world, and you compile 
in compilation state into a word that might later run in interpretation 
state.  If you EXECUTEd them right away, they would show their compilation 
semantics, if you COMPILE,d them, they would later show their interpretation 
semantics.  Or their compilation semantics, if the assumption above is 
wrong.

> Say, if I know that I want to EXECUTE a sequence of xts several times,
> I can define a colon definition, COMPILE, the xts into it, and then
> call the colon definition several times.  With your approach, I could
> no lonmger do that; you suggested that I should replace COMPILE, with
> POSTPONE LITERAL POSTPONE EXECUTE, but that's neither nice nor fast.

If you actually need that property.  For me, this looks like an academic 
exercise.  I've built my fair share of hand-written compilers.  They usually 
use the fragment Mitch Bradley posted to clarify what COMPILE, was for, i.e. 
that FIND 0> IF EXECUTE ELSE COMPILE, THEN, because they wanted the 
compilation semantics of the words found, not the interpretation semantics.  
This is the common case.  The fact that we need to look at a result from 
FIND, which is not passed on with the xt to decide whether to use EXECUTE or 
COMPILE, shows that this solution will have problems (and the problems are 
in the xt, which is why we can't find a good replacement for FIND).

The uncommon case, where you need this ['] foo execute style is where you 
deliberately want the interpretation semantics.  We don't actually have a 
POSTPONE compagnion for doing that, so I doubt it is of much use.  Rather 
the contrary: We do have POSTPONE, because this is what we want, and we 
don't want to distinguish between immediate and non-immediate words: We want 
compilation semantics.  POSTPONE is for named words, COMPILE, for xts, but 
because the immediate flag is lost when going to the xt, COMPILE, can't do 
its job properly.  IMHO that part of COMPILE,'s functionality you want is 
the one that is only there by accident - since STATE + IMMEDIATE are not a 
good way to have compilation macros.

BTW: for the state-smart implementations, it won't work either way.  
COMPILE, will just preserve the state-smart nature of the word, just as well 
as ]] LITERAL EXEUCTE [[ will (no difference there).

A typical hand-written compiler is e.g. the scoping and super call in an OOP 
package, which forces early binding, either to the particular class you 
selected, or to the super class.  You first look up the actual xt in the 
vtable (do the binding), and then what do you want with the token?  Compile 
it.  If it has special compilation semantics, you probably want it.

The only place in Gforth where the new semantics might case problems is in 
DEFERS.  DEFERS takes the action of a deferred word, and compiles it.  Note 
that a deferred word itself can only expose the execution semantics of the 
word bound to it, so the definition

: defers ( "name" -- ) ' defer@ compile, ; immediate compile-only

is actually not correct.  It should use that ]] literal execute [[ thing.  
The same thing for the OOP early binding, because the vtable also can only 
do EXECUTE, and therefore, COMPILE, would be wrong.

However, despite defers is used not so infrequently, this didn't cause any 
problem.

The most interesting piece here is probably porting BerndOOF to this 
approach, because in BerndOOF, you have methods with special compilation 
semantics.  But they aren't polymorph... though with the state-smart 
approach, that would have worked.

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

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

#20222

On Sun, 03 Mar 2013 22:42:31 +0100, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>The uncommon case, where you need this ['] foo execute style is where you 
>deliberately want the interpretation semantics.  We don't actually have a 
>POSTPONE compagnion for doing that, so I doubt it is of much use.

VFX provides
  [INTERP] <name
for this because we needed it once or twice.

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]

#20231

On Mar 3, 9:42 pm, Bernd Paysan <bernd.pay...@gmx.de> wrote:
> Anton Ertl wrote:
> > However, what I am worried about is that your approach breaks the
> > currently existing relation between EXECUTE and COMPILE,.  Currently I
> > know that, when I write some tool that processes xts in some way, I
> > can COMPILE, these xts, and when they run, they will do what they
> > would have done if I had EXECUTEd them right away.
>
> Not really.  Consider you start with the state-smart world, and you compile
> in compilation state into a word that might later run in interpretation
> state.  If you EXECUTEd them right away, they would show their compilation
> semantics, if you COMPILE,d them, they would later show their interpretation
> semantics.  Or their compilation semantics, if the assumption above is
> wrong.
>
> > Say, if I know that I want to EXECUTE a sequence of xts several times,
> > I can define a colon definition, COMPILE, the xts into it, and then
> > call the colon definition several times.  With your approach, I could
> > no lonmger do that; you suggested that I should replace COMPILE, with
> > POSTPONE LITERAL POSTPONE EXECUTE, but that's neither nice nor fast.
>
> If you actually need that property.  For me, this looks like an academic
> exercise.  I've built my fair share of hand-written compilers.  They usually
> use the fragment Mitch Bradley posted to clarify what COMPILE, was for, i.e.
> that FIND 0> IF EXECUTE ELSE COMPILE, THEN, because they wanted the
> compilation semantics of the words found, not the interpretation semantics.
> This is the common case.  The fact that we need to look at a result from
> FIND, which is not passed on with the xt to decide whether to use EXECUTE or
> COMPILE, shows that this solution will have problems (and the problems are
> in the xt, which is why we can't find a good replacement for FIND).
>
> The uncommon case, where you need this ['] foo execute style is where you
> deliberately want the interpretation semantics.  We don't actually have a
> POSTPONE compagnion for doing that, so I doubt it is of much use.  Rather
> the contrary: We do have POSTPONE, because this is what we want, and we
> don't want to distinguish between immediate and non-immediate words: We want
> compilation semantics.  POSTPONE is for named words, COMPILE, for xts, but
> because the immediate flag is lost when going to the xt, COMPILE, can't do
> its job properly.  IMHO that part of COMPILE,'s functionality you want is
> the one that is only there by accident - since STATE + IMMEDIATE are not a
> good way to have compilation macros.
>
> BTW: for the state-smart implementations, it won't work either way.
> COMPILE, will just preserve the state-smart nature of the word, just as well
> as ]] LITERAL EXEUCTE [[ will (no difference there).
>
> A typical hand-written compiler is e.g. the scoping and super call in an OOP
> package, which forces early binding, either to the particular class you
> selected, or to the super class.  You first look up the actual xt in the
> vtable (do the binding), and then what do you want with the token?  Compile
> it.  If it has special compilation semantics, you probably want it.
>
> The only place in Gforth where the new semantics might case problems is in
> DEFERS.  DEFERS takes the action of a deferred word, and compiles it.  Note
> that a deferred word itself can only expose the execution semantics of the
> word bound to it, so the definition
>
> : defers ( "name" -- ) ' defer@ compile, ; immediate compile-only
>
> is actually not correct.  It should use that ]] literal execute [[ thing.
> The same thing for the OOP early binding, because the vtable also can only
> do EXECUTE, and therefore, COMPILE, would be wrong.
>
> However, despite defers is used not so infrequently, this didn't cause any
> problem.
>
> The most interesting piece here is probably porting BerndOOF to this
> approach, because in BerndOOF, you have methods with special compilation
> semantics.  But they aren't polymorph... though with the state-smart
> approach, that would have worked.
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"http://bernd-paysan.de/

Can we not think of the problem 'the other way around' for a minute?
Maybe it would be useful.

We're pointing the finger at "state-smart" (using the conventional
meaning ;-) words because we cannot differentiate interpretation
semantics from compilation sematics via tick.

So, rotating the problem by 180 degrees, the problem is tick, not the
state-smart words themselves.

Therefore, simply standardise a new word, something like 'I (which
means 'tick the *interpretation* behaviour/address/cfa/whatever' of
the word.

Of course, this has implications on the underlying architecture, and
raises further questions. Now the dictionary (presumably) must be able
to store pointers to both the compilation (for regular ') and
interpretation semantics (for 'I ). Furthermore, what happens if the
word has no interpretation sematics? Do you return the compilation
sematics as a default, or return a 0 to expressly indicate that there
are no interpretation semantics? All open for argument.

Discuss.

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

#20262

Mark Wills wrote:
> Can we not think of the problem 'the other way around' for a minute?
> Maybe it would be useful.
> 
> We're pointing the finger at "state-smart" (using the conventional
> meaning ;-) words because we cannot differentiate interpretation
> semantics from compilation sematics via tick.

Actually, the problem goes a bit deeper, it is the xt returned by ' and 
FIND.  This xt is the problem, it does not allow straight-forward access to 
its interpretation and compilation semantics.  Especially since the 
immediate flag is lost, the xt does not know if it is immediate or not.

Smart COMPILE, fixes that.  But then, it somewhat changes the meaning of 
COMPILE,.

> Therefore, simply standardise a new word, something like 'I (which
> means 'tick the *interpretation* behaviour/address/cfa/whatever' of
> the word.

Or COMP' for ticking the compilation behavior, as ' always did return the xt 
for the interpretation semantics.

> Of course, this has implications on the underlying architecture, and
> raises further questions. Now the dictionary (presumably) must be able
> to store pointers to both the compilation (for regular ') and
> interpretation semantics (for 'I ). Furthermore, what happens if the
> word has no interpretation sematics? Do you return the compilation
> sematics as a default, or return a 0 to expressly indicate that there
> are no interpretation semantics? All open for argument.

The dual-token approach with ' for interpretation semantics and COMP' for 
compilation semantics has already been tried out, it's Anton's approach at 
solving the problem; it is in Gforth since quite some time.

It wasn't a full solution, since it required adding another type, the "name 
token", which still had all relevant informations, and converting that to an 
xt, these informations were lost.

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

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

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

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

csiph-web