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

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

?EXEC

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

Contents

  ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-15 20:40 +0000
    Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-16 11:14 +1000
    Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-16 07:10 -0700
      Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-17 03:01 +0000
        Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-17 13:36 +1000
        Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-17 12:27 +0000
          Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-17 20:45 +0000
            Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-18 13:31 +0000
              Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-18 18:29 +0000
                Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-18 08:01 -1000
                Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-19 14:09 +0000
                  Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-19 10:51 -0500
                    Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-19 16:04 +0000
                      Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-19 12:45 -0500
                        Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-20 10:50 +0000
                          Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-20 07:10 -0500
                            Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-20 12:47 +0000
                  Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-19 22:52 +0000
                    Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-20 10:59 +0000
                  Defining Compilation Behaviour - was Re: ?EXEC JennyB <jennybrien@googlemail.com> - 2012-06-21 04:58 -0700
                    Re: Defining Compilation Behaviour - was Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-21 15:44 +0000
              Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-19 02:11 +0200
                Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-18 14:45 -1000
                  Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-19 10:48 +0000
                    Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-19 15:53 +0000
                      Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-19 23:00 +0000
                        Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-20 11:09 +0000
                          Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-20 07:39 -0700
                            Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-20 15:32 +0000
                              Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-21 11:24 -0700
                          Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-20 22:43 +0000
                          Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-21 21:39 +0200
                          Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-22 02:33 -0500
                            Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-22 11:12 +0000
                              Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-22 21:34 +0200
                                Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-24 14:58 +0000
                                  Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-24 23:53 +0200
                  Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-19 15:43 +0000
                Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-19 14:52 +0000
                  Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-21 22:15 +0200
                    Re: ?EXEC stephenXXX@mpeforth.com (Stephen Pelc) - 2012-06-22 10:32 +0000
                      Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-22 05:49 -0500
                        Alternatives to S" and TO (was: ?EXEC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-22 15:19 +0000
                          Re: Alternatives to S'' and TO mhx@iae.nl (Marcel Hendrix) - 2012-06-22 20:37 +0200
                            Re: Alternatives to S'' and TO anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-23 14:46 +0000
                          Re: Alternatives to S" and TO (was: ?EXEC) BruceMcF <agila61@netscape.net> - 2012-06-22 12:32 -0700
                          Re: Alternatives to S" and TO Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-23 03:07 -0500
                            Re: Alternatives to S" and TO anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-23 13:32 +0000
                              Re: Alternatives to S" and TO Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-24 08:50 -0500
                                Re: Alternatives to S" and TO anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-24 15:39 +0000
                                  Re: Alternatives to S" and TO Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-25 04:49 -0500
                                    Re: Alternatives to S" and TO BruceMcF <agila61@netscape.net> - 2012-06-25 07:17 -0700
                                      Re: Alternatives to S" and TO Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-25 10:13 -0500
                          Re: Alternatives to S" and TO (was: ?EXEC) Alex McDonald <blog@rivadpm.com> - 2012-06-23 16:01 -0700
                            Re: Alternatives to S" and TO (was: ?EXEC) Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-24 01:59 +0200
                              Re: Alternatives to S" and TO (was: ?EXEC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-24 13:21 +0000
                              Re: Alternatives to S" and TO (was: ?EXEC) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-24 16:50 +0000
                              Re: Alternatives to S" and TO (was: ?EXEC) Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-27 23:30 +0200
                            Re: Alternatives to S" and TO (was: ?EXEC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-24 13:15 +0000
                            Re: Alternatives to S" and TO (was: ?EXEC) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-24 16:47 +0000
                        Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-22 20:34 +0000
                      Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-22 21:46 +0200
                        Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-22 10:16 -1000
                          Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-22 22:43 +0200
                            Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-22 11:18 -1000
                            Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-23 13:50 +0000
        Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-17 10:41 -0700
    Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-17 12:52 +0000
      Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-17 08:03 -1000
        Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-18 15:06 +1000
          Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-17 20:31 -1000
            Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-21 13:07 +1000
              Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-21 14:00 +0000
                Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-21 07:51 -0700
                Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-21 15:39 +0000
                  Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-21 20:28 +0000
                    Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-28 14:22 +1000
                      Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-28 04:00 -0500
              Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-21 16:09 +0000
              Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-21 11:51 -0500
                Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-21 11:21 -0700
                  Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-22 01:42 -0500
                    Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-21 21:47 -1000
                      Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-22 15:10 +0000
                        Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-22 20:39 +0000
                      Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-22 12:47 -0700
                    Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-22 12:53 -0700
          Re: ?EXEC stephenXXX@mpeforth.com (Stephen Pelc) - 2012-06-21 08:39 +0000
            Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-23 15:36 +1000
              Re: ?EXEC stephenXXX@mpeforth.com (Stephen Pelc) - 2012-06-23 10:58 +0000
                Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-25 14:26 +1000
                  Re: ?EXEC stephenXXX@mpeforth.com (Stephen Pelc) - 2012-06-25 08:37 +0000
        Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-18 10:34 +0000
    Re: ?EXEC Coos Haak <chforth@hccnet.nl> - 2012-06-18 17:47 +0200
      Re: ?EXEC Coos Haak <chforth@hccnet.nl> - 2012-06-18 17:49 +0200
    Re: ?EXEC jacko <jackokring@gmail.com> - 2012-06-22 15:43 -0700

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

#13131 — Re: Defining Compilation Behaviour - was Re: ?EXEC

JennyB <jennybrien@googlemail.com> writes:
>On Tuesday, 19 June 2012 15:09:44 UTC+1, Anton Ertl  wrote:
>> If you want to add interpretation semantics for IF and DO, then go
>> ahead.  But don't produce STATE-smart IF and DO; for simple cases they
>> work as desired, but for more complex cases they sometimes fail.
>> Instead, if you want that stuff, bite the bullet and implement one of
>> the schemes for doing that properly.
>>=20
>> My feeling, though, is that in the balance it's a bad idea to have
>> such words.  Not only do you have to implement one of the schemes
>> above, but you also have repercussions elsewhere (like the meaning of
>> xts and how to reify the interpretation and compilation semantics).
>>=20
>
>It may be a bad idea, but it's even worse to have a bad idea, badly execute=
>d. Since people insist doing such things, shouldn't there be a clear way of=
> showing their meaning without mixing up interpretation and compilation beh=
>aviour in the one definition?
>
>The simplest way I can think of is:
>
>  COMPILES  xt -- set most recent definition to perform xt=20
>                  at compile-time
>
>IMMEDIATE may (or may not) be defined as LATESTXT COMPILES=20
>
>COMPILES may be implemented either by extending FIND when compiling to retu=
>rn the compiling xt and an immediate flag

Yes, that's a possibility, but it's pretty ugly: basically FIND now
has STATE as additional parameter and may deliver completely different
results based in this parameter.  I know that it's ugly because that's
what Gforth's FIND does.

It's better to have separate words for producing an xt for the
interpretation semantics and something (either an xt or xt1 xt2) for
the compilation semantics.

>or by a smart COMPILE, to perfor=
>m the appropriate action for the given xt.

That's a broken "COMPILE,", not a smart one.  A properly working
"COMPILE," compiles the same semantics that EXECUTE performs.  That
would not be the case if "COMPILE," performs the compilation semantics
(of, e.g., S") whereas EXECUTE performs the interpretation/execution
semantics.

- 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 2012: http://www.euroforth.org/ef12/

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

#13052

Anton Ertl wrote:
> Try <http://www.complang.tuwien.ac.at/forth/postponetest.fs> and see
> how IF and DO with ?COMP are broken.

I think this is a misunderstanding what "compilation semantics" could 
possibly mean - it's a literal reading of the standard.  Compilation 
semantics is what the text interpreter does with a word it encounters, 
which is

FIND 0< IF  COMPILE,  ELSE  EXECUTE  THEN

So what POSTPONE does is essentially (minus the self-reference, but I 
assume this is the cross compiler's POSTPONE):

FIND SWAP POSTPONE LITERAL 0< IF POSTPONE COMPILE, ELSE POSTPONE EXECUTE 
THEN

with some opportunity to optimize (lit+execute is call).  POSTPONE was 
introduced so that the implementer can choose to make some words 
immediate or not.

For an immediate word, the compilation semantics is to EXECUTE that 
word, for an non-immediate word, it is to COMPILE, this word.  POSTPONE 
embeds this into the current definition.  Unfortunately, for an 
immediate word, EXECUTE is also used to get the interpretation semantics 
fo that word.  The interpretation semantics of a word like IF is 
undefined, and the only standard way IF has to find out if it's 
interpretation or compilation semantics are requested is STATE.

postponetest.fs tests if the compiler uses non-standard features to 
implement these things.  You always argued that the standard would 
mandate postponetest.fs to pass.  It reads that way, but our recent 
discussion about semantics has revealed that things are a bit more 
complicated (or maybe let's say a bit more simplistic).

ANS Forth mandates that you implement CORE, but it also intents that 
CORE is a good minimal set of words which can be used as tools for the 
implementer himself.  If you have dual-xt name tokens, a compile-only 
flag, or an intelligent COMPILE,, you have no problems to implement 
?COMP in a way that postponetest.fs passes.  But the standard does not 
mandate these extensions, they are quality-of-implementation issues (and 
not having too many features is considered as quality of implementation 
by some people in the Forth community).

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

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

#13053

On 6/18/12 2:11 PM, Bernd Paysan wrote:
> Anton Ertl wrote:
>> Try<http://www.complang.tuwien.ac.at/forth/postponetest.fs>  and see
>> how IF and DO with ?COMP are broken.
>

The question means, what is "broken"? Interpretive versions of IF and DO 
are not illegal, those words are just not *guaranteed* to work in 
interpret mode.  "Interpretation semantics are undefined" means exactly 
that: a standard program may not depend on any specif behavior in that 
case. It's ok if it works. It's ok if it aborts. It's ok if it fails 
silently.

...
>
> postponetest.fs tests if the compiler uses non-standard features to
> implement these things.  You always argued that the standard would
> mandate postponetest.fs to pass.  It reads that way, but our recent
> discussion about semantics has revealed that things are a bit more
> complicated (or maybe let's say a bit more simplistic).
>
> ANS Forth mandates that you implement CORE, but it also intents that
> CORE is a good minimal set of words which can be used as tools for the
> implementer himself.  If you have dual-xt name tokens, a compile-only
> flag, or an intelligent COMPILE,, you have no problems to implement
> ?COMP in a way that postponetest.fs passes.  But the standard does not
> mandate these extensions, they are quality-of-implementation issues (and
> not having too many features is considered as quality of implementation
> by some people in the Forth community).

In my view, the intent of the standard is to be very laissez-faire about 
"undefined" features and "ambiguous conditions". It's ok to provide 
certain features, but they aren't required. It's ok to write programs 
that depend upon "undefined" features if you're willing to shoulder the 
responsibility for using only systems that provide them. It's also ok to 
issue error messages for options that you choose not to provide (or 
not). So, things like ?COMP are neither required nor illegal, they are 
matters of taste (even though some people think they're silly).

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]

#13061

In article <Z82dnTsD6awiVkLSnZ2dnUVZ_gqdnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 6/18/12 2:11 PM, Bernd Paysan wrote:
>> Anton Ertl wrote:
>>> Try<http://www.complang.tuwien.ac.at/forth/postponetest.fs>  and see
>>> how IF and DO with ?COMP are broken.
>>
>
>The question means, what is "broken"? Interpretive versions of IF and DO
>are not illegal, those words are just not *guaranteed* to work in
>interpret mode.  "Interpretation semantics are undefined" means exactly
>that: a standard program may not depend on any specif behavior in that
>case. It's ok if it works. It's ok if it aborts. It's ok if it fails
>silently.

So if I was wary about a program being standard w.r.t. to IF
 I could load a  preamble.
-----------
: IF    STATE @ 0=
    ABORT" NONPORTABLE: interpretation semantics of IF is undefined"
    POSTPONE IF ; IMMEDIATE
-----------

and it would only sift out nonportable programs.

If it triggers,I could try to find out whether I expect this particular
program to run on this particular implementation or modify the program
to behave as intended.

>Cheers,
>Elizabeth

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]

#13071

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>So if I was wary about a program being standard w.r.t. to IF
> I could load a  preamble.
>-----------
>: IF    STATE @ 0=
>    ABORT" NONPORTABLE: interpretation semantics of IF is undefined"
>    POSTPONE IF ; IMMEDIATE
>-----------
>
>and it would only sift out nonportable programs.

After this definition the system is non-standard and would fail for
some standard programs.  That's because your redefined IF has
compilation semantics that fail in interpret state.

- 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 2012: http://www.euroforth.org/ef12/

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

#13084

In article <2012Jun19.175328@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>So if I was wary about a program being standard w.r.t. to IF
>> I could load a  preamble.
>>-----------
>>: IF    STATE @ 0=
>>    ABORT" NONPORTABLE: interpretation semantics of IF is undefined"
>>    POSTPONE IF ; IMMEDIATE
>>-----------
>>
>>and it would only sift out nonportable programs.
>
>After this definition the system is non-standard and would fail for
>some standard programs.  That's because your redefined IF has
>compilation semantics that fail in interpret state.

Apparently I miss the point here. Can you give an example where
such a preamble would spoil the cake?

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

#13105

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>In article <2012Jun19.175328@mips.complang.tuwien.ac.at>,
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>>So if I was wary about a program being standard w.r.t. to IF
>>> I could load a  preamble.
>>>-----------
>>>: IF    STATE @ 0=
>>>    ABORT" NONPORTABLE: interpretation semantics of IF is undefined"
>>>    POSTPONE IF ; IMMEDIATE
>>>-----------
>>>
>>>and it would only sift out nonportable programs.
>>
>>After this definition the system is non-standard and would fail for
>>some standard programs.  That's because your redefined IF has
>>compilation semantics that fail in interpret state.
>
>Apparently I miss the point here. Can you give an example where
>such a preamble would spoil the cake?

: gen-foo ... postpone if ... ;
: bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;

- 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 2012: http://www.euroforth.org/ef12/

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

#13111

On Jun 20, 7:09 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>
>
>
>
>
>
>
>
>
> >In article <2012Jun19.175...@mips.complang.tuwien.ac.at>,
> >Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >>Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
> >>>So if I was wary about a program being standard w.r.t. to IF
> >>> I could load a  preamble.
> >>>-----------
> >>>: IF    STATE @ 0=
> >>>    ABORT" NONPORTABLE: interpretation semantics of IF is undefined"
> >>>    POSTPONE IF ; IMMEDIATE
> >>>-----------
>
> >>>and it would only sift out nonportable programs.
>
> >>After this definition the system is non-standard and would fail for
> >>some standard programs.  That's because your redefined IF has
> >>compilation semantics that fail in interpret state.
>
> >Apparently I miss the point here. Can you give an example where
> >such a preamble would spoil the cake?
>
> : gen-foo ... postpone if ... ;
> : bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;

So if source is trying, while interpreting, to perform the compilation
semantics of a word that doesn't necessarily have interpretation
behavior, that will be problematic?

Or, IOW, its problematic for source code with an implementation
dependency on a word containing postponed compilation semantics
functioning in interpretation state.

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

#13112

BruceMcF <agila61@netscape.net> writes:
>On Jun 20, 7:09=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
>> >Apparently I miss the point here. Can you give an example where
>> >such a preamble would spoil the cake?
>>
>> : gen-foo ... postpone if ... ;
>> : bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;
>
>So if source is trying, while interpreting, to perform the compilation
>semantics of a word that doesn't necessarily have interpretation
>behavior, that will be problematic?

I am not sure what your question is, but the issue is about performing
compilation semantics in interpret state.  An implementation of IF
containing ?COMP (or equivalent, like Albert's preamble) will fail
then, while it will likely work if the ?COMP is removed.

That's the general problem with STATE-smart words: they check STATE at
run-time instead of at parse time.  It works when the word is
text-interpreted directly (because then the run-time is performed
right after parsing), but it can fail if the run-time is delayed by
ticking or POSTPONEing (or [COMPILE]ing).

- 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 2012: http://www.euroforth.org/ef12/

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

#13137

On Jun 20, 11:32 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> BruceMcF <agil...@netscape.net> writes:
> >On Jun 20, 7:09=A0am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
> >wrote:
> >> Albert van der Horst <alb...@spenarnc.xs4all.nl> writes:
> >> >Apparently I miss the point here. Can you give an example where
> >> >such a preamble would spoil the cake?

> >> : gen-foo ... postpone if ... ;
> >> : bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;

> >So if source is trying, while interpreting, to perform the compilation
> >semantics of a word that doesn't necessarily have interpretation
> >behavior, that will be problematic?

> I am not sure what your question is, but the issue is about performing
> compilation semantics in interpret state.

Yes, which we are not necessarily guaranteed to be able to do with a
compliant implementation, but which some otherwise portable source may
have an implementation dependency on being able to do.

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

#13117

In article <2012Jun20.130929@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>In article <2012Jun19.175328@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>>>So if I was wary about a program being standard w.r.t. to IF
>>>> I could load a  preamble.
>>>>-----------
>>>>: IF    STATE @ 0=
>>>>    ABORT" NONPORTABLE: interpretation semantics of IF is undefined"
>>>>    POSTPONE IF ; IMMEDIATE
>>>>-----------
>>>>
>>>>and it would only sift out nonportable programs.
>>>
>>>After this definition the system is non-standard and would fail for
>>>some standard programs.  That's because your redefined IF has
>>>compilation semantics that fail in interpret state.
>>
>>Apparently I miss the point here. Can you give an example where
>>such a preamble would spoil the cake?
>
>: gen-foo ... postpone if ... ;
>: bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;

I see. For the moment I think the following is best.

I leave ?COMP in but in the rare case that some one would do the
above:

- program doesn't compile
- double check: "Hey it is intentional"
- WANT NO-SECURITY   NO-SECURITY

As far as I remember even the GNU c-compiler is only fully
compliant with the -pedantic option.
In Forth the equivalent is
        REQUIRE pedantic

To answer your question in the other thread:
I must have either ?COMP or an interpreted IF DO ,

otherwise
"
   1 \ size
   class ARRAY
     M: limit @ M; DUP ,
     0 DO 0 , LOOP
   endclass
"
goes wrong without a message and without an indication.

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

#13139

Anton Ertl wrote:
>>Apparently I miss the point here. Can you give an example where
>>such a preamble would spoil the cake?
> 
> : gen-foo ... postpone if ... ;
> : bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;

Anton, you should really stop reading the standard as a divine work, but 
as a work of Elizabeth Rather, Mitch Bradley, and others.  And these 
people simply think you are wrong with your interpretation.

There may be a compliation token within the system, but it is not 
required to have one (when it does not have one, it uses STATE at run-
time to decide which mode it is in).  All it is required to have is 
STATE and IMMEDIATE, and this implies that the compilation semantics 
(=the text interpreter result in compilation state) is only accessible 
when STATE is set to true.

We should write that into Forth200x, so that this silly discussion 
stops.  If you want to get rid of STATE and IMMEDIATE, make an RFC that

a) declare them as obsolescent and moves them out of CORE
b) provides a standard way to implement special 
compilation/interpretation behavior

RFI007 declares that "normal" words (i.e. those where only the execution 
semantics is specified, and all other semantics are derived by implicit 
rules) cannot be implemented as immediate state-smart words. This means 
that systems like VFX, where each primitive contains a special compiler 
for itself have to use a compilation-token approach like smart COMPILE,.

I think we all agree that a "normal" word is most useful: You can 
interpret and compile it, it does the same thing in both cases.  You can 
' and EXECUTE it, and you can ' and COMPILE, it, and the result is also 
the same.  Its behavior does not depend on a global variable like STATE.  
This is good.  This however has its own set of limitations.

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

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

#13152

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>In article <2012Jun19.175328@mips.complang.tuwien.ac.at>,
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>>>So if I was wary about a program being standard w.r.t. to IF
>>>> I could load a  preamble.
>>>>-----------
>>>>: IF    STATE @ 0=
>>>>    ABORT" NONPORTABLE: interpretation semantics of IF is undefined"
>>>>    POSTPONE IF ; IMMEDIATE
>>>>-----------
>>>>
>>>>and it would only sift out nonportable programs.
>>>
>>>After this definition the system is non-standard and would fail for
>>>some standard programs.  That's because your redefined IF has
>>>compilation semantics that fail in interpret state.
>>
>>Apparently I miss the point here. Can you give an example where
>>such a preamble would spoil the cake?
> 
> : gen-foo ... postpone if ... ;
> : bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;

But interpretation semantics of IF are undefined.  They don't
magically get to be defined just because you POSTPONEd  IF .

Andrew.

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

#13160

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>>Apparently I miss the point here. Can you give an example where
>>>such a preamble would spoil the cake?
>> 
>> : gen-foo ... postpone if ... ;
>> : bla ... [ 5 gen-foo s" hi" gen-bar ] ... ;
>
>But interpretation semantics of IF are undefined.  They don't
>magically get to be defined just because you POSTPONEd  IF .

There are no interpretation semantics of IF in play in this example.
POSTPONE IF compiles the compilation semantics of IF into GEN-FOO, and
GEN-FOO then performs the compilation semantics of IF.

- 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 2012: http://www.euroforth.org/ef12/

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

#13170

Anton Ertl wrote:
> There are no interpretation semantics of IF in play in this example.
> POSTPONE IF compiles the compilation semantics of IF into GEN-FOO, and
> GEN-FOO then performs the compilation semantics of IF.

So this works if there is a compilation token for IF, which only 
represents the compilation semantics, and not the interpretation 
semantis, which the implementer of a Forth system is free to decide what 
to do with (parse for the next ELSE/THEN in the input stream like [IF] 
does, or report an error, or just compile a forward branch without 
warning).

So far, we have a few solutions to this problem, with words like TO and 
S" being the hardest:

* State-smart words, which have the problem that they check for the 
state at run-time rather than at parse-time.

* Dual-xt solutions (whether dual-wordlist or a special flag in the 
header like in Gforth) result in a state-smart FIND, which just moves 
the problem around.

* Intelligent COMPILE, solutions, which however "violate" the spec of 
COMPILE, - that is specified to compile the "execution semantics".  This 
works in VFX Forth:

: if1 ['] if compile, ; immediate  ok
: else1 ['] else compile, ; immediate  ok
: then1 ['] then compile, ; immediate  ok
: test  if1 ." true" else1 ." false" then1 ;  ok
true test true ok

This is a bit embarrasing, but as IF in VFX Forth 4.4 is not immediate, 
it passes Mitch's "user written text interpreter" test.

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

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

#13221

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> There are no interpretation semantics of IF in play in this example.
>> POSTPONE IF compiles the compilation semantics of IF into GEN-FOO, and
>> GEN-FOO then performs the compilation semantics of IF.
>
>So this works if there is a compilation token for IF, which only 
>represents the compilation semantics, and not the interpretation 
>semantis, which the implementer of a Forth system is free to decide what 
>to do with (parse for the next ELSE/THEN in the input stream like [IF] 
>does, or report an error, or just compile a forward branch without 
>warning).
>
>So far, we have a few solutions to this problem, with words like TO and 
>S" being the hardest:
[...]
>* Dual-xt solutions (whether dual-wordlist or a special flag in the 
>header like in Gforth) result in a state-smart FIND, which just moves 
>the problem around.

Not in the least.  With these solutions the GEN-FOO example and S" and
TO work as described in the standard, so the problem has not just
moved around, it has been solved.

Concerning FIND, it's not a good fit for such systems, true.  That's
easy to solve by getting rid of FIND, which is also a good idea for
other reasons (counted string input).  Replace it with something
cleaner; there are so many better alternatives to FIND possible that
we have not been able to find consensus on which one we want to
standardize on.  But if you insist on keeping FIND, having FIND check
STATE is much less problematic in my experience than more typical
STATE-smartness.

Anyway, for stuff like the GEN-FOO example such a system is actually
not necessary.  A traditional-style single-xt-with-immediate system
can work for that, too.  But ?COMP will break it.  So ?COMP is the
problem.

>* Intelligent COMPILE, solutions, which however "violate" the spec of 
>COMPILE,

A COMPILE, that violates (not just "violates") the spec of COMPILE, is
not intelligent, but broken.

- 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 2012: http://www.euroforth.org/ef12/

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

#13225

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>So far, we have a few solutions to this problem, with words like TO
>>and S" being the hardest:
> [...]
>>* Dual-xt solutions (whether dual-wordlist or a special flag in the
>>header like in Gforth) result in a state-smart FIND, which just moves
>>the problem around.
> 
> Not in the least.  With these solutions the GEN-FOO example and S" and
> TO work as described in the standard, so the problem has not just
> moved around, it has been solved.

By now creating a problem in FIND.  And as the discussion about a 
replacement of FIND have shown, moving the problem there does not make 
the situation easier.

> But if you insist on keeping FIND, having FIND check
> STATE is much less problematic in my experience than more typical
> STATE-smartness.

I've no problems with the more typical STATE-smartness, either.  I just 
know that the state is not just there for fun, but that compilation 
state means when I want to compile something, I have to have STATE=true.  
I need it to find the right token (if I use FIND), and I need it to get 
the right reaction (if I use POSTPONE).

You said, you don't use FIND in your code, but I do.  I've considered 
rewriting my OOF to use Gforth's double tokens, but immediately realized 
that this solves exactly nothing, because my OOF first uses FIND and 
then EXECUTE or COMPILE, (depending on the flag) - all on potentially 
state smart words, because I need quite a bunch of them.  Either I have 
the problem in FIND, or in EXECUTing the word, but the problem remains 
the same.

> Anyway, for stuff like the GEN-FOO example such a system is actually
> not necessary.  A traditional-style single-xt-with-immediate system
> can work for that, too.  But ?COMP will break it.  So ?COMP is the
> problem.

?COMP is a very traditional way of doing this check.  Header flags are 
more modern.  Header flags have their own set of problems (particularly 
that the xt comes without them).

>>* Intelligent COMPILE, solutions, which however "violate" the spec of
>>COMPILE,
> 
> A COMPILE, that violates (not just "violates") the spec of COMPILE, is
> not intelligent, but broken.

IMHO the spec of COMPILE, is broken.  It doesn't really fit to what 
Mitch Bradley said it should fit to - his user-written text interpreter.  
It fits in a particular classical implementation, with the FIND we have 
now.

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

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

#13070

"Elizabeth D. Rather" <erather@forth.com> writes:
>On 6/18/12 2:11 PM, Bernd Paysan wrote:
>> Anton Ertl wrote:
>>> Try<http://www.complang.tuwien.ac.at/forth/postponetest.fs>  and see
>>> how IF and DO with ?COMP are broken.
>>
>
>The question means, what is "broken"?

Very simple: If I have an IF that passes postponetest.fs, and then
redefine it to call ?COMP (": if ?comp postpone if ; immediate"), it
then fails postponetest.fs.

>Interpretive versions of IF and DO 
>are not illegal

This is not about adding interpretation semantics to IF and DO.  It's
about the compilation semantics.  postponetest.fs only tests the
compilation semantics of IF and DO (it POSTPONEs IF, and POSTPONE
accesses the compilation semantics).

>In my view, the intent of the standard is to be very laissez-faire about 
>"undefined" features and "ambiguous conditions".

The compilation semantics of IF and DO are defined and unambiguous.

>So, things like ?COMP are neither required nor illegal, they are 
>matters of taste (even though some people think they're silly).

Putting ?COMP in an IF makes the IF non-standard.

- 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 2012: http://www.euroforth.org/ef12/

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

#13066

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> Try <http://www.complang.tuwien.ac.at/forth/postponetest.fs> and see
>> how IF and DO with ?COMP are broken.
>
>I think this is a misunderstanding what "compilation semantics" could 
>possibly mean - it's a literal reading of the standard.

And in what way is this a misunderstanding?  What do you suggest to
replace "reading the standard" with?  Divine inspiration?

Anyway, even if we agree that we don't want to put the onus of
implementing S" and TO properly on all systems (i.e., such that they
pass postponetest.fs), it's a good idea for implementors to pass as
much of postponetest.fs as possible, because there is production code
out there that will fail on systems where certain postponetest.fs
tests fail.

And putting ?COMP in an IF and DO that pass postponetest.fs will make
them fail postponetest.fs.

>ANS Forth mandates that you implement CORE, but it also intents that 
>CORE is a good minimal set of words which can be used as tools for the 
>implementer himself.  If you have dual-xt name tokens, a compile-only 
>flag, or an intelligent COMPILE,, you have no problems to implement 
>?COMP in a way that postponetest.fs passes.

What do you mean by that?  ?COMP is a check of STATE at run-time.  It
has this problem by nature.  If you mean that on some systems I have
ways to do properly what people try (and fail) to achieve with ?COMP,
that's true, but that's not ?COMP.  It's, e.g., Gforth's COMPILE-ONLY.

Here's what happens if I add ?COMP on a system that supports a
compile-only flag:

First, here's how it works without ?COMP:

gforth test/tester.fs test/coretest.fs postponetest.fs -e 'cr ." passed" cr bye'

[...]
passed


And here is the version with ?COMP:

gforth -e ': ?comp state @ 0= abort" running in interpret state" ;   : if ?comp postpone if ; immediate' test/tester.fs test/coretest.fs postponetest.fs -e 'cr ." passed" cr bye'
[...]
in file included from *the terminal*:0
postponetest.fs:202: running in interpret state
{ : PIF1 [ POSTPONE-IF ] 123 THEN ; -> }
           ^^^^^^^^^^^

>But the standard does not 
>mandate these extensions, they are quality-of-implementation issues (and 
>not having too many features is considered as quality of implementation 
>by some people in the Forth community).

In particular, one should not include misfeatures like ?COMP.  And
that's not just a quality-of-implementation issue.

- 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 2012: http://www.euroforth.org/ef12/

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

#13140

Anton Ertl wrote:
> And in what way is this a misunderstanding?  What do you suggest to
> replace "reading the standard" with?  Divine inspiration?

Asking the people who wrote it.  We don't need divine inspiration.

And: The way we standardize things is by looking at common practice.  If 
we find a feature in the standard which is *not* common practice, it's 
time to de-standardize it.

> Anyway, even if we agree that we don't want to put the onus of
> implementing S" and TO properly on all systems (i.e., such that they
> pass postponetest.fs), it's a good idea for implementors to pass as
> much of postponetest.fs as possible, because there is production code
> out there that will fail on systems where certain postponetest.fs
> tests fail.

Maybe.  There are however quite a lot of Forths out there which fail 
postponetest.fs, and they have production code running on it.  I had 
quite some troubles with VFX Forth with Postpone, and I was "the only 
one" who used strange things where Stephen's source inliner failed.  The 
tests required to break that weren't even part of test/postpone.fs, it 
would be something like

: n+: ( n -- )  >r  : r> postpone literal postpone + postpone ; ;
3 n+: 3+
: bar 3+ ;
{ 5 bar -> 8 }

With the source inliner, VFX Forth did not see any source after the 
definition of 3+, so it inlined that "nothing" into bar.  I should 
really add this one to postponetest.fs

> And putting ?COMP in an IF and DO that pass postponetest.fs will make
> them fail postponetest.fs.

Yes.  But the question is whether postponetest really tests something 
that is worth testing.  It tests whether postpone is able to preserve 
the compilation semantics of its postponed words in interpretation 
state.

> What do you mean by that?  ?COMP is a check of STATE at run-time.  It
> has this problem by nature.  If you mean that on some systems I have
> ways to do properly what people try (and fail) to achieve with ?COMP,
> that's true, but that's not ?COMP.  It's, e.g., Gforth's COMPILE-ONLY.

Yes, but COMPILE-ONLY (which sets a header flag) is not a standard word.  
It's a nice way to implement this feature, but it has to be pretty deep 
in the system. You can't add it later.  It's something that (including 
other features) makes Gforth EC 16kB large, while 4kB probably should be 
enough on an embedded system (and that 4k will not check anything and 
only implement core words).

>>But the standard does not
>>mandate these extensions, they are quality-of-implementation issues
>>(and not having too many features is considered as quality of
>>implementation by some people in the Forth community).
> 
> In particular, one should not include misfeatures like ?COMP.  And
> that's not just a quality-of-implementation issue.

IMHO, if the ANS Forth TC wanted to deliberately outlaw this misfeature 
(which was pretty common back then), it should have said so explicitely, 
and offer a way how to do it properly.

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

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

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

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

csiph-web