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

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

?EXEC

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

Contents

  ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-15 20:40 +0000
    Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-16 11:14 +1000
    Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-16 07:10 -0700
      Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-17 03:01 +0000
        Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-17 13:36 +1000
        Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-17 12:27 +0000
          Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-17 20:45 +0000
            Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-18 13:31 +0000
              Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-18 18:29 +0000
                Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-18 08:01 -1000
                Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-19 14:09 +0000
                  Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-19 10:51 -0500
                    Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-19 16:04 +0000
                      Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-19 12:45 -0500
                        Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-20 10:50 +0000
                          Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-20 07:10 -0500
                            Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-20 12:47 +0000
                  Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-19 22:52 +0000
                    Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-20 10:59 +0000
                  Defining Compilation Behaviour - was Re: ?EXEC JennyB <jennybrien@googlemail.com> - 2012-06-21 04:58 -0700
                    Re: Defining Compilation Behaviour - was Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-21 15:44 +0000
              Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-19 02:11 +0200
                Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-18 14:45 -1000
                  Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-19 10:48 +0000
                    Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-19 15:53 +0000
                      Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-19 23:00 +0000
                        Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-20 11:09 +0000
                          Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-20 07:39 -0700
                            Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-20 15:32 +0000
                              Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-21 11:24 -0700
                          Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-20 22:43 +0000
                          Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-21 21:39 +0200
                          Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-22 02:33 -0500
                            Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-22 11:12 +0000
                              Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-22 21:34 +0200
                                Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-24 14:58 +0000
                                  Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-24 23:53 +0200
                  Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-19 15:43 +0000
                Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-19 14:52 +0000
                  Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-21 22:15 +0200
                    Re: ?EXEC stephenXXX@mpeforth.com (Stephen Pelc) - 2012-06-22 10:32 +0000
                      Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-22 05:49 -0500
                        Alternatives to S" and TO (was: ?EXEC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-22 15:19 +0000
                          Re: Alternatives to S'' and TO mhx@iae.nl (Marcel Hendrix) - 2012-06-22 20:37 +0200
                            Re: Alternatives to S'' and TO anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-23 14:46 +0000
                          Re: Alternatives to S" and TO (was: ?EXEC) BruceMcF <agila61@netscape.net> - 2012-06-22 12:32 -0700
                          Re: Alternatives to S" and TO Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-23 03:07 -0500
                            Re: Alternatives to S" and TO anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-23 13:32 +0000
                              Re: Alternatives to S" and TO Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-24 08:50 -0500
                                Re: Alternatives to S" and TO anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-24 15:39 +0000
                                  Re: Alternatives to S" and TO Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-25 04:49 -0500
                                    Re: Alternatives to S" and TO BruceMcF <agila61@netscape.net> - 2012-06-25 07:17 -0700
                                      Re: Alternatives to S" and TO Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-25 10:13 -0500
                          Re: Alternatives to S" and TO (was: ?EXEC) Alex McDonald <blog@rivadpm.com> - 2012-06-23 16:01 -0700
                            Re: Alternatives to S" and TO (was: ?EXEC) Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-24 01:59 +0200
                              Re: Alternatives to S" and TO (was: ?EXEC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-24 13:21 +0000
                              Re: Alternatives to S" and TO (was: ?EXEC) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-24 16:50 +0000
                              Re: Alternatives to S" and TO (was: ?EXEC) Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-27 23:30 +0200
                            Re: Alternatives to S" and TO (was: ?EXEC) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-24 13:15 +0000
                            Re: Alternatives to S" and TO (was: ?EXEC) Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-24 16:47 +0000
                        Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-22 20:34 +0000
                      Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-22 21:46 +0200
                        Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-22 10:16 -1000
                          Re: ?EXEC Bernd Paysan <bernd.paysan@gmx.de> - 2012-06-22 22:43 +0200
                            Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-22 11:18 -1000
                            Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-23 13:50 +0000
        Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-17 10:41 -0700
    Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-17 12:52 +0000
      Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-17 08:03 -1000
        Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-18 15:06 +1000
          Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-17 20:31 -1000
            Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-21 13:07 +1000
              Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-21 14:00 +0000
                Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-21 07:51 -0700
                Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-21 15:39 +0000
                  Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-21 20:28 +0000
                    Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-28 14:22 +1000
                      Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-28 04:00 -0500
              Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-21 16:09 +0000
              Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-21 11:51 -0500
                Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-21 11:21 -0700
                  Re: ?EXEC Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-06-22 01:42 -0500
                    Re: ?EXEC "Elizabeth D. Rather" <erather@forth.com> - 2012-06-21 21:47 -1000
                      Re: ?EXEC anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-06-22 15:10 +0000
                        Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-22 20:39 +0000
                      Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-22 12:47 -0700
                    Re: ?EXEC BruceMcF <agila61@netscape.net> - 2012-06-22 12:53 -0700
          Re: ?EXEC stephenXXX@mpeforth.com (Stephen Pelc) - 2012-06-21 08:39 +0000
            Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-23 15:36 +1000
              Re: ?EXEC stephenXXX@mpeforth.com (Stephen Pelc) - 2012-06-23 10:58 +0000
                Re: ?EXEC "Ed" <invalid@nospam.com> - 2012-06-25 14:26 +1000
                  Re: ?EXEC stephenXXX@mpeforth.com (Stephen Pelc) - 2012-06-25 08:37 +0000
        Re: ?EXEC Albert van der Horst <albert@spenarnc.xs4all.nl> - 2012-06-18 10:34 +0000
    Re: ?EXEC Coos Haak <chforth@hccnet.nl> - 2012-06-18 17:47 +0200
      Re: ?EXEC Coos Haak <chforth@hccnet.nl> - 2012-06-18 17:49 +0200
    Re: ?EXEC jacko <jackokring@gmail.com> - 2012-06-22 15:43 -0700

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

#13156

On Thu, 21 Jun 2012 22:15:08 +0200, Bernd Paysan <bernd.paysan@gmx.de>
wrote:

>Maybe.  There are however quite a lot of Forths out there which fail 
>postponetest.fs, and they have production code running on it.  I had 
>quite some troubles with VFX Forth with Postpone, and I was "the only 
>one" who used strange things where Stephen's source inliner failed.  The 
>tests required to break that weren't even part of test/postpone.fs, it 
>would be something like

1) I did not write the source inliner. It was MPE's, not Stephen's.
2) The source inliner is dead! Long live the tokeniser!

>Yes.  But the question is whether postponetest really tests something 
>that is worth testing.  It tests whether postpone is able to preserve 
>the compilation semantics of its postponed words in interpretation 
>state.

POSTPONE had no common practice at the time it was introduced.
18 years later we still have trouble with it.

By comparison, CATCH and THROW had plenty of common practice, albeit
in other languages. It has caused no trouble.

The lesson is not to standardise a solution until it has been
exhaustively evaluated. However, POSTPONE is a mess we have to
cope with until we have a proper model of xt's and Forth compilation
that allows for modern techniques. Once we have a model we can try
it and define a sensible word set. STATE POSTPONE and IMMEDIATE
may be casualties of this process in 20 years time.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#13157

Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Thu, 21 Jun 2012 22:15:08 +0200, Bernd Paysan <bernd.paysan@gmx.de>
> wrote:
> 
>>Maybe.  There are however quite a lot of Forths out there which fail 
>>postponetest.fs, and they have production code running on it.  I had 
>>quite some troubles with VFX Forth with Postpone, and I was "the only 
>>one" who used strange things where Stephen's source inliner failed.  The 
>>tests required to break that weren't even part of test/postpone.fs, it 
>>would be something like
> 
> 1) I did not write the source inliner. It was MPE's, not Stephen's.
> 2) The source inliner is dead! Long live the tokeniser!

He'll never let it go.  :-)

>>Yes.  But the question is whether postponetest really tests something 
>>that is worth testing.  It tests whether postpone is able to preserve 
>>the compilation semantics of its postponed words in interpretation 
>>state.
> 
> POSTPONE had no common practice at the time it was introduced.
> 18 years later we still have trouble with it.
> 
> By comparison, CATCH and THROW had plenty of common practice, albeit
> in other languages. It has caused no trouble.
> 
> The lesson is not to standardise a solution until it has been
> exhaustively evaluated. However, POSTPONE is a mess we have to
> cope with until we have a proper model of xt's and Forth compilation
> that allows for modern techniques. Once we have a model we can try
> it and define a sensible word set. STATE POSTPONE and IMMEDIATE
> may be casualties of this process in 20 years time.

I'm very nervous about suggesting this, but here goes:

I've been thinking the opposite.  Maybe the problem with some of the
modern techniques is that they're exposed to the programmer; they're
too shallow.  Perhaps the right solution is to let the Forth compiler
generate tokens (just like a very trad Forth) and then let the
optimizing compiler run over them.  Let IMMEDIATE do what it used to
do.  Get rid of other ways of creating words that execute at compile
time.  Let FIND do what it used to do.  Etc., etc...

This is probably worthy of a workshop at EuroFORTH.

Andrew.

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

#13165 — Alternatives to S" and TO (was: ?EXEC)

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>I've been thinking the opposite.  Maybe the problem with some of the
>modern techniques is that they're exposed to the programmer; they're
>too shallow.  Perhaps the right solution is to let the Forth compiler
>generate tokens (just like a very trad Forth) and then let the
>optimizing compiler run over them.

That's an implementation issue, but it's the right approach.

> Let IMMEDIATE do what it used to
>do.  Get rid of other ways of creating words that execute at compile
>time.

There is no other way in the standard.  A problem may be that the
other ways are *not* exposed to the programmer (in standard programs),
so people still resort to STATE-smartness in standard programs.

Anyway, it's not totally clear what you mean by this.

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.

Another take on your statement is that we should get rid of words like
S" and TO (and not design more of the kind) which some implementations
implement with STATE-smartness, for which other implementations
provide implementations with better properties, but with repercussions
that are far more trouble than these words are worth.

Instead, we would only have normal words (like +) and IMMEDIATE words
like ( and IF (the latter maybe compile-only), but no access to STATE
and no words that have independent interpretation and compilation
semantics.

We would have to replace S" and TO with something else.  The classic
approach would be the ' ['] solution, but that's not very popular.

What is popular is the solution taken for numbers: The text
interpreter deals with them as appropriate and everyone is happy.  We
don't use NUM 123 and [NUM] 123 for numbers, we let the text
interpreter deal with them.

Probably most of the parsing words (the main driver behind STATE-smart
words) can be eliminated by having a few additions to the text
interpreter.  E.g., instead of writing ." bla" or .( bla) one could
write "bla" TYPE, and have code that works both interpretively and
compiled as intended.

There are a few parsing words where the replacement requires its own
treatment in the text interpreter, in particular TO.  Instead of 

TO v

we could write

->v

and the text interpreter would do the appropriate thing with V.

Albert van der Horst used to call this feature "denotations", but
lately I have seen him use "prefixes".

Many will cry out against this complication of the text interpreter.
Some may also find the idea bad because up to now the text interpreter
is a black box so any additions there are only done by the compiler
vendor.  However:

1) I think that this feature adds relatively little complexity to the
text interpreter, and it gets rid of a huge amount of baggage
elsewhere (STATE-smart words and the restrictions that their defenders
want to put upon us, or the complexities of the alternatives and their
ramifications).

2) One could make it possible for "mere" users to add further
prefixes/denotations (or, as Gforth calls them, recognizers) to the
text interpreter, just like it is possible to add further words now.
Of course some people will fear giving this much power to the users,
and it's certainly a feature that should be used sparingly, but that's
a management issue.

>This is probably worthy of a workshop at EuroFORTH.

Yes.


- 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/

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

#13168 — Re: Alternatives to S'' and TO

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: Alternatives to S" and TO (was: ?EXEC)

> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>I've been thinking the opposite.  Maybe the problem with some of the
>>modern techniques is that they're exposed to the programmer; they're
>>too shallow.  Perhaps the right solution is to let the Forth compiler
>>generate tokens (just like a very trad Forth) and then let the
>>optimizing compiler run over them.

This is the approach taken by iForth. Almost every word has a 
tokenized form, and another form intended for ' ['] or direct execution. 

> That's an implementation issue, but it's the right approach.

>> Let IMMEDIATE do what it used to
>>do.  Get rid of other ways of creating words that execute at compile
>>time.

I don't know the repercussions of all that. My approach would be to
make the language as simple as possible, without worrying about speed
or size. Alternatives can go. Hooks can go too.

[..]
> What is popular is the solution taken for numbers: The text
> interpreter deals with them as appropriate and everyone is happy.  We
> don't use NUM 123 and [NUM] 123 for numbers, we let the text
> interpreter deal with them.

An interesting idea. Then we could maybe also have dotted notation
and such.

[..]
> There are a few parsing words where the replacement requires its own
> treatment in the text interpreter, in particular TO.  Instead of 

> TO v

> we could write

> ->v

Great.

> and the text interpreter would do the appropriate thing with V.

[..]

> Many will cry out against this complication of the text interpreter.
> Some may also find the idea bad because up to now the text interpreter
> is a black box so any additions there are only done by the compiler
> vendor.  However:

> 1) I think that this feature adds relatively little complexity to the
> text interpreter, and it gets rid of a huge amount of baggage
> elsewhere (STATE-smart words and the restrictions that their defenders
> want to put upon us, or the complexities of the alternatives and their
> ramifications).

The iForth text interpreter is already hugely complicated by workarounds 
that are of no real benefit to the user.

> 2) One could make it possible for "mere" users to add further
> prefixes/denotations (or, as Gforth calls them, recognizers) to the
> text interpreter, just like it is possible to add further words now.

There is that old idea to factor the text interpreter, that would fit here.

> Of course some people will fear giving this much power to the users,
> and it's certainly a feature that should be used sparingly, but that's
> a management issue.

Who are these people? 

[..]

-marcel

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

#13200 — Re: Alternatives to S'' and TO

mhx@iae.nl (Marcel Hendrix) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes Re: Alternatives to S" and TO (was: ?EXEC)
>> 1) I think that this feature adds relatively little complexity to the
>> text interpreter, and it gets rid of a huge amount of baggage
>> elsewhere (STATE-smart words and the restrictions that their defenders
>> want to put upon us, or the complexities of the alternatives and their
>> ramifications).
>
>The iForth text interpreter is already hugely complicated by workarounds 
>that are of no real benefit to the user.

Hmm, so would you like to have this feature because it would replace
some of the workarounds?  Or would you like not to have it because
even if taken by itself, the complexity is not big, it adds to the
already considerable complexity?

>> 2) One could make it possible for "mere" users to add further
>> prefixes/denotations (or, as Gforth calls them, recognizers) to the
>> text interpreter, just like it is possible to add further words now.
>
>There is that old idea to factor the text interpreter, that would fit here.
>
>> Of course some people will fear giving this much power to the users,
>> and it's certainly a feature that should be used sparingly, but that's
>> a management issue.
>
>Who are these people? 

There always tend to be such people, but it's hard to predict who
turns out to be in that camp on a specific issue.  We will learn at
the latest when someone makes an RfC for this feature.

- 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/

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

#13169 — Re: Alternatives to S" and TO (was: ?EXEC)

On Jun 22, 11:19 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> We would have to replace S" and TO with something else.  The classic
> approach would be the ' ['] solution, but that's not very popular.

Is this conflating? The problem with S" is entirely that the buffered
S" and the compiled S" were given the same name. If "parse into a
buffer" S" had been given a name such as T" in the first place, then
there would be no problem.

OTOH, would be multiply overloaded even with TO and [TO] ... as noted,
inventing a new Forth94-like language with prefix semantics *could*
eliminate that overloading, but it would be just as likely to
proliferate the overloading into the prefixes, if the prefixes are
taken beyond just one-shot base modifications.

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

#13191 — Re: Alternatives to S" and TO

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>I've been thinking the opposite.  Maybe the problem with some of the
>>modern techniques is that they're exposed to the programmer; they're
>>too shallow.  Perhaps the right solution is to let the Forth compiler
>>generate tokens (just like a very trad Forth) and then let the
>>optimizing compiler run over them.
> 
> That's an implementation issue, but it's the right approach.
> 
>>Let IMMEDIATE do what it used to do.  Get rid of other ways of
>>creating words that execute at compile time.
> 
> There is no other way in the standard.

True, but there are other ways that an implementer may use internally,
as we konw.

> A problem may be that the other ways are *not* exposed to the
> programmer (in standard programs), so people still resort to
> STATE-smartness in standard programs.
> 
> Anyway, it's not totally clear what you mean by this.
> 
> 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 .
I don't think this alone makes state-smartness an accepted technique;
just one to be tolerated.

Given no means other than IMMEDIATE to create words with compilation
semantics, FIND would have one unambigous defintion.

> Another take on your statement is that we should get rid of words like
> S" and TO (and not design more of the kind) which some implementations
> implement with STATE-smartness, for which other implementations
> provide implementations with better properties, but with repercussions
> that are far more trouble than these words are worth.

Probably, yes.

> Instead, we would only have normal words (like +) and IMMEDIATE words
> like ( and IF (the latter maybe compile-only), but no access to STATE
> and no words that have independent interpretation and compilation
> semantics.
> 
> We would have to replace S" and TO with something else.  The classic
> approach would be the ' ['] solution, but that's not very popular.
> 
> What is popular is the solution taken for numbers: The text
> interpreter deals with them as appropriate and everyone is happy.  We
> don't use NUM 123 and [NUM] 123 for numbers, we let the text
> interpreter deal with them.
> 
> Probably most of the parsing words (the main driver behind STATE-smart
> words) can be eliminated by having a few additions to the text
> interpreter.  E.g., instead of writing ." bla" or .( bla) one could
> write "bla" TYPE, and have code that works both interpretively and
> compiled as intended.
> 
> There are a few parsing words where the replacement requires its own
> treatment in the text interpreter, in particular TO.  Instead of 
> 
> TO v
> 
> we could write
> 
> ->v
> 
> and the text interpreter would do the appropriate thing with V.
> 
> Albert van der Horst used to call this feature "denotations", but
> lately I have seen him use "prefixes".
> 
> Many will cry out against this complication of the text interpreter.
> Some may also find the idea bad because up to now the text interpreter
> is a black box so any additions there are only done by the compiler
> vendor.  However:
> 
> 1) I think that this feature adds relatively little complexity to the
> text interpreter, and it gets rid of a huge amount of baggage
> elsewhere (STATE-smart words and the restrictions that their defenders
> want to put upon us, or the complexities of the alternatives and their
> ramifications).
> 
> 2) One could make it possible for "mere" users to add further
> prefixes/denotations (or, as Gforth calls them, recognizers) to the
> text interpreter, just like it is possible to add further words now.
> Of course some people will fear giving this much power to the users,
> and it's certainly a feature that should be used sparingly, but that's
> a management issue.

All of this is very interesting, but I wasn't proposing anything as
radical.

My solution is more "Back to the future": a Forth that looks to the
programmer like a traditional implementation, but does as much
optimization as you want under the hood.  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.

Andrew.

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

#13197 — Re: Alternatives to S" and TO

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.

However, there is a reason why we got S" and TO, and that reason does
not stop at these words: people want to be able to write code (that
includes parsing words) that works both interpretively and inside
colon definitions.  And they will define such words, and if no other
options are available, they will define STATE-smart words.

>Given no means other than IMMEDIATE to create words with compilation
>semantics, FIND would have one unambigous defintion.

For user-defined words yes, but what about system-defined words like
S" and TO?  Do you want to require them to be STATE-smart?

>My solution is more "Back to the future": a Forth that looks to the
>programmer like a traditional implementation, but does as much
>optimization as you want under the hood.

That is definitely a good idea.  The smart COMPILE, goes in that
direction, but I guess what you have in mind is optimization at an
even later stage.

>  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), it's just pretty awful.

And it's certainly not optimal to put code generation/optimization at
a level visible through FIND; e.g., consider ['] + COMPILE, in
cmForth; it will compile a call to a colon definition that performs a
+ instead of just compiling +.  An intellingent COMPILE, does not have
this issue.

- 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/

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

#13218 — Re: Alternatives to S" and TO

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.

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

#13222 — Re: Alternatives to S" and TO

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/

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

#13235 — Re: Alternatives to S" and TO

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.

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

#13241 — Re: Alternatives to S" and TO

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.

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

#13243 — Re: Alternatives to S" and TO

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.

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

#13204 — Re: Alternatives to S" and TO (was: ?EXEC)

On Jun 22, 4:19 pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:
> Andrew Haley <andre...@littlepinkcloud.invalid> writes:
> >I've been thinking the opposite.  Maybe the problem with some of the
> >modern techniques is that they're exposed to the programmer; they're
> >too shallow.  Perhaps the right solution is to let the Forth compiler
> >generate tokens (just like a very trad Forth) and then let the
> >optimizing compiler run over them.
>
> That's an implementation issue, but it's the right approach.
>
> > Let IMMEDIATE do what it used to
> >do.  Get rid of other ways of creating words that execute at compile
> >time.
>
> There is no other way in the standard.  A problem may be that the
> other ways are *not* exposed to the programmer (in standard programs),
> so people still resort to STATE-smartness in standard programs.
>
> Anyway, it's not totally clear what you mean by this.
>
> 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.
>
> Another take on your statement is that we should get rid of words like
> S" and TO (and not design more of the kind) which some implementations
> implement with STATE-smartness, for which other implementations
> provide implementations with better properties, but with repercussions
> that are far more trouble than these words are worth.
>
> Instead, we would only have normal words (like +) and IMMEDIATE words
> like ( and IF (the latter maybe compile-only), but no access to STATE
> and no words that have independent interpretation and compilation
> semantics.
>
> We would have to replace S" and TO with something else.  The classic
> approach would be the ' ['] solution, but that's not very popular.
>
> What is popular is the solution taken for numbers: The text
> interpreter deals with them as appropriate and everyone is happy.  We
> don't use NUM 123 and [NUM] 123 for numbers, we let the text
> interpreter deal with them.
>
> Probably most of the parsing words (the main driver behind STATE-smart
> words) can be eliminated by having a few additions to the text
> interpreter.  E.g., instead of writing ." bla" or .( bla) one could
> write "bla" TYPE, and have code that works both interpretively and
> compiled as intended.

Agreed. Quoted string support is a long overdue enhancement. We
already have single quoted characters ( 'A' ).

>
> There are a few parsing words where the replacement requires its own
> treatment in the text interpreter, in particular TO.  Instead of
>
> TO v
>
> we could write
>
> ->v
>
> and the text interpreter would do the appropriate thing with V.

While we're at it, junk ACTION-OF and IS as well.

>
> Albert van der Horst used to call this feature "denotations", but
> lately I have seen him use "prefixes".
>
> Many will cry out against this complication of the text interpreter.
> Some may also find the idea bad because up to now the text interpreter
> is a black box so any additions there are only done by the compiler
> vendor.  However:
>
> 1) I think that this feature adds relatively little complexity to the
> text interpreter, and it gets rid of a huge amount of baggage
> elsewhere (STATE-smart words and the restrictions that their defenders
> want to put upon us, or the complexities of the alternatives and their
> ramifications).
>
> 2) One could make it possible for "mere" users to add further
> prefixes/denotations (or, as Gforth calls them, recognizers) to the
> text interpreter, just like it is possible to add further words now.
> Of course some people will fear giving this much power to the users,
> and it's certainly a feature that should be used sparingly, but that's
> a management issue.

WF32* has supported such a scheme for a number of years now,
specifically to support prefixed numbers; but it can support any other
token that's not found in the dictionary. See below.

*(my now so heavily modified Win32Forth that a name change is in
order)

>
> >This is probably worthy of a workshop at EuroFORTH.
>
> Yes.

I would like to be there in person, but can't attend.

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.

Here's how it supports a quoted string given the above support
structure;

: interpret-qstring ( addr len -- d )
    dup 2 < throw
    over c@ >r 2dup + c@ r> '"' dup d= if
      1 /string 1-
      true to double ( flag for type of number)
    else true throw then ;

: compile-qstring ( addr len -- d )
    interpret-string
    here over 2dup 2>r 2+ allot place 2r> ; ( counted str, null
terminated)

' interpret-qstring interpret-chain chain+ ( add in to interpret-chain
list)
' compile-qstring   compile-chain   chain+ ( add in to compile-chain
list)

The DOUBLE flag is a bit messy (FALSE indicates a single cell, and
there is another variable to indicate if it's to be interpreted as a
pointer to a float value), but that's a historical hangover.

>
> - 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/

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

#13206 — Re: Alternatives to S" and TO (was: ?EXEC)

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 :-):

: slit,  postpone sliteral ;

' noop ' slit, dup recognizer: r:string

: string-recognizer ( addr u -- addr u' r:string | addr u r:fail )
    2dup s\" \"" string-prefix?
    IF    drop source drop - 1+ >in !  \"-parse save-mem r:string
    ELSE  r:fail  THEN ;

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

We have only one recognizer chain, and instead of passing a flag, we 
return a vtable, which contains three methods: how to interpret the 
thing, how to compile the thing, and how to serialize the thing 
(serializing is for POSTPONE,).  "Thing" is the rest the recognizer 
returns (token, number, float, whatever).

Of course, we also want ."Print quoted string":

: slit.  slit, postpone type ;

' type ' slit. ' slit, recognizer: r:."

: ."-recognizer  ( addr u -- addr u' r:." | addr u r:fail )
    2dup ".\"" string-prefix?
    IF    drop source drop - 2 + >in !  \"-parse save-mem r:."
    ELSE  r:fail  THEN ;

' ."-recognizer
forth-recognizer get-recognizers
1+ forth-recognizer set-recognizers

The recognizer actions do the parse-time stuff, and pass the stuff for 
further processing to the text interpreter - or whoever uses the 
recognizer (like ]] for postponing multiple words).  Yes, you can now 
postpone string literals:

: test ]] "This is " type ."a test." [[ ; immediate  ok  
: test2 test ;  ok
test2 This is a test. ok

Note that ." something" will partly conflict with normal .", as this is 
a Forth word, and will be recognized first. So until we get rid of .", 
print something starting with a space is

."\ something with a space"

I'm really for recognizer to solve the parse-time problem.  They do it 
nicely, they *only* work at parse-time, and they just tokenize.  I.e. 
the text processing is done, but whether to interpret or to compile (or 
postpone) is not yet decided.

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

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

#13217 — Re: Alternatives to S" and TO (was: ?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/

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

#13224 — Re: Alternatives to S" and TO (was: ?EXEC)

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

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

#13298 — Re: Alternatives to S" and TO (was: ?EXEC)

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/

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

#13216 — Re: Alternatives to S" and TO (was: ?EXEC)

Alex McDonald <blog@rivadpm.com> writes:
>On Jun 22, 4:19=A0pm, an...@mips.complang.tuwien.ac.at (Anton Ertl)
>wrote:
>> There are a few parsing words where the replacement requires its own
>> treatment in the text interpreter, in particular TO. =A0Instead of
>>
>> TO v
>>
>> we could write
>>
>> ->v
>>
>> and the text interpreter would do the appropriate thing with V.
>
>While we're at it, junk ACTION-OF and IS as well.

Yes, of course.  "IS d" might become "->d", too.  "ACTION-OF d" could
be replaced with "' d defer@", and "' d", "['] d" might also be
replaced with some prefix-based syntax.

- 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/

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

#13223 — Re: Alternatives to S" and TO (was: ?EXEC)

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

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

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

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

csiph-web