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

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

State and the standard ...

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

Contents

  State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-02-28 11:35 -0500
    Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-01 20:46 -0500
      Re: State and the standard ... Elizabeth D Rather <erather@forth.com> - 2013-03-01 19:33 -1000
      Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-02 03:33 -0600
        Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-03 18:09 -0500
          Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-03 15:01 -1000
          Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 03:06 -0600
          Re: State and the standard ... Lars Brinkhoff <lars.spam@nocrew.org> - 2013-03-04 11:38 +0100
    Re: State and the standard ... stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-02 11:34 +0000
      Re: State and the standard ... "A. K." <akk@nospam.org> - 2013-03-02 13:47 +0100
      Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-02 14:07 +0100
      Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-02 12:38 -0500
        Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-02 15:50 -0600
          Re: State and the standard ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-02 22:11 +0000
            Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-03 02:51 +0100
              Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:56 +0000
                Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-03 22:42 +0100
                  Re: State and the standard ... stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-03 22:02 +0000
                  Re: State and the standard ... Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-04 00:19 -0800
                    Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-05 00:14 +0100
                    Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 16:34 +0000
                  Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-07 18:04 +0000
                    Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-08 01:31 +0100
                      Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 14:41 +0000
                        Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-09 17:04 +0100
                    Re: State and the standard ... Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-08 02:19 -0800
                      Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 04:25 -0600
                        Re: State and the standard ... Mark Wills <markrobertwills@yahoo.co.uk> - 2013-03-08 03:35 -0800
                          Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-08 06:58 -0600
                      Re: State and the standard ... Coos Haak <chforth@hccnet.nl> - 2013-03-08 20:57 +0100
            Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-03 11:25 -0500
              Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-03 15:13 -0600
                Re: State and the standard ... Coos Haak <chforth@hccnet.nl> - 2013-03-04 20:55 +0100
                  Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 15:17 -0600
                    Re: State and the standard ... Coos Haak <chforth@hccnet.nl> - 2013-03-05 00:27 +0100
                      Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 18:41 -0600
                        Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-04 20:49 -0500
                          Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-05 02:59 -0600
                            Re: State and the standard ... Alex McDonald <blog@rivadpm.com> - 2013-03-05 06:58 -0800
        Re: State and the standard ... Howerd <howerdo@yahoo.co.uk> - 2013-03-02 14:50 -0800
          Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-03 11:06 -0500
        Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:17 +0000
      Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 17:55 +0000
        Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-02 20:24 +0100
          Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-03 14:25 +0000
          Re: State and the standard ... Lars Brinkhoff <lars.spam@nocrew.org> - 2013-03-03 16:27 +0100
            Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-03 15:15 -0600
              Re: State and the standard ... Howerd <howerdo@yahoo.co.uk> - 2013-03-03 13:41 -0800
                Re: State and the standard ... Paul Rubin <no.email@nospam.invalid> - 2013-03-10 00:51 -0800
                  Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-10 04:35 -0500
                    Re: State and the standard ... Paul Rubin <no.email@nospam.invalid> - 2013-03-10 20:56 -0700
                      Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-11 03:47 -0500
                        Re: State and the standard ... Paul Rubin <no.email@nospam.invalid> - 2013-03-13 23:48 -0700
                          Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-13 21:01 -1000
                            Re: State and the standard ... Paul Rubin <no.email@nospam.invalid> - 2013-03-14 00:23 -0700
                            Re: State and the standard ... Lars Brinkhoff <lars.spam@nocrew.org> - 2013-03-14 09:18 +0100
                            Re: State and the standard ... Lars Brinkhoff <lars.spam@nocrew.org> - 2013-11-21 14:26 +0100
                          Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-14 03:34 -0500
                          Re: State and the standard ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-14 11:25 +0000
                      Re: State and the standard ... Mark Wills <forthfreak@gmail.com> - 2013-03-11 01:51 -0700
                  Re: State and the standard ... Howerd <howerdo@yahoo.co.uk> - 2013-03-10 03:03 -0700
              Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-07 18:00 +0000
            Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-03 22:49 +0100
              Re: State and the standard ... "A. K." <akk@nospam.org> - 2013-03-05 00:18 +0100
                Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-04 18:44 -0600
            intelligent COMPILE, and smart COMPILE, anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-04 17:52 +0000
              Re: intelligent COMPILE, and smart COMPILE, Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-05 00:49 +0100
                Re: intelligent COMPILE, and smart COMPILE, stephenXXX@mpeforth.com (Stephen Pelc) - 2013-03-05 10:55 +0000
        Re: State and the standard ... albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-02 22:22 +0000
    Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-02 17:37 +0000
      Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-03-03 18:08 -0500
        Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 16:26 +0000
    Re: State and the standard ... Michael L Gassanenko <m_l_g3@yahoo.com> - 2013-03-04 23:08 -0800
      Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-05 10:47 -0500
        Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-05 08:11 -1000
          Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-05 13:44 -0500
            Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-05 09:26 -1000
              Re: State and the standard ... Michael L Gassanenko <m_l_g3@yahoo.com> - 2013-03-07 04:24 -0800
                Re: State and the standard ... Doug Hoffman <glidedog@gmail.com> - 2013-03-07 09:42 -0500
                Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-07 08:16 -1000
                  Re: State and the standard ... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-03-08 17:14 +0000
                    Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-08 08:57 -1000
                      Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-09 17:31 +0100
                        Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-09 12:28 -0600
                          Re: State and the standard ... Bernd Paysan <bernd.paysan@gmx.de> - 2013-03-09 21:41 +0100
            Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-06 17:51 -0500
              Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 13:13 -1000
          Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-06 17:51 -0500
            Re: State and the standard ... "Elizabeth D. Rather" <erather@forth.com> - 2013-03-06 13:12 -1000
        Re: State and the standard ... Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-03-05 18:18 -0600
          Re: State and the standard ... Brad Eckert <hwfwguy@gmail.com> - 2013-03-06 08:22 -0800
        Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-06 17:49 -0500
          Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-06 17:56 -0500
          Re: State and the standard ... Rob Sciuk <rob@controlq.com> - 2013-03-06 18:17 -0500
            Re: State and the standard ... "Rod Pemberton" <do_not_have@notemailnotq.cpm> - 2013-03-08 04:22 -0500

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

#20449

Mark Wills <markrobertwills@yahoo.co.uk> writes:
>We're pointing the finger at "state-smart" (using the conventional
>meaning ;-) words because we cannot differentiate interpretation
>semantics from compilation sematics via tick.
>
>So, rotating the problem by 180 degrees, the problem is tick, not the
>state-smart words themselves.
>
>Therefore, simply standardise a new word, something like 'I (which
>means 'tick the *interpretation* behaviour/address/cfa/whatever' of
>the word.
>
>Of course, this has implications on the underlying architecture, and
>raises further questions. Now the dictionary (presumably) must be able
>to store pointers to both the compilation (for regular ') and
>interpretation semantics (for 'I ).

Since ' is defined to produce an xt for the interpretation semantics,
it would be a synonym to 'I, no need to standarize 'I.  What you have
described is pretty close to what has been in Gforth from 1996 to
2012.

Of course these words where ' knows how to access the interpretation
semantics (and POSTPONE the compilation semantics) do not behave like
STATE-smart words, and therefore are not STATE-smart words; if you
write a conventional STATE-smart word in Gforth, you will get a
STATE-smart word: ticking it will give you the xt that, when executed,
depends on STATE.

> Furthermore, what happens if the
>word has no interpretation sematics? Do you return the compilation
>sematics as a default, or return a 0 to expressly indicate that there
>are no interpretation semantics? All open for argument.

Gforth heeds the "fail early" principle here and reports an error:

' if 
*the terminal*:1: Cannot tick compile-only word (try COMP' ... DROP)
' 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 2013: http://www.euroforth.org/ef13/

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

#20407

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> However, what I am worried about is that your approach breaks the
>> currently existing relation between EXECUTE and COMPILE,.  Currently I
>> know that, when I write some tool that processes xts in some way, I
>> can COMPILE, these xts, and when they run, they will do what they
>> would have done if I had EXECUTEd them right away.
>
>Not really.  Consider you start with the state-smart world, and you compile 
>in compilation state into a word that might later run in interpretation 
>state.  If you EXECUTEd them right away, they would show their compilation 
>semantics, if you COMPILE,d them, they would later show their interpretation 
>semantics.  Or their compilation semantics, if the assumption above is 
>wrong.

You don't need STATE for that.  Any variable that the code reads will
do.  So, of course, in the presence of state variables, these
variables all need to have the same state.  But for the kind of stuff
I am thinking of, that is the case.

>> Say, if I know that I want to EXECUTE a sequence of xts several times,
>> I can define a colon definition, COMPILE, the xts into it, and then
>> call the colon definition several times.  With your approach, I could
>> no lonmger do that; you suggested that I should replace COMPILE, with
>> POSTPONE LITERAL POSTPONE EXECUTE, but that's neither nice nor fast.
>
>If you actually need that property.  For me, this looks like an academic 
>exercise.

Maybe, after all, I am an academic.  But I find such equivalences
useful.  I find it useful to know that > is equivalent to SWAP <, that
it is always equivalent and not just nearly always.  And I think that
industrial people profit from that, too.  Maybe after a few decades of
academic mulling over it, but eventually they do.

Currently I give an example of how MAP-ARRAY
<http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Execution-Tokens-Tutorial.html>
relates to COMPILE-MAP-ARRAY
<http://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Advanced-macros-Tutorial.html>.
If that equivalence no longer holds, I either have to say that this
may or may not work, but more likely I would not have written it at
all if that equivalence had not held.

>  I've built my fair share of hand-written compilers.  They usually 
>use the fragment Mitch Bradley posted to clarify what COMPILE, was for, i.e. 
>that FIND 0> IF EXECUTE ELSE COMPILE, THEN, because they wanted the 
>compilation semantics of the words found, not the interpretation semantics.  
>This is the common case.  The fact that we need to look at a result from 
>FIND, which is not passed on with the xt to decide whether to use EXECUTE or 
>COMPILE, shows that this solution will have problems (and the problems are 
>in the xt, which is why we can't find a good replacement for FIND).

FIND is a dinosaur that deserves to die.  But if you want to keep FIND
and keep that interpreter loop, no problem; This kind of interpreter
loop works with Gforth's FIND in all the versions of Gforth that had
combined words and where the equivalence held, so don't use that as an
excuse for breaking the equivalence!

Sure this FIND is ugly, but what do you expect?  It's a relic from
another world.

>BTW: for the state-smart implementations, it won't work either way.  
>COMPILE, will just preserve the state-smart nature of the word, just as well 
>as ]] LITERAL EXEUCTE [[ will (no difference there).

Yes, that's as it should be.

>The only place in Gforth where the new semantics might case problems is in 
>DEFERS.  DEFERS takes the action of a deferred word, and compiles it.  Note 
>that a deferred word itself can only expose the execution semantics of the 
>word bound to it, so the definition
>
>: defers ( "name" -- ) ' defer@ compile, ; immediate compile-only
>
>is actually not correct.  It should use that ]] literal execute [[ thing.  

So you found a place where the equivalence matters, and it was not
even written by me.  Maybe it is not so academic after all.  The
definition of DEFERS used to be correct.  By making COMPILE, incorrect
DEFERS becaome incorrect.  The mistake is not in DEFERS, but in the
change to COMPILE,.

>The same thing for the OOP early binding, because the vtable also can only 
>do EXECUTE, and therefore, COMPILE, would be wrong.

And another example.

>However, despite defers is used not so infrequently, this didn't cause any 
>problem.

Sure, most of the time the equivalence still holds.  But STATE-smart
words also work most of the time.

- 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 2013: http://www.euroforth.org/ef13/

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

#20421

Anton Ertl wrote:
>>: defers ( "name" -- ) ' defer@ compile, ; immediate compile-only
>>
>>is actually not correct.  It should use that ]] literal execute [[ thing.
> 
> So you found a place where the equivalence matters, and it was not
> even written by me.  Maybe it is not so academic after all.  The
> definition of DEFERS used to be correct.  By making COMPILE, incorrect
> DEFERS becaome incorrect.  The mistake is not in DEFERS, but in the
> change to COMPILE,.

No, the thing does not cause any problems at all.  It shows that the 
equivalence for all practical purposes is correct, and your concern is 
academical.  You wouldn't assign a word with special compilation semantics 
to a deferred word, because it already would be broken that way.  Think 
about this:

defer " immediate
\ we want our single quote back, but the user can select c" or s"
' s" is " \ a reasonable default

: foo " blabla" ;

Oops, this doesn't work, it would have worked if s" is state-smart.  
Actually, we can make it work with

: [defer] ( "name" -- )
  defer [: >body @ compile, ;] set-compiler ;

Now if we use [defer] to define a deferred word, it can take a special 
compilation semantics word, and perform their special compilation semantics 
in compilation state.

>>The same thing for the OOP early binding, because the vtable also can only
>>do EXECUTE, and therefore, COMPILE, would be wrong.
> 
> And another example.

But still, it does not cause any problems.  This is because the methods are 
actually just :noname definitions which don't have any special compilation 
semantics.  Only if they had, it would be a potential problem.  You might 
want something like [method] to create such a selector, which then would 
allow you to define compiler macro methods (there's a place for them, 
BerndOOF has several).

If you want to extend such a compiler macro method, and use super on them, 
you then want to carefully select the interpretation and the compilation 
semantics, so you actually need to versions of super.

>>However, despite defers is used not so infrequently, this didn't cause any
>>problem.
> 
> Sure, most of the time the equivalence still holds.  But STATE-smart
> words also work most of the time.

Yes.  But on the other hand, IMHO this equivalence is an artificial one, and 
comes out of a mis-specification of compile,, as you actually don't have 
access to the compilation semantics of an xt in ANS Forth.

The fix for that IMHO is to provide interp, for the purpose you want.  That 
word makes pretty clear that you append the interpretation/execution 
semantics, and are not actually attempting to really compile the token.

BTW, in VFX, [INTERP] is really just

: [interp] ( "name" -- )
  ' postpone Literal postpone execute ; immediate

The compiler does some optimizations, so it ends up as call, but no inlining 
magic is performed.  An optimizted version in Gforth could use an INTERP, 
which does the original case statement for COMPILE, (looking at the doer to 
decide what to compile).

This is Forth, we are striving for simplicity.  One indication about 
simplicity is orthogonality in the description.  The ANS Forth standard has 
three clearly defined semantics: interpretation, compilation, and run-time 
semantics.  By default, run-time=interpretation, and compilation=add 
interpretation semantics.  Now, COMPILE, is specified to perform the 
default, this is breaking the symmetry, and making things more complicated.  
The reason is that at that time, non-default compilation semantics was 
specified by IMMEDIATE, and the xt doesn't know if it's immediate or not.

Let's assume we do what you suggest: add another method to the vtable, and 
add another word to do "the compiling", which would be something different 
than compile,.  Now, you might have set-compiler and set-compile, to set 
them.  How to choose which is the appropriate one?  Most of the time, it 
doesn't make a difference, so chances are high that people will not 
understand why there are two, and treat them interchangeable.  It will 
sometimes result in non-optimal code (if the optimizing version ends up in 
compiler, but should end up in compile,), sometimes in bugs like the above, 
where you can't use COMPILE, to get at the interpretation semantics.

If you have two things that do almost the same, but differ in sublte things 
that happen only once in a blue moon, you better do just one of them.

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

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

#20446

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>>>: defers ( "name" -- ) ' defer@ compile, ; immediate compile-only
>>>
>>>is actually not correct.  It should use that ]] literal execute [[ thing.
>> 
>> So you found a place where the equivalence matters, and it was not
>> even written by me.  Maybe it is not so academic after all.  The
>> definition of DEFERS used to be correct.  By making COMPILE, incorrect
>> DEFERS becaome incorrect.  The mistake is not in DEFERS, but in the
>> change to COMPILE,.
>
>No, the thing does not cause any problems at all.

Yet.

>  It shows that the 
>equivalence for all practical purposes is correct, and your concern is 
>academical.

Well, then why do you want to break that equivalence?

>You wouldn't assign a word with special compilation semantics 
>to a deferred word, because it already would be broken that way.

Depends on what you expect.  I guess you are thinking of a changeable
SYNONYM.  I would hav thought that your universal xt and broken
"COMPILE," are intended to achieve that with an unchanged DEFER (just
like for the interpreter loop).  If it does not achieve that, maybe
your concepts are not as good as you think.

OTOH, I don't expect DEFER to be a changeable SYNONYM, just like I
don't expect ALIAS to be a SYNONYM.  I would just define a new word
for changeable synonyms, and that may or may not be tied to your ideas
about xts (preferably it would not depend on them).

Here you suggest a version that depends on them:

>: [defer] ( "name" -- )
>  defer [: >body @ compile, ;] set-compiler ;

But it would be just as possible to write a [defer] without breaking
"COMPILE,", or (with a different interface) to write it in Gforth
0.7.0 (you would either pass the name, the nt or the xt and ct to the
IS replacement).

However, looking at the example again, I expect a deferred word to
bind at run-time, not at deferred-word compilation like your [DEFER]
does.  I have not seen an example where such a changeable synonym that
binds at compile time when it is compiled, and at run-time when it is
interpreted, is useful.

The " example is not convincing, because you cannot use S" and C"
interchangeably (different stack effects), so switching them around
dynamically makes no sense.  What you try to achieve with that can be
achieved already with SYNONYM and search order.

[...]
>>>The same thing for the OOP early binding, because the vtable also can only
>>>do EXECUTE, and therefore, COMPILE, would be wrong.
>> 
>> And another example.
>
>But still, it does not cause any problems.  This is because the methods are 
>actually just :noname definitions which don't have any special compilation 
>semantics.  Only if they had, it would be a potential problem.  You might 
>want something like [method] to create such a selector, which then would 
>allow you to define compiler macro methods (there's a place for them, 
>BerndOOF has several).

So you can think of potential problems.  If combined words are used
more commonly than now (and I guess you would be among the frequent
users), the problems will eventually show up in reality. 

>Yes.  But on the other hand, IMHO this equivalence is an artificial one

Why do you think so?

Looking at the DEFERS and [BIND]/SUPER/:: examples, it seems pretty
natural; did you even consider for one second that you should write
"POSTPONE literal POSTPONE execute" instead of "COMPILE," when you
originally wrote that code?

> and 
>comes out of a mis-specification of compile,, as you actually don't have 
>access to the compilation semantics of an xt in ANS Forth.

In ANS Forth compilation semantics is bound to named words, not xts.
There are two places where it occurs: When the text interpreter
processes a (named) word in compilation state, and in POSTPONE (which
also takes a name).

I think that COMPILE, is well specified.  Why do you think it is
mis-specified?  And please post your "improved" specification again.

>The fix for that IMHO is to provide interp, for the purpose you want.  That 
>word makes pretty clear that you append the interpretation/execution 
>semantics, and are not actually attempting to really compile the token.

You mean that we should change "COMPILE," to do something different
from what it does now, and introduce "INTERP," to do what "COMPILE,"
does now?  Memories of Forth-83 arise.

An alternative would be to just leave "COMPILE," as it is and
introduce a new word (maybe "COMPSEM,", but you sure can come up with
a better name) that does what you want.  You would have to use
"COMPSEM," in the interpreter loop, but the FIND would be cleaner.

Or, if you want to keep the Bradley interpreter loop unchanged,
implement FIND to return different xts depending on STATE (like Gforth
is doing now).  You can still introduce "COMPSEM," if you want.

>This is Forth, we are striving for simplicity.  One indication about 
>simplicity is orthogonality in the description.  The ANS Forth standard has 
>three clearly defined semantics: interpretation, compilation, and run-time 
>semantics.  By default, run-time=interpretation, and compilation=add 
>interpretation semantics.

Yes, except that what you call "run-time semantics" is called
"execution semantics" in ANS Forth, and in ANS Forth the run-time
semantics of some words is a helper for defining the compilation
semantics of that word.

>  Now, COMPILE, is specified to perform the 
>default, this is breaking the symmetry, and making things more complicated.  

What symmetry?

What makes things complicated is combined words.

>The reason is that at that time, non-default compilation semantics was 
>specified by IMMEDIATE, and the xt doesn't know if it's immediate or not.

And?  Why should it be necessary to know that?

>Let's assume we do what you suggest: add another method to the vtable, and 
>add another word to do "the compiling", which would be something different 
>than compile,.  Now, you might have set-compiler and set-compile, to set 
>them.  How to choose which is the appropriate one?  Most of the time, it 
>doesn't make a difference, so chances are high that people will not 
>understand why there are two, and treat them interchangeable.  It will 
>sometimes result in non-optimal code (if the optimizing version ends up in 
>compiler, but should end up in compile,), sometimes in bugs like the above, 
>where you can't use COMPILE, to get at the interpretation semantics.

These are not bugs.  These use COMPILE, as specified.

OTOH, if you are right, you should be able to point to lots of uses of
COMPILE, where the current usage of COMPILE, is wrong, because the
programmer actually intended to perform the compilation semantics
instead of appending the intepretation/execution semantics.  Until now
we only know several cases that would be broken by the change you
suggest for "COMPILE,".  How many cases do you have that would be
fixed by that change?

>If you have two things that do almost the same, but differ in sublte things 
>that happen only once in a blue moon, you better do just one of them.

Sounds like an argument against your "INTERP," (as well as against
"COMPSEM,").

You can also look at how many uses of POSTPONE, are wrong.  Of course
POSTPONE, is sufficiently different (different stack effect) that it's
not easy to use it instead of COMPILE,.  If so, and you are right
about confusing "COMPILE," with the other words, that's an argument
against going for a universal xt.

- 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 2013: http://www.euroforth.org/ef13/

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

#20491

Anton Ertl wrote:
>>No, the thing does not cause any problems at all.
> 
> Yet.
> 
>>  It shows that the
>>equivalence for all practical purposes is correct, and your concern is
>>academical.
> 
> Well, then why do you want to break that equivalence?

Because it was an unintended consequence of a misformulation of what 
COMPILE, is supposed to do.  It should *compile* something.  It should not 
add interpretation semantics.

I think our main difference is that I consider the current COMPILE, as 
broken and misspecified, and you think it's god-given.  It's not.  It's 
Mitch-Bradley-given, and Mitch Bradley had explained what he wanted it to 
do.  And following that explanation, the spec of COMPILE, in ANS Forth is 
simply wrong.

>>You wouldn't assign a word with special compilation semantics
>>to a deferred word, because it already would be broken that way.
> 
> Depends on what you expect.  I guess you are thinking of a changeable
> SYNONYM.  I would hav thought that your universal xt and broken
> "COMPILE," are intended to achieve that with an unchanged DEFER (just
> like for the interpreter loop).  If it does not achieve that, maybe
> your concepts are not as good as you think.

How would that be possible?  The unchanged DEFER uses EXECUTE on the token, 
never COMPILE,.  So how would that work without other changes?  The token 
knows how to compile, but the unchanged DEFER can't access this.

> OTOH, I don't expect DEFER to be a changeable SYNONYM, just like I
> don't expect ALIAS to be a SYNONYM.  I would just define a new word
> for changeable synonyms, and that may or may not be tied to your ideas
> about xts (preferably it would not depend on them).

You probably would use your nt for that.  This is something I absolutely 
hate about typical Java code: Tons of types which are slightly different, 
and do almost the same, but are incompatible, you often can only do forward 
conversions (but not backward to where this thing came from), and it all 
wraps onion layers around the real thing.  Don't add things like this to a 
language.  Try to reduce the number of types to what you actually need.

> Here you suggest a version that depends on them:
> 
>>: [defer] ( "name" -- )
>>  defer [: >body @ compile, ;] set-compiler ;
> 
> But it would be just as possible to write a [defer] without breaking
> "COMPILE,", or (with a different interface) to write it in Gforth
> 0.7.0 (you would either pass the name, the nt or the xt and ct to the
> IS replacement).

You see your inflation of types, which do almost, but certainly not exactly 
the same thing, which lead to confusion and again subtle bugs.

> However, looking at the example again, I expect a deferred word to
> bind at run-time, not at deferred-word compilation like your [DEFER]
> does.  I have not seen an example where such a changeable synonym that
> binds at compile time when it is compiled, and at run-time when it is
> interpreted, is useful.

That's probably why we don't have such a thing.  BTW: The special-
compilation semantics OOP methods in BerndOOF are also all early bound, so 
they actually don't go through a method table.  But that might change if we 
think of them as part of a Meta-OOP package, where different OOP systems 
might want to implement them slightly differently.

> The " example is not convincing, because you cannot use S" and C"
> interchangeably (different stack effects), so switching them around
> dynamically makes no sense.  What you try to achieve with that can be
> achieved already with SYNONYM and search order.

Maybe.  The " example would be introduced as harness code for code that uses 
" instead of C" or S".

> [...]
>>Only if they had, it would be a potential problem.  You might
>>want something like [method] to create such a selector, which then would
>>allow you to define compiler macro methods (there's a place for them,
>>BerndOOF has several).
> 
> So you can think of potential problems.  If combined words are used
> more commonly than now (and I guess you would be among the frequent
> users), the problems will eventually show up in reality.

Which means go forward, and implement BerndOOF using monotokens, and see 
when it starts to cause problems.

>>Yes.  But on the other hand, IMHO this equivalence is an artificial one
> 
> Why do you think so?
> 
> Looking at the DEFERS and [BIND]/SUPER/:: examples, it seems pretty
> natural; did you even consider for one second that you should write
> "POSTPONE literal POSTPONE execute" instead of "COMPILE," when you
> originally wrote that code?

Let's go back again, and let's assume we have a POSTPONE method (there is), 
which we want to override (which we can't ATM), say for debugging purposes.  
So we do

: postpone ( "name" -- )  compile-only-error ;
comp: ( xt -- ) drop ." Print some debugging stuff" super postpone postpone 
;

super as literal+execute would be clearly wrong here.  Note that we need 
this double "postpone", because the super postpone just performs the 
compilation semantics in the super context, and there, it just postpones the 
next word.  Which is postpone in the super context - that's what we want.

BTW: Most of those state-smart words in BerndOOF are state-smart for 
optimization, not as compilation macros.  We want use COMPILE, on them, 
definitely, because we want to optimize the code.

>> and
>>comes out of a mis-specification of compile,, as you actually don't have
>>access to the compilation semantics of an xt in ANS Forth.
> 
> In ANS Forth compilation semantics is bound to named words, not xts.

Yes, this comes from the immediate flag, which is a header flag, and not 
available through the xt.

> There are two places where it occurs: When the text interpreter
> processes a (named) word in compilation state, and in POSTPONE (which
> also takes a name).

Yes, but if you think the concept further, and we do that, we need 
compilation semantics on tokens that are detached from their names, and that 
detaching happens before we know if we want to compile them or just 
interpret them.

> I think that COMPILE, is well specified.  Why do you think it is
> mis-specified?

You still don't want to accept the rationale Mitch Bradley has given for 
COMPILE,, and the fact that COMPILE, was added late in the process and 
didn't get much review.

> And please post your "improved" specification again.

COMPILE, performs the compilation semantics of non-immediate words.  The 
compilation semantics of immediate words is performed with EXECUTE.  
immediate words are a legacy of the STATE-smart universe.  We can't get rid 
of them quickly, but we know we need something better.

>>The fix for that IMHO is to provide interp, for the purpose you want. 
>>That word makes pretty clear that you append the interpretation/execution
>>semantics, and are not actually attempting to really compile the token.
> 
> You mean that we should change "COMPILE," to do something different
> from what it does now, and introduce "INTERP," to do what "COMPILE,"
> does now?  Memories of Forth-83 arise.

Well, VFX has already changed that 15 years ago.  If there was a serious 
problem with that approach, I would have found it.  I found quite a number 
of problems with VFX (for that kind of "guru code" I write).  COMPILE, 
wasn't one.  And I do write my own interpreters which use COMPILE, a lot, 
especially in BerndOOF.

Stephen Pelc accused me that my attitude of porting programs to other 
systems (by improving their implementation quality rather than lowering my 
expectations) would not make the next port easier, and he's right.  It will 
not make *my* next port easier, but it will make the next port of all others 
easier, because the systems behave more alike.

> An alternative would be to just leave "COMPILE," as it is and
> introduce a new word (maybe "COMPSEM,", but you sure can come up with
> a better name) that does what you want.  You would have to use
> "COMPSEM," in the interpreter loop, but the FIND would be cleaner.

IMHO we just can't have both Mitch's interpreter loop and what you want.  
From my point of view, Mitch's interpreter loop is more important, because 
this really does exist (e.g. in BerndOOF - if VFX's COMPILE, would do what 
you want it to do, BerndOOF quite likely wouldn't work).

MPE introduced [INTERP] <name>, because they had two use cases for that, 
both with names.  Given that it just expands to ['] <name> EXECUTE, it's not 
sure if that was actually necessary.

> Or, if you want to keep the Bradley interpreter loop unchanged,
> implement FIND to return different xts depending on STATE (like Gforth
> is doing now).  You can still introduce "COMPSEM," if you want.

I can't let FIND return different xts for that, because an executable 
"compilation token" always is a pair of xts (as in Gforth).  This won't 
work.

There's some place for a NAME>COMP EXECUTE replacement, which handles both 
the immediate case and the separate compilation semantics case.

> Yes, except that what you call "run-time semantics" is called
> "execution semantics" in ANS Forth, and in ANS Forth the run-time
> semantics of some words is a helper for defining the compilation
> semantics of that word.

Nah.  The execution semantics of an immediate word is its compilation 
semantics, and then it can add some other run-time semantics.

>>  Now, COMPILE, is specified to perform the
>>default, this is breaking the symmetry, and making things more
>>complicated.
> 
> What symmetry?

As described in the ANS Forth standard, words have interpretation and 
compilation semantics.  ANS Forth's COMPILE, performs default compilation 
semantics even on those words which don't have default compilation 
semantics.  This is a part of COMPILE,'s behavior, which should have better 
not specified.  And in fact, IMHO VFX shows that leaving that open is not a 
problem at all - other parts of VFX were problems, and have been fixed 
since, but the non-standard COMPILE, is not one.

> What makes things complicated is combined words.

No, what makes things complicated is this mess of immediate and state-smart 
to make words have non-default compilation semantics, and to detach the 
compilation semantics from the xt.

>>The reason is that at that time, non-default compilation semantics was
>>specified by IMMEDIATE, and the xt doesn't know if it's immediate or not.
> 
> And?  Why should it be necessary to know that?

Because if it doesn't know that, you have to either introduce a new type 
(the nt), or you have to pass around strings and maybe even contexts 
(vocabulary stacks)...  and then you end up with the bag of problems you 
have with MPE's source inliner.  You don't want to have that, you want to 
have tokens.  And I don't want to have yet another token, which is not 
directly executable, because that did cause significant problems in Gforth, 
when I started with the recognizers.

>>Let's assume we do what you suggest: add another method to the vtable, and
>>add another word to do "the compiling", which would be something different
>>than compile,.  Now, you might have set-compiler and set-compile, to set
>>them.  How to choose which is the appropriate one?  Most of the time, it
>>doesn't make a difference, so chances are high that people will not
>>understand why there are two, and treat them interchangeable.  It will
>>sometimes result in non-optimal code (if the optimizing version ends up in
>>compiler, but should end up in compile,), sometimes in bugs like the
>>above, where you can't use COMPILE, to get at the interpretation
>>semantics.
> 
> These are not bugs.  These use COMPILE, as specified.

The spec is buggy.  As I said, you can't have both: The spec for COMPILE, 
and Mitch's interpreter.  Mitch's interpreter is the reason to specify 
COMPILE,, and it went wrong.  Spec bugs are the worst kinds, because some 
people, like you, think the spec is always right.  In this case, it is just 
wrong, and we need to fix it.

> OTOH, if you are right, you should be able to point to lots of uses of
> COMPILE, where the current usage of COMPILE, is wrong, because the
> programmer actually intended to perform the compilation semantics
> instead of appending the intepretation/execution semantics.

Look at BerndOOF, it does that.  It uses COMPILE, on all non-immediate 
words, and wants compilation semantics.  If you replace the immediate words 
with special-compilation semantics words, this part of BerndOOF will still 
work as it should.  If you change the semantics of COMPILE, to what you 
want, you have to keep the state-smart implementation.

Do you now tell me that state-smart is actually *not* evil, because it 
harmonizes perfectly with your understanding of what COMPILE, should do?

> Until now
> we only know several cases that would be broken by the change you
> suggest for "COMPILE,".  How many cases do you have that would be
> fixed by that change?

All the cases of Mitch's interpreter.  As long as you stay with a immediate-
flag implementation, and have no special compile, words, you won't see the 
difference.

>>If you have two things that do almost the same, but differ in sublte
>>things that happen only once in a blue moon, you better do just one of
>>them.
> 
> Sounds like an argument against your "INTERP," (as well as against
> "COMPSEM,").

Yes, use ['] foo exeucte instead, don't give it a name.  It's likely below 
threshold of introducing a new name for it.  If you deliberately want 
interpretation semantics, this is how you get it.  This is *not* the usual 
case.  Usually, when you want deliberate interpretation semantics, it's 
because you reuse some word for defining a combined word.  Then, you know 
what you are doing.

> You can also look at how many uses of POSTPONE, are wrong.

You think POSTPONE where you really want [INTERP]?  Works only in state-
smart systems.  Yes, by removing state-smartness, you do break some 
programs.  You fix way more than you break, which is why this change is 
accepted.

> Of course
> POSTPONE, is sufficiently different (different stack effect) that it's
> not easy to use it instead of COMPILE,.  If so, and you are right
> about confusing "COMPILE," with the other words, that's an argument
> against going for a universal xt.

You can only reduce confusion about things like this if you *reduce* the 
number of terms, states, and concepts.  Not by increasing them, as you do.

The Forth approach at things is not through increasing complexity.  It is 
often by using ad-hoc approaches, which is why we have immediate and state.  
But if we get at the limits, the Forth approach is to rethink, comprehend 
the problem in total, and then remove the unnecessary cruft.

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

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

#20431

I've been thinking about this, and it really is a tricky problem.

Separating out compilation and interpretation semantics, such that a
system can excplicitly determine the difference, seems trvial to this
novice: The problem is that FIND, ' and ['] can only return a single
XT. That's the problem. FIND can tell you if a word is immediate, but
that's only half of the information. Like you say, if it's state
smart, how do you get the compilation (run-time) semantics? (I know
this is obvious to you guys, please humour me as I endevour to keep
up!)

What to do? Can we not invent new words that supercede the old ones
(the old ones could remain for a while) that return both XT's?

SEARCH-DICT ( caddr u -- intXT|0 compXT|0 )

Then you simply DROP or NIP according to the semantics you are
interested in. If a word doesn't exist then it has neither compilation
nor interpretation XTs, so 0 0 is returned.

The same approach for ' - though a new name would be required: I
hereby nominate on this day ^ and [^] .

^ ( "(spaces)name" -- intXT|0 compXT|0 )
[^] Compilation:    ( "(spaces)name" -- )
    Interpretation: ( -- intXT|0 compXT|0 )

This could be retro-fitted to systems (like mine) that don't support
separate interpretation and compilation execution tokens.

For example, on my system I could leverage FIND:

: SEARCH-DICT ( c-addr u -- intXT|0 compXT|0)
  FIND ?DUP 0= IF
    drop 0 0 \ ( -- 0 0 ) not found
  ELSE
    0> IF    \ immediate?
      0      \ set compXT to 0
    ELSE     \ non-immediate
      0 swap \ set intXT to 0
    THEN
  THEN
;

On systems that support dual XTs, compilation of the correct behaviour
is now trivial, requiring nothing more than comma.

Okay, that let's one access the interpretation and compilation
semantics individually. Good. One *still* cannot determine if a word
that has interpretation semantics is state smart, though.

I've been pondering STATE-SMART, used in a similar way to IMMEDIATE:

For example:

: ASCII
  ( interpretation: "string" -- c )
  (       run-time: -- c )
  STATE @ IF
    POSTPONE CHAR
  ELSE
    POSTPONE CHAR POSTPONE LIT ,
  THEN ; STATE-SMART

STATE-SMART words are immediate. A word such as STATE-SMART? would,
upon supply of an XT, indicate if a word is state-smart. Trouble is,
one doesn't gain anything. Okay, one can determine that a word is
state-smart, and ^ or [^] would return a value in the intXT field.
Great. One *still* cannot access the actual *run-time* behaviour of
the word (the part in the ELSE clause).

Yes. State-smart words truly are evil.

The only way to solve this cleanly is by not inventing clever
solutions to solve it. The solution lies in the discipline of the
programmer. ASCII should be built from two other colon definitions,
one dealing with interpretation behaviour, and one dealing with run-
time behaviour. Neither need be immediate:

: ASCII
  ( interpretation: "string" -- c )
  (       run-time: -- c )
  STATE @ IF
    PUSH-CHAR
  ELSE
    COMPILE-CHAR
  THEN ; IMMEDIATE

ASCII is still evil, but now one is free to avoid it; it's
constituents can now be accessed individually.

So, I think what I'm saying is that state-smart words are a non-
problem if they are implemented with care and consideration for other
users; factor their behaviours out. Then the problem just goes away.

And the way forward for determining interpretation/compilation
semantics is simply that future Forth systems *must* move to a dual XT
architecture. How that is done internally is of course irrelevant. But
the only clean and simple (in the Forth vein) solution is dual XTs.

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

#20432

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> I've been thinking about this, and it really is a tricky problem.
> 
> Separating out compilation and interpretation semantics, such that a
> system can excplicitly determine the difference, seems trvial to this
> novice: The problem is that FIND, ' and ['] can only return a single
> XT. That's the problem. FIND can tell you if a word is immediate, but
> that's only half of the information. Like you say, if it's state
> smart, how do you get the compilation (run-time) semantics? (I know
> this is obvious to you guys, please humour me as I endevour to keep
> up!)
> 
> What to do? Can we not invent new words that supercede the old ones
> (the old ones could remain for a while) that return both XT's?

Before you get deep into this, have you read the previous threads
where we discussed it at length?

Andrew.

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

#20436

On Mar 8, 10:25 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
> > I've been thinking about this, and it really is a tricky problem.
>
> > Separating out compilation and interpretation semantics, such that a
> > system can excplicitly determine the difference, seems trvial to this
> > novice: The problem is that FIND, ' and ['] can only return a single
> > XT. That's the problem. FIND can tell you if a word is immediate, but
> > that's only half of the information. Like you say, if it's state
> > smart, how do you get the compilation (run-time) semantics? (I know
> > this is obvious to you guys, please humour me as I endevour to keep
> > up!)
>
> > What to do? Can we not invent new words that supercede the old ones
> > (the old ones could remain for a while) that return both XT's?
>
> Before you get deep into this, have you read the previous threads
> where we discussed it at length?
>
> Andrew.

Good morning, Andrew.

Well, this has come up probably more than 10 times in the 3 or 4 years
that I've been frequenting C.L.F. Which particular threads were you
referring to? :-)

Mark

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

#20440

Mark Wills <markrobertwills@yahoo.co.uk> wrote:
> On Mar 8, 10:25?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> Mark Wills <markrobertwi...@yahoo.co.uk> wrote:
>> > I've been thinking about this, and it really is a tricky problem.
>>
>> > Separating out compilation and interpretation semantics, such that a
>> > system can excplicitly determine the difference, seems trvial to this
>> > novice: The problem is that FIND, ' and ['] can only return a single
>> > XT. That's the problem. FIND can tell you if a word is immediate, but
>> > that's only half of the information. Like you say, if it's state
>> > smart, how do you get the compilation (run-time) semantics? (I know
>> > this is obvious to you guys, please humour me as I endevour to keep
>> > up!)
>>
>> > What to do? Can we not invent new words that supercede the old ones
>> > (the old ones could remain for a while) that return both XT's?
>>
>> Before you get deep into this, have you read the previous threads
>> where we discussed it at length?
>>
>> Andrew.
> 
> Good morning, Andrew.

Morning.

> Well, this has come up probably more than 10 times in the 3 or 4 years
> that I've been frequenting C.L.F. Which particular threads were you
> referring to? :-)

We discussed, at considerable length, the way gforth's FIND works, and
why it works with the classic interpreter loop.  One of the
suggestions was IIRC very similar to what you're saying.  You seem to
be talking like this idea came out of a clear blue sky, but it has
been done to death and then some.

Andrew.

https://groups.google.com/group/comp.lang.forth/browse_frm/thread/b5ada700d07a276a/

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

#20462

Op Fri, 8 Mar 2013 02:19:07 -0800 (PST) schreef Mark Wills:

<snip>
>: ASCII
>   ( interpretation: "string" -- c )
>   (       run-time: -- c )
>   STATE @ IF
>     POSTPONE CHAR
>   ELSE
>     POSTPONE CHAR POSTPONE LIT ,
>   THEN ; STATE-SMART
Why POSTPONE CHAR ? CHAR is not immediate, do you want to compile it in a
definition?
: CHAR  BL WORD 1+ C@ ;

: ASCII
   CHAR STATE @ IF POSTPONE LITERAL THEN ;
( STATE-SMART )

-- 
Coos

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

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

#20212

On Sat, 2 Mar 2013, Albert van der Horst wrote:

> Date: 02 Mar 2013 22:11:14 GMT
> From: Albert van der Horst <albert@spenarnc.xs4all.nl>
> Newsgroups: comp.lang.forth
> Subject: Re: State and the standard ...
> 
> In article <P-qdnRKtTO2H6a_MnZ2dnUVZ_uudnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>> Rob Sciuk <rob@controlq.com> wrote:
>>
>>>
>>> Immediate words seem to inherently require state awareness to properly lay
>>> down the correct run time behaviours during compilation.
>>
>> That's not true.
>>
>>> Take the word ascii, which looks ahead to the next word on the input
>>> stream and pushes the value of the ascii character to the stack.  To work
>>> properly in a compilation, it must be immediate, and aware of state, and
>>> in addition to its runtime semantics, must also compile the (literal)
>>> runtime semantics, along with the constant.
>>
>> No.  The right way (IMO, YMMV, etc.) to do this is to have two words,
>> one immediate and one not.  The standard names for these words are
>> [CHAR] and CHAR.  Like this:
>>
>> : char ( "name" -- char )   bl word 1+ c@ ;
>> : [char] ( -- )   char  postpone literal ;  immediate
>>
>> It's important to separate CHAR and [CHAR] because sometimes you want
>> to use CHAR (the non-immediate form that parses a char and pushes it
>> onto the stack) inside a definition.  POSTPONE CHAR doesn't get you
>> the behaviour you need because when CHAR eventually executes it's
>> STATE-smart: whether it pushes a character onto the stack or compiles
>> a character depends on STATE.  You can't control it.  If you really
>> need the CHAR behaviour regardless of STATE, you're stuck.
>
> Or use &C for a number-like thing. Nobody is tempted to do
> POSTPONE &C  and if you can separate the & at all, you know you're
> extending a very carnal part of the system.
> Use &C as a number. No more headaches.
>
>>
>> Andrew.

I guess I would prefer to avoid the use of [ and ] to control STATE, or 
worse, having two words x and [x], which presupposes subtle knowledge of 
the behaviour of the word at execute and compile time, thus cluttering up 
vocabulary with the implemenation un-niceties of differentiating between 
STATEs.

Forth puts some serious demands upon its adherents to understand a great 
deal about the language.  Arguably, better programmers will by definition 
understand such arcanery, but elegance shouldn't demand it.  Things like 
[, ], postpone, compile and other adverbs are taxing beyond the point of 
where a pleasant script language should require of the user.

I suppose that one might take the point of view that Unix is also "user 
friendly", it is just picky about who its friends are 8-).

Tcl for example uses square braces to defer execution of the contents 
until run time, and pass back the result to the calling sequence:

 	proc shiftLeft Arg {
            return [expr $Arg * 2]
         }

This syntax is simple, and doesn't require run time and compile time 
semantics to be well understood.

Am I out to lunch on this???

Just wondering,
Cheers,
Rob.

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

#20216

Rob Sciuk <rob@controlq.com> wrote:
> I guess I would prefer to avoid the use of [ and ] to control STATE,
> or worse, having two words x and [x], which presupposes subtle
> knowledge of the behaviour of the word at execute and compile time,
> thus cluttering up vocabulary with the implemenation un-niceties of
> differentiating between STATEs.

It's not really to do with implementation: they really are different.

> Forth puts some serious demands upon its adherents

Eh?  Adherents?  It's a programming language, not a religion!

> to understand a great deal about the language.  Arguably, better
> programmers will by definition understand such arcanery, but
> elegance shouldn't demand it.  Things like [, ], postpone, compile
> and other adverbs are taxing beyond the point of where a pleasant
> script language should require of the user.

Perhaps, but standard Forth doesn't have COMPILE , [COMPILE], and so
on.  These are obsolete.

There is a small cost in learning in order to make the full language
better and more powerful and maintainable for reasonablty skilled
programmers.  Evey programming language has to make that choice
somewhere.

> I suppose that one might take the point of view that Unix is also "user 
> friendly", it is just picky about who its friends are 8-).
> 
> Tcl for example uses square braces to defer execution of the contents 
> until run time, and pass back the result to the calling sequence:
> 
>        proc shiftLeft Arg {
>            return [expr $Arg * 2]
>         }
> 
> This syntax is simple, and doesn't require run time and compile time 
> semantics to be well understood.

Sure, but TCL doesn't have a compile time: it always interprets.

Andrew.

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

#20253

Op Sun, 03 Mar 2013 15:13:18 -0600 schreef Andrew Haley:

> Rob Sciuk <rob@controlq.com> wrote:
>> I guess I would prefer to avoid the use of [ and ] to control STATE,
>> or worse, having two words x and [x], which presupposes subtle
>> knowledge of the behaviour of the word at execute and compile time,
>> thus cluttering up vocabulary with the implemenation un-niceties of
>> differentiating between STATEs.
> 
> It's not really to do with implementation: they really are different.
> 
>> Forth puts some serious demands upon its adherents
> 
> Eh?  Adherents?  It's a programming language, not a religion!
> 
>> to understand a great deal about the language.  Arguably, better
>> programmers will by definition understand such arcanery, but
>> elegance shouldn't demand it.  Things like [, ], postpone, compile
>> and other adverbs are taxing beyond the point of where a pleasant
>> script language should require of the user.
> 
> Perhaps, but standard Forth doesn't have COMPILE , [COMPILE], and so
> on.  These are obsolete.

Since when is [COMPILE] obsolete? I nearly never use it, most instances can
be dealt with POSTPONE. COMPILE is surely obsolete.

> 
> There is a small cost in learning in order to make the full language
> better and more powerful and maintainable for reasonablty skilled
> programmers.  Evey programming language has to make that choice
> somewhere.

Yes, Forth is not hard to learn.

-- 
Coos

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

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

#20259

Coos Haak <chforth@hccnet.nl> wrote:
> Op Sun, 03 Mar 2013 15:13:18 -0600 schreef Andrew Haley:
> 
>> Rob Sciuk <rob@controlq.com> wrote:
>>> to understand a great deal about the language.  Arguably, better
>>> programmers will by definition understand such arcanery, but
>>> elegance shouldn't demand it.  Things like [, ], postpone, compile
>>> and other adverbs are taxing beyond the point of where a pleasant
>>> script language should require of the user.
>> 
>> Perhaps, but standard Forth doesn't have COMPILE , [COMPILE], and so
>> on.  These are obsolete.
> 
> Since when is [COMPILE] obsolete? 

Since POSTPONE.

Andrew.

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

#20264

Op Mon, 04 Mar 2013 15:17:01 -0600 schreef Andrew Haley:

> Coos Haak <chforth@hccnet.nl> wrote:
>> Op Sun, 03 Mar 2013 15:13:18 -0600 schreef Andrew Haley:
>> 
>>> Rob Sciuk <rob@controlq.com> wrote:
>>>> to understand a great deal about the language.  Arguably, better
>>>> programmers will by definition understand such arcanery, but
>>>> elegance shouldn't demand it.  Things like [, ], postpone, compile
>>>> and other adverbs are taxing beyond the point of where a pleasant
>>>> script language should require of the user.
>>> 
>>> Perhaps, but standard Forth doesn't have COMPILE , [COMPILE], and so
>>> on.  These are obsolete.
>> 
>> Since when is [COMPILE] obsolete? 
> 
> Since POSTPONE.
> 
> Andrew.

In www.forth200x.org/documents/forth-rc1.pdf (2012) is no mention of
obsolescense of [COMPILE]

-- 
Coos

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

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

#20267

Coos Haak <chforth@hccnet.nl> wrote:
> Op Mon, 04 Mar 2013 15:17:01 -0600 schreef Andrew Haley:
> 
>> Coos Haak <chforth@hccnet.nl> wrote:
>>> Op Sun, 03 Mar 2013 15:13:18 -0600 schreef Andrew Haley:
>>> 
>>>> Rob Sciuk <rob@controlq.com> wrote:
>>>>> to understand a great deal about the language.  Arguably, better
>>>>> programmers will by definition understand such arcanery, but
>>>>> elegance shouldn't demand it.  Things like [, ], postpone, compile
>>>>> and other adverbs are taxing beyond the point of where a pleasant
>>>>> script language should require of the user.
>>>> 
>>>> Perhaps, but standard Forth doesn't have COMPILE , [COMPILE], and so
>>>> on.  These are obsolete.
>>> 
>>> Since when is [COMPILE] obsolete? 
>> 
>> Since POSTPONE.
> 
> In www.forth200x.org/documents/forth-rc1.pdf (2012) is no mention of
> obsolescense of [COMPILE]

It's in the rationale,  A.6.1.2033 POSTPONE.

Andrew.

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

#20269

"Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
news:oridnYhak5PToqjMnZ2dnUVZ_tOdnZ2d@supernews.com...
> Coos Haak <chforth@hccnet.nl> wrote:
> > Op Mon, 04 Mar 2013 15:17:01 -0600 schreef Andrew Haley:
> >> Coos Haak <chforth@hccnet.nl> wrote:
> >>> Op Sun, 03 Mar 2013 15:13:18 -0600 schreef Andrew Haley:
> >>>> Rob Sciuk <rob@controlq.com> wrote:

> >>>>> to understand a great deal about the language.  Arguably,
> >>>>> better programmers will by definition understand such
> >>>>> arcanery, but elegance shouldn't demand it.  Things like
> >>>>> [, ], postpone, compile and other adverbs are taxing
> >>>>> beyond the point of where a pleasant script language
> >>>>> should require of the user.
> >>>>
> >>>> Perhaps, but standard Forth doesn't have COMPILE ,
> >>>> [COMPILE], and so on.  These are obsolete.
> >>>
> >>> Since when is [COMPILE] obsolete?
> >>
> >> Since POSTPONE.
> >
> > In www.forth200x.org/documents/forth-rc1.pdf (2012) is no
> > mention of obsolescense of [COMPILE]
>
> It's in the rationale,  A.6.1.2033 POSTPONE.
>

If it's obsoleted, why is it still a part of CORE EXT (6.2.2530)?

Shouldn't it be a part of CORE "OBS" ... ?

If it's _truly_ obsoleted, why does A.6.1.2033 say POSTPONE only
replaces   MOST   of the functionality of COMPILE and [COMPILE]?

Wouldn't POSTPONE need to replace  ALL  the functionality to
obsolete [COMPILE]?

A.6.1.2033 only states "... [COMPILE] has been moved in favor of
POSTPONE".  That doesn't say it's obsolete.  Why the word "moved"
is misused is a mystery, unless it originally said "removed".

ANS 94 had section D.6.7 on "Immediacy" which demonstrates *three*
situations where COMPILE and [COMPILE] can't be replaced
completely by use of POSTPONE.  Two are in the body and one is at
the end.  However, it only demonstrates a solution for only one of
the situations.  I.e., there seems to still be two situations
which need [COMPILE].


Rod Pemberton

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

#20281

Rod Pemberton <do_not_have@notemailnotz.cnm> wrote:
> "Andrew Haley" <andrew29@littlepinkcloud.invalid> wrote in message
> news:oridnYhak5PToqjMnZ2dnUVZ_tOdnZ2d@supernews.com...
>> Coos Haak <chforth@hccnet.nl> wrote:
>> > Op Mon, 04 Mar 2013 15:17:01 -0600 schreef Andrew Haley:
>> >> Coos Haak <chforth@hccnet.nl> wrote:
>> >>> Op Sun, 03 Mar 2013 15:13:18 -0600 schreef Andrew Haley:
>> >>>> Rob Sciuk <rob@controlq.com> wrote:
> 
>> >>>>> to understand a great deal about the language.  Arguably,
>> >>>>> better programmers will by definition understand such
>> >>>>> arcanery, but elegance shouldn't demand it.  Things like
>> >>>>> [, ], postpone, compile and other adverbs are taxing
>> >>>>> beyond the point of where a pleasant script language
>> >>>>> should require of the user.
>> >>>>
>> >>>> Perhaps, but standard Forth doesn't have COMPILE ,
>> >>>> [COMPILE], and so on.  These are obsolete.
>> >>>
>> >>> Since when is [COMPILE] obsolete?
>> >>
>> >> Since POSTPONE.
>> >
>> > In www.forth200x.org/documents/forth-rc1.pdf (2012) is no
>> > mention of obsolescense of [COMPILE]
>>
>> It's in the rationale,  A.6.1.2033 POSTPONE.
> 
> If it's obsoleted, why is it still a part of CORE EXT (6.2.2530)?
>
> Shouldn't it be a part of CORE "OBS" ... ?

Probably.

> If it's _truly_ obsoleted, why does A.6.1.2033 say POSTPONE only
> replaces   MOST   of the functionality of COMPILE and [COMPILE]?
> 
> Wouldn't POSTPONE need to replace  ALL  the functionality to
> obsolete [COMPILE]?

No.  That's not what obsolete means.  Programming practices change,
and in applications it makes far more sense to use POSTPONE, even if
that requires small changes.  POSTPONE isn't a direct replacement but
a functional one.

> A.6.1.2033 only states "... [COMPILE] has been moved in favor of
> POSTPONE".  That doesn't say it's obsolete.  Why the word "moved"
> is misused is a mystery, unless it originally said "removed".
> 
> ANS 94 had section D.6.7 on "Immediacy" which demonstrates *three*
> situations where COMPILE and [COMPILE] can't be replaced
> completely by use of POSTPONE.  Two are in the body and one is at
> the end.  However, it only demonstrates a solution for only one of
> the situations.  I.e., there seems to still be two situations
> which need [COMPILE].

It's all explained pretty thoroughly there: the use of [COMPILE] with
non-immediate words is never needed, and COMPILE [COMPILE] isn't
really necessary, as also explained there.

[COMPILE] isn't necessary for anything, and can't be used portably in
most cases anyway.  It's obsolete.

Andrew.

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

#20291

On Mar 5, 8:59 am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> Rod Pemberton <do_not_h...@notemailnotz.cnm> wrote:
> > "Andrew Haley" <andre...@littlepinkcloud.invalid> wrote in message
> >news:oridnYhak5PToqjMnZ2dnUVZ_tOdnZ2d@supernews.com...
> >> Coos Haak <chfo...@hccnet.nl> wrote:
> >> > Op Mon, 04 Mar 2013 15:17:01 -0600 schreef Andrew Haley:
> >> >> Coos Haak <chfo...@hccnet.nl> wrote:
> >> >>> Op Sun, 03 Mar 2013 15:13:18 -0600 schreef Andrew Haley:
> >> >>>> Rob Sciuk <r...@controlq.com> wrote:
>
> >> >>>>> to understand a great deal about the language.  Arguably,
> >> >>>>> better programmers will by definition understand such
> >> >>>>> arcanery, but elegance shouldn't demand it.  Things like
> >> >>>>> [, ], postpone, compile and other adverbs are taxing
> >> >>>>> beyond the point of where a pleasant script language
> >> >>>>> should require of the user.
>
> >> >>>> Perhaps, but standard Forth doesn't have COMPILE ,
> >> >>>> [COMPILE], and so on.  These are obsolete.
>
> >> >>> Since when is [COMPILE] obsolete?
>
> >> >> Since POSTPONE.
>
> >> > Inwww.forth200x.org/documents/forth-rc1.pdf(2012) is no
> >> > mention of obsolescense of [COMPILE]
>
> >> It's in the rationale,  A.6.1.2033 POSTPONE.
>
> > If it's obsoleted, why is it still a part of CORE EXT (6.2.2530)?
>
> > Shouldn't it be a part of CORE "OBS" ... ?
>
> Probably.
>
> > If it's _truly_ obsoleted, why does A.6.1.2033 say POSTPONE only
> > replaces   MOST   of the functionality of COMPILE and [COMPILE]?
>
> > Wouldn't POSTPONE need to replace  ALL  the functionality to
> > obsolete [COMPILE]?
>
> No.  That's not what obsolete means.  Programming practices change,
> and in applications it makes far more sense to use POSTPONE, even if
> that requires small changes.  POSTPONE isn't a direct replacement but
> a functional one.
>
> > A.6.1.2033 only states "... [COMPILE] has been moved in favor of
> > POSTPONE".  That doesn't say it's obsolete.  Why the word "moved"
> > is misused is a mystery, unless it originally said "removed".
>
> > ANS 94 had section D.6.7 on "Immediacy" which demonstrates *three*
> > situations where COMPILE and [COMPILE] can't be replaced
> > completely by use of POSTPONE.  Two are in the body and one is at
> > the end.  However, it only demonstrates a solution for only one of
> > the situations.  I.e., there seems to still be two situations
> > which need [COMPILE].
>
> It's all explained pretty thoroughly there: the use of [COMPILE] with
> non-immediate words is never needed, and COMPILE [COMPILE] isn't
> really necessary, as also explained there.
>
> [COMPILE] isn't necessary for anything, and can't be used portably in
> most cases anyway.  It's obsolete.
>
> Andrew.

My compiler doesn't have it; I've not noticed the loss. With smart (or
is it intelligent? I find the difference hard to grasp) COMPILE,
POSTPONE can deal with parsing words such as TO S" and so on. It's
worth it for that reason alone; there are no exceptions to POSTPONE
and just the one word.

(With possibly the issue of POSTPONE EXIT. Anton discusses in "State-
smartness; Why it is Evil and How to Exorcise it" IIRC.)

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

#20194

On Saturday, March 2, 2013 5:38:43 PM UTC, Rob Sciuk wrote:
> On Sat, 2 Mar 2013, Stephen Pelc wrote:
> 
> 
> 
> [snip]
> 
> 
> 
> > Note that ." is not IMMEDIATE - it just has separate interpretation
> 
> > and compilation behaviours. The problem is just to standardise the
> 
> > notation.
> 
> >
> 
> > Stephen
> 
> 
> 
> Stephen, thanks for your reply, in fact thanks to all, I appreciate the 
> 
> views expressed thus far.
> 
> 
> 
> You bring up the concept of immediacy, and it occurs that it is the 
> 
> combination of STATE and IMMEDIACY which allows the language extension 
> 
> facility.
> 
> 
> 
> Immediate words seem to inherently require state awareness to properly lay 
> 
> down the correct run time behaviours during compilation.
> 
> 
> 
> Take the word ascii, which looks ahead to the next word on the input 
> 
> stream and pushes the value of the ascii character to the stack.  To work 
> 
> properly in a compilation, it must be immediate, and aware of state, and 
> 
> in addition to its runtime semantics, must also compile the (literal) 
> 
> runtime semantics, along with the constant.  My implementation looks like 
> 
> this:
> 
> 
> 
> void ascii(){
> 
>    Str_t p ;
> 
> 
> 
>    word() ;
> 
>    p = (Str_t) pop() ;
> 
>    push( (Cell_t) *p ) ;
> 
>    if( state == state_Compiling ){
> 
>      push( (Cell_t) lookup( "(literal)" ) ) ;
> 
>      comma();
> 
>      comma();
> 
>    }
> 
> }
> 
> 
> 
> And it behaves as expected ...
> 
> 
> 
> ok ' ascii see
> 
> -- ascii (5058e0) flg: 1 is coded in C (403060).
> 
> ok ascii x .
> 
> 120 ok : z ascii x . cr ;
> 
> ok z
> 
> 120
> 
> ok ' z see
> 
> -- z (507c00) word flg: 0.
> 
> 50bc08  (literal) = 120
> 
> 50bc18  .
> 
> 50bc20  cr
> 
> 50bc28  next
> 
> ok
> 
> 
> 
> I suppose I'm wondering if there is a more elegant mechanism to reconcile 
> 
> compiling words such that *ALL* words are equivalent, and have for lack of 
> 
> a better term, BOTH run time and compile time forks, rather than the 
> 
> current situation where some words are "special" by means of having 
> 
> immediacy (or not), and state awareness (or not).
> 
> 
> 
> Currently, immediacy and state awareness accrue only to certain "special" 
> 
> words.  I'm not saying that this is either good or bad, I'm just wondering 
> 
> if there is an alternative implementation where such differentiation is 
> 
> unnecessary and all words simply do the right thing in any context???
> 
> 
> 
> Cheers,
> 
> Rob.

Hi Rob,

> ... an alternative implementation where such differentiation is
> unnecessary and all words simply do the right thing in any context??? 
I think colorForth is just such an implementation :-)

Best regards,
Howerd

[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