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

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

COMPILE, and :NONAME

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

Contents

  COMPILE, and :NONAME "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 12:48 +0100
    Re: COMPILE, and :NONAME Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-05-29 14:15 +0100
      Re: COMPILE, and :NONAME "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 15:23 +0100
    Re: COMPILE, and :NONAME anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 13:25 +0000
      Re: COMPILE, and :NONAME "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 15:22 +0100
        Re: COMPILE, and :NONAME anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 14:45 +0000
          Re: COMPILE, and :NONAME "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 17:09 +0100
            Re: COMPILE, and :NONAME "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 17:13 +0100
            Re: COMPILE, and :NONAME anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-29 17:21 +0000
              Re: COMPILE, and :NONAME "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 19:36 +0100
          Re: COMPILE, and :NONAME Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-29 22:47 +0200
            Re: COMPILE, and :NONAME "Alex McDonald" <blog@rivadpm.com> - 2015-05-29 23:23 +0100
              Re: COMPILE, and :NONAME Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-30 02:03 +0200
                Re: COMPILE, and :NONAME "Alex McDonald" <blog@rivadpm.com> - 2015-05-30 20:58 +0100
              Re: COMPILE, and :NONAME anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-05-30 11:56 +0000
                Re: COMPILE, and :NONAME albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-05-30 13:34 +0000
                Re: COMPILE, and :NONAME "Alex McDonald" <blog@rivadpm.com> - 2015-05-30 20:54 +0100
                  Re: COMPILE, and :NONAME foxaudioresearch@gmail.com - 2015-06-01 17:34 -0700
                    Re: COMPILE, and :NONAME "Alex McDonald" <blog@rivadpm.com> - 2015-06-02 15:54 +0100
                Re: COMPILE, and :NONAME Bernd Paysan <bernd.paysan@gmx.de> - 2015-05-30 23:45 +0200

#39409 — COMPILE, and :NONAME

Is the following permitted by the standard? Here we COMPILE, the XT of a
:NONAME.

:noname ; constant noname
: foo [ noname ] literal compile, ;

[toc] | [next] | [standalone]

#39410

On 29/05/2015 12:48, Alex McDonald wrote:
> Is the following permitted by the standard? Here we COMPILE, the XT of a
> :NONAME.
>
> :noname ; constant noname
> : foo [ noname ] literal compile, ;
>

Why not, COMPILE, doesn't care where an xt comes from. This works in GForth

:noname ." Hello" ; constant x  ok
: foo [ x ] literal compile, ; immediate ok
: bar foo ;  ok
bar Hello ok


-- 
Gerry

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

#39416

on 29/05/2015 14:15:38, Gerry Jackson wrote:
> On 29/05/2015 12:48, Alex McDonald wrote:
>> Is the following permitted by the standard? Here we COMPILE, the XT of a
>> :NONAME.
>>
>> :noname ; constant noname
>> : foo [ noname ] literal compile, ;
>>
> 
> Why not, COMPILE, doesn't care where an xt comes from. This works in
> GForth
> 
>:noname ." Hello" ; constant x  ok
>: foo [ x ] literal compile, ; immediate ok
>: bar foo ;  ok
> bar Hello ok
> 
> 

Yes, I appear to have a problem in that my :NONAMEs have no compilation
semantics. Needs fixed.

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

#39412

"Alex McDonald" <blog@rivadpm.com> writes:
>Is the following permitted by the standard? Here we COMPILE, the XT of a
>:NONAME.
>
>:noname ; constant noname
>: foo [ noname ] literal compile, ;

Sure, why not?  But why not write

: foo noname compile, ;

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39415

on 29/05/2015 14:25:52,  wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>>Is the following permitted by the standard? Here we COMPILE, the XT of a
>>:NONAME.
>>
>>:noname ; constant noname
>>: foo [ noname ] literal compile, ;
> 
> Sure, why not?  But why not write
> 
>: foo noname compile, ;
> 
> - anton

Good point. Either way, I was having difficulties finding the compilation
semantics of my :NONAMEs and the compile kept blowing up on a wild
address pointer. I have just realised that they have none. This arose as
part of an experiment with extending the name token to have a built-in
recognizer.

Needs fixed. 

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

#39419

"Alex McDonald" <blog@rivadpm.com> writes:
>Good point. Either way, I was having difficulties finding the compilation
>semantics of my :NONAMEs

But COMPILE, does not (and should not, that's what the discussion with
Bernd Paysan is about) perform compilation semantics.  Instead, it
appends the semantics represented by the xt to the current definition.
But of course, if you have an intelligent COMPILE, (in contrast to
Bernd Paysan's "smart COMPILE,") in the sense described in my headers
page <http://www.complang.tuwien.ac.at/forth/header-ideas.html>,
nameless words need a COMP field (but not an xt2 field which
represents the compilation semantics).  The page says:

|You should put the comp field with the code field (if you want to have
|a comp field); it is needed for unnamed words, too.
|
|This gives us:
|
|link field
|name field
|xt2 field
|xt1 field
|
|comp field
|code field  <-- cfa (xt1)
|parameter field (body)

This is for a separate-header organization, where the blank line
indicates the separation of the parts (which may be in totally
different places).

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39425

on 29/05/2015 15:45:56,  wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>>Good point. Either way, I was having difficulties finding the compilation
>>semantics of my :NONAMEs
> 
> But COMPILE, does not (and should not, that's what the discussion with
> Bernd Paysan is about) perform compilation semantics. Instead, it
> appends the semantics represented by the xt to the current definition.
> But of course, if you have an intelligent COMPILE, (in contrast to
> Bernd Paysan's "smart COMPILE,") in the sense described in my headers
> page <http://www.complang.tuwien.ac.at/forth/header-ideas.html>,
> nameless words need a COMP field (but not an xt2 field which
> represents the compilation semantics). The page says:
> 
>|You should put the comp field with the code field (if you want to have
>|a comp field); it is needed for unnamed words, too.
>|
>|This gives us:
>|
>|link field
>|name field
>|xt2 field
>|xt1 field
>|
>|comp field
>|code field  <-- cfa (xt1)
>|parameter field (body)
> 
> This is for a separate-header organization, where the blank line
> indicates the separation of the parts (which may be in totally
> different places).
> 
> - anton

That's what I have, slightly modified. 

 lfield: head.ct    \ [ ' compile,   ] <-+ or execute for immediate
 lfield: head.xtptr \ [ xt ptr field ]   | xt pointer
lfield: : head.comp \ [ ' xt-call, ] | how to compile, normally a call

The compilation token is followed by HEAD.COMP (the comp field), and an
XT backpointer points at the compilation token. I now point all :NONAMEs
at a dummy compilation token

0 , 0 , ' xt-call, 

and COMPILE, does 

: >ct    ( xt -- ct ) ( move from the XT to the compilation token) ;
: compile, ( xt -- ) dup >ct head.comp @ execute ;

The HEAD.CT and HEAD.XTPTR fields are irrelevant as only NAME>COMPILE
does a 2@ on HEAD.CT; and :NONAMEs have no name.

I'd managed to bork :NONAME during an attempt to use it for quotations.
So it's fixed for :NONAME, but this:

: named ( -- xt ) [: 1 2 3 ;] ; constant x

still needs work; X isn't COMPILE,able yet as there's no backpointer.
Should be fixable though.

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

#39426

on 29/05/2015 17:09:27, "Alex McDonald" wrote:
>: named ( -- xt ) [: 1 2 3 ;] ; constant x

should be

: named ( -- xt ) [: 1 2 3 ;] ; named constant x

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

#39429

"Alex McDonald" <blog@rivadpm.com> writes:
>That's what I have, slightly modified. 
>
> lfield: head.ct    \ [ ' compile,   ] <-+ or execute for immediate
> lfield: head.xtptr \ [ xt ptr field ]   | xt pointer
>lfield: : head.comp \ [ ' xt-call, ] | how to compile, normally a call
>
>The compilation token is followed by HEAD.COMP (the comp field), and an
>XT backpointer points at the compilation token. I now point all :NONAMEs
>at a dummy compilation token
>
>0 , 0 , ' xt-call, 
>
>and COMPILE, does 
>
>: >ct    ( xt -- ct ) ( move from the XT to the compilation token) ;
>: compile, ( xt -- ) dup >ct head.comp @ execute ;

Yes, that should work.  I consider your terminology confusing; Didn't
you explain in another posting that what you call the ct here is the
nt? I would find that less confusing.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39430

on 29/05/2015 18:21:27,  wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>>That's what I have, slightly modified.
>>
>> lfield: head.ct    \ [ ' compile,   ] <-+ or execute for immediate
>> lfield: head.xtptr \ [ xt ptr field ]   | xt pointer
>>lfield: : head.comp \ [ ' xt-call, ] | how to compile, normally a call
>>
>>The compilation token is followed by HEAD.COMP (the comp field), and an
>>XT backpointer points at the compilation token. I now point all :NONAMEs
>>at a dummy compilation token
>>
>>0 , 0 , ' xt-call,
>>
>>and COMPILE, does
>>
>>: >ct    ( xt -- ct ) ( move from the XT to the compilation token) ;
>>: compile, ( xt -- ) dup >ct head.comp @ execute ;
> 
> Yes, that should work.  I consider your terminology confusing; Didn't
> you explain in another posting that what you call the ct here is the
> nt? I would find that less confusing.

I apologise for the confusion. The CT pair is part of the NT, as is the
COMP field (it follows). NAME>COMPILE produces ( nt -- nt ' NT-COMPILE, |
NT-EXECUTE ) rather than ( nt -- xt ' COMPILE, | EXECUTE ). It could
produce ( nt -- ct ' CT-COMPILE, | CT-EXECUTE ). There's reason in this
madness, as treating the NT and CT as separate allows changes without
having to replumb the entire header architecture. 

> 
> - anton

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

#39434

Anton Ertl wrote:
> But of course, if you have an intelligent COMPILE, (in contrast to
> Bernd Paysan's "smart COMPILE,")

This is not my idea, this is originally Stephen Pelc's idea.  I like the 
idea, and you did show some considerably sympathy more than 10 years ago, 
too.

https://www.complang.tuwien.ac.at/forth/header-ideas.html

I took up the idea after you made that posting which suggested a new header 
structure, that includes that compile,-field, but also had a separate 
compilation semantics field, but didn't find time to implement it until 
2011.  When implementing it, it became obvious that you also need a TO-
action (or action pair, one for interpretation, one for compilation), and 
that the compilation semantics action in Gforth better can be represented by 
a NAME>INT and NAME>COMP action pair; which might also be a unified xt with 
EXECUTE for NAME>INT and COMPILE, for NAME>COMP, as I do it for the TO 
action.

So the original credit goes to Stephen Pelc (or someone else at MPE), 
followed by Anton Ertl, and I'm only third in the chain.  For me, 
"intelligent COMPILE," is what we had in Gforth 20 years ago, with a 
deferred COMPILE, and a CASE statement to do different things for a small 
list of doers, and allowed to implement the primitive-centric version of 
Gforth.  Ugly, maybe "intelligent", but certainly not "smart".

http://dict.leo.org/#/search=smart&searchLoc=0&resultOrder=basic&multiwordShowSingle=on

(look at the adjective translations).  "Smart" is also "elegant" and 
"proper".

In Stephen Pelc's approach, COMPILE, does perform the compilation semantics  
- which normally is appending the execution semantics, and therefore 
normally not different from the standard's COMPILE, - and where it *is* 
different, only one case of standard words have well-specified properties: 
IMMEDIATE words.  In his approach, there's a fairly small set of clearly 
different concepts. That's not exactly what you want, but it's IMHO a good 
idea.  And that's why I defend his idea.

IMHO, your idea is too much about preserving backwards compatibility to 
something you read into the standard (not something that really exists 
outside Gforth), without evidence that people did put that deliberately and 
as an informed decision into the standard.  The latter is necessary, because 
standards come by votes.  Only an informed decision can result in a valid 
vote, everything else is an accident.

Your concept "breaks symmetry" at two points:

* You distinguish between named and unnamed words

* You distinguish between text interpreter and the usage of xts.

Both are related.

Stephen Pelc showed that unifying that works remarkable well.  It is hard to 
identify real code breakage (unlike e.g. his source tokenizer, where we have 
not only academic examples of broken code, but broken real-world code), and 
we made sure that the Forth-2012 is sufficiently ambiguous to fully allow 
his apprach.  This approach is standard, with the limitation that you can't 
do

: immediate ['] execute set-compiler ;

So the old immediate/state concept is a wart here.  But at least it is a 
legacy concept we can declare obsolescent.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#39435

on 29/05/2015 21:47:39, Bernd Paysan wrote:
> Anton Ertl wrote:
>> But of course, if you have an intelligent COMPILE, (in contrast to
>> Bernd Paysan's "smart COMPILE,")
> 
> This is not my idea, this is originally Stephen Pelc's idea. I like
> the idea, and you did show some considerably sympathy more than 10
> years ago, too.
> 
> https://www.complang.tuwien.ac.at/forth/header-ideas.html

Now I'm thoroughly confused. I've implemented, with a few minor
modifications, the ideas in that post. Is it smart or intelligent? (An
aside; can we pick names that aren't synonyms please?)

So the rest kind of gets lost in transaltion, I'm afraid.
  

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

#39438

Alex McDonald wrote:
> Now I'm thoroughly confused. I've implemented, with a few minor
> modifications, the ideas in that post. Is it smart or intelligent? (An
> aside; can we pick names that aren't synonyms please?)

Haha.  There's a reason for using that particular synonym.

> So the rest kind of gets lost in transaltion, I'm afraid.

The primary reason for chosing the name "smart COMPILE," instead of 
"intelligent COMPILE," was that it includes usage for compilation semantics, 
which can replace "STATE-smart" words, otherwise, it's the same.  Note the 
common "smart" component.  This is meant as clue.

Effectively, there's no implementation difference between intelligent and 
smart COMPILE, - in both cases, you have a mechanism to implement a COMPILE, 
that does different things for different classes of words (or different 
words).

The difference is what usage is actually allowed: can you use it for special 
compilation semantics or not?

IMHO, rule number one of hearding Forth programmers is that you can't 
control what people use it for.  Therefore, if you give them a tool, usage 
is permissive: be creative, use it for whatever thing you like, and if users 
shoot into their foot, well, make sure it hurts enough so that people stop 
shooting into their foot.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#39471

on 30/05/2015 01:03:12, Bernd Paysan wrote:
> Alex McDonald wrote:
>> Now I'm thoroughly confused. I've implemented, with a few minor
>> modifications, the ideas in that post. Is it smart or intelligent? (An
>> aside; can we pick names that aren't synonyms please?)
> 
> Haha.  There's a reason for using that particular synonym.
> 
>> So the rest kind of gets lost in transaltion, I'm afraid.
> 
> The primary reason for chosing the name "smart COMPILE," instead of
> "intelligent COMPILE," was that it includes usage for compilation
> semantics, which can replace "STATE-smart" words, otherwise, it's the
> same. Note the common "smart" component.  This is meant as clue.

Ah, I didn't see that. Thanks for your & Anton's explanation.

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

#39454

"Alex McDonald" <blog@rivadpm.com> writes:
>on 29/05/2015 21:47:39, Bernd Paysan wrote:
>> https://www.complang.tuwien.ac.at/forth/header-ideas.html
>
>Now I'm thoroughly confused. I've implemented, with a few minor
>modifications, the ideas in that post. Is it smart or intelligent?

If COMPILE, appends the behaviour to the current definition that
EXECUTE performs (i.e., COMPILE, does what the standard specifies),
it's intelligent.  If not, it's "smart"; one could also say "buggy",
but I guess fans of this behaviour would not use this term.

> (An
>aside; can we pick names that aren't synonyms please?)

I did not pick "smart", and nobody was writing about "smart COMPILE,",
when I wrote about "intelligent COMPILE," (first in 1997); "smart
COMPILE," was first used synonymous to "intelligent COMPILE, starting
in 2000 in my records <86a74g$ntm$1@newsg1.svr.pol.co.uk>
<cgph3o$cir$1@hercules.btinternet.com> ...

Then Bernd Paysan started to use "smart COMPILE," it for a COMPILE,
that does not behave as specified in the standard.  I thought that's
quite appropriate, because it reminds me immediately of "state-smart
words" (which also work in the common case, and act up in uncommon
cases, and then their defenders try to blame the uncommon case instead
of the state-smart word), but I guess it might be different for a
native speaker; so I would be fine with a different term, but you have
to convince Bernd Paysan.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#39456

In article <2015May30.135603@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>"Alex McDonald" <blog@rivadpm.com> writes:
>>on 29/05/2015 21:47:39, Bernd Paysan wrote:
>>> https://www.complang.tuwien.ac.at/forth/header-ideas.html
>>
>>Now I'm thoroughly confused. I've implemented, with a few minor
>>modifications, the ideas in that post. Is it smart or intelligent?
>
>If COMPILE, appends the behaviour to the current definition that
>EXECUTE performs (i.e., COMPILE, does what the standard specifies),
>it's intelligent.  If not, it's "smart"; one could also say "buggy",
>but I guess fans of this behaviour would not use this term.

I know you object to me calling numbers (and other denotations)
"smart". According to this definition they are intelligent.
Not that I approve of assigning an xt to a number (or other denotation),
it unnecessarily complicate things.

<SNIP>

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

#39470

on 30/05/2015 12:56:00,  wrote:
> "Alex McDonald" <blog@rivadpm.com> writes:
>>on 29/05/2015 21:47:39, Bernd Paysan wrote:
>>> https://www.complang.tuwien.ac.at/forth/header-ideas.html
>>
>>Now I'm thoroughly confused. I've implemented, with a few minor
>>modifications, the ideas in that post. Is it smart or intelligent?
> 
> If COMPILE, appends the behaviour to the current definition that
> EXECUTE performs (i.e., COMPILE, does what the standard specifies),
> it's intelligent.  If not, it's "smart"; one could also say "buggy",
> but I guess fans of this behaviour would not use this term.
> 
>> (An
>>aside; can we pick names that aren't synonyms please?)
> 
> I did not pick "smart", and nobody was writing about "smart COMPILE,",
> when I wrote about "intelligent COMPILE," (first in 1997); "smart
> COMPILE," was first used synonymous to "intelligent COMPILE, starting
> in 2000 in my records <86a74g$ntm$1@newsg1.svr.pol.co.uk>
> <cgph3o$cir$1@hercules.btinternet.com> ...
> 
> Then Bernd Paysan started to use "smart COMPILE," it for a COMPILE,
> that does not behave as specified in the standard.  I thought that's
> quite appropriate, because it reminds me immediately of "state-smart
> words" (which also work in the common case, and act up in uncommon
> cases, and then their defenders try to blame the uncommon case instead
> of the state-smart word), but I guess it might be different for a
> native speaker; so I would be fine with a different term, but you have
> to convince Bernd Paysan.
> 
> - anton

I see. Thank you, as this is now a lot clearer to me and makes sense of
some of the recent conversations here. When I see smart I will just have
to think of a sharp, stinging pain.

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

#39512

On Saturday, May 30, 2015 at 3:54:05 PM UTC-4, Alex McDonald wrote:
> on 30/05/2015 12:56:00,  wrote:
> > "Alex McDonald" <blog@rivadpm.com> writes:
<snip>
> When I see smart I will just have
> to think of a sharp, stinging pain.

That's not very nice to use such language among people who are using English as a 2nd or 3rd language. :-)  (I still don't get most of the jokes in Dutch when my wife's family speaks after 37 years, but then I'm not too smart.)

Exlanation:
"That smarts" can be used in English to mean that something caused me to have pain. Somewhat archaic in modern speech but can still be heard on occassion.

Apologies if that was already known by the readers here, but I know that when I don't those Dutch jokes "it smarts".  :-)

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

#39517

on 02/06/2015 01:34:10,  wrote:
> On Saturday, May 30, 2015 at 3:54:05 PM UTC-4, Alex McDonald wrote:
>> on 30/05/2015 12:56:00,  wrote:
>> > "Alex McDonald" <blog@rivadpm.com> writes:
> <snip>
>> When I see smart I will just have
>> to think of a sharp, stinging pain.
> 
> That's not very nice to use such language among people who are using
> English as a 2nd or 3rd language. :-) (I still don't get most of the
> jokes in Dutch when my wife's family speaks after 37 years, but then
> I'm not too smart.)
> 
> Exlanation:
> "That smarts" can be used in English to mean that something caused me
> to have pain. Somewhat archaic in modern speech but can still be heard
> on occassion.
> 
> Apologies if that was already known by the readers here, but I know
> that when I don't those Dutch jokes "it smarts". :-)
> 

I like this dictionary, as it illustrates words as they change through
usage and time. http://www.etymonline.com/index.php?term=smart

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

#39476

Anton Ertl wrote:
> but I guess it might be different for a
> native speaker; so I would be fine with a different term, but you have
> to convince Bernd Paysan.

I didn't come up with the concept (that's from MPE and Stephen Pelc).  I'm 
not even sure if I used that term intentional or accidently; it started out 
as synonym.

MPE just hides it inside their glossary entry of COMPILE,:

defer Compile, \ xt --                               6.2.0945
Compile the word specified by xt into the current definition.

and has a single sentence that shows the possibility of using SET-COMPILER 
to replace STATE-smart words:

"State-smart words (considered "evil" by some) can be be avoided using set-
compiler and interp>."

(page 202 in my copy).  It's pretty obvious that this sentence is a 
consequence of your "State - why is evil and how to exorcise it" paper, and 
from the context of VFX's compiler (which is a lot about optimizing), you 
can suppose it relates to usage 2 of STATE-smart words:

http://www.complang.tuwien.ac.at/anton/euroforth/ef98/ertl98.pdf

This paper contains two usages of STATE-smart words (both problematic), and 
two different solutions: dual-xt for the parsing words, and intelligent 
compile, for optimization.

We changed Gforth from STATE-smart to dual-xt, experiencing little problems.  
MPE changed from STATE-smart to "smart compile," (i.e. using solution 2 for 
problem 1, too), and experienced little problems.  Why?

Because STATE-smart words have apparently more problems, especially all the 
corner cases where dual-xt and smart compile, differ, STATE-smart is even 
worse.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

[toc] | [prev] | [standalone]

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

csiph-web