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

#1602

On Fri, 29 Apr 2011 15:45:21 -0400, "Rod Pemberton"
<do_not_have@noavailemail.cmm> wrote:

>> If you are looking to fig-Forth, you are arguing that it *is* a moot
>> point, since fig-Forth code would assume that STATE names a variable.

>a strong emphasis on ANSI correctness, but what would one do if common code
>usage was different?  You could not - in this theoretical situation - comply
>with the spec. and not break code.

If you are replicating a fig-Forth, then the fig-Forth "standard" is
relevant. Otherwise, it is irrelevant and you probably follow the
emergent Forth20xx standard.

You then end up with the current situation in which STATE is
apparently a  read-only variable. How STATE is changed is an
implementation detail of the Forth kernel.

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]

#1605

On Apr 30, 7:53 am, stephen...@mpeforth.com (Stephen Pelc) wrote:
> On Fri, 29 Apr 2011 15:45:21 -0400, "Rod Pemberton"
>
> >> If you are looking to fig-Forth, you are arguing that it *is* a moot
> >> point, since fig-Forth code would assume that STATE names a variable.

> >a strong emphasis on ANSI correctness, but what would one do if common code
> >usage was different?  You could not - in this theoretical situation - comply
> >with the spec. and not break code.

> If you are replicating a fig-Forth, then the fig-Forth "standard" is
> relevant. Otherwise, it is irrelevant and you probably follow the
> emergent Forth20xx standard.

If you are replicating a fig-Forth, then STATE is one of the things
you do in a way that is both a common code usage and which complies
with the Forth94 spec ~ it is a USER variable (user variable offset
$24 in the 6502 listing), has all bits clear in interpret state, and
some bits set in compile state.

It is of course true that there is much else that you would be doing
would no longer be common code usage and would also not comply with
the Forth94 spec.

> You then end up with the current situation in which STATE is
> apparently a  read-only variable. How STATE is changed is an
> implementation detail of the Forth kernel.

Which is to say, the current situation is that STATE is *permitted to
be* a read-only variable. Its allowed to be a read/write variable
actually used as the compile/interpret state variable by the compiler,
allowed to be a constant pointing to a memory location that contains
an XT in compile state and a null in interpret state or a memory
location holding a bit or byte flag padded out to a cell, and also
allowed to be a dummy variable, inferred on the fly.

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

#1612

MarkWills <markrobertwills@yahoo.co.uk> writes:
>Just musing here... Is there any reason why (apart from historical
>reasons) STATE should be a variable?

No.  There is also no reason (apart from historical reasons) why STATE
should be implemented as a user-visible word at all (I used to think
that STATE would be useful in the pattern "save some state, set it,
call something that uses it, restore it", but nowadays I don't believe
that one would use this pattern for maintaining the text interpreter
mode (aka STATE), so I don't see a reason for using STATE in
well-written code.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2010: http://www.euroforth.org/ef10/

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

#1620

On Apr 28, 1:59 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> ... but nowadays I don't believe
> that one would use this pattern for maintaining the text interpreter
> mode (aka STATE), so I don't see a reason for using STATE in
> well-written code.

User code has no reason to write to STATE, but sometimes it needs to
read from it:

: H#  ( <hex> -- u )
   ( code to get number )
   STATE @ IF POSTPONE LITERAL THEN
; IMMEDIATE

-Brad

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

#1625

Brad <hwfwguy@gmail.com> wrote:
> On Apr 28, 1:59?am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> wrote:
>> ... but nowadays I don't believe
>> that one would use this pattern for maintaining the text interpreter
>> mode (aka STATE), so I don't see a reason for using STATE in
>> well-written code.
> 
> User code has no reason to write to STATE, but sometimes it needs to
> read from it:
> 
> : H#  ( <hex> -- u )
>   ( code to get number )
>   STATE @ IF POSTPONE LITERAL THEN
> ; IMMEDIATE

I suspect Anton wouild say that is not well-written code.  I know I
would!  :-)

Andrew.

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

#1631

On 4/28/11 7:16 AM, Andrew Haley wrote:
> Brad<hwfwguy@gmail.com>  wrote:
>> On Apr 28, 1:59?am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>> wrote:
>>> ... but nowadays I don't believe
>>> that one would use this pattern for maintaining the text interpreter
>>> mode (aka STATE), so I don't see a reason for using STATE in
>>> well-written code.
>>
>> User code has no reason to write to STATE, but sometimes it needs to
>> read from it:
>>
>> : H#  (<hex>  -- u )
>>    ( code to get number )
>>    STATE @ IF POSTPONE LITERAL THEN
>> ; IMMEDIATE
>
> I suspect Anton wouild say that is not well-written code.  I know I
> would!  :-)

Well, I agree, too, but that is the crux of the argument for the way 
it's presented in Forth94: preservation of the entitlement to write (or 
use existing) code that does this sort of thing, for those who think 
it's a good thing to do.

And note that it's perfectly acceptable to put STATE in memory to which 
user programs cannot write, since writing to STATE is declared non-portable.

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]

#1635

On Apr 28, 11:01 am, Brad <hwfw...@gmail.com> wrote:
> User code has no reason to write to STATE, but sometimes it needs to
> read from it:

> : H#  ( <hex> -- u )
>    ( code to get number )
>    STATE @ IF POSTPONE LITERAL THEN
> ; IMMEDIATE

Of course, if COMPILE-IMMEDIATE words are not "seen" by the
interpreter in compile state, that's:

: H# ( <hex> -- u ) ( code to get number ;
: H# ( <hex> -- u ) H# POSTPONE LITERAL ; COMPILE-IMMEDIATE

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

#1647

On Apr 28, 3:56 pm, BruceMcF <agil...@netscape.net> wrote:
> > : H#  ( <hex> -- u )
> >    ( code to get number )
> >    STATE @ IF POSTPONE LITERAL THEN
> > ; IMMEDIATE
>
> Of course, if COMPILE-IMMEDIATE words are not "seen" by the
> interpreter in compile state, that's:
>
> : H# ( <hex> -- u ) ( code to get number ;
> : H# ( <hex> -- u ) H# POSTPONE LITERAL ; COMPILE-IMMEDIATE

I would like to see desktop systems adopt the cross-compiler standard
proposed by FORTH inc and MPE. That would allow things like:

INTERPRETER
: H# ( <hex> -- u ) ( code to get number ) ;
COMPILER
: H# ( <hex> -- u ) H# POSTPONE LITERAL ;
TARGET

-Brad

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

#1655

On Apr 29, 10:49 am, Brad <hwfw...@gmail.com> wrote:

> I would like to see desktop systems adopt the cross-compiler standard
> proposed by FORTH inc and MPE. That would allow things like:

> INTERPRETER
> : H# ( <hex> -- u ) ( code to get number ) ;
> COMPILER
> : H# ( <hex> -- u ) H# POSTPONE LITERAL ;
> TARGET

I've read it a while back, but was not thinking in this context ~
where is the proposal online, again?

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

#1650

Brad <hwfwguy@gmail.com> writes:
>On Apr 28, 1:59=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> ... but nowadays I don't believe
>> that one would use this pattern for maintaining the text interpreter
>> mode (aka STATE), so I don't see a reason for using STATE in
>> well-written code.
>
>User code has no reason to write to STATE, but sometimes it needs to
>read from it:
>
>: H#  ( <hex> -- u )
>   ( code to get number )
>   STATE @ IF POSTPONE LITERAL THEN
>; IMMEDIATE

Ugh.  Still, it can be replaced with code that does not mention STATE:

: eval-num ( c-addr u -- |n|d )
  get-order n>r 0 set-order
  ['] evaluate catch
  nr> set-order
  throw ;

: base-exec ( ... xt ubase -- ... )
  base @ >r
  base !
  catch
  r> base !
  throw ;

: h#
  parse-name ['] eval-num $10 base-execute ; immediate

h# add .
: foo h# add ;

Works even with double numbers, unlike the original version.  Still, I
don't like H# approach.

On a tangent: I used three Forth200x extensions in this short piece of
code to good effect (PARSE-NAME, number prefixes, N>R/NR>); these
extensions do prove useful.

- 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 2010: http://www.euroforth.org/ef10/

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

#1622

In article <2011Apr28.105956@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>MarkWills <markrobertwills@yahoo.co.uk> writes:
>>Just musing here... Is there any reason why (apart from historical
>>reasons) STATE should be a variable?
>
>No.  There is also no reason (apart from historical reasons) why STATE
>should be implemented as a user-visible word at all (I used to think
>that STATE would be useful in the pattern "save some state, set it,
>call something that uses it, restore it", but nowadays I don't believe
>that one would use this pattern for maintaining the text interpreter
>mode (aka STATE), so I don't see a reason for using STATE in
>well-written code.

I have a word
: T]    STATE @ 0= IF SWAP-DP HERE THEN STATE @ ] ;

SWAP-DP swaps the dictionary pointer to a temporary buffer.
This word is a factor of loops in interpret mode.

It is used as
: BEGIN    T] POSTPONE BEGIN ; IMMEDIATE

You can imagine a corresponding T[ word and a corresponding
redefinition of WHILE and REPEAT .

Where this code is only semi-portable (it depends on SWAP-DP
being possible), I think it is better off with STATE defined
in the standard.

I would be perfectly happy with STATE@ though, where it is
only possible to investigate STATE, not change it directly
by storing into it.

>
>- anton

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#1632

On 4/28/11 7:47 AM, Albert van der Horst wrote:
> In article<2011Apr28.105956@mips.complang.tuwien.ac.at>,
> Anton Ertl<anton@mips.complang.tuwien.ac.at>  wrote:
>> MarkWills<markrobertwills@yahoo.co.uk>  writes:
>>> Just musing here... Is there any reason why (apart from historical
>>> reasons) STATE should be a variable?
>>
>> No.  There is also no reason (apart from historical reasons) why STATE
>> should be implemented as a user-visible word at all (I used to think
>> that STATE would be useful in the pattern "save some state, set it,
>> call something that uses it, restore it", but nowadays I don't believe
>> that one would use this pattern for maintaining the text interpreter
>> mode (aka STATE), so I don't see a reason for using STATE in
>> well-written code.
>
> I have a word
> : T]    STATE @ 0= IF SWAP-DP HERE THEN STATE @ ] ;
>
> SWAP-DP swaps the dictionary pointer to a temporary buffer.
> This word is a factor of loops in interpret mode.
>
> It is used as
> : BEGIN    T] POSTPONE BEGIN ; IMMEDIATE
>
> You can imagine a corresponding T[ word and a corresponding
> redefinition of WHILE and REPEAT .
>
> Where this code is only semi-portable (it depends on SWAP-DP
> being possible), I think it is better off with STATE defined
> in the standard.
>
> I would be perfectly happy with STATE@ though, where it is
> only possible to investigate STATE, not change it directly
> by storing into it.

As you note, anything involving some reliance on DP-access is guaranteed 
non-portable.  On the other hand, within the context of system code, you 
can do whatever works, because it's your system! That is why the 
Standard makes such a clear distinction between Standard Programs and 
Standard Systems: the standardness is at the interface between the two.

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]

#1633

"MarkWills" <markrobertwills@yahoo.co.uk> wrote in message
news:496ffa3f-5ac9-45a9-9190-bb3875e8b44e@m40g2000vbt.googlegroups.com...
>
> Just musing here... Is there any reason why (apart from historical
> reasons) STATE should be a variable?
>

What?!?


Does it's value change?  Then, it's not a constant, but a variable.  Yes?
So, if it's not a constant and now you're thinking about making it _not_ a
variable too, what part of Forth would it be exactly?  Is there some other
type left?

Yes, there is a touch of sarcasm there, but not much.  Constants don't
change their values.  Variables do.  That's why.


Rod Pemberton

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

#1643

On Apr 28, 9:32 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> "MarkWills" <markrobertwi...@yahoo.co.uk> wrote in message
>
> news:496ffa3f-5ac9-45a9-9190-bb3875e8b44e@m40g2000vbt.googlegroups.com...
>
>
>
> > Just musing here... Is there any reason why (apart from historical
> > reasons) STATE should be a variable?
>
> What?!?
>
> Does it's value change?  Then, it's not a constant, but a variable.  Yes?
> So, if it's not a constant and now you're thinking about making it _not_ a
> variable too, what part of Forth would it be exactly?  Is there some other
> type left?
>
> Yes, there is a touch of sarcasm there, but not much.  Constants don't
> change their values.  Variables do.  That's why.
>
> Rod Pemberton

Hello Rod,

Yes, you're right. I guess I should have said VALUE rather than
VARIABLE. The point being, STATE would return its value, rather than
its address, since there is rarely (if ever) a need to directly write
to STATE, especially in a user program. I accept its largely a moot
point; clearly there are thousands of lines of legacy code that would
break if it were to be changed now. Sometimes it's just interesting to
muse out loud though, and covet other people's opinions!

Regards

Mark

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

#1645

On Apr 29, 5:11 am, MarkWills <markrobertwi...@yahoo.co.uk> wrote:
> ... clearly there are thousands of lines of legacy code that would
> break if it were to be changed now. ...

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.

If STATE? is a value, its easy enough to offer the legacy interface to
code that needs it.

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

#1651

"MarkWills" <markrobertwills@yahoo.co.uk> wrote in message
news:d78fa1a4-efa0-435f-8d3a-d97cc3a439fd@24g2000yqk.googlegroups.com...
>
> I guess I should have said VALUE rather than
> VARIABLE. The point being, STATE would return its value, rather than
> its address, since there is rarely (if ever) a need to directly write
> to STATE, especially in a user program. I accept its largely a moot
> point; clearly there are thousands of lines of legacy code that would
> break if it were to be changed now.
>

I don't know if it's moot.  E.g., the version of the fig-Forth spec. that's
available as text, says TIB returns an address:

"
      TIB           ---  addr                               U
               A user variable containing the address of the terminal
               input buffer.
"

DP is stated to be implemented the same way as TIB.  The fig-Forth memory
map shows the same thing.  I.e., both should be variables that place the
address on the stack:

"
      DP            ---  addr                               U,L
               A user variable, the dictionary pointer, which contains
               the address of the next free memory above the dictionary.
               The value may be read by HERE and altered by ALLOT.
"

When working on my interpreter, I implemented TIB that needed to be fetched,
just like DP.  However, much example code using TIB just didn't work!  So, I
checked some Forths on their use of TIB and DP.  Many didn't have, or don't
allow, access to TIB or DP.  When present, TIB is not fetched.  The one
exception being 8088 fig-Forth.  When present, DP is fetched.  So, I'm only
aware of one Forth interpreter that follows the fig-Forth spec. in regards
to TIB being a variable.  I.e., almost no Forths, that use TIB, correctly
implement TIB as a variable.  Yes?  They both should work the same way, and
user variable's return the variable's address, not the variable's content
which are addresses in this case.  Correct?

I tried both of these sequences to see if TIB is fetched:

TIB @ 5 TYPE
TIB 5 TYPE

I used this sequence to determine if DP is fetched:

HERE . 1 ALLOT HERE . DP . DP @ .

BTW, I saw someone say in post here that TIB needed to be 80 per user.  If
you follow the fig-Forth spec., it's 82, for EOL...


Rod Pemberton

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

#1656

On Apr 29, 1:56 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:
> I don't know if it's moot.  E.g., the version of the fig-Forth spec. that's
> available as text, says TIB returns an address:

If you are looking to fig-Forth, you are arguing that it *is* a moot
point, since fig-Forth code would assume that STATE names a variable.

Not sure what difference that makes at this point, though. What would
be the relevance of the implementation details of fig-Forth be to any
particular question of how something should be implemented today?

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

#1659

"BruceMcF" <agila61@netscape.net> wrote in message
news:13ec1787-cf0d-416e-998f-98b0552fd333@w21g2000yqm.googlegroups.com...
> On Apr 29, 1:56 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
> wrote:
> > I don't know if it's moot. E.g., the version of the fig-Forth spec.
that's
> > available as text, says TIB returns an address:
>
> If you are looking to fig-Forth, you are arguing that it *is* a moot
> point, since fig-Forth code would assume that STATE names a variable.
>

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.  Which do you follow?  Do you chose to
comply with the spec.?  Do you chose to not break common code?  I.e., not
moot.  What if such a situation were present with ANSI Forth?  People place
a strong emphasis on ANSI correctness, but what would one do if common code
usage was different?  You could not - in this theoretical situation - comply
with the spec. and not break code.


Rod Pemberton

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

#1660

On 4/29/11 9:45 AM, Rod Pemberton wrote:
> "BruceMcF"<agila61@netscape.net>  wrote in message
> news:13ec1787-cf0d-416e-998f-98b0552fd333@w21g2000yqm.googlegroups.com...
>> On Apr 29, 1:56 pm, "Rod Pemberton"<do_not_h...@noavailemail.cmm>
>> wrote:
>>> I don't know if it's moot. E.g., the version of the fig-Forth spec.
> that's
>>> available as text, says TIB returns an address:
>>
>> If you are looking to fig-Forth, you are arguing that it *is* a moot
>> point, since fig-Forth code would assume that STATE names a variable.
>>
>
> 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.  Which do you follow?  Do you chose to
> comply with the spec.?  Do you chose to not break common code?  I.e., not
> moot.  What if such a situation were present with ANSI Forth?  People place
> a strong emphasis on ANSI correctness, but what would one do if common code
> usage was different?  You could not - in this theoretical situation - comply
> with the spec. and not break code.

Good question.  In theory, a Standard is supposed to represent common 
usage.  However, that's subject to change.  This is why official 
standards bodies such as ANSI, IEEE, and ISO *require* standards to be 
re-examined every five years. If common usage has changed, or if 
something in the standard has proven problematic, the standard should be 
fixed, and it should also keep up with new technology if possible.  The 
20xx effort started a bit late, but is appropriately addressing issues 
such as locals, where Forth94 was not very successful.

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]

#1661

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

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

That seems to be a misreading of the statement, since if even obsolete
fig-Forth implementation details are relevant, then surely the kind of
legacy code that the spec. respects are also relevant, and if they
are, then the question is moot.

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, it seems like a compiler/interpreter that
consults compiler state per word could reasonably implement it as a
value, and an implied state compiler/interpreter could generate it on
the fly if STATE is executed, so STATE would be a dummy variable.

It seems to be the first case that Mark had in mind. But if the
compiler state as used by the system is a value, then it shouldn't be
called STATE, and STATE, which may be placed in a Forth94
compatibility overlay file, should emulate a read-only variable:

eg, as I already mentioned, if the implementation used STATE?, then in
the Forth94 overlay file:

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

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

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

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

csiph-web