F83 split ' (tick) into ' (tick) and ['] (bracket-tick). Why?

[Rod Pemberton]

I've got the same question as this guy:
http://groups.google.com/group/net.lang.forth/msg/918a69f68bc22d04

I just got around to implementing compile behavior for ' (tick). Of course,
testing tick's compile behavior against a few ANS Forths confirmed that '
(tick) is not useable for ANS in a colon-definition, i.e., I should've been
using ['] not ' . Apparently, F83 split ' (tick) into ' (tick) interactive
and ['] (bracket-tick) compile-only. There doesn't seem to be an
explanation in the F83 specification. Why?


Rod Pemberton

[BruceMcF]

On Mar 10, 8:19 pm, "Rod Pemberton" <do_not_h...@noavailemail.cmm>
wrote:

> I've got the same question as this guy:http://groups.google.com/group/net.lang.forth/msg/918a69f68bc22d04
>
> I just got around to implementing compile behavior for ' (tick).
> Of course, testing tick's compile behavior against a few ANS Forths
> confirmed that ' (tick) is not useable for ANS in a colon-definition,
> i.e., I should've been using ['] not ' .

' is certainly quite useable in a colon definition, if you want to get
the xt from a string in the current input that you know is going to be
the name of a word.

Making it state smart would interfere with that use.

> Apparently, F83 split ' (tick) into ' (tick) interactive
> and ['] (bracket-tick) compile-only.  There doesn't seem to be an
> explanation in the F83 specification.  Why?

Could be following some Forth system of the time that did it that way.
Someone who used polyForth back in the day could say whether polyForth
did it that way. Or some other variety ~ Forth79 may have been labeled
a standard but it ended up just being one more variety of Forth.

The basic "why" would be because when you compile the interpreted
version of ' its handy for it to be state-insensitive so that it works
the same way if the word it is in is made immediate and used in
compile state. Making ' state insensitive and splitting the special
compiler behavior out as a separate word ['] untangles some of the
tangles caused by a state-smart ' that tangles ' and ['] together.

[Coos Haak]

Op Sat, 10 Mar 2012 20:19:50 -0500 schreef Rod Pemberton:

Why can't you use tick in a colon definition? In fact, bracket-tick can be
defined like this:

: ['] ' POSTPONE LITERAL ; IMMEDIATE

The split IMO is a result of avoidance of state-smart words.

--
Coos

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

[Andrew Haley]

I'd ask why not? But the deep reason is that ' is a useful factor for
other words. A state-smart version of ' would not have been such a
useful factor.

Andrew.

[Elizabeth D. Rather]

On 3/10/12 4:28 PM, BruceMcF wrote:
> On Mar 10, 8:19 pm, "Rod Pemberton"<do_not_h...@noavailemail.cmm>
> wrote:
>> I've got the same question as this guy:http://groups.google.com/group/net.lang.forth/msg/918a69f68bc22d04
>>
>> I just got around to implementing compile behavior for ' (tick).
>> Of course, testing tick's compile behavior against a few ANS Forths
>> confirmed that ' (tick) is not useable for ANS in a colon-definition,
>> i.e., I should've been using ['] not ' .
>
> ' is certainly quite useable in a colon definition, if you want to get
> the xt from a string in the current input that you know is going to be
> the name of a word.
>
> Making it state smart would interfere with that use.

Exactly.

>> Apparently, F83 split ' (tick) into ' (tick) interactive
>> and ['] (bracket-tick) compile-only. There doesn't seem to be an
>> explanation in the F83 specification. Why?
>
> Could be following some Forth system of the time that did it that way.
> Someone who used polyForth back in the day could say whether polyForth
> did it that way. Or some other variety ~ Forth79 may have been labeled
> a standard but it ended up just being one more variety of Forth.

polyFORTH (and FORTH, Inc. systems dating back before polyFORTH) have
never favored "state-smartness". In the early days, FIG developers (most
of whom were more interested in developing Forth than in using it to
write applications) were quite keen on state-smart words. This was one
of several major points of disagreement between FIG and FORTH, Inc.,
which was using Forth in major applications routinely, as were our
customers.

By the early 80's, there were a number of other independent Forth
vendors, and a lot more people using Forth in applications. In one of
the two meetings in 1982 that produced Forth83, the major players in
FIG, accompanied by several of these vendors, announced that they had
realized that state-smartness was not as useful as they had thought, and
backed the separation of functions that you see.

> The basic "why" would be because when you compile the interpreted
> version of ' its handy for it to be state-insensitive so that it works
> the same way if the word it is in is made immediate and used in
> compile state. Making ' state insensitive and splitting the special
> compiler behavior out as a separate word ['] untangles some of the
> tangles caused by a state-smart ' that tangles ' and ['] together.

Yes. The naming convention [<name>] meaning an immediate, compile-only
version of <name> was adopted then. The use of square brackets was
because ] and [ control STATE.

Incidentally, 'Forth83' is the name of the standard; F83 is the name of
a public-domain system (implementation) produced by Laxen, Perry, and
Harris that was promoted as being a Forth83-compatible replacement for
figForth. Although it improved on figForth in many respects, it wasn't
actually Forth83 compatible in a few areas. It's confusing to say 'F83'
when you mean the standard.

Cheers,
Elizabeth

--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

[Rod Pemberton]

"Coos Haak" <chf...@hccnet.nl> wrote in message
news:1tg8suuc29dus.1m9hs79xl51xg$.dlg@40tude.net...
[...]

> Why can't you use tick in a colon definition? In fact, bracket-tick can be
> defined like this:
>
> : ['] ' POSTPONE LITERAL ; IMMEDIATE
>

Once you have ['] (bracke-tick) defined in terms of ' (tick) , where do you
need ' inside a definition?

> The split IMO is a result of avoidance of state-smart words.

Ok, then if Forth standards are avoiding state-smart words, why did they
merge COMPILE and [COMPILE] into POSTPONE?


Rod Pemberton

[Elizabeth D. Rather]

On 3/12/12 1:42 PM, Rod Pemberton wrote:
> "Coos Haak"<chf...@hccnet.nl> wrote in message
> news:1tg8suuc29dus.1m9hs79xl51xg$.dlg@40tude.net...
> [...]
>
>> Why can't you use tick in a colon definition? In fact, bracket-tick can be
>> defined like this:
>>
>> : ['] ' POSTPONE LITERAL ; IMMEDIATE
>>
>
> Once you have ['] (bracke-tick) defined in terms of ' (tick) , where do you
> need ' inside a definition?

In a word that needs to read a word from the input stream and look it
up. Not as many uses for that as for needing to read forward one
character, but I have encountered quite a few.

>> The split IMO is a result of avoidance of state-smart words.
>
> Ok, then if Forth standards are avoiding state-smart words, why did they
> merge COMPILE and [COMPILE] into POSTPONE?

Because to use COMPILE and [COMPILE] you need to know whether the word
you're compiling is IMMEDIATE or not, and implementations vary in terms
of which words are IMMEDIATE. For example, one cheap way to expand short
primitives inline is to define words like DUP as IMMEDIATE state-smart
words that compile a code sequence. To avoid having to specify every
word as IMMEDIATE or not, POSTPONE was necessary.

[Albert van der Horst]

In article <jjguko$e9i$1...@speranza.aioe.org>,

If you look at ' it is essentially the combination of PARSE-NAME
and a dictionary lookup aka FIND .

But PARSE-NAME -- though itself not state-smart -- can be executed at
compile time or at run time. Furthermore FIND may not be the preferred
dictionary lookup method. So you have to define carefully what lookup
is performed by '.

As an exercise you are advised where ever you want ' to replace it
by a NAME FOUND sequence. You will be naturally inserting LITERAL
at some place and not at others. Trying to automate that goes wrong.
At the very moment it would be handy for novices, the traps start.

You have this problem whenever there is a combination of a parsing
and a processing action. That is why I'm experimenting to replace
.( WE GAAN NAAR ROME)
." WE GAAN NAAR ROME"
by
"WE GAAN NAAR ROME" $.

The rule is that parsing actions only ever may leave a constant
that is valid at compile time through runtime, like numbers do.

>
>
>Rod Pemberton
>

Groetjes Albert

--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst