?EXEC

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Of course, we also want ."Print quoted string":

"print quoted string" TYPE

is good enough for me. And it does not introduce the ." bla" ambiguity.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> One interpretation is that we should go back to implementing S" and
>>> TO with STATE-smart words, and to make STATE-smart words an accepted
>>> technique, and to hell with xts, POSTPONE, code generators and other
>>> guru stuff that's troublesome in the presence of STATE-smart words.
>>
>>There's no need to use state-smartness for any words except S" and TO .
>
> Yes, and with a more capable system it's not even needed for S" and TO.

Not by my definition of state-smart, but OK. I think I'd better start
saying something else. We need a tidy phrase that refers to words
with compilation semantics and non-default interpretation seamntics.
"Frankensetein words", perhaps.

>>One that does its tricks, but not in a way that confuses FIND with
>>several different kinds of token. We know from our discussions here
>>that isn't going to work.

> Actually it does work (Gforth is one example)

I think you're overstating that a litle. FIND makes perfect sense
when all words with compilation semantics are created by IMMEDIATE; it
doesn't make as much sense if such words are created in another way.
It seems to me that we (not just you and me, everyone) tied ourselves
in knots trying to figure out what FIND means in that situation. The
only solutions that made sense were (IMO over-) complicated
replacements for FIND.

> , it's just pretty awful.

Andrew.

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>> There are no interpretation semantics of IF in play in this example.
>> POSTPONE IF compiles the compilation semantics of IF into GEN-FOO, and
>> GEN-FOO then performs the compilation semantics of IF.
>
>So this works if there is a compilation token for IF, which only
>represents the compilation semantics, and not the interpretation
>semantis, which the implementer of a Forth system is free to decide what
>to do with (parse for the next ELSE/THEN in the input stream like [IF]
>does, or report an error, or just compile a forward branch without
>warning).
>
>So far, we have a few solutions to this problem, with words like TO and
>S" being the hardest:
[...]
>* Dual-xt solutions (whether dual-wordlist or a special flag in the
>header like in Gforth) result in a state-smart FIND, which just moves
>the problem around.

Not in the least. With these solutions the GEN-FOO example and S" and
TO work as described in the standard, so the problem has not just
moved around, it has been solved.

Concerning FIND, it's not a good fit for such systems, true. That's
easy to solve by getting rid of FIND, which is also a good idea for
other reasons (counted string input). Replace it with something
cleaner; there are so many better alternatives to FIND possible that
we have not been able to find consensus on which one we want to
standardize on. But if you insist on keeping FIND, having FIND check
STATE is much less problematic in my experience than more typical
STATE-smartness.

Anyway, for stuff like the GEN-FOO example such a system is actually
not necessary. A traditional-style single-xt-with-immediate system
can work for that, too. But ?COMP will break it. So ?COMP is the
problem.

>* Intelligent COMPILE, solutions, which however "violate" the spec of
>COMPILE,

A COMPILE, that violates (not just "violates") the spec of COMPILE, is
not intelligent, but broken.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>> One interpretation is that we should go back to implementing S" and
>>>> TO with STATE-smart words, and to make STATE-smart words an accepted
>>>> technique, and to hell with xts, POSTPONE, code generators and other
>>>> guru stuff that's troublesome in the presence of STATE-smart words.
>>>
>>>There's no need to use state-smartness for any words except S" and TO .
>>
>> Yes, and with a more capable system it's not even needed for S" and TO.
>
>Not by my definition of state-smart, but OK. I think I'd better start
>saying something else.

Good idea.

> We need a tidy phrase that refers to words
>with compilation semantics and non-default interpretation seamntics.
>"Frankensetein words", perhaps.

Fine with me. Although I think you mean "words with interpretation
semantics and non-default non-immediate compilation semantics". I
used to call them "combined words", but it has not caught on. Maybe
Frankenstein words is catchy enough:-).

>>>One that does its tricks, but not in a way that confuses FIND with
>>>several different kinds of token. We know from our discussions here
>>>that isn't going to work.
>
>> Actually it does work (Gforth is one example)
>
>I think you're overstating that a litle. FIND makes perfect sense
>when all words with compilation semantics are created by IMMEDIATE; it
>doesn't make as much sense if such words are created in another way.
>It seems to me that we (not just you and me, everyone) tied ourselves
>in knots trying to figure out what FIND means in that situation.

Not quite. Pretty early (like 15 years ago) I got the idea from
discussions with TC members that FIND should work in a user-defined
interpreter, and implemented it that way, and that has not changed
since. So, as an implementor there were no knots, although the result
is pretty awful (about as awful as specifying that in the standard
would be).

The problem I see is that this is not specified in the standard. The
standard specifies FIND so unclearly that it cannot really be used for
anything useful.

In addition, FIND has other problems like it's counted-string-based
interface.

Another problem that I see is: What's the point of designing FIND (or
its replacement) for a user-written interpreter? Nobody uses such an
interpreter in standard programs, because there is no way to plug such
an interpreter into the existing infrastructure (INCLUDED EVALUATE
....).

>The
>only solutions that made sense were (IMO over-) complicated
>replacements for FIND.

If they make sense, maybe they are not overcomplicated, just
complicated enough.

Even if we just have normal, immediate ("("), and compile-only words
(IF), or maybe just normal and immediate ("(" and "IF") words, it
seems to me that using a FIND-style interface for extracting
interpretation semantics and compilation semantics is by no means
simpler than having a word for extracting interpretation semantics and
a word for extracting compilation semantics.

The user-written text interpreter would look like (something like):

parse-name state @ if
find-comp if execute else ( convert to a number ) postpone literal then
else
find-int if execute else ( convert to a number ) then
then

instead of

bl word find dup if
0< state @ state @ or if execute else compile, then
else
( convert a number) state @ if postpone literal then
then

(both simplified; the number case is further complicated by doubles
and floats).

The nesting is reversed, but there does not seem to be much of a
difference in complication level (especially if you also look at
doubles etc.).

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2012: http://www.euroforth.org/ef12/

In article <3e9da4e8-0ce2-4758-8558-56fd38de3c17@k5g2000vbf.googlegroups.com>,
Alex McDonald <blog@rivadpm.com> wrote:
>
>If you or Andrew are interested in an implementation, I can supply the
>WF32 ANS compliant code that supports it, along with examples. The
>text interpreter remains simple, as each recogniser is plugged into a
>chain of recognisers that are successively invoked with a CATCH and
>the signature ( addr len -- double ) (augmented with a DOUBLE flag to
>indicate if it's a single, double, float cell value). On failure, a
>recogniser does a THROW and the next in the chain is tried until
>success or the last fails, when a -13 THROW is percolated up to the
>parser. There's a chain for compiling and a chain for interpreting.

The mechanism in ciforth is much simpler. A word from the input stream
is found in the dictionary if its first part matches the prefix.
So based on the prefix flag the comparison is done over the length
of the prefix instead of the length of the word by SEARCH-WORDLIST.

That's all. So "AAAP" strings are recognized by a word " in the
ONLY wordlist.
: " ... ; PREFIX IMMEDIATE

In particular prefixes have no relation to each other and can reside
in a wordlist where they belong. So the order is under user control
in a familiar way.

This is more robust, the code for " is only called with a "AAP"
string. If it is not implemented correctly, it still cannot interfere
with regular numbers.

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

In article <js5l9b$vhr$1@online.de>, Bernd Paysan <bernd.paysan@gmx.de> wrote:
>
>Of course, we also want ."Print quoted string":

Isn't it time to want $. $? instead?

"Print quoted string" $.

"Print quoted string" PAD $!
PAD $?

>
>--
>Bernd Paysan
>

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

Anton Ertl wrote:

> Bernd Paysan <bernd.paysan@gmx.de> writes:
>>So far, we have a few solutions to this problem, with words like TO
>>and S" being the hardest:
> [...]
>>* Dual-xt solutions (whether dual-wordlist or a special flag in the
>>header like in Gforth) result in a state-smart FIND, which just moves
>>the problem around.
>
> Not in the least. With these solutions the GEN-FOO example and S" and
> TO work as described in the standard, so the problem has not just
> moved around, it has been solved.

By now creating a problem in FIND. And as the discussion about a
replacement of FIND have shown, moving the problem there does not make
the situation easier.

> But if you insist on keeping FIND, having FIND check
> STATE is much less problematic in my experience than more typical
> STATE-smartness.

I've no problems with the more typical STATE-smartness, either. I just
know that the state is not just there for fun, but that compilation
state means when I want to compile something, I have to have STATE=true.
I need it to find the right token (if I use FIND), and I need it to get
the right reaction (if I use POSTPONE).

You said, you don't use FIND in your code, but I do. I've considered
rewriting my OOF to use Gforth's double tokens, but immediately realized
that this solves exactly nothing, because my OOF first uses FIND and
then EXECUTE or COMPILE, (depending on the flag) - all on potentially
state smart words, because I need quite a bunch of them. Either I have
the problem in FIND, or in EXECUTing the word, but the problem remains
the same.

> Anyway, for stuff like the GEN-FOO example such a system is actually
> not necessary. A traditional-style single-xt-with-immediate system
> can work for that, too. But ?COMP will break it. So ?COMP is the
> problem.

?COMP is a very traditional way of doing this check. Header flags are
more modern. Header flags have their own set of problems (particularly
that the xt comes without them).

>>* Intelligent COMPILE, solutions, which however "violate" the spec of
>>COMPILE,
>
> A COMPILE, that violates (not just "violates") the spec of COMPILE, is
> not intelligent, but broken.

IMHO the spec of COMPILE, is broken. It doesn't really fit to what
Mitch Bradley said it should fit to - his user-written text interpreter.
It fits in a particular classical implementation, with the FIND we have
now.

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

Stephen Pelc wrote:
> On Sat, 23 Jun 2012 15:36:50 +1000, "Ed" <invalid@nospam.com> wrote:
>
> >So what do you now use in place of ?COMP ?EXEC etc
> >(if anything). Does VFX still warn if an attempt is made to
> >use conditionals IF THEN etc interpretively?
>
> We allow the compilation behaviour to be defined separately
> from the interpretation behaviour.
>
> dis if
> IF
> ( 00409E20 E86FF5FFFF ) CALL 00409394 NOINTERP
> ( 00409E25 C3 ) NEXT,
> ( 6 bytes, 2 instructions )
> ok
>
> IF has a separate compilation behaviour. This allows all the
> structure words to be non-IMMEDIATE. The problem that this approach
> solves is that IMMEDIATE specifies that the interpretation and
> compilation actions are the same. In this case, in order to
> differentiate, e.g. when compiling native code, one has to be
> STATE smart, which is a "bad thing".
>
> This approach also makes it very easy to have both interpreted
> and compiled behaviours in S" and friends.

Thanks. I take it from your disassembly that executing IF BEGIN
DO etc interpretively in VFX still results in an error and abort.

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>>>> One interpretation is that we should go back to implementing S" and
>>>>> TO with STATE-smart words, and to make STATE-smart words an accepted
>>>>> technique, and to hell with xts, POSTPONE, code generators and other
>>>>> guru stuff that's troublesome in the presence of STATE-smart words.
>>>>
>>>>There's no need to use state-smartness for any words except S" and TO .
>>>
>>> Yes, and with a more capable system it's not even needed for S" and TO.
>>
>>Not by my definition of state-smart, but OK. I think I'd better start
>>saying something else.
>
> Good idea.
>
>> We need a tidy phrase that refers to words
>>with compilation semantics and non-default interpretation seamntics.
>>"Frankensetein words", perhaps.
>
> Fine with me. Although I think you mean "words with interpretation
> semantics and non-default non-immediate compilation semantics".

By state-smart I mean words with interpretation semantics and
non-default compilation semantics. As far as I'm concerned, it's not
really of any huge consquence how they're created, whether by
IMMEDIATE or some other means.

>>The only solutions that made sense were (IMO over-) complicated
>>replacements for FIND.
>
> If they make sense, maybe they are not overcomplicated, just
> complicated enough.

I don't agree with you about that: they were complicated because the
requirement was complicated. Forth tradition is to simplify
requirements as well as solutions.

> Even if we just have normal, immediate ("("), and compile-only words
> (IF), or maybe just normal and immediate ("(" and "IF") words, it
> seems to me that using a FIND-style interface for extracting
> interpretation semantics and compilation semantics is by no means
> simpler than having a word for extracting interpretation semantics and
> a word for extracting compilation semantics.
>
> The user-written text interpreter would look like (something like):
>
> parse-name state @ if
> find-comp if execute else ( convert to a number ) postpone literal then
> else
> find-int if execute else ( convert to a number ) then
> then
>
> instead of
>
> bl word find dup if
> 0< state @ state @ or if execute else compile, then
> else
> ( convert a number) state @ if postpone literal then
> then
>
> (both simplified; the number case is further complicated by doubles
> and floats).
>
> The nesting is reversed, but there does not seem to be much of a
> difference in complication level (especially if you also look at
> doubles etc.).

I agreee that makes the most sense of the various schemes that was
proposed. There is some hidden complexity, though. I presume this is
the scheme where FIND-COMP returns two XTs, one to execute and one to
compile.

Andrew.

On Jun 25, 5:49*am, Andrew Haley <andre...@littlepinkcloud.invalid>
wrote:
> I agreee that makes the most sense of the various schemes that was
> proposed. *There is some hidden complexity, though. *I presume this is
> the scheme where FIND-COMP returns two XTs, one to execute and one to
> compile.

The flag free version of find-comp returns two xt's,

FIND-COMP ( xt1 xt2 -- )
... where the stack diagram for xt2 is ( xt -- )

.... which allows simple implementations to implement it by just
checking an immediate flag and returning xt2 as either EXECUTE or
COMPILE, allows dual-xt systems on gforth's approach to just return
their pair of xt's and allows dual-xt systems with a stand-alone
compile xt to just return EXECUTE and the compile-xt.

BruceMcF <agila61@netscape.net> wrote:
> On Jun 25, 5:49?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> I agreee that makes the most sense of the various schemes that was
>> proposed. There is some hidden complexity, though. I presume this is
>> the scheme where FIND-COMP returns two XTs, one to execute and one to
>> compile.
>
> The flag free version of find-comp returns two xt's,
>
> FIND-COMP ( xt1 xt2 -- )
> ... where the stack diagram for xt2 is ( xt -- )
>
> ... which allows simple implementations to implement it by just
> checking an immediate flag and returning xt2 as either EXECUTE or
> COMPILE, allows dual-xt systems on gforth's approach to just return
> their pair of xt's and allows dual-xt systems with a stand-alone
> compile xt to just return EXECUTE and the compile-xt.

Yes, that's what I thought. The top XT is always executed, the second
compiled (or executed).

Thanks,
Andrew.

Bernd Paysan wrote:

> Alex McDonald wrote:
>> Agreed. Quoted string support is a long overdue enhancement. We
>> already have single quoted characters ( 'A' ).
>
> Here's the implementation in Gforth, just written in a few minutes
> (recognizers are really great :-):

Ok, I also wrote the ->something recognizer, and had to factor the
nonames for TO a little bit, but then it was easy:

' (int-to) ' (comp-to) ' lit, recognizer: r:to

: to-recognizer ( addr u -- xt r:to | addr u r:fail )
2dup s" ->" string-prefix? 0= IF r:fail EXIT THEN
2dup 2 /string dup 0= IF 2drop r:fail EXIT THEN
find-name dup 0= IF drop r:fail EXIT THEN
name>comp drop nip nip r:to ;

' to-recognizer
forth-recognizer get-recognizers
1+ forth-recognizer set-recognizers

(int-to) and (comp-to) are the two factors that already go into TO. You
now can even postpone things like "update the first local defined" with

: >l0 { a } postpone ->a ; immediate

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

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

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

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

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

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

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

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

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

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

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

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

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

> - whatever problems it may cause for the Standard.

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

Andrew.