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

#13180

In article <97-dnWNi04BM0HnSnZ2dnUVZ8nydnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>Stephen Pelc <stephenXXX@mpeforth.com> wrote:
>> On Thu, 21 Jun 2012 22:15:08 +0200, Bernd Paysan <bernd.paysan@gmx.de>
>> wrote:
>>
>>>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
>>
>> 1) I did not write the source inliner. It was MPE's, not Stephen's.
>> 2) The source inliner is dead! Long live the tokeniser!
>
>He'll never let it go.  :-)
>
>>>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.
>>
>> POSTPONE had no common practice at the time it was introduced.
>> 18 years later we still have trouble with it.
>>
>> By comparison, CATCH and THROW had plenty of common practice, albeit
>> in other languages. It has caused no trouble.
>>
>> The lesson is not to standardise a solution until it has been
>> exhaustively evaluated. However, POSTPONE is a mess we have to
>> cope with until we have a proper model of xt's and Forth compilation
>> that allows for modern techniques. Once we have a model we can try
>> it and define a sensible word set. STATE POSTPONE and IMMEDIATE
>> may be casualties of this process in 20 years time.
>
>I'm very nervous about suggesting this, but here goes:
>
>I've been thinking the opposite.  Maybe the problem with some of the
>modern techniques is that they're exposed to the programmer; they're
>too shallow.  Perhaps the right solution is to let the Forth compiler
>generate tokens (just like a very trad Forth) and then let the
>optimizing compiler run over them.  Let IMMEDIATE do what it used to
>do.  Get rid of other ways of creating words that execute at compile
>time.  Let FIND do what it used to do.  Etc., etc...
>
>This is probably worthy of a workshop at EuroFORTH.

This ressembles an old idea of mine. Start with a very simple
indirect threaded Forth, with headers that allow for extra
information. A single one cell flag field goes a long way in
32 bits and 64 bits Forth.
I've added stack information to a version of ciforth, based on
analysis of the lowest (code) words. Then one can optimise away dead
code and execute all code that results in compile time constants,
meanwhile doing inlining. Then inline the assembler code and peephole
that.
See
    http://home.hccnet.nl/a.w.m.van.der.horst/forthlecture5.html

The main thing is that we want to exhaust all optimisation possibilities
on the higher level before we look at low level aspects.

(Related: an experiment with an editor that show stack effect.)

The most dramatic results I expect in the use of generic tools like
a quicksort that works with execution tokens:

: my-sort ['] my-swap ['] my-compare qsort ;

At a certain point this collapses to
<constant xt> execute
which can be replaced by xt, which can be inlined etc.
This all happens even before all words like DUP and >R are replaced
by their code sequences, where there will be a lot of POP's and
PUSHES that cancel.

>
>Andrew.

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]

#13171

Stephen Pelc wrote:
> 1) I did not write the source inliner. It was MPE's, not Stephen's.
> 2) The source inliner is dead! Long live the tokeniser!

Yes.  This was the consequence of that discussion, and we now know that 
this is the right way to do it.

> POSTPONE had no common practice at the time it was introduced.
> 18 years later we still have trouble with it.

POSTPONE "solved" a problem created by COMPILE and [COMPILE], without 
understanding that the problem comes from the immediate flag, which 
apparently is the root of all evil.

> By comparison, CATCH and THROW had plenty of common practice, albeit
> in other languages. It has caused no trouble.

We actually went some way further with CATCH as originally envisioned.  
E.g. take all these file-IO words which return an ior.  This wasn't 
specified as "you can just throw this, the system will produce a 
meaningful error message".  We now all do it that way, we expect an ior 
is something to throw.

> The lesson is not to standardise a solution until it has been
> exhaustively evaluated. However, POSTPONE is a mess we have to
> cope with until we have a proper model of xt's and Forth compilation
> that allows for modern techniques. Once we have a model we can try
> it and define a sensible word set. STATE POSTPONE and IMMEDIATE
> may be casualties of this process in 20 years time.

If we kill IMMEDIATE, what remains of POSTPONE is what once was called 
COMPILE, and it probably will be equal to ['] xxx COMPILE, .

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

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

#13176

On 6/22/12 9:46 AM, Bernd Paysan wrote:
> Stephen Pelc wrote:
...

>> By comparison, CATCH and THROW had plenty of common practice, albeit
>> in other languages. It has caused no trouble.
>
> We actually went some way further with CATCH as originally envisioned.
> E.g. take all these file-IO words which return an ior.  This wasn't
> specified as "you can just throw this, the system will produce a
> meaningful error message".  We now all do it that way, we expect an ior
> is something to throw.

Speak for yourself. I assure you, the Forth94 TC was very keen on using 
THROW on iors. It didn't seem either appropriate or necessary to specify 
it (or any of the other potential uses of THROW); it seemed obvious.

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]

#13183

Elizabeth D. Rather wrote:

> On 6/22/12 9:46 AM, Bernd Paysan wrote:
>> E.g. take all these file-IO words which return an ior.  This wasn't
>> specified as "you can just throw this, the system will produce a
>> meaningful error message".  We now all do it that way, we expect an
>> ior is something to throw.
> 
> Speak for yourself. I assure you, the Forth94 TC was very keen on
> using THROW on iors. It didn't seem either appropriate or necessary to
> specify it (or any of the other potential uses of THROW); it seemed
> obvious.

Yes, but what seems obvious and what is specified are two things - a 
standard has to be specific, not obvious.  At least it seemed obvious to 
me to implement it that way, and AFAIK there was an RFC in Forth200x 
which made it specific.

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

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

#13185

On 6/22/12 10:43 AM, Bernd Paysan wrote:
> Elizabeth D. Rather wrote:
>
>> On 6/22/12 9:46 AM, Bernd Paysan wrote:
>>> E.g. take all these file-IO words which return an ior.  This wasn't
>>> specified as "you can just throw this, the system will produce a
>>> meaningful error message".  We now all do it that way, we expect an
>>> ior is something to throw.
>>
>> Speak for yourself. I assure you, the Forth94 TC was very keen on
>> using THROW on iors. It didn't seem either appropriate or necessary to
>> specify it (or any of the other potential uses of THROW); it seemed
>> obvious.
>
> Yes, but what seems obvious and what is specified are two things - a
> standard has to be specific, not obvious.  At least it seemed obvious to
> me to implement it that way, and AFAIK there was an RFC in Forth200x
> which made it specific.
>

A standard has to be specific about required behavior, but not all the 
possible uses to which things may be put. THROW is useful for handling 
iors, but it is certainly not required that they be handled that way.

I note that several examples in the Appendix to the File Access wordset 
(e.g. A.11.6.1.2080 READ-FILE) show the use of THROW with iors returned.

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]

#13198

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Elizabeth D. Rather wrote:
>> Speak for yourself. I assure you, the Forth94 TC was very keen on
>> using THROW on iors. It didn't seem either appropriate or necessary to
>> specify it (or any of the other potential uses of THROW); it seemed
>> obvious.
>
>Yes, but what seems obvious and what is specified are two things - a 
>standard has to be specific, not obvious.  At least it seemed obvious to 
>me to implement it that way, and AFAIK there was an RFC in Forth200x 
>which made it specific.

IIRC we talked about it, but there is no RfD/CfV yet.

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

#13036

On Jun 16, 11:01 pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> In article <b445b94c-64c5-4773-be56-ee8c75f24...@h10g2000yqn.googlegroups.com>,
>
> BruceMcF  <agil...@netscape.net> wrote:
> >On Jun 15, 4:40=A0pm, Albert van der Horst <alb...@spenarnc.xs4all.nl>
> >wrote:
> >> I find places where ?EXEC is used. This gives an error because a word
> >> if a word is executed while it never should.
>
> >"because a word if a word is executed while it never should." ?
>
> >... seems to be mangled. What is the actual condition that is supposed
> >to trigger the error? Ed notes that its a fig-Forthism, and its been
> >several decades since I knew the fig Forth model in any detail.
>
> Sorry. I put too much trust in my spell checker ;-)
> Maybe just this:
> "
> SEE ?EXEC
>
> : ?EXEC
> STATE   @   12 ?ERROR
> ;
> "
> ?ERROR is THROW with some decoration.

Aha, so its just the opposite of ?COMP with its own distinctive error
return.

I think I'm with Anton. If I was trying to implement a small Forth in
some retro system or other, rather than ?COMP I'd have a compile-only
bit and blind the interpreter to compile-only words in interpret mode.

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

#13034

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>I find places where ?EXEC is used. This gives an error because a word
>if a word is executed while it never should.
>
>Examples are CODE and END-CODE in an assembler, but does this make
>sense?
>
>: CODE ?EXEC .... ;
>: END-CODE ?EXEC .... ;

Hardly.  It makes a little more sense if CODE and END-CODE are
immediate.  I guess the idea is to protect the porgrammer against

: foo
  ... \ missing ";"

code bar
  ...

And of course in fig-Forth also ":" was immediate and contained a
?EXEC.

For defining words we usually get an error when the name of the word
to be defined is seen; ok, the error is not as descriptive as the one
produced by ?EXEC, but programmers learn to interpret it pretty fast.

And the disadvantages are pretty bad: First, if you want to include
CODE (or ":") in another word, you have to use [COMPILE] or POSTPONE
(note that standard CODE and : don't need this).  Worse, that word
becomes STATE-smart; if you tick it and then happen to EXECUTE the xt
in compile STATE, you get an error, pretty removed from the cause of
the whole thing.

Overall, ?EXEC is a bad idea, like ?COMP and STATE-smart words in
general.

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

#13038

On 6/17/12 2:52 AM, Anton Ertl wrote:
> Albert van der Horst<albert@spenarnc.xs4all.nl>  writes:
>> I find places where ?EXEC is used. This gives an error because a word
>> if a word is executed while it never should.
>>
>> Examples are CODE and END-CODE in an assembler, but does this make
>> sense?
>>
>> : CODE ?EXEC .... ;
>> : END-CODE ?EXEC .... ;
>
> Hardly.  It makes a little more sense if CODE and END-CODE are
> immediate.  I guess the idea is to protect the porgrammer against
>
> : foo
>    ... \ missing ";"
>
> code bar
>    ...
>
> And of course in fig-Forth also ":" was immediate and contained a
> ?EXEC.

Baffled. By what logic should CODE, END-CODE, and : be immediate?

...
> Overall, ?EXEC is a bad idea, like ?COMP and STATE-smart words in
> general.

Agreed. All of these fall in the category of cute tricks that you *can* 
do in Forth, but are really a poor idea in serious production code. 
Newbies in Forth like to explore "uncharted waters". That's ok, but it's 
not how serious code is written.

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]

#13042

Elizabeth D. Rather wrote:
> On 6/17/12 2:52 AM, Anton Ertl wrote:
> > Albert van der Horst<albert@spenarnc.xs4all.nl>  writes:
> >> I find places where ?EXEC is used. This gives an error because a word
> >> if a word is executed while it never should.
> >>
> >> Examples are CODE and END-CODE in an assembler, but does this make
> >> sense?
> >>
> >> : CODE ?EXEC .... ;
> >> : END-CODE ?EXEC .... ;
> >
> > Hardly.  It makes a little more sense if CODE and END-CODE are
> > immediate.  I guess the idea is to protect the porgrammer against
> >
> > : foo
> >    ... \ missing ";"
> >
> > code bar
> >    ...
> >
> > And of course in fig-Forth also ":" was immediate and contained a
> > ?EXEC.
>
> Baffled. By what logic should CODE, END-CODE, and : be immediate?

Presumably so that you don't attempt:

    : foo ...  code foo2 ... end-code ... ;

> ...
> > Overall, ?EXEC is a bad idea, like ?COMP and STATE-smart words in
> > general.
>
> Agreed. All of these fall in the category of cute tricks that you *can*
> do in Forth, but are really a poor idea in serious production code.
> Newbies in Forth like to explore "uncharted waters". That's ok, but it's
> not how serious code is written.

VFX is loaded with ?COMPs.  Not "serious production code" ?

Until such time as someone can show an issue with using ?COMP
in IF ELSE THEN etc then how is it a problem?  Similarly CODE is
non-portable so whether it's immediate or contains a ?EXEC affects
no-one but the user.

Most tools can be mis-used.  We don't ban them because someone
has managed to cut their finger.

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

#13043

On 6/17/12 7:06 PM, Ed wrote:
> Elizabeth D. Rather wrote:
>> On 6/17/12 2:52 AM, Anton Ertl wrote:
>>> Albert van der Horst<albert@spenarnc.xs4all.nl>   writes:
>>>> I find places where ?EXEC is used. This gives an error because a word
>>>> if a word is executed while it never should.
>>>>
>>>> Examples are CODE and END-CODE in an assembler, but does this make
>>>> sense?
>>>>
>>>> : CODE ?EXEC .... ;
>>>> : END-CODE ?EXEC .... ;
>>>
>>> Hardly.  It makes a little more sense if CODE and END-CODE are
>>> immediate.  I guess the idea is to protect the porgrammer against
>>>
>>> : foo
>>>     ... \ missing ";"
>>>
>>> code bar
>>>     ...
>>>
>>> And of course in fig-Forth also ":" was immediate and contained a
>>> ?EXEC.
>>
>> Baffled. By what logic should CODE, END-CODE, and : be immediate?
>
> Presumably so that you don't attempt:
>
>      : foo ...  code foo2 ... end-code ... ;

What's to prevent...

	code foo ... : poo ... ; end-code ;

Since CODE isn't specified to set STATE, it's legal. Equally silly, 
equally unlikely.

>> ...
>>> Overall, ?EXEC is a bad idea, like ?COMP and STATE-smart words in
>>> general.
>>
>> Agreed. All of these fall in the category of cute tricks that you *can*
>> do in Forth, but are really a poor idea in serious production code.
>> Newbies in Forth like to explore "uncharted waters". That's ok, but it's
>> not how serious code is written.
>
> VFX is loaded with ?COMPs.  Not "serious production code" ?

Everybody gets to draw his/her own line as to what's too foolish to warn 
against.

> Until such time as someone can show an issue with using ?COMP
> in IF ELSE THEN etc then how is it a problem?  Similarly CODE is
> non-portable so whether it's immediate or contains a ?EXEC affects
> no-one but the user.
>
> Most tools can be mis-used.  We don't ban them because someone
> has managed to cut their finger.

I don't advocate banning ?COMP. I just think it's silly. And making CODE 
etc. IMMEDIATE just so you can issue an error message in case of blatant 
silliness is doubly silly.

As I've said elsewhere, I support the "intelligent programmer, 
permissive compiler" theory of programming. I can think of several 
reasons for using : and END-CODE in definitions, somewhat fewer for 
CODE, but I see no advantage to making them immediate unless you fancy 
yourself a programming nanny, in which case maybe Forth is not for you.

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]

#13122

Elizabeth D. Rather wrote:
> ...
> I don't advocate banning ?COMP. I just think it's silly. And making CODE
> etc. IMMEDIATE just so you can issue an error message in case of blatant
> silliness is doubly silly.
>
> As I've said elsewhere, I support the "intelligent programmer,
> permissive compiler" theory of programming. I can think of several
> reasons for using : and END-CODE in definitions, somewhat fewer for
> CODE, but I see no advantage to making them immediate unless you fancy
> yourself a programming nanny, in which case maybe Forth is not for you.

And presumably most forth implementors including MPE by
implication!

?COMP ?EXEC was part of Fig's compiler security package.
Given compiler security is all about catching unlikely things,
it was not unreasonable.

If making CODE END-CODE immediate was a bad move,
then I'm sure those affected would like to hear about it, even
after all this time.  Do you have practical examples to make
the case?

As regards ?COMP it is the more useful and has been used
for two things - to prevent inadvertent execution of conditionals
from corrupting memory, and/or to pinpoint errors early.

In SwiftForth inadvertent execution of BEGIN in immediate
mode results in an OK message.  Is it "Ok" ?  Most forth
implementations including commercials don't agree it is.

No, I don't fancy myself as a "programming nanny".  In fact my
system uses less syntax checking than most.  I could remove
the four ?COMPs currently present and my system would
still be protected.  I don't mind spending the 35 bytes plus
header it costs for the additional warning ?COMP provides.
Who knows, even SwiftForth users might like it :)

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

#13128

In article <jru388$iqb$1@speranza.aioe.org>, Ed <invalid@nospam.com> wrote:
>Elizabeth D. Rather wrote:
>> ...
>> I don't advocate banning ?COMP. I just think it's silly. And making CODE
>> etc. IMMEDIATE just so you can issue an error message in case of blatant
>> silliness is doubly silly.
>>
>> As I've said elsewhere, I support the "intelligent programmer,
>> permissive compiler" theory of programming. I can think of several
>> reasons for using : and END-CODE in definitions, somewhat fewer for
>> CODE, but I see no advantage to making them immediate unless you fancy
>> yourself a programming nanny, in which case maybe Forth is not for you.
>
>And presumably most forth implementors including MPE by
>implication!
>
>?COMP ?EXEC was part of Fig's compiler security package.
>Given compiler security is all about catching unlikely things,
>it was not unreasonable.
>
>If making CODE END-CODE immediate was a bad move,
>then I'm sure those affected would like to hear about it, even
>after all this time.  Do you have practical examples to make
>the case?
>
>As regards ?COMP it is the more useful and has been used
>for two things - to prevent inadvertent execution of conditionals
>from corrupting memory, and/or to pinpoint errors early.
>
>In SwiftForth inadvertent execution of BEGIN in immediate
>mode results in an OK message.  Is it "Ok" ?  Most forth
>implementations including commercials don't agree it is.
>
>No, I don't fancy myself as a "programming nanny".  In fact my
>system uses less syntax checking than most.  I could remove
>the four ?COMPs currently present and my system would
>still be protected.  I don't mind spending the 35 bytes plus
>header it costs for the additional warning ?COMP provides.
>Who knows, even SwiftForth users might like it :)

I think this is a good presentation of the trade offs.
It helps me to decide what I want to do with ciforth.

For ciforth I want ?COMP in. It catches lots of typos.

Using ?EXEC and making defining words IMMEDIATE can prevent
a situation that is extremely puzzling to a novice:

: def1 .... 
 DROP     \ note missing semicolon
: def2 ... 
;
\ Point A
....
much later
....
: def3   ...... def2 .....
                ^^^^
                Not found.

The problem is that an error is signalled at a much later time.
If the novice doesn't panic he discovers that at Point A
`` def2 '' is not defined. Then the bug is found soon enough.
The second time the novice (and even I myself) finds the
mistake immediately^H^H^H^H^H^H^H much faster.

On the other side the consequence is to always having to do
POSTPONE : .
One tends to forget that : is IMMEDIATE , because there
seems no good reason to do so, so this too leads to errors
(but those are signalled at the spot and easily corrected.)

Given that ciforth is simplistic and not very user
friendly to begin with, I'm not going to make all defining 
words immediate and will not used ?EXEC.


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

#13129

On Jun 21, 10:00 am, Albert van der Horst <alb...@spenarnc.xs4all.nl>
wrote:
> On the other side the consequence is to always having to do
> POSTPONE : .

Which makes it impossible to run standard source that compiles : to
execute at runtime. Forth94 : *has* default compilation semantics, so
an implementation with ?EXEC in : is not a Forth94 implementation.

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

#13130

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>Using ?EXEC and making defining words IMMEDIATE can prevent
>a situation that is extremely puzzling to a novice:
>
>: def1 .... 
> DROP     \ note missing semicolon
>: def2 ... 
   ^^^ Not found
>;
>\ Point A
>....
>much later
>....
>: def3   ...... def2 .....
>                ^^^^
>                Not found.
>
>The problem is that an error is signalled at a much later time.

It's usually signaled right after the defining word.  I have inserted
this "not found" message in the example above.

>On the other side the consequence is to always having to do
>POSTPONE : .

Better use [COMPILE] :.  That works on standard systems, too.

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

#13138

In article <2012Jun21.173954@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>Using ?EXEC and making defining words IMMEDIATE can prevent
>>a situation that is extremely puzzling to a novice:
>>
>>: def1 ....
>> DROP     \ note missing semicolon
>>: def2 ...
>   ^^^ Not found

OOF! you're right. This whole rant I sited from memory without trying
it. I'm pretty sure I have encountered situations that presented
problems, but at least they are rarer. It makes the case against
immediacy of defining words stronger.

>>;
>>\ Point A
>>....
>>much later
>>....
>>: def3   ...... def2 .....
>>                ^^^^
>>                Not found.
>>
>>The problem is that an error is signalled at a much later time.
>
>It's usually signaled right after the defining word.  I have inserted
>this "not found" message in the example above.
>
>>On the other side the consequence is to always having to do
>>POSTPONE : .
>
>Better use [COMPILE] :.  That works on standard systems, too.

Standard, i.e. where : is not IMMEDIATE.
That is an important point, and I'm glad I finally understand it.
Luckily it doesn't matter, because I don't go that way.

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

#13312

While IMMEDIATE and STATE can pose certain issues I don't see it as
the "evil" that's being made out.

Definers such as CONSTANT USER etc were classically not immediate
because there was no need.  Compiler words (IF DO LITERAL etc) were
immediate in Forth-79, 83 in recognition that, unlike regular words, these
needed to execute when in compilation state.

Forth-94 relaxed the immediacy tag on these words simply stating they
had "no interpretation semantics".  This doesn't stop one from keeping
them immediate, and of course it makes adding compiler security easy.

Compiler words are also differentiated from regular words in that 'Standard
programs' are not permitted to tick or FIND them.  That immediate and
state-smart words must be handled with care should not be surprising
given one is dealing with a special class of words.  Forth never claimed
to be user-proof - I doubt any language which allows the user to fool with
the compiler to the extent that Forth does, can be.

Forth has co-existed with immediacy and state-smartness for a very
long time and many (most?) systems currently employ it.  It hasn't
stopped users from creating substantial applications for over four
decades.  It can't have been too evil - whatever problems it may cause
for the Standard.

Most things come with a cost and removing immediacy/state-smartness
has its own.  Small systems in particular may see the cost outweigh
any benefit.

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

#13325

Ed <invalid@nospam.com> wrote:
> Compiler words are also differentiated from regular words in that 'Standard
> programs' are not permitted to tick or FIND them.

No.  The Forth programmer has an entitlement to write an interpreter,
so compiler words must work with FIND .

> Forth has co-existed with immediacy and state-smartness for a very
> long time and many (most?) systems currently employ it. 

By definition, standard systems have to: it's a requirement.

> It hasn't stopped users from creating substantial applications for
> over four decades.  It can't have been too evil

Yeah, it can.  STATE is one of those features, like COBOL's notorious
ALTER verb, that have their uses but are best avoided if possible.

> - whatever problems it may cause for the Standard.

STATE doesn't cause any problems for the standard AFAIK .

Andrew.

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

#13132

"Ed" <invalid@nospam.com> writes:
>If making CODE END-CODE immediate was a bad move,
>then I'm sure those affected would like to hear about it, even
>after all this time.  Do you have practical examples to make
>the case?

I don't use CODE, but fig-Forth also made : immediate with ?EXEC.
This means that you cannot just use : inside a colon definition to get
a defining word.  Instead, you have to [COMPILE] :.  And that's what I
did in the first release of Gray.  A bit later Marcel Hendrix ported
Gray to his Forth (not sure if it was iForth at the time); he saw the
[COMPILE] and converted it to POSTPONE.  Since his : was not
immediate, this did not achieve what was intended ([COMPILE] would
have been ok).

>As regards ?COMP it is the more useful and has been used
>for two things - to prevent inadvertent execution of conditionals
>from corrupting memory, and/or to pinpoint errors early.

There are much better approaches for achieving this.

>I don't mind spending the 35 bytes plus
>header it costs for the additional warning ?COMP provides.

I think you can have a proper solution for similar cost.

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

#13134

Ed <invalid@nospam.com> wrote:
> Elizabeth D. Rather wrote:
>> ...
>> I don't advocate banning ?COMP. I just think it's silly. And making CODE
>> etc. IMMEDIATE just so you can issue an error message in case of blatant
>> silliness is doubly silly.
>>
>> As I've said elsewhere, I support the "intelligent programmer,
>> permissive compiler" theory of programming. I can think of several
>> reasons for using : and END-CODE in definitions, somewhat fewer for
>> CODE, but I see no advantage to making them immediate unless you fancy
>> yourself a programming nanny, in which case maybe Forth is not for you.
> 
> And presumably most forth implementors including MPE by
> implication!
> 
> ?COMP ?EXEC was part of Fig's compiler security package.
> Given compiler security is all about catching unlikely things,
> it was not unreasonable.

I think the key to understanding this is that IMMEDIATE words are, by
definition, anomalous.  That is to say, they don't (or probably don't)
have "default compilation semantics".

The default in Forth is that given

: z   ( -) foo bar baz ;

you expect that Z calls FOO, BAR, then BAZ .  You may be wrong, but
it's a good first guess.  The principle of least surprise says that
you want to match, as far as possible, the readers' experience,
expectations, and mental models.  From this one can directly derive
the principle that one should minimize the number of IMMEDIATE words.

"Compiler security" in the fig-FORTH sense is part of Forth's history.

Andrew.


http://en.wikipedia.org/wiki/Principle_of_least_astonishment

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

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

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

csiph-web