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

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

STATE

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

Contents

  STATE MarkWills <markrobertwills@yahoo.co.uk> - 2011-04-27 12:41 -0700
    Re: STATE Alex McDonald <blog@rivadpm.com> - 2011-04-27 13:04 -0700
      Re: STATE MarkWills <markrobertwills@yahoo.co.uk> - 2011-04-27 13:13 -0700
        Re: STATE Alex McDonald <blog@rivadpm.com> - 2011-04-27 13:45 -0700
      Re: STATE "P.M.Lawrence" <pml540114@gmail.com> - 2011-04-28 03:00 -0700
        Re: STATE Alex McDonald <blog@rivadpm.com> - 2011-04-28 04:09 -0700
          Re: STATE Alex McDonald <blog@rivadpm.com> - 2011-04-28 04:10 -0700
    Re: STATE Micke <oh2aun@gmail.com> - 2011-04-27 13:20 -0700
      Re: STATE MarkWills <markrobertwills@yahoo.co.uk> - 2011-04-27 13:26 -0700
        Re: STATE MarkWills <markrobertwills@yahoo.co.uk> - 2011-04-27 13:30 -0700
        Re: STATE Elizabeth D Rather <erather@forth.com> - 2011-04-27 11:13 -1000
          Re: STATE Elizabeth D Rather <erather@forth.com> - 2011-04-27 17:17 -1000
          Re: STATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-29 06:14 -0500
            Re: STATE Elizabeth D Rather <erather@forth.com> - 2011-04-29 08:47 -1000
              Re: STATE MarkWills <markrobertwills@yahoo.co.uk> - 2011-04-29 14:07 -0700
    Re: STATE BruceMcF <agila61@netscape.net> - 2011-04-27 19:22 -0700
    Re: STATE BruceMcF <agila61@netscape.net> - 2011-04-30 08:18 -0700
    Re: STATE BruceMcF <agila61@netscape.net> - 2011-04-30 08:26 -0700
    Re: STATE "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-04-30 03:24 -0400
    Re: STATE stephenXXX@mpeforth.com (Stephen Pelc) - 2011-04-30 11:41 +0000
    Re: STATE stephenXXX@mpeforth.com (Stephen Pelc) - 2011-04-30 11:53 +0000
      Re: STATE BruceMcF <agila61@netscape.net> - 2011-04-30 08:48 -0700
    Re: STATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-28 08:59 +0000
      Re: STATE Brad <hwfwguy@gmail.com> - 2011-04-28 08:01 -0700
        Re: STATE Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-28 12:16 -0500
          Re: STATE Elizabeth D Rather <erather@forth.com> - 2011-04-28 09:47 -1000
        Re: STATE BruceMcF <agila61@netscape.net> - 2011-04-28 15:56 -0700
          Re: STATE Brad <hwfwguy@gmail.com> - 2011-04-29 07:49 -0700
            Re: STATE BruceMcF <agila61@netscape.net> - 2011-04-29 11:47 -0700
        Re: STATE anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-29 17:30 +0000
      Re: STATE Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-04-28 17:47 +0000
        Re: STATE Elizabeth D Rather <erather@forth.com> - 2011-04-28 09:50 -1000
    Re: STATE "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-04-28 16:32 -0400
      Re: STATE MarkWills <markrobertwills@yahoo.co.uk> - 2011-04-29 02:11 -0700
        Re: STATE BruceMcF <agila61@netscape.net> - 2011-04-29 07:24 -0700
        Re: STATE "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-04-29 13:56 -0400
          Re: STATE BruceMcF <agila61@netscape.net> - 2011-04-29 11:44 -0700
            Re: STATE "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-04-29 15:45 -0400
              Re: STATE Elizabeth D Rather <erather@forth.com> - 2011-04-29 10:22 -1000
              Re: STATE BruceMcF <agila61@netscape.net> - 2011-04-29 13:31 -0700
          Re: STATE Elizabeth D Rather <erather@forth.com> - 2011-04-29 09:07 -1000

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

#1582 — STATE

Just musing here... Is there any reason why (apart from historical
reasons) STATE should be a variable?

I'm struggling to think of a scenario in a running Forth program where
you'd want to set STATE to 0 (for example).

At interpret time, we have [ and ] which modify STATE. There really
seems to be little reason for STATE to be a variable. I would have
thought a Constant would have made more sense?

Regards

Mark

[toc] | [next] | [standalone]

#1584

On Apr 27, 8:41 pm, MarkWills <markrobertwi...@yahoo.co.uk> wrote:
> Just musing here... Is there any reason why (apart from historical
> reasons) STATE should be a variable?
>
> I'm struggling to think of a scenario in a running Forth program where
> you'd want to set STATE to 0 (for example).
>
> At interpret time, we have [ and ] which modify STATE. There really
> seems to be little reason for STATE to be a variable. I would have
> thought a Constant would have made more sense?
>
> Regards
>
> Mark

Here's my STATE;

variable _state 0 _state !
: state _state ; \ state is read-only

Only the kernel can modify _STATE (in [ ] and QUIT).

Having it as a CONSTANT would throw most optimisers a wobbly; many
compile and replace CONSTANTs with literals and optimise further.

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

#1585

On Apr 27, 9:04 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Apr 27, 8:41 pm, MarkWills <markrobertwi...@yahoo.co.uk> wrote:
>
> > Just musing here... Is there any reason why (apart from historical
> > reasons) STATE should be a variable?
>
> > I'm struggling to think of a scenario in a running Forth program where
> > you'd want to set STATE to 0 (for example).
>
> > At interpret time, we have [ and ] which modify STATE. There really
> > seems to be little reason for STATE to be a variable. I would have
> > thought a Constant would have made more sense?
>
> > Regards
>
> > Mark
>
> Here's my STATE;
>
> variable _state 0 _state !
> : state _state ; \ state is read-only
>
> Only the kernel can modify _STATE (in [ ] and QUIT).
>
> Having it as a CONSTANT would throw most optimisers a wobbly; many
> compile and replace CONSTANTs with literals and optimise further.

Hi Alex,

Ok, my head just exploded. How does that work? Your definition of
STATE returned the *address* of _state, not it's value. Therefore, it
can't be read-only, unless I'm missing something...?

Mark

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

#1589

On Apr 27, 9:13 pm, MarkWills <markrobertwi...@yahoo.co.uk> wrote:
> On Apr 27, 9:04 pm, Alex McDonald <b...@rivadpm.com> wrote:
>
>
>
>
>
>
>
>
>
> > On Apr 27, 8:41 pm, MarkWills <markrobertwi...@yahoo.co.uk> wrote:
>
> > > Just musing here... Is there any reason why (apart from historical
> > > reasons) STATE should be a variable?
>
> > > I'm struggling to think of a scenario in a running Forth program where
> > > you'd want to set STATE to 0 (for example).
>
> > > At interpret time, we have [ and ] which modify STATE. There really
> > > seems to be little reason for STATE to be a variable. I would have
> > > thought a Constant would have made more sense?
>
> > > Regards
>
> > > Mark
>
> > Here's my STATE;
>
> > variable _state 0 _state !
> > : state _state ; \ state is read-only
>
> > Only the kernel can modify _STATE (in [ ] and QUIT).
>
> > Having it as a CONSTANT would throw most optimisers a wobbly; many
> > compile and replace CONSTANTs with literals and optimise further.
>
> Hi Alex,
>
> Ok, my head just exploded. How does that work? Your definition of
> STATE returned the *address* of _state, not it's value. Therefore, it
> can't be read-only, unless I'm missing something...?
>
> Mark

Sorry, I should have explained; _STATE is in a read-only section of
the module, and only addressable from the kernel code too. Hence :
STATE _STATE ; that makes the address of _STATE visible in other code.

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

#1614

Alex McDonald wrote:
.
.
.
>
> Here's my STATE;
>
> variable _state 0 _state !
> : state _state ; \ state is read-only
>
> Only the kernel can modify _STATE (in [ ] and QUIT).
>
> Having it as a CONSTANT would throw most optimisers a wobbly; many
> compile and replace CONSTANTs with literals and optimise further.

I don't see how that delivers any different behaviour, unless you
meant to write something like

: state _state @ ;

Am I missing something? P.M.Lawrence.

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

#1616

On Apr 28, 11:00 am, "P.M.Lawrence" <pml540...@gmail.com> wrote:
> Alex McDonald wrote:
>
> .
> .
> .
>
>
>
> > Here's my STATE;
>
> > variable _state 0 _state !
> > : state _state ; \ state is read-only
>
> > Only the kernel can modify _STATE (in [ ] and QUIT).
>
> > Having it as a CONSTANT would throw most optimisers a wobbly; many
> > compile and replace CONSTANTs with literals and optimise further.
>
> I don't see how that delivers any different behaviour, unless you
> meant to write something like
>
> : state _state @ ;
>
> Am I missing something? P.M.Lawrence.

_STATE is in read-only memory, except for the kernel that can make it
writable, and the name is only available in the kernel. I omitted to
explain that in the first post.

I am, however, replacing it and stealing Anton's code below.

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

#1617

On Apr 28, 12:09 pm, Alex McDonald <b...@rivadpm.com> wrote:
> On Apr 28, 11:00 am, "P.M.Lawrence" <pml540...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
> > Alex McDonald wrote:
>
> > .
> > .
> > .
>
> > > Here's my STATE;
>
> > > variable _state 0 _state !
> > > : state _state ; \ state is read-only
>
> > > Only the kernel can modify _STATE (in [ ] and QUIT).
>
> > > Having it as a CONSTANT would throw most optimisers a wobbly; many
> > > compile and replace CONSTANTs with literals and optimise further.
>
> > I don't see how that delivers any different behaviour, unless you
> > meant to write something like
>
> > : state _state @ ;
>
> > Am I missing something? P.M.Lawrence.
>
> _STATE is in read-only memory, except for the kernel that can make it
> writable, and the name is only available in the kernel. I omitted to
> explain that in the first post.
>
> I am, however, replacing it and stealing Anton's code below.

Correction, BruceMcF's code below.

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

#1586

On Apr 27, 10:41 pm, MarkWills <markrobertwi...@yahoo.co.uk> wrote:
> Just musing here... Is there any reason why (apart from historical
> reasons) STATE should be a variable?
>
> I'm struggling to think of a scenario in a running Forth program where
> you'd want to set STATE to 0 (for example).
>
> At interpret time, we have [ and ] which modify STATE. There really
> seems to be little reason for STATE to be a variable. I would have
> thought a Constant would have made more sense?
>
> Regards
>
> Mark

In my FlashForth STATE is a word which leaves the value if STATE on
the stack.
It can only be changed by [ and ] .

So it looks like constant which can be changed by [ and ].

Not a standard solution but I have deviated from the standard in many
other ways as well.

Mike

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

#1587

On Apr 27, 9:20 pm, Micke <oh2...@gmail.com> wrote:
> On Apr 27, 10:41 pm, MarkWills <markrobertwi...@yahoo.co.uk> wrote:
>
> > Just musing here... Is there any reason why (apart from historical
> > reasons) STATE should be a variable?
>
> > I'm struggling to think of a scenario in a running Forth program where
> > you'd want to set STATE to 0 (for example).
>
> > At interpret time, we have [ and ] which modify STATE. There really
> > seems to be little reason for STATE to be a variable. I would have
> > thought a Constant would have made more sense?
>
> > Regards
>
> > Mark
>
> In my FlashForth STATE is a word which leaves the value if STATE on
> the stack.
> It can only be changed by [ and ] .
>
> So it looks like constant which can be changed by [ and ].
>
> Not a standard solution but I have deviated from the standard in many
> other ways as well.
>
> Mike

Hi Mike,

Well, I'm kind of in agreement with you. In reality, changing it now
would break a lot of legacy Forth code, but, with hindsight, I would
venture a better definition for state would be something like:

0 VALUE _state
: STATE? _state ;
HIDE _state

That is, STATE? (with a question mark) as in:

... STATE? IF ( compiling) ... ... ELSE ( interpreting) ... ... THEN


Regards

Mark

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

#1588

On Apr 27, 9:26 pm, MarkWills <markrobertwi...@yahoo.co.uk> wrote:
> On Apr 27, 9:20 pm, Micke <oh2...@gmail.com> wrote:
>
>
>
> > On Apr 27, 10:41 pm, MarkWills <markrobertwi...@yahoo.co.uk> wrote:
>
> > > Just musing here... Is there any reason why (apart from historical
> > > reasons) STATE should be a variable?
>
> > > I'm struggling to think of a scenario in a running Forth program where
> > > you'd want to set STATE to 0 (for example).
>
> > > At interpret time, we have [ and ] which modify STATE. There really
> > > seems to be little reason for STATE to be a variable. I would have
> > > thought a Constant would have made more sense?
>
> > > Regards
>
> > > Mark
>
> > In my FlashForth STATE is a word which leaves the value if STATE on
> > the stack.
> > It can only be changed by [ and ] .
>
> > So it looks like constant which can be changed by [ and ].
>
> > Not a standard solution but I have deviated from the standard in many
> > other ways as well.
>
> > Mike
>
> Hi Mike,
>
> Well, I'm kind of in agreement with you. In reality, changing it now
> would break a lot of legacy Forth code, but, with hindsight, I would
> venture a better definition for state would be something like:
>
> 0 VALUE _state
> : STATE? _state ;
> HIDE _state
>
> That is, STATE? (with a question mark) as in:
>
> ... STATE? IF ( compiling) ... ... ELSE ( interpreting) ... ... THEN
>
> Regards
>
> Mark

Or, just to be properly correct ;-)

<pedantry>
0 VALUE _state
: STATE? _state ;
: [  0 TO _state ; IMMEDIATE
: ]  1 TO _state ; IMMEDIATE
HIDE _state
</pedantry>

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

#1591

On 4/27/11 10:26 AM, MarkWills wrote:
> On Apr 27, 9:20 pm, Micke<oh2...@gmail.com>  wrote:
>> On Apr 27, 10:41 pm, MarkWills<markrobertwi...@yahoo.co.uk>  wrote:
>>
>>> Just musing here... Is there any reason why (apart from historical
>>> reasons) STATE should be a variable?
>>
>>> I'm struggling to think of a scenario in a running Forth program where
>>> you'd want to set STATE to 0 (for example).
>>
>>> At interpret time, we have [ and ] which modify STATE. There really
>>> seems to be little reason for STATE to be a variable. I would have
>>> thought a Constant would have made more sense?
>>
>>> Regards
>>
>>> Mark
>>
>> In my FlashForth STATE is a word which leaves the value if STATE on
>> the stack.
>> It can only be changed by [ and ] .
>>
>> So it looks like constant which can be changed by [ and ].
>>
>> Not a standard solution but I have deviated from the standard in many
>> other ways as well.
>>
>> Mike
>
> Hi Mike,
>
> Well, I'm kind of in agreement with you. In reality, changing it now
> would break a lot of legacy Forth code, but, with hindsight, I would
> venture a better definition for state would be something like:
>
> 0 VALUE _state
> : STATE? _state ;
> HIDE _state
>
> That is, STATE? (with a question mark) as in:
>
> ... STATE? IF ( compiling) ... ... ELSE ( interpreting) ... ... THEN

The principal (really, the *sole*) reason for keeping STATE a variable 
is to avoid breaking legacy Forth code.  polyFORTH, for example, didn't 
use STATE as a flag for about 10 years ( ] actually ran the compiler, 
and its address was placed in STATE by : etc.).  However, there is 
apparently a *lot* of legacy code that does expect STATE to be a simple 
flag stored in a variable, so although the Forth94 TC could think of 
lots of better ways to manage the information, there was sufficient 
demand to avoid breaking this code that the mandate went in as it is.

Trust me, if I had the dictatorial powers that Jeff Fox attributes to 
me, that (and a lot of things in Forth94) would be different!

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]

#1606

On 4/27/11 11:13 AM, Elizabeth D Rather wrote:
...
> The principal (really, the *sole*) reason for keeping STATE a variable
> is to avoid breaking legacy Forth code. polyFORTH, for example, didn't
> use STATE as a flag for about 10 years ( ] actually ran the compiler,
> and its address was placed in STATE by : etc.). However, there is
> apparently a *lot* of legacy code that does expect STATE to be a simple
> flag stored in a variable, so although the Forth94 TC could think of
> lots of better ways to manage the information, there was sufficient
> demand to avoid breaking this code that the mandate went in as it is.

Oops, upon reviewing the final language in Forth94, I find that it is 
not required to be a *flag* so long as it's non-zero during compilation, 
and that Standard Programs are prohibited from changing it.  Also, "Only 
the following standard words alter the value in STATE: : (colon), ; 
(semicolon), ABORT, QUIT, :NONAME, [ (left-bracket), and ] (right-bracket)."

It does have to return an address, though.  Given that Standard Programs 
can't change it, it would be reasonable to make it a VALUE, but the 
argument for retaining compatibility won out (lovers of STATE-smart 
words operated that lobby).

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]

#1644

Elizabeth D Rather <erather@forth.com> wrote:
> 
> The principal (really, the *sole*) reason for keeping STATE a variable 
> is to avoid breaking legacy Forth code.

It didn't qork out that way, though, did it?  People have been writing
broken state-smart words ever since.

> polyFORTH, for example, didn't use STATE as a flag for about 10
> years ( ] actually ran the compiler, and its address was placed in
> STATE by : etc.).

From what I remember, for a long while the compiler's address wasn't
placed in STATE except by a compatibility wordset.  This meant that
multi-line colon definitions didn't work, but because every block is a
single line that didn't matter.

Andrew.

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

#1653

On 4/29/11 1:14 AM, Andrew Haley wrote:
> Elizabeth D Rather<erather@forth.com>  wrote:
>>
>> The principal (really, the *sole*) reason for keeping STATE a variable
>> is to avoid breaking legacy Forth code.
>
> It didn't qork out that way, though, did it?  People have been writing
> broken state-smart words ever since.
>
>> polyFORTH, for example, didn't use STATE as a flag for about 10
>> years ( ] actually ran the compiler, and its address was placed in
>> STATE by : etc.).
>
>  From what I remember, for a long while the compiler's address wasn't
> placed in STATE except by a compatibility wordset.  This meant that
> multi-line colon definitions didn't work, but because every block is a
> single line that didn't matter.

As I recall, the compiler's address was in STATE right enough, but it 
wasn't reset by the text interpreter at the end of a line.

As a result, if you typed the first part of a definition at the command 
line and pressed Enter, the compiler was still waiting for you to 
continue, a condition often referred to as 'ok mode' because the system 
said 'ok' to every line you typed, so long as it contained recognizable 
Forth words.  It was either a wonderful feature or utterly maddening, 
depending on whether you intended to do it or not.

Ah, history.

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]

#1663

On Apr 29, 7:47 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> On 4/29/11 1:14 AM, Andrew Haley wrote:
>
>
>
>
>
>
>
> > Elizabeth D Rather<erat...@forth.com>  wrote:
>
> >> The principal (really, the *sole*) reason for keeping STATE a variable
> >> is to avoid breaking legacy Forth code.
>
> > It didn't qork out that way, though, did it?  People have been writing
> > broken state-smart words ever since.
>
> >> polyFORTH, for example, didn't use STATE as a flag for about 10
> >> years ( ] actually ran the compiler, and its address was placed in
> >> STATE by : etc.).
>
> >  From what I remember, for a long while the compiler's address wasn't
> > placed in STATE except by a compatibility wordset.  This meant that
> > multi-line colon definitions didn't work, but because every block is a
> > single line that didn't matter.
>
> As I recall, the compiler's address was in STATE right enough, but it
> wasn't reset by the text interpreter at the end of a line.
>
> As a result, if you typed the first part of a definition at the command
> line and pressed Enter, the compiler was still waiting for you to
> continue, a condition often referred to as 'ok mode' because the system
> said 'ok' to every line you typed, so long as it contained recognizable
> Forth words.  It was either a wonderful feature or utterly maddening,
> depending on whether you intended to do it or not.
>
> Ah, history.
>
> 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 90045http://www.forth.com
>
> "Forth-based products and Services for real-time
> applications since 1973."
> ==================================================

That's exactly how my system works. A nice (IMO) side-effect.

On my system, I can write a colon def up to 80 characters. Or, I can
simply press enter at a convenient point, and my colon def can be any
length you like, like this:

: TEST ." HELLO" SPACE<enter> OK:0
." MOTHER!" ;

When semi-colon is encountered, the compiler is turned off, the word
un-smudged etc. Works a treat and is a great feature IMO!

Mark

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

#1593

On Apr 27, 3:41 pm, MarkWills <markrobertwi...@yahoo.co.uk> wrote:
> Just musing here... Is there any reason why (apart from historical
> reasons) STATE should be a variable?

No problem not using a variable, just don't call it STATE.

Say that you have a byte value STATE? and that is what your system
uses.

Then STATE could be:

VARIABLE {STATE}

: STATE ( -- a ) STATE? {STATE} TUCK ! ;

There the "read only" is in the sense that you can write to it if you
want, but nothing will happen as a result.

Indeed, you don't even have to have it in your system, as long as its
available to be loaded somehow.

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

#1595

On Apr 30, 3:24 am, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> 1) less wordy
> There was no question.  That's very literal of you.  You disregarded the
> meaning.  You disregarded the context.

1) Less Wordy
You responded to a comment that the original question, which was why
STATE should be a VARIABLE, apart from historical reasons, is rendered
moot if the reason that STATE is a VARIABLE in the spec is precisely
historical legacy, that is, to support legacy code.

Your response was to misread or pretend that it was something else
which was rendered moot in the remark, because the something else was
what you rather wanted to go on about.

So with respect to disregarding meaning and context, pot, kettle,
black.

=============
2) More Wordy

The only thing that can be standardized is the implementation
informing userland as to which of the two states the interpreter/
compiler is in at the time a word is executing.

So while the information varies, as far as what can be done in a
standard way, just delivering the information directly:
   STATE? ( -- state )
... is more space efficient and in many cases more time efficient than
delivering an address from which to retrieve the information:
   STATE ( -- address )

So as far as the question of what kind of stack interface there should
be to the standard word, it would seem to be more sensible to use
STATE? for a "read-only variable".

Except for the issue of legacy code.

There is a two state process. It has in the past variously been
implemented with a subroutine for one of the states, with a pair of
alternating loops for the two states, and with a single loop that
reacts differently based on a loop variable.

For the approach based on a variable, that can be a flag, a bit field,
an XT representing either one or both of the alternative behaviors
(one if there is a default action to do instead of it is nul). It
could be data with an inverted FALSE to the conventional STATE ~ eg,
if the actual data is a byte sized AND mask used in conjunction with a
COMPILE-ONLY bit to pass over a compile-only word in hunting for a
word, then it should be the bit corresponding to the compile-only bit
set in interpret state, zero in compile state, so that it gives one
result when both interpreting and the word is COMPILE-ONLY, and the
other result when its either compiling or not COMPILE-ONLY or both.

In the various implementation userlands at the time of Forth94, in
some implementation userlands putting a flag into the state variable
would be a coherent action, in others it would be incoherent. So as
noted above, the standard can only standardize the reading of the
status, it cannot standardize a capacity to change the status.

Given that fact, the thing to standardize on would seem to be
something like STATE? leaving STATE as an implementation specific for
those implementation that have a state variable written in.

In the compile-only mask for a BIT operation described above, STATE?
is:

: STATE? ( -- state ) CO-MASK C@ 0= ;

The STATE version is:

VARIABLE {STATE}
: STATE ( -- address ) CO-MASK C@ 0= {STATE} TUCK ! ;

For an implementation that relies on a STATE variable, STATE already
exists, and STATE? is:

: STATE? ( -- state ) STATE @ ;

From the perspective of that userland, which seems likely to be a
substantial share of the total userland, all the code that presently
uses "STATE @" will either have to be rewritten, given a portability
overlay, or just be declared to be nonstandard to that extent ~ that
is, declared to have an implementation dependency on the existence of
a STATE variable.

If the code is rewritten, all that happens is a change of where the @
occurs.

However, if there is a substantial legacy that relies on reading
STATE, the portability overlay for STATE? is to write into a dummy
variable, which when run on systems that actually have STATE results
in reading from the actual STATE variable to store into a dummy
variable to read from the dummy variable.

Since those who cared the most about getting the information were also
those most likely to have legacy code that used the previous most
common approach, its natural that they cared more and won the
argument.

So its a VARIABLE not because of some abstract objection to variable
information being delivered directly to the stack rather than as an
address, but rather its a VARIABLE because that's what it was before
for a sufficiently large userland to get that legacy approach to
informing an implementation's userland of the state of the compiler to
written into the standard, except with restriction to those uses of
such a variable that it was possible to standardize for systems
without such a variable already built in.

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

#1596

On Apr 30, 7:41 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Fri, 29 Apr 2011 07:24:07 -0700 (PDT), BruceMcF

> <agil...@netscape.net> wrote:
> >But there's no need to design your system around a legacy code
> >requirement, especially when its not as if those hypothetical "Klines
> >of legacy code" are not widely available Forth94 open source.

> But some of us need to *maintain* systems that compile millions
> of lines of *proprietary* source. The better our standards are,
> the more likely it is that code will be ported. There considerable
> evidence for this after ANS was released. A recent Forth200x
> meeting discussion indicated that it could take 20 years to
> remove a feature completely from a standard. It can certainly
> take ten years to remove a feature from an implementation.

Quite ~ designing a system as Mark Will is doing is a quite different
matter from changing an implementation with a substantial established
source base.

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

#1598

"BruceMcF" <agila61@netscape.net> wrote in message
news:f1988d87-facb-4c48-ad56-5f3384b1c41c@28g2000yqu.googlegroups.com...
> On Apr 29, 3:45 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > I don't know if it's moot whether or not one treats a low-use, or
> >  minimal-value-change, variable as a constant. E.g., spec. says one
> > thing, but common implementation differs.
>
> The statement that you were replying to was that the question of
> whether or not it [STATE] should be treated as a variable is moot
> if legacy code lock requires it to be available as a variable in any
> event, irrespective of behind the scenes implementation.
>

1) less wordy
There was no question.  That's very literal of you.  You disregarded the
meaning.  You disregarded the context.

2) more wordy
If you disregard all of the prior context regarding constant vs. variable,
and choose to restrict my statements to only the statement of Mark's
immediately prior to the first response of mine that you replied to, then,
yes, that would be correct, except for the fact that Mark's statement didn't
involve a question.  He stated his response in terms of STATE.  I took that
to be equivalent to constant vs. variable.  First, his response is
equivalent.  Second,  I assumed he expressed primarily in terms of STATE
because his earlier question seemed to express uncertainty about the
difference between variables and constant.  Unfortunately, the context
covers four messages prior to your response, not just the immediate
statement(s) to which I replied.  Constant vs. variable was what was being
discussed in this part of the thread, IMO.

> You raised the implementation details of a once-common implementation,
> that is now primarily a historical curiosity, to question whether the
> statement was right.
>

I took the conversation in this part of the thread to be choice of constant
vs. variable.   That was what Mark asked about.  That was what I replied to.
That was what he replied to, in an equivalent form IMO.  That was what I
responded to, just prior to you responding.

> That seems to be a misreading of the statement,
>

Only if you disregard earlier context ...

> If write once, read many should be a constant, write rarely, read
> often should be a value, and read and write with similar frequency
> should be a variable,
>

Who said that's what they should be?  And, why not four? five? six types?

Of course, you didn't mention other combinations of once, rarely, often,
many for read and write.  So, one could select other combinations.  Are any
of them more useful than constant or variable?  Probably not...  Is the
implementation of write once, read rarely any different than constant?  Is
write rarely, read often any different from read and write similarly?  I
agree that adding a third type - value in this case - would theoretically
solve this discussion, er... make it moot.  But, such combinations are
unneeded.  Constants are just variables that are never written to again.
So, you could ask if a low-use variable is just a constant in disguise, as
Mark did indirectly via his question about implementation of STATE.  And,
you could ask why does Forth - a language of minimalism - support constants
at all.  Clearly, there is no need for constants when one has variables.  Of
course, that denies the reality of most assembly languages which implement
constants and "variables".  Language pedants (wrongly) regard assembly as
irrelevant anyway, preferring the more abstract (simple, vague) descriptions
in the language specification.  But, a house is not built without a
foundation.  Both Forth and C were rewritten to make them work with various
assemblies of their era's.  In Forth's case, it was rewritten to work with a
HLL also.  That (assembly) is why they have variables and constants, at
least IMO.

> ... it seems like a compiler/interpreter that
> consults compiler state per word could reasonably
> implement it as a value,
>

A compiler/interpreter could reasonably implement it [STATE] as two of the
three you suggested ...  So?

> [SNIP]


Rod Pemberton

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

#1601

On Fri, 29 Apr 2011 07:24:07 -0700 (PDT), BruceMcF
<agila61@netscape.net> wrote:

>But there's no need to design your system around a legacy code
>requirement, especially when its not as if those hypothetical "Klines
>of legacy code" are not widely available Forth94 open source.

But some of us need to *maintain* systems that compile millions
of lines of *proprietary* source. The better our standards are,
the more likely it is that code will be ported. There considerable
evidence for this after ANS was released. A recent Forth200x
meeting discussion indicated that it could take 20 years to
remove a feature completely from a standard. It can certainly
take ten years to remove a feature from an implementation.

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]

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

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

csiph-web