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

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

Reformulation of "STATE @ IF"

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

Contents

  Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-23 19:01 +0200
    Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-23 17:18 +0000
      Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-23 19:56 +0200
        Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-23 20:20 +0200
        Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-23 14:42 -0700
          Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-24 07:57 +0200
            Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-23 22:06 -1000
              Re: Reformulation of "STATE @ IF" Hans Bezemer <the.beez.speaks@gmail.com> - 2012-04-26 08:42 +0200
                Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-26 03:55 -0500
            Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-24 07:55 -0700
            Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-24 08:00 -0700
          Re: Reformulation of "STATE @ IF" awegel@arcor.de (Alex Wegel) - 2012-04-25 14:32 +0200
        Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-24 10:26 +0000
          Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-24 19:38 +0200
            Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-24 11:25 -0700
              Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-24 22:10 +0200
                Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-24 16:02 -0700
                Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-24 13:54 -1000
                  Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-25 06:58 +0200
                    Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-24 21:01 -1000
                    Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-24 21:40 -1000
                    Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-25 05:56 -0700
          Re: Reformulation of "STATE @ IF" Alex McDonald <blog@rivadpm.com> - 2012-04-24 12:11 -0700
          Re: Reformulation of "STATE @ IF" Coos Haak <chforth@hccnet.nl> - 2012-04-24 22:40 +0200
            Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-25 13:03 +0000
              Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-25 08:37 -0700
                Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-26 16:17 +0000
    Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-25 01:44 -0400
      Re: Reformulation of "STATE @ IF" "A. K." <akk@nospam.org> - 2012-04-25 08:33 +0200
        Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-25 04:09 -0500
          Re: Reformulation of "STATE @ IF" stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-25 13:15 +0000
            Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-25 10:52 -0500
              Re: Reformulation of "STATE @ IF" stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-25 17:50 +0000
                Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-26 04:06 -0500
                  Re: Reformulation of "STATE @ IF" Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-27 11:37 +0000
              Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-25 15:28 -0400
                Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-25 10:02 -1000
                Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 01:30 -0700
                  Re: Reformulation of "STATE @ IF" Coos Haak <chforth@hccnet.nl> - 2012-04-26 16:48 +0200
                  Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-26 09:27 -0700
                  Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-26 16:42 -0400
                    Re: Reformulation of "STATE @ IF" Coos Haak <chforth@hccnet.nl> - 2012-04-27 00:46 +0200
                      Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-27 05:32 -0400
                        Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-27 05:35 -0500
                        Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-27 04:00 -0700
                          Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-27 20:38 -0400
                            Re: Reformulation of "STATE @ IF" awegel@arcor.de (Alex Wegel) - 2012-04-28 03:02 +0200
                            Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-27 18:12 -0700
                              Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-30 12:45 +0000
                                Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-30 07:56 -0700
                                  Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-30 16:17 +0000
                              Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-05-02 15:51 -0400
                                Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-05-02 13:15 -0700
                                Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-02 12:59 -0700
                                  Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-05-02 13:54 -0700
                                    Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-05-02 14:25 -0700
                Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 01:43 -0700
                  Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 02:18 -0700
                    Re: Reformulation of "STATE @ IF" Coos Haak <chforth@hccnet.nl> - 2012-04-26 16:54 +0200
                      Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-26 10:46 -0700
                        Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 12:21 -0700
                          Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-26 18:31 -0400
                            Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-26 14:32 -1000
                              Re: Reformulation of "STATE @ IF" BruceMcF <agila61@netscape.net> - 2012-04-27 01:50 -0700
                              Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-27 09:10 +0000
                                Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-27 09:47 -1000
                              Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-27 05:33 -0400
                                Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-27 15:06 -0400
                              Re: Reformulation of "STATE @ IF" JennyB <jennybrien@googlemail.com> - 2012-04-27 02:54 -0700
                                Re: Reformulation of "STATE @ IF" stephenXXX@mpeforth.com (Stephen Pelc) - 2012-04-27 11:30 +0000
                      Re: Reformulation of "STATE @ IF" Mark Wills <markrobertwills@yahoo.co.uk> - 2012-04-26 12:18 -0700
                        Re: Reformulation of "STATE @ IF" Coos Haak <chforth@hccnet.nl> - 2012-04-26 22:21 +0200
                Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-26 04:27 -0500
      Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-25 04:08 -0500
        Re: Reformulation of "STATE @ IF" "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-04-25 15:29 -0400
          Re: Reformulation of "STATE @ IF" "Elizabeth D. Rather" <erather@forth.com> - 2012-04-25 10:27 -1000
          Re: Reformulation of "STATE @ IF" Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-04-26 04:31 -0500
          Re: Reformulation of "STATE @ IF" anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-04-26 16:35 +0000
            Re: Reformulation of "STATE @ IF" Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-04-27 11:58 +0000

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

#11598

On 4/24/12 6:58 PM, A. K. wrote:
> On 25.04.2012 01:54, Elizabeth D. Rather wrote:
>> On 4/24/12 10:10 AM, A. K. wrote:
>>> On 24.04.2012 20:25, BruceMcF wrote:
>>>
>>>> 3.4.2 does not specify whether a dual-xt word *will* find the
>>>> interpretation or compilation semantics when compiling, but the
>>>> definition of FIND specifies that a different xt *may be* return in
>>>> interpretation and compilation state, which implies that the execution
>>>> semantics *may be* different in the two states.
>>>>
>>>> Since IMMEDIATE simply says it has the word perform the execution
>>>> semantics in compilation state, and the dual-xt system *does* perform
>>>> the compilation state execution semantics in compilation state, the
>>>> IMMEDIATE would be redundant but respected nonetheless.
>>>
>>> It seems that with those many "maybe"s we are ending again at the
>>> classical fringe of a so-called standard that it is
>>> "implementation-dependent". ;-)
>>>
>>
>> Well, obviously, since how you implement a dictionary and immediacy is
>> inherently implementation-dependent, and deliberately so. The point
>> everyone is trying to make is that the use of the word IMMEDIATE in that
>> definition is meaningless, given the very explicit description of
>> IMMEDIATE in the standard.
>>
>> Cheers,
>> Elizabeth
>>
>
> Sure, it's nothing that shakes the world. But whether it can shake an
> application depends on the application -- and different Forths behave
> differently here, each of them claiming to be standard Forths. I
> wouldn't call it meaningless.

Comments in addition to my previous post: a "Standard Forth" must 
provide a list of "implementation-specified" details. This puts an app 
on notice that if it relies on any of those items it has a dependency, 
meaning that the programmer *knows* that certain features may require 
modification or a compatibility layer for Forths that don't supply them.

The Standard also calls out both implementation-specific items (which 
require documentation) and implementation-dependent items (that don't 
require explicit documentation but which application programmer is 
explicitly *warned* may vary.

If you want to write portable programs, these features make it very 
clear what you can and cannot rely on, in writing a "Standard Program" 
(no dependencies) or a "Standard Program with a dependency on [list of 
features]".

Knowledge is power. You can choose, depending on your needs and your 
expectations as to what platforms you expect your program to run on, 
what dependencies to accept or program around. I (and the various TCs 
that have worked on this) doubt very much that there are many 
significant program that don't have *some* kind of dependency. But if 
you know what your dependencies are, and can choose them deliberately, 
you will not be blind-sided when porting your program in the future.

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]

#11610

On Apr 25, 12:58 am, "A. K." <a...@nospam.org> wrote:
> On 25.04.2012 01:54, Elizabeth D. Rather wrote:
>> On 4/24/12 10:10 AM, A. K. wrote:
>> Well, obviously, since how you implement a dictionary and immediacy is
>> inherently implementation-dependent, and deliberately so. The point
>> everyone is trying to make is that the use of the word IMMEDIATE in that
>> definition is meaningless, given the very explicit description of
>> IMMEDIATE in the standard.

> Sure, it's nothing that shakes the world. But whether it can shake an
> application depends on the application -- and different Forths behave
> differently here, each of them claiming to be standard Forths. I
> wouldn't call it meaningless.

In the example that started this thread of the discussion, over and
above the question of what IMMEDIATE would do if applied to a word
with dual-behaviors, IMMEDIATE would also have served no useful
purpose.

The original question may be posed as whether there are any
implementations that allow the creation of words with special
compilation behavior, different from either the default compilation
behavior and what IMMEDIATE offers, the compilation behavior of
executing the interpretation behavior.

If the default behavior of the compiler is to execute that special
compilation behavior, then IMMEDIATE is not needed ~ its at best
redundant, and at worst interferes with what you are trying to do in
defining the dual-xt word.

IMMEDIATE would only be needed if the default behavior of the compiler
was to compile that special compilation behavior, so if that's how
some implementation does it, use IMMEDIATE with that one.

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

#11579

On Apr 24, 11:26 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> "A. K." <a...@nospam.org> writes:
> >On 23.04.2012 19:18, Anton Ertl wrote:
> >> "A. K."<a...@nospam.org>  writes:
> >>> How would one reformulate this?  Perhaps similar to CREATE ... DOES>? Eg:
> >>> : IS
> >>>    executes>  '>is ! compiles>  compile (is) ; IMMEDIATE
>
> >>> But which subpart would then be affected by IMMEDIATE?
>
> >> IMMEDIATE is a way to change the compilation semantics of the word,
> >> but you already changed it with COMPILES>.  So IMMEDIATE does not make
> >> much sense here.  Either it has no effect (then why did you write
> >> IMMEDIATE) or it overwrites the compilation semantics with the
> >> execution semantics (then why did you write the COMPILES>  part?).
>
> >In a system with 1 dictionary entry for IF, IMMEDIATE would affect this
> >one dictionary entry for IF.
>
> >But in a system creating 2 dictionary entries for IF, the question seems
> >valid, although admittedly strange. However IMO at least the system
> >should be able to handle it intelligently.
>
> Which question?  My statement is not about the implementation, but the
> meaning (semantics) of IMMEDIATE and COMPILES>.  Both change the
> compilation semantics.  It does not make sense to use them on the same
> word, but if the programmer does, either behaviour of the system is
> equally plausible; or the system migh produce an error message.
>
> Let's see what Gforth does:
>
> :noname cr ." interpretation semantics" ;
> :noname cr ." compilation semantics" ;
> interpret/compile: foo \ first without IMMEDIATE
> foo                    \ prints "interpretation semantics"
> ] foo [                \ prints "compilation semantics"
> immediate              \ now with IMMEDIATE
> foo                    \ prints "interpretation semantics"
> ] foo [                \ prints "compilation semantics"
>
> So the IMMEDIATE has no effect here.

Dual XT W32F returns;

STC Experimental Version: 0.05.01 Build: 535
: foo cr ." interpretation semantics"
  compilation> drop
      cr ." compilation semantics" ;  ok
foo
interpretation semantics ok
] foo [
compilation semantics ok
immediate              \ now with IMMEDIATE  ok
foo
interpretation semantics ok
] foo [                \ note difference
interpretation semantics ok




>
> - 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 2011:http://www.euroforth.org/ef11/

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

#11582

Op Tue, 24 Apr 2012 10:26:33 GMT schreef Anton Ertl:

> "A. K." <akk@nospam.org> writes:
>>On 23.04.2012 19:18, Anton Ertl wrote:
>>> "A. K."<akk@nospam.org>  writes:
>>>> How would one reformulate this?  Perhaps similar to CREATE ... DOES>? Eg:
>>>> : IS
>>>>    executes>  '>is ! compiles>  compile (is) ; IMMEDIATE
>>>>
>>>> But which subpart would then be affected by IMMEDIATE?
>>>
>>> IMMEDIATE is a way to change the compilation semantics of the word,
>>> but you already changed it with COMPILES>.  So IMMEDIATE does not make
>>> much sense here.  Either it has no effect (then why did you write
>>> IMMEDIATE) or it overwrites the compilation semantics with the
>>> execution semantics (then why did you write the COMPILES>  part?).
>>
>>In a system with 1 dictionary entry for IF, IMMEDIATE would affect this 
>>one dictionary entry for IF.
>>
>>But in a system creating 2 dictionary entries for IF, the question seems 
>>valid, although admittedly strange. However IMO at least the system 
>>should be able to handle it intelligently.
> 
> Which question?  My statement is not about the implementation, but the
> meaning (semantics) of IMMEDIATE and COMPILES>.  Both change the
> compilation semantics.  It does not make sense to use them on the same
> word, but if the programmer does, either behaviour of the system is
> equally plausible; or the system migh produce an error message.
> 
> Let's see what Gforth does:
> 
>:noname cr ." interpretation semantics" ;
>:noname cr ." compilation semantics" ;
> interpret/compile: foo \ first without IMMEDIATE
> foo                    \ prints "interpretation semantics"
> ] foo [                \ prints "compilation semantics"
> immediate              \ now with IMMEDIATE
> foo                    \ prints "interpretation semantics"
> ] foo [                \ prints "compilation semantics"
> 
> So the IMMEDIATE has no effect here.
> 
Why would it, interpret/compile: create IMMEDIATE definitions, at least in 
Gforth version 0.7.0. IMMEDIATE sets bits, the result would be different if 
it toggled the bits.

> - anton


-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#11612

Coos Haak <chforth@hccnet.nl> writes:
>Op Tue, 24 Apr 2012 10:26:33 GMT schreef Anton Ertl:
>> Let's see what Gforth does:
>> 
>>:noname cr ." interpretation semantics" ;
>>:noname cr ." compilation semantics" ;
>> interpret/compile: foo \ first without IMMEDIATE
>> foo                    \ prints "interpretation semantics"
>> ] foo [                \ prints "compilation semantics"
>> immediate              \ now with IMMEDIATE
>> foo                    \ prints "interpretation semantics"
>> ] foo [                \ prints "compilation semantics"
>> 
>> So the IMMEDIATE has no effect here.
>> 
>Why would it, interpret/compile: create IMMEDIATE definitions

Hmm, does it?  Let's see what an immediate word is: From 2.1:

|immediate word:
|    A Forth word whose compilation semantics are to perform its
|    execution semantics.

Well, FOO has interpretation semantics and compilation semantics, but
does it have execution semantics?  And if it has them, what are they?

Is there a standard way to get at the execution semantics?  Not
really.  FIND is completely underspecified, and ' might be interpreted
as giving us the execution semantics, but there is no specification of
what happens if there is no execution semantics.

So one might argue that FOO has no execution semantics, and that "'"
and IMMEDIATE are then allowed to do anything.  Of course, one might
also argue that INTERPRET/COMPILE: is not a standard word, so the
standard does not say anything about the program above anyway.

Back to why you say the INTERPRET/COMPILE: creates IMMEDIATE
definitions: These definitions may have the immediate bit set and
IMMEDIATE just sets this bit (so it has no effect on such
definitions), but that's a very implementation-oriented view; it
explains why Gforth behaves the way it does, but does not really throw
any light on the original question.

- 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 2011: http://www.euroforth.org/ef11/

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

#11619

On Apr 25, 9:03 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> Hmm, does it?  Let's see what an immediate word is: From 2.1:
>
> |immediate word:
> |    A Forth word whose compilation semantics are to perform its
> |    execution semantics.
>
> Well, FOO has interpretation semantics and compilation semantics, but
> does it have execution semantics?  And if it has them, what are they?

The behavior performed by the xt returned by FIND. The execution
behavior is permitted to be different if the search is performed in a
different state, and by construction that execution behavior is
permitted to be contingent upon the state.

> Is there a standard way to get at the execution semantics?

> Not really.  FIND is completely underspecified,

Which is why execution semantics are underspecified ...

> and ' might be interpreted
> as giving us the execution semantics, but there is no specification of
> what happens if there is no execution semantics.

There is always execution semantics for any word specified in the
standard or created with defining words specific in the standard, but
whether there are execution semantics for words defined in
implementation-specific ways not specified in the standard is an
interesting question.

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

#11652

BruceMcF <agila61@netscape.net> writes:
>On Apr 25, 9:03=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>
>> Hmm, does it? =A0Let's see what an immediate word is: From 2.1:
>>
>> |immediate word:
>> | =A0 =A0A Forth word whose compilation semantics are to perform its
>> | =A0 =A0execution semantics.
>>
>> Well, FOO has interpretation semantics and compilation semantics, but
>> does it have execution semantics? =A0And if it has them, what are they?
>
>The behavior performed by the xt returned by FIND. The execution
>behavior is permitted to be different if the search is performed in a
>different state, and by construction that execution behavior is
>permitted to be contingent upon the state.

Ok, that's an interesting interpretation, but I don't see an advantage
over the interpretation that I am using, given that FIND says little
more than that.

>There is always execution semantics for any word specified in the
>standard

No, the standard specifies a number of words without specifying
execution semantics, e.g., IF and S".

- 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 2011: http://www.euroforth.org/ef11/

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

#11594

"A. K." <akk@nospam.org> wrote in message
news:4f958ae9$0$7610$9b4e6d93@newsspool1.arcor-online.net...
> I know the ambiguities of state-smart words. However I am wondering
> whether there is some common practice (or even an alternative optimum?)
> of how to replace the construct by other means, eg dual wordlists and or
> dual execution tokens, and with another practical syntax.
>

Ok, I reread the thread, but I'm not following ...  None of the replies seem
to have anything to do with your initial question, AIUI.

Wasn't this ("Reformulation of 'STATE @ IF'") already solved with ' (tick)?

Tick was state-smart in fig-Forth, but was then made state-dumb for later
forths.  It was split into ' (tick) and ['] .  Other state-smart words were
also broken into or implemented as an interpret version and a "compile-time"
version.  The compile-time versions use brackets around the name [ ] .
Later on, they merged COMPILE and [COMPILE] into state-aware POSTPONE .

> F. ex. F83 contains:
>
> : IS   (S cfa --- )
>    STATE @ IF  COMPILE (IS)  ELSE  ' >IS !  THEN ; IMMEDIATE
>
> (the meanings of >IS and (IS) are of no great importance now)
>
> How would one reformulate this?  Perhaps similar to CREATE ... DOES>? Eg:
> : IS
>    executes> ' >is ! compiles> compile (is) ; IMMEDIATE
>

Given the [] notation for compile-time versions of words.  I'd split IS into
IS and [IS] .  That will eliminate the STATE @ IF ... ELSE ... THEN
construct.  E.g.,

: IS ' >IS ! ;

: [IS] COMPILE (IS) ;  IMMEDIATE


> But which subpart would then be affected by IMMEDIATE?
> Etc etc.... ?????
>

I think that's answered both with the definition above and with the
explanation that follows.

The whole word IS as you posted it is IMMEDIATE.  The first section of the
IF, i.e., IF-ELSE, due to STATE @ is the compile-time portion.  The
IMMEDIATE is needed so that the compile-time IF-ELSE section is executed
immediately during compilation, i.e., during a colon-definition.  That is
the section which will have COMPILEs or [COMPILE]s or POSTPONEs.  For ANS,
POSTPONE replaces COMPILE and [COMPILE] .  You can convert back, if needed.
COMPILE for non-immediates and [COMPILE] for immediates.  The other IF
section, i.e., ELSE-THEN, is for interpretive mode.


From the c.l.f. archives, IS typically is implemented either with the same
definition as TO, which is usually inline, i.e., without >IS or (IS) .

: IS ' >BODY STATE @ IF POSTPONE LITERAL POSTPONE ! ELSE ! THEN ; IMMEDIATE

: IS ' >BODY STATE @ IF [COMPILE] LITERAL COMPILE ! ELSE ! THEN ; IMMEDIATE

As you can see, ' >BODY !   is the key definition.  Sometimes you'll see IS
or TO written with ' and >BODY moved into the IF sections.  Since your F83
definition doesn't have ' and >BODY, that must've been done for them.


IS can also be implemented in terms of TO which was standardized:

: IS POSTPONE TO ; IMMEDIATE

I saw an old discussion in c.l.f. that claimed "POSTPONE TO" is not valid
for ANS Forth.


Rod Pemberton

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

#11596

On 25.04.2012 07:44, Rod Pemberton wrote:
> "A. K."<akk@nospam.org>  wrote in message
> news:4f958ae9$0$7610$9b4e6d93@newsspool1.arcor-online.net...
>> I know the ambiguities of state-smart words. However I am wondering
>> whether there is some common practice (or even an alternative optimum?)
>> of how to replace the construct by other means, eg dual wordlists and or
>> dual execution tokens, and with another practical syntax.
>>
>
> Ok, I reread the thread, but I'm not following ...  None of the replies seem
> to have anything to do with your initial question, AIUI.
>

TO resolves VALUEs, IS resolves DEFERs. F83 is the old DOS Forth-83 
implementation by Laxen & Perry.

But you are right, the thread wandered a bit off topic. I was asking for 
some common practice of defining words with dual semantics, as 
replacement for state-smart words. But there does not seem to be one, 
and so everything is up to the implementor.

OTOH if there is neither a precise standard, nor a widely used syntax, 
then there is no further reason to bother. Just cruise around a be 
happy.  :-)

And as Elizabeth already stated: it is not forbidden to continue using 
state-smart words...

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

#11604

A. K. <akk@nospam.org> wrote:

> And as Elizabeth already stated: it is not forbidden to continue
> using state-smart words...

And, as she also stated, it's not sensible either.

Andrew.

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

#11611

On Wed, 25 Apr 2012 04:09:04 -0500, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>A. K. <akk@nospam.org> wrote:
>
>> And as Elizabeth already stated: it is not forbidden to continue
>> using state-smart words...
>
>And, as she also stated, it's not sensible either.

State-smart words have become part of a new demonology - ooh, they
are so unsafe. For a Forth veteran to denigrate a technique because
you have to know what you are doing is somewhat absurd.

State-smart words are still useful in a very bounded environment.
I will continue to use them for specific manipulations. I will
mark them as state-smart.

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]

#11621

Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Wed, 25 Apr 2012 04:09:04 -0500, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
> 
>>A. K. <akk@nospam.org> wrote:
>>
>>> And as Elizabeth already stated: it is not forbidden to continue
>>> using state-smart words...
>>
>>And, as she also stated, it's not sensible either.
> 
> State-smart words have become part of a new demonology

There's nothing new about it: as you know, Forth, Inc. had a stateless
Forth more than twenty years ago, and probably still would have but
for ANS.

> - ooh, they are so unsafe. For a Forth veteran to denigrate a
> technique because you have to know what you are doing is somewhat
> absurd.

That's not it, exactly: it's that, in general, state-smartness makes
programs harder to understand, and that state-smart words are hard to
use as factors.  There are, I admit, some exceptions to this rule.  On
the other hand, I'm sure you can name cases where state-smartness
really does help; if someone put a gun to my head, I probably could
too.

You must, surely, have had hot-shot programmers who liked to define
kewl syntaxes with state-smart words that you later ripped out, making
the resulting program clearer, but less cute?  Maybe not.

> State-smart words are still useful in a very bounded environment.
> I will continue to use them for specific manipulations. I will
> mark them as state-smart.

It may be that I am a bit too pure, a bit too much of an idealist.
Very well, I will admit to that.  But I suspect that "Don't write
state-smart words" will remain good advice, just like "don't GOTO".  A
programmer sometimes will ignore such advice, with good reason.

Andrew.

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

#11625

On Wed, 25 Apr 2012 10:52:41 -0500, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>You must, surely, have had hot-shot programmers who liked to define
>kewl syntaxes with state-smart words that you later ripped out, making
>the resulting program clearer, but less cute?  Maybe not.

I rip out those programmers as well ... they usually can't write
maintainable code. If the syntax improves readability and the
syntax can be maintained, then that's a good thing.

>But I suspect that "Don't write state-smart words" will remain
>good advice, just like "don't GOTO".

You just have to know where the dragons are.

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]

#11642

Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Wed, 25 Apr 2012 10:52:41 -0500, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
> 
>>You must, surely, have had hot-shot programmers who liked to define
>>kewl syntaxes with state-smart words that you later ripped out,
>>making the resulting program clearer, but less cute?  Maybe not.
> 
> I rip out those programmers as well ... they usually can't write
> maintainable code. If the syntax improves readability and the
> syntax can be maintained, then that's a good thing.

Maybe.  Do you not think that there is a difference between
superficial "readability" and maintainability?  I think that
state-smart words can score well on the former, but not the latter.
You look at the code and think you know what it's doing but are
misled.
 
>>But I suspect that "Don't write state-smart words" will remain good
>>advice, just like "don't GOTO".
> 
> You just have to know where the dragons are.

That perhaps depends on who "you" is: the person writing this stuff,
or the maintenance programmer ten years later.

Andrew.

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

#11682

In article <xdmdnch0AcG0jQTSnZ2dnUVZ_gadnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Stephen Pelc <stephenXXX@mpeforth.com> wrote:
>> On Wed, 25 Apr 2012 10:52:41 -0500, Andrew Haley
>> <andrew29@littlepinkcloud.invalid> wrote:
>>
>>>You must, surely, have had hot-shot programmers who liked to define
>>>kewl syntaxes with state-smart words that you later ripped out,
>>>making the resulting program clearer, but less cute?  Maybe not.
>>
>> I rip out those programmers as well ... they usually can't write
>> maintainable code. If the syntax improves readability and the
>> syntax can be maintained, then that's a good thing.
>
>Maybe.  Do you not think that there is a difference between
>superficial "readability" and maintainability?  I think that
>state-smart words can score well on the former, but not the latter.
>You look at the code and think you know what it's doing but are
>misled.
>
>>>But I suspect that "Don't write state-smart words" will remain good
>>>advice, just like "don't GOTO".
>>
>> You just have to know where the dragons are.
>
>That perhaps depends on who "you" is: the person writing this stuff,
>or the maintenance programmer ten years later.

There is not much difference. I come accross old programs.
This is terribly well-written! Oh, this is the way I would
have done it! This is nicely understandable!"
Turns out it *was* written by me.

You *are* a different person, ten years from now.

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

#11629

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:nfydnXXFXaBUgAXSnZ2dnUVZ_vednZ2d@supernews.com...
...

> [...] in general, state-smartness makes
> programs harder to understand, [...]

That claim comes up now and again.  I don't understand that claim at all.
Can someone explain that?

AISI, state-aware words work the *exactly* same way interactively as when
compiled.  How is that difficult to understand?  That seems *ideal* to me.
The word has zero ambiguity.

In fig-Forth, ' (tick) had one behavior, be it compiled or interactive.
What's wrong with that?  Why did Forth need to separate state-aware ' (tick)
into interactive ' (tick) and compile ['] ?

With non-state-aware words, you have to remember that a word doesn't work
*as expected* when compiled and you have to use another word.  Isn't it more
confusing to remember that *two* non-state-aware words are needed to do the
*exact* same thing in different modes instead of one state-aware word which
*always* does the correct thing?  I surely think so.  Not having a word work
the same way under all circumstances creates ambiguity.  Fortunately, the
somewhat standard use of [ and ] syntax to mark the compile version of words
helps.  Even so, how many times have you used ' instead of ['] at first?
(gotcha ;-)  Would we need POSTPONE if COMPILE had done what it was
supposed to do for all modes in the first place?  This syntax ambiguity
problem *has* to have contributed to the "write-once" beliefs about Forth.

> and that state-smart words are hard to
> use as factors.

Yes, I understand that.  You can't easily re-use parts of a state-aware
word.  But, does that really justify creating the syntax malarky and code
obfuscation due to the multiple words for non-state-awareness?


Rod Pemberton

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

#11631

On 4/25/12 9:28 AM, Rod Pemberton wrote:
> "Andrew Haley"<andrew29@littlepinkcloud.invalid>  wrote in message
> news:nfydnXXFXaBUgAXSnZ2dnUVZ_vednZ2d@supernews.com...
> ...
>
>> [...] in general, state-smartness makes
>> programs harder to understand, [...]
>
> That claim comes up now and again.  I don't understand that claim at all.
> Can someone explain that?
>
> AISI, state-aware words work the *exactly* same way interactively as when
> compiled.  How is that difficult to understand?  That seems *ideal* to me.
> The word has zero ambiguity.
>
> In fig-Forth, ' (tick) had one behavior, be it compiled or interactive.
> What's wrong with that?  Why did Forth need to separate state-aware ' (tick)
> into interactive ' (tick) and compile ['] ?

No, they are two very different behaviors.

' reads forward in the input stream and returns the xt of a word on the 
stack.

['] compiles the xt of a word in the current definition.

Not the same at all.

> With non-state-aware words, you have to remember that a word doesn't work
> *as expected* when compiled and you have to use another word.

Your expectations are faulty:

All Forth words except compiler directives (flow-of-control) and a very 
few exceptions (e.g. ( ) execute when encountered in the input stream, 
and are compiled when encountered inside a colon definition.

' *always* parses the input stream when it is *executed*, looks up the 
string in the dictionary, etc.

Therefore, it is perfectly reasonable to *expect* ' to be compiled when 
encountered in a colon definition and parse the input stream when the 
word in which it is compiled is executed.

It is extremely useful to have ' behave like normal Forth words because 
then you can use it in definitions which will parse the input stream 
when they are executed, look up a word in the dictionary, and return its 
xt to do something with.  If ' is state-smart you can't do that without 
getting involved with [COMPILE], COMPILE, etc., which are messy.

> Isn't it more
> confusing to remember that *two* non-state-aware words are needed to do the
> *exact* same thing in different modes instead of one state-aware word which
> *always* does the correct thing?  I surely think so.  Not having a word work
> the same way under all circumstances creates ambiguity.  Fortunately, the
> somewhat standard use of [ and ] syntax to mark the compile version of words
> helps.  Even so, how many times have you used ' instead of ['] at first?

About the same number of times I've used : when I meant VARIABLE, i.e., 
never. They are two different words.

...

>> and that state-smart words are hard to
>> use as factors.
>
> Yes, I understand that.  You can't easily re-use parts of a state-aware
> word.  But, does that really justify creating the syntax malarky and code
> obfuscation due to the multiple words for non-state-awareness?

Yes, because experience taught us that being able to use things line ' 
and CHAR inside of a definition is more *useful*, as well as more 
consistent and logical (per the description above) than having them be 
state-smart.

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]

#11639

On Apr 25, 8:28 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
wrote:
>
> AISI, state-aware words work the *exactly* same way interactively as when
> compiled.  How is that difficult to understand?  That seems *ideal* to me.
> The word has zero ambiguity.

I'm sure others can explain it better than me, but, in my newbie-
speak, the word (or rather, the action taken by the word) *can* become
ambiguous (or, more succinctly, not immediately obvious to the
programmer) when the word is used in conjunction with [COMPILE].

For example, I have a very useful word called ASCII :

: ASCII [COMPILE] CHAR STATE @ IF COMPILE LIT , THEN ; IMMEDIATE

This uses CHAR to get the first character of the word from the
terminal input buffer (following ASCII itself). If used with a colon
defintion it compiles that character as a literal. If used
interactively, it simply leaves the character on the stack. I find it
makes code quite readable:

ASCII A CONSTANT KEY_A

Is more readable (and conveys more information) than

65 CONSTANT KEY_A

And in a colon definition:

: colon ascii : emit ;

Is more intuitive than

: colon 58 emit ;

So, IMHO, there's a very good example of a genuinely useful state-
smart word.

Thing is, what happens here:

: clever-thing ... ... ... [compile] ascii ... ... ;

When clever-thing runs, it will invoke ascii. Which of the two
behaviours will ascii actually execute? What if you wanted to execute
the opposite behaviour?

This is where the argument (which I followed with some interest) of
having sucessors to FIND return two execution tokens, so that one can
choose the appropriate behaviour. Words with identical execution and
compilation semantics would return identical tokens for both states.

Anyway, hopefully that's a useful illustration. It's a very
interesting area of debate. I personally think it's okay to use state-
smart words, as long as the products' documentation makes the user
aware.

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

#11650

Op Thu, 26 Apr 2012 01:30:03 -0700 (PDT) schreef Mark Wills:

> On Apr 25, 8:28 pm, "Rod Pemberton" <do_not_h...@notemailnot.cmm>
> wrote:
>>
>> AISI, state-aware words work the *exactly* same way interactively as when
>> compiled.  How is that difficult to understand?  That seems *ideal* to me.
>> The word has zero ambiguity.
> 
> I'm sure others can explain it better than me, but, in my newbie-
> speak, the word (or rather, the action taken by the word) *can* become
> ambiguous (or, more succinctly, not immediately obvious to the
> programmer) when the word is used in conjunction with [COMPILE].
> 
> For example, I have a very useful word called ASCII :
> 
>: ASCII [COMPILE] CHAR STATE @ IF COMPILE LIT , THEN ; IMMEDIATE
> 
Why the [COMPILE] ?  CHAR is a normal word.

"COMPILE LIT ," can be written as "POSTPONE LITERAL" or "[COMPILE] LITERAL"
So you don't have to remember what LIT is. Some implementations use (LIT)
other may use something else, especially native code compilers.

> This uses CHAR to get the first character of the word from the
> terminal input buffer (following ASCII itself). If used with a colon
> defintion it compiles that character as a literal. If used
> interactively, it simply leaves the character on the stack. I find it
> makes code quite readable:
> 
> ASCII A CONSTANT KEY_A
CHAR A CONSTANT KEY_A  does the same.
> 
> Is more readable (and conveys more information) than
> 
> 65 CONSTANT KEY_A
> 
> And in a colon definition:
> 
>: colon ascii : emit ;
> 
Is it a problem to add two brackets as in:
: colon [char] : emit ;

> Is more intuitive than
> 
>: colon 58 emit ;
> 
Of course, do not use strange numbers in your code.

> So, IMHO, there's a very good example of a genuinely useful state-
> smart word.
> 
It's nnot.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#11653

On Apr 26, 4:30 am, Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> So, IMHO, there's a very good example of a genuinely
> useful state-smart word.

But its the behavior that makes it useful, not that fact that its
state-smart. That real advantage of [CHAR] and CHAR comes when it
comes time to use a word that *contains* CHAR or POSTPONE [CHAR]
(depending on what you *actually want to do*) ... when you POSTPONE a
state-smart word you can sometimes get an unexpectedly state-idiotic
result.

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

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

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

csiph-web