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

Groups > comp.lang.forth > #26004

Re: Execution tokens for return stack manipulation

Show all headers | View raw

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/

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web