COMPILE, and :NONAME

[Alex McDonald]

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

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

[Gerry Jackson]

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

[Anton Ertl]

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

[Alex McDonald]

on 29/05/2015 14:25:52, wrote:
> "Alex McDonald" <bl...@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.

[Alex McDonald]

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

[Anton Ertl]

"Alex McDonald" <bl...@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).

[Alex McDonald]

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.

[Alex McDonald]

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

[Anton Ertl]

"Alex McDonald" <bl...@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.

[Alex McDonald]

on 29/05/2015 18:21:27, wrote:
> "Alex McDonald" <bl...@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

[Bernd Paysan]

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/

[Alex McDonald]

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.

[Bernd Paysan]

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.

[Anton Ertl]

"Alex McDonald" <bl...@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.

[Albert van der Horst]

In article <2015May3...@mips.complang.tuwien.ac.at>,

Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>"Alex McDonald" <bl...@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

[Alex McDonald]

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.

[Alex McDonald]

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.

[Bernd Paysan]

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.

[foxaudio...@gmail.com]

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" <bl...@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". :-)

[Alex McDonald]

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