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

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

Execution tokens for return stack manipulation

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

Contents

  Execution tokens for return stack manipulation Lauri Alanko <la@iki.fi> - 2013-09-23 19:32 +0000
    Re: Execution tokens for return stack manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-23 14:59 -0500
      Re: Execution tokens for return stack manipulation Lauri Alanko <la@iki.fi> - 2013-09-23 20:21 +0000
        Re: Execution tokens for return stack manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-23 15:53 -0500
      Re: Execution tokens for return stack manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-23 23:27 +0200
        Re: Execution tokens for return stack manipulation "Alex McDonald" <blog@rivadpm.com> - 2013-09-23 23:37 +0100
        Re: Execution tokens for return stack manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-24 06:52 -0500
          Re: Execution tokens for return stack manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-09-24 12:36 +0000
            Re: Execution tokens for return stack manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-24 12:10 -0500
              Re: Execution tokens for return stack manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-24 22:22 +0200
          Re: Execution tokens for return stack manipulation Bernd Paysan <bernd.paysan@gmx.de> - 2013-09-24 16:14 +0200
            Re: Execution tokens for return stack manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-09-24 12:12 -0500
    Re: Execution tokens for return stack manipulation "Rod Pemberton" <dont_use_email@nohavenotit.com> - 2013-09-23 18:09 -0400
    Re: Execution tokens for return stack manipulation "Elizabeth D. Rather" <erather@forth.com> - 2013-09-23 12:40 -1000
      Re: Execution tokens for return stack manipulation Lauri Alanko <la@iki.fi> - 2013-09-23 22:43 +0000
        Re: Execution tokens for return stack manipulation Spam@ControlQ.com - 2013-09-24 01:38 -0400

#25975 — Execution tokens for return stack manipulation

Hello.

Are execution tokens for primitive return stack operations (r>, r@, >r
etc.) supposed to be usable? I.e. is this legal?

: foo >r ['] r> execute . ;
42 foo

On gforth this outputs 42, but I'm wondering if this is something that
can be commonly relied on.

I remember being a while ago concerned that supporting this would
complicate the implementation of primitive execution tokens, but then
I found out that the above situation doesn't actually need to be
supported. However, now that I scan the Forth 200x draft, I cannot
find where I got that idea from.

Could someone clarify what the standard (and common practice)
dictates? Thanks.


Lauri

[toc] | [next] | [standalone]

#25977

Hi,

Lauri Alanko <la@iki.fi> wrote:
> 
> Are execution tokens for primitive return stack operations (r>, r@, >r
> etc.) supposed to be usable? I.e. is this legal?
> 
> : foo >r ['] r> execute . ;
> 42 foo
> 
> On gforth this outputs 42, but I'm wondering if this is something that
> can be commonly relied on.
> 
> I remember being a while ago concerned that supporting this would
> complicate the implementation of primitive execution tokens, but then
> I found out that the above situation doesn't actually need to be
> supported. However, now that I scan the Forth 200x draft, I cannot
> find where I got that idea from.
> 
> Could someone clarify what the standard (and common practice)
> dictates?

You can't tick and execute >R.

This is implied because of the interpretation semantics of >R:

 6.1.0580 >R
         Interpretation semantics for this word are undefined.

So, >R has only compilation semantics.

Andrew.

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

#25978

In article <D6KdncmsPd8EAN3PnZ2dnUVZ_vydnZ2d@supernews.com>,
Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
> You can't tick and execute >R.
> 
> This is implied because of the interpretation semantics of >R:

Ah, that was it, thanks!

However, I must say this is somewhat non-obvious. The prohibition
comes from 4.1.2, which forbids "attempting to obtain the execution
token of a definition with undefined interpretation semantics".

But 3.4.3.1 says that EXECUTE executes the _execution_ semantics,
which the return stack operations do have. And neither the glossary
for the tick operations nor for EXECUTE mentions the constraint. So it
is very hard to find out, unless one already knows where to look.


Lauri

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

#25979

Lauri Alanko <la@iki.fi> wrote:
> In article <D6KdncmsPd8EAN3PnZ2dnUVZ_vydnZ2d@supernews.com>,
> Andrew Haley  <andrew29@littlepinkcloud.invalid> wrote:
>> You can't tick and execute >R.
>> 
>> This is implied because of the interpretation semantics of >R:
> 
> Ah, that was it, thanks!
> 
> However, I must say this is somewhat non-obvious. The prohibition
> comes from 4.1.2, which forbids "attempting to obtain the execution
> token of a definition with undefined interpretation semantics".
> 
> But 3.4.3.1 says that EXECUTE executes the _execution_ semantics,
> which the return stack operations do have. And neither the glossary
> for the tick operations nor for EXECUTE mentions the constraint. So it
> is very hard to find out, unless one already knows where to look.

That's a fair complaint.  Perhaps we could just add a cross-reference
to the glossary for the tick operations?

I think it's fair to say that the Forth 200x discussions around the
area of rewording (or rewriting) the handling of compilation/
execution/interpretation semantics have been tortuous.  It's really
hard to get right in a way that allows all the variations of Forth
systems but prohibits the things that shouldn't be done.

Andrew.

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

#25980

Andrew Haley wrote:
> You can't tick and execute >R.
> 
> This is implied because of the interpretation semantics of >R:
> 
>  6.1.0580 >R
>          Interpretation semantics for this word are undefined.
> 
> So, >R has only compilation semantics.

I don't think that is conclusive.  It has execution semantics, if you can't 
' and execute it, having exection semantics is the wrong label, don't you 
think?  If you look at 3.4.3.1, you see that there are two ways to get 
execution semantics: Either by compiling code into a word, or by obtaining 
the xt and executing it.  So if something has execution semantics, I would 
conclude that both obtaining the xt and executing it should work.

The ANS TC had already ruled on the question concerning EXIT, and decided 
that you are allowed not to have an xt for EXIT, i.e. through their 
interpretation, you are right - >R is the same case.

However: The interpretation semantics is what the Forth interpreter does 
with a word.  There is an obvious reason why

: int>r ( n -- r:n )  ['] >r execute ;

doesn't make >r work on the interpreter: It is a definition with an 
unbalanced stack effect.  But in terms of what the standard actually 
specifies (TC interpreations non-withstanding), I would think that ['] >R 
EXECUTE is indeed equivalent to >R inside a definition.  The reason why >R 
has no interpretation semantics is that the interpreter quite likely uses 
the return stack, and >R therefore can't work.

To be honest, this is all a mess, needs to be fixed, and in fact, >R does 
quite often not have execution semantics, but only run-time semantics.  In 
bigForth, e.g., >R is immediate, because this is necessary for the shared 
locals and return stack.  Even a non-immediate >R would not work, because 
that one is a macro which just generates the code for >R.  EXECUTE is an 
indirect call, and therefore modifies the return stack, so >R would 
conflict.  It *is* possible to have a working >R with ['] >R EXECUTE in a 
native code system, though (the executed part just needs to first pop the 
return address, then do the >R, and then return to the popped address), but 
this requires a smart COMPILE, or similar.  In bigForth my conclusion was 
certainly "not worth the effort", in Gforth, the effort is less (threaded 
code), and we even decided to have interpretation semantics, but it must be 
balanced within one line.  The reason we can do this is because in Gforth, 
the EXECUTE happens within the main interpreter loop, so the return stack is 
free to use within that loop (within one line).

I think we have agreed that we need to fix the definitions for the various 
semantics to remove known inconsistencies, and to adjust some words' 
definitions.  Especially those with return stack effects, as they all don't 
have full execution semantics, only run-time semantics.

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

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

#25983

on 23/09/2013 22:27:15, Bernd Paysan wrote:
> Andrew Haley wrote:
>> You can't tick and execute >R.
>>
>> This is implied because of the interpretation semantics of >R:
>>
>>  6.1.0580 >R
>>          Interpretation semantics for this word are undefined.
>>
>> So, >R has only compilation semantics.
> 
> I don't think that is conclusive. It has execution semantics, if you
> can't ' and execute it, having exection semantics is the wrong label,

That is the point.


> don't you think? If you look at 3.4.3.1, you see that there are two
> ways to get execution semantics: Either by compiling code into a word,
> or by obtaining the xt and executing it. So if something has execution
> semantics, I would conclude that both obtaining the xt and executing
> it should work.
> 
> The ANS TC had already ruled on the question concerning EXIT, and
> decided that you are allowed not to have an xt for EXIT, i.e. through
> their interpretation, you are right - >R is the same case.
> 
> However: The interpretation semantics is what the Forth interpreter
> does with a word.  There is an obvious reason why
> 
>: int>r ( n -- r:n )  ['] >r execute ;
> 
> doesn't make >r work on the interpreter: It is a definition with an
> unbalanced stack effect.  But in terms of what the standard actually
> specifies (TC interpreations non-withstanding), I would think that [']
> >R EXECUTE is indeed equivalent to >R inside a definition. The reason
> why >R has no interpretation semantics is that the interpreter quite
> likely uses the return stack, and >R therefore can't work.
> 
> To be honest, this is all a mess, needs to be fixed, and in fact, >R
> does quite often not have execution semantics, but only run-time
> semantics. In bigForth, e.g., >R is immediate, because this is
> necessary for the shared locals and return stack. Even a non-immediate
> >R would not work, because that one is a macro which just generates
> the code for >R. EXECUTE is an indirect call, and therefore modifies
> the return stack, so >R would conflict. It *is* possible to have a
> working >R with ['] >R EXECUTE in a native code system, though (the
> executed part just needs to first pop the return address, then do the
> >R, and then return to the popped address), but this requires a smart
> COMPILE, or similar. In bigForth my conclusion was certainly "not
> worth the effort", in Gforth, the effort is less (threaded code), and
> we even decided to have interpretation semantics, but it must be
> balanced within one line. The reason we can do this is because in
> Gforth, the EXECUTE happens within the main interpreter loop, so the
> return stack is free to use within that loop (within one line).
> 
> I think we have agreed that we need to fix the definitions for the
> various semantics to remove known inconsistencies, and to adjust some
> words' definitions. Especially those with return stack effects, as
> they all don't have full execution semantics, only run-time semantics.
> 

Seconded. One of my issues is the lack of clarity with these "semantics".

Where (and when) do we start?  

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

#25992

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> You can't tick and execute >R.
>> 
>> This is implied because of the interpretation semantics of >R:
>> 
>>  6.1.0580 >R
>>          Interpretation semantics for this word are undefined.
>> 
>> So, >R has only compilation semantics.
> 
> I don't think that is conclusive.  It has execution semantics, if you can't 
> ' and execute it, having exection semantics is the wrong label, don't you 
> think?  If you look at 3.4.3.1, you see that there are two ways to get 
> execution semantics: Either by compiling code into a word, or by obtaining 
> the xt and executing it.  So if something has execution semantics, I would 
> conclude that both obtaining the xt and executing it should work.

Not necessarily:

4.1.2 Ambiguous conditions

attempting to obtain the execution token, (e.g., with 6.1.0070 ',
6.1.1550 FIND, etc.) of a definition with undefined interpretation
semantics;

So, you have to decide what your implementation does.

> It *is* possible to have a working >R with ['] >R EXECUTE in a
> native code system, though (the executed part just needs to first
> pop the return address, then do the >R, and then return to the
> popped address), but this requires a smart COMPILE, or similar.

In a threaded-code system,  ['] >R EXECUTE  should just work.

> I think we have agreed that we need to fix the definitions for the
> various semantics to remove known inconsistencies, and to adjust
> some words' definitions.  Especially those with return stack
> effects, as they all don't have full execution semantics, only
> run-time semantics.

But what is "run-time semantics" ?  Don't we have enough kinds of
semantics already?

Andrew.

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

#25993

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>4.1.2 Ambiguous conditions
>
>attempting to obtain the execution token, (e.g., with 6.1.0070 ',
>6.1.1550 FIND, etc.) of a definition with undefined interpretation
>semantics;

I think it's a problem that this is not mentioned as ambiguous
condition in ' ['] FIND SEARCH-WORDLIST.

>But what is "run-time semantics" ?  Don't we have enough kinds of
>semantics already?

"Run-time semantics" occurs in various words that have compilation
semantics (e.g., IF).  It describes what the code compiled by the
compilation semantics does at run-time.  It's a helper for defining
compilation semantics, so not every word has such a section (not even
through a default mechanism).

We could define >R etc. in this way, e.g.:

>R 

 Interpretation: Interpretation semantics for this word are undefined.

 Compilation: ( -- )
  Compile the run-time semantics below

 Run-time: ( x -- ) ( R:  -- x )
  Move x to the return stack.

- 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 2013: http://www.euroforth.org/ef13/

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

#25999

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>4.1.2 Ambiguous conditions
>>
>>attempting to obtain the execution token, (e.g., with 6.1.0070 ',
>>6.1.1550 FIND, etc.) of a definition with undefined interpretation
>>semantics;
> 
> I think it's a problem that this is not mentioned as ambiguous
> condition in ' ['] FIND SEARCH-WORDLIST.
> 
>>But what is "run-time semantics" ?  Don't we have enough kinds of
>>semantics already?
> 
> "Run-time semantics" occurs in various words that have compilation
> semantics (e.g., IF).  It describes what the code compiled by the
> compilation semantics does at run-time.  It's a helper for defining
> compilation semantics, so not every word has such a section (not even
> through a default mechanism).
> 
> We could define >R etc. in this way, e.g.:
> 
>>R 
> 
> Interpretation: Interpretation semantics for this word are undefined.
> 
> Compilation: ( -- )
>  Compile the run-time semantics below
> 
> Run-time: ( x -- ) ( R:  -- x )
>  Move x to the return stack.

That seems to me to be unneceearily complicated when the traditional
definition could have been

>R ( x -- ) ( R:  -- x )
    Move x to the return stack.

I agree there are some problems with that, but surely the standard
should not be so obscure.

Andrew.

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

#26004

Andrew Haley wrote:
> That seems to me to be unneceearily complicated when the traditional
> definition could have been
> 
>>R ( x -- ) ( R:  -- x )
>     Move x to the return stack.
> 
> I agree there are some problems with that, but surely the standard
> should not be so obscure.

With the right formalism in place, it should be sufficient to say

>R ( x -- ) ( R: -- x )
Run-time: Move x to the return stack.

The formalism is: Default compilation semantics is append run-time.  If only 
run-time is specified, interpretation and execution semantics are undefined 
(a non-definition by definition is "undefined").  If there's no label what 
is specified, it is a "normal" word, which is interpretation=execution=run-
time semantics + default compilation semantics.  There are some implications 
following the "standard interpreter" design.

Shouldn't be that difficult to reduce the amount of boilerplate *and* at the 
same time being more easy to understand.  Forth-83 and before had flags, 
which was too implementation specific, Forth-94 introduced semantics, which 
was a good idea, but there is room for improvement.  As we are programming 
Forth, "less boilerplate" is good.  More clarity is a must.  Descriptions 
which result in hairsplitting are wrong (by being "bad documentation").

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

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

#25994

Andrew Haley wrote:
> Not necessarily:
> 
> 4.1.2 Ambiguous conditions
> 
> attempting to obtain the execution token, (e.g., with 6.1.0070 ',
> 6.1.1550 FIND, etc.) of a definition with undefined interpretation
> semantics;
> 
> So, you have to decide what your implementation does.

If we accept that

BL WORD FIND ... 0> IF EXECUTE ELSE COMPILE, THEN

is a standard way to define the compiler of a Forth system, then you ought 
to be able to get an xt of >R, at least with FIND. Either this xt is for 
EXECUTE (when it's immediate) or for COMPILE, when it's not. Regardless, you 
can obtain an xt with FIND, and when that is an xt from a word with 
execution semantics, I would think that it should be possible to execute it, 
even though it might not be useful in the outer interpreter.

I'm pretty much in agreement with Stephen Pelc that you shoul not need 
Spock's ears and Data's memory to deduce what the standard actually means. 
This should be much more straight-forward.  If you can't EXECUTE a word, the 
standard should not devine an execution semantics.

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

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

#26000

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
>> Not necessarily:
>> 
>> 4.1.2 Ambiguous conditions
>> 
>> attempting to obtain the execution token, (e.g., with 6.1.0070 ',
>> 6.1.1550 FIND, etc.) of a definition with undefined interpretation
>> semantics;
>> 
>> So, you have to decide what your implementation does.
> 
> If we accept that
> 
> BL WORD FIND ... 0> IF EXECUTE ELSE COMPILE, THEN
> 
> is a standard way to define the compiler of a Forth system, then you ought 
> to be able to get an xt of >R, at least with FIND.

Yes.  But that's not what it says.

> Either this xt is for EXECUTE (when it's immediate) or for COMPILE,
> when it's not. Regardless, you can obtain an xt with FIND, and when
> that is an xt from a word with execution semantics, I would think
> that it should be possible to execute it, even though it might not
> be useful in the outer interpreter.

Indeed.

> I'm pretty much in agreement with Stephen Pelc that you shoul not
> need Spock's ears and Data's memory to deduce what the standard
> actually means.  This should be much more straight-forward.  If you
> can't EXECUTE a word, the standard should not devine an execution
> semantics.

Probably not.

Andrew.

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

#25982

On Mon, 23 Sep 2013 15:32:02 -0400, Lauri Alanko <la@iki.fi> wrote:

> Are execution tokens for primitive return stack operations (r>, r@, >r
> etc.) supposed to be usable? I.e. is this legal?
>
> : foo >r ['] r> execute . ;
> 42 foo
>
> On gforth this outputs 42, but I'm wondering if this is something that
> can be commonly relied on.
>
> I remember being a while ago concerned that supporting this would
> complicate the implementation of primitive execution tokens, but then
> I found out that the above situation doesn't actually need to be
> supported. However, now that I scan the Forth 200x draft, I cannot
> find where I got that idea from.
>
> Could someone clarify what the standard (and common practice)
> dictates? Thanks.
>


Results for a few Windows Forths:

gForth (0.7.0 ITC)
   works

bigForth (1.4.0)
   fails

Win32Forth (6.14.02)
   works


Results for a few old DOS Forths:

eForth (6 flavors)
  eForth (v1.0)
   doesn't recognize [']
   works when ['] is defined
  eForth (v1.01 86v2)
   doesn't recognize [']
   works when ['] is defined
  eForth (v1.01 86v1)
   doesn't recognize [']
   works when ['] is defined
  eForth (ITC16i)
   works
  eForth (bFORTH 80x86 v1.02)
   works
  eForth (86eForth v2.2)
   doesn't recognize [']
   works when ['] is defined

CamelForth (v1.0)
  works

TCOM (2.50)
  accepts definition
  executes without failure
  doesn't emit value
  inccorectly complains about using EXECUTE in INTERPRET mode upon upon exit
  calling this a fail...

SPF (4.00 build 016)
  works

RetroForth
  doesn't recognize >R
  doesn't recognize R>
  doesn't recognize EXECUTE
  etc...
  unable to test

BB4WForth (0.38)
  works

ATLast
  works

This4th
  fails

8088 Fig-forth (1.0)
  doesn't recognize [']
  not sure how to define a working ['] for it...
  unable to test

F83 (2.1.0)
  works

ZimmerForth (8.111F)
  works

F-PC (3.60)
  works

MiniForth
  doesn't recognize [']
  doesn't recognize ' (tick)
  doesn't recognize [COMPILE]
  has no IMMEDIATE word but has functionality
  etc...
  unable to test

HTH,


Rod Pemberton

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

#25984

On 9/23/13 9:32 AM, Lauri Alanko wrote:
> Hello.
>
> Are execution tokens for primitive return stack operations (r>, r@, >r
> etc.) supposed to be usable? I.e. is this legal?
>
> : foo >r ['] r> execute . ;
> 42 foo
>
> On gforth this outputs 42, but I'm wondering if this is something that
> can be commonly relied on.
>
> I remember being a while ago concerned that supporting this would
> complicate the implementation of primitive execution tokens, but then
> I found out that the above situation doesn't actually need to be
> supported. However, now that I scan the Forth 200x draft, I cannot
> find where I got that idea from.
>
> Could someone clarify what the standard (and common practice)
> dictates? Thanks.

Others are addressing your technical question, but I'm curious as to why 
on earth you want to do this?

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."
==================================================

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

#25985

In article <_umdndyUjubJXt3PnZ2dnUVZ_jydnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
> On 9/23/13 9:32 AM, Lauri Alanko wrote:
> > Hello.
> >
> > Are execution tokens for primitive return stack operations (r>, r@, >r
> > etc.) supposed to be usable? I.e. is this legal?
> >
> > : foo >r ['] r> execute . ;
> > 42 foo

> Others are addressing your technical question, but I'm curious as to why 
> on earth you want to do this?

Oh, I don't want to do this. I'm writing a toy implementation and I
wanted to know if it would need to support this case. I'm glad that
the consensus seems to be negative.


Lauri

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

#25986

On Mon, 23 Sep 2013, Lauri Alanko wrote:

> Date: Mon, 23 Sep 2013 22:43:10 +0000 (UTC)
> From: Lauri Alanko <la@iki.fi>
> Newsgroups: comp.lang.forth
> Subject: Re: Execution tokens for return stack manipulation
> 
> In article <_umdndyUjubJXt3PnZ2dnUVZ_jydnZ2d@supernews.com>,
> Elizabeth D. Rather <erather@forth.com> wrote:
>> On 9/23/13 9:32 AM, Lauri Alanko wrote:
>>> Hello.
>>>
>>> Are execution tokens for primitive return stack operations (r>, r@, >r
>>> etc.) supposed to be usable? I.e. is this legal?
>>>
>>> : foo >r ['] r> execute . ;
>>> 42 foo
>
>> Others are addressing your technical question, but I'm curious as to why
>> on earth you want to do this?
>
> Oh, I don't want to do this. I'm writing a toy implementation and I
> wanted to know if it would need to support this case. I'm glad that
> the consensus seems to be negative.
>
>
> Lauri
>

Heh heh ... Well done!  Of course Elizabeth might try to talk you out of 
it 8-P

Cheers,
Rob.

[toc] | [prev] | [standalone]

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

csiph-web