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

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

A poor mans memoizer.

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

Contents

  A poor mans memoizer. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-02 12:37 +0000
    Re: A poor mans memoizer. the_gavino_himself <visphatesjava@gmail.com> - 2014-12-02 05:37 -0800
    Re: A poor mans memoizer. "Elizabeth D. Rather" <erather@forth.com> - 2014-12-02 08:52 -1000
      Re: A poor mans memoizer. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-03 13:17 +0000
        Re: A poor mans memoizer. "Elizabeth D. Rather" <erather@forth.com> - 2014-12-03 09:07 -1000
          Re: A poor mans memoizer. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-04 09:08 +0000
            Re: A poor mans memoizer. Paul Rubin <no.email@nospam.invalid> - 2014-12-04 12:42 -0800
              Re: A poor mans memoizer. stephen@mpeforth.com (Stephen Pelc) - 2014-12-05 12:18 +0000
          Re: A poor mans memoizer. Mark Wills <markwills1970@gmail.com> - 2014-12-04 03:47 -0800
            Re: A poor mans memoizer. "Elizabeth D. Rather" <erather@forth.com> - 2014-12-04 08:43 -1000
        Re: A poor mans memoizer. mhx@iae.nl - 2014-12-03 14:47 -0800
          Re: A poor mans memoizer. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-04 09:31 +0000
            Re: A poor mans memoizer. "Elizabeth D. Rather" <erather@forth.com> - 2014-12-04 08:58 -1000
              Re: A poor mans memoizer. albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-05 12:11 +0000
                van der Horsts Stallman convention (was: A poor mans memoizer.) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-12-05 12:23 +0000
                  Re: van der Horsts Stallman convention "Elizabeth D. Rather" <erather@forth.com> - 2014-12-05 09:01 -1000
                  Re: van der Horsts Stallman convention (was: A poor mans memoizer.) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-12-06 10:06 +0000
        Re: A poor mans memoizer. Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-12-04 10:19 +0000
          Should Forth Be Recommended Here? Celeros <kern000@gmail.com> - 2014-12-05 11:42 +0200
            Re: Should Forth Be Recommended Here? Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-12-05 14:54 +0000
      Re: A poor mans memoizer. Rob Sciuk <rob@controlq.com> - 2014-12-05 14:08 -0500

Page 1 of 2  [1] 2  Next page →

#34751 — A poor mans memoizer.

The BAG utility and coroutine calls allow for a very
simple memoizer. A memoizer is a help that returns
values, if they are already known by previous
calculation. This happens all the time in a (brain damaged)
recursive Fibonacci calculation.

It is again a one screener.

\ -------------------------------------------------------------
( memoize                                       ) \ AvdHB4mar18
WANT BAG                WANT BAG-WHERE
1000 CONSTANT CSIZE
CSIZE BAG keys          CSIZE BAG values
keys !BAG               values !BAG
\ The memoizer works on a one input one output function.
: memoize DUP keys BAG-WHERE DUP IF NIP keys - values + @
  RDROP ELSE  DROP DUP   CO   SWAP keys BAG+!
  DUP values BAG+! THEN ;


\ -------------------------------------------------------------

:keys" and "values" are parallel arrays, a technique often used
in early FORTRAN before there where structs. It means that
related items have the same offset.


This is an example of usage, simply put memoize as the first word
in your word with (n --n ) stack diagram.

(Fibonacci numbers, again).
: fib DUP 2 <  IF DROP  1 EXIT THEN DUP 1- RECURSE SWAP
    2 -  RECURSE + ;
: fib2 memoize DUP 2 <  IF DROP  1 EXIT THEN DUP 1- RECURSE SWAP
    2 -  RECURSE + ;

WANT FORMAT
WANT MARK-TIME
keys !BAG
values !BAG
MARK-TIME 35 fib . CR
ELAPSED  35 "For the %d fib, it takes %d microseconds.%n" .FORMAT
MARK-TIME 35 fib2 . CR
ELAPSED  35 "For the %d fib, memoized it takes %d microsec'.%n" .FORMAT


Some tips:

In quite a few systems CO may be defined as
: CO R> R> DROP >R ;

For those who don't yet have stolen bags from the ciforth
library:

\-------------------------
( BAG !BAG BAG? BAG+! BAG@- BAG-REMOVE BAG-HOLE BAG-INSERT )
\ Warning uses $@ as as @+
( Build a bag with X items. )
: BUILD-BAG   HERE CELL+ , CELLS ALLOT ;
( Create a bag "x" with X items. )
: BAG   CREATE HERE CELL+ , CELLS ALLOT DOES> ;
: !BAG   DUP CELL+ SWAP ! ;   ( Make the BAG empty )
: BAG?   $@ = 0= ;   ( For the BAG : it IS non-empty )
: BAG+!   DUP >R @ ! 0 CELL+ R> +! ;   ( Push ITEM to the BAG )
: BAG@- 0 CELL+ NEGATE OVER +! @ @ ;   ( From BAG: pop ITEM )
: BAG-REMOVE    ( Remove entry at ADDRESS from BAG. )
>R   DUP CELL+ SWAP  OVER R@ @ SWAP -   MOVE -1   CELLS R> +! ;
: BAG-HOLE      ( Make hole at ADDRESS in BAG. )
>R   DUP CELL+   OVER R@ @ SWAP -   MOVE   0 CELL+ R> +! ;
( Insert VALUE at ADDRESS in BAG. )
: BAG-INSERT   OVER SWAP BAG-HOLE   ! ;
( |BAG| DO-BAG .BAG BAG-WHERE IN-BAG? BAG- SET+ SET- ) \ AvdH
: |BAG|   $@ SWAP - 0 CELL+ / ; ( For BAG : NUMBER of items )
\ Loop over a bag, see ``.BAG'' for an example.
: DO-BAG  POSTPONE $@ POSTPONE SWAP POSTPONE ?DO ; IMMEDIATE
: LOOP-BAG 0 CELL+ POSTPONE LITERAL POSTPONE +LOOP ; IMMEDIATE
: .BAG   DO-BAG I ? LOOP-BAG ; ( Print BAG )
( For VALUE and BAG : ADDRESS of value in bag/nill.)
: BAG-WHERE DO-BAG DUP I @ = IF DROP I UNLOOP EXIT THEN
    LOOP-BAG  DROP 0 ;
( For VALUE and BAG : value IS present in bag.)
: IN-BAG? BAG-WHERE 0= 0= ;
( Remove VALUE from BAG. )
: BAG-   DUP >R   BAG-WHERE   R> BAG-REMOVE ;
( Add/remove VALUE to bag, used as a SET, i.e. no duplicates.)
: SET+   2DUP IN-BAG? IF 2DROP ELSE BAG+! THEN ;
: SET-   2DUP IN-BAG? IF BAG- ELSE 2DROP THEN ;
\-------------------------

Oh, and this is the result of the test:

14930352
For the 35 fib, it takes 1801359 microseconds.
14930352
For the 35 fib, memoized it takes 182 microseconds.

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] | [next] | [standalone]

#34756

On Tuesday, December 2, 2014 7:37:21 AM UTC-5, Albert van der Horst wrote:
> The BAG utility and coroutine calls allow for a very
> simple memoizer. A memoizer is a help that returns
> values, if they are already known by previous
> calculation. This happens all the time in a (brain damaged)
> recursive Fibonacci calculation.
> 
> It is again a one screener.
> 
> \ -------------------------------------------------------------
> ( memoize                                       ) \ AvdHB4mar18
> WANT BAG                WANT BAG-WHERE
> 1000 CONSTANT CSIZE
> CSIZE BAG keys          CSIZE BAG values
> keys !BAG               values !BAG
> \ The memoizer works on a one input one output function.
> : memoize DUP keys BAG-WHERE DUP IF NIP keys - values + @
>   RDROP ELSE  DROP DUP   CO   SWAP keys BAG+!
>   DUP values BAG+! THEN ;
> 
> 
> \ -------------------------------------------------------------
> 
> :keys" and "values" are parallel arrays, a technique often used
> in early FORTRAN before there where structs. It means that
> related items have the same offset.
> 
> 
> This is an example of usage, simply put memoize as the first word
> in your word with (n --n ) stack diagram.
> 
> (Fibonacci numbers, again).
> : fib DUP 2 <  IF DROP  1 EXIT THEN DUP 1- RECURSE SWAP
>     2 -  RECURSE + ;
> : fib2 memoize DUP 2 <  IF DROP  1 EXIT THEN DUP 1- RECURSE SWAP
>     2 -  RECURSE + ;
> 
> WANT FORMAT
> WANT MARK-TIME
> keys !BAG
> values !BAG
> MARK-TIME 35 fib . CR
> ELAPSED  35 "For the %d fib, it takes %d microseconds.%n" .FORMAT
> MARK-TIME 35 fib2 . CR
> ELAPSED  35 "For the %d fib, memoized it takes %d microsec'.%n" .FORMAT
> 
> 
> Some tips:
> 
> In quite a few systems CO may be defined as
> : CO R> R> DROP >R ;
> 
> For those who don't yet have stolen bags from the ciforth
> library:
> 
> \-------------------------
> ( BAG !BAG BAG? BAG+! BAG@- BAG-REMOVE BAG-HOLE BAG-INSERT )
> \ Warning uses $@ as as @+
> ( Build a bag with X items. )
> : BUILD-BAG   HERE CELL+ , CELLS ALLOT ;
> ( Create a bag "x" with X items. )
> : BAG   CREATE HERE CELL+ , CELLS ALLOT DOES> ;
> : !BAG   DUP CELL+ SWAP ! ;   ( Make the BAG empty )
> : BAG?   $@ = 0= ;   ( For the BAG : it IS non-empty )
> : BAG+!   DUP >R @ ! 0 CELL+ R> +! ;   ( Push ITEM to the BAG )
> : BAG@- 0 CELL+ NEGATE OVER +! @ @ ;   ( From BAG: pop ITEM )
> : BAG-REMOVE    ( Remove entry at ADDRESS from BAG. )
> >R   DUP CELL+ SWAP  OVER R@ @ SWAP -   MOVE -1   CELLS R> +! ;
> : BAG-HOLE      ( Make hole at ADDRESS in BAG. )
> >R   DUP CELL+   OVER R@ @ SWAP -   MOVE   0 CELL+ R> +! ;
> ( Insert VALUE at ADDRESS in BAG. )
> : BAG-INSERT   OVER SWAP BAG-HOLE   ! ;
> ( |BAG| DO-BAG .BAG BAG-WHERE IN-BAG? BAG- SET+ SET- ) \ AvdH
> : |BAG|   $@ SWAP - 0 CELL+ / ; ( For BAG : NUMBER of items )
> \ Loop over a bag, see ``.BAG'' for an example.
> : DO-BAG  POSTPONE $@ POSTPONE SWAP POSTPONE ?DO ; IMMEDIATE
> : LOOP-BAG 0 CELL+ POSTPONE LITERAL POSTPONE +LOOP ; IMMEDIATE
> : .BAG   DO-BAG I ? LOOP-BAG ; ( Print BAG )
> ( For VALUE and BAG : ADDRESS of value in bag/nill.)
> : BAG-WHERE DO-BAG DUP I @ = IF DROP I UNLOOP EXIT THEN
>     LOOP-BAG  DROP 0 ;
> ( For VALUE and BAG : value IS present in bag.)
> : IN-BAG? BAG-WHERE 0= 0= ;
> ( Remove VALUE from BAG. )
> : BAG-   DUP >R   BAG-WHERE   R> BAG-REMOVE ;
> ( Add/remove VALUE to bag, used as a SET, i.e. no duplicates.)
> : SET+   2DUP IN-BAG? IF 2DROP ELSE BAG+! THEN ;
> : SET-   2DUP IN-BAG? IF BAG- ELSE 2DROP THEN ;
> \-------------------------
> 
> Oh, and this is the result of the test:
> 
> 14930352
> For the 35 fib, it takes 1801359 microseconds.
> 14930352
> For the 35 fib, memoized it takes 182 microseconds.
> 
> 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

sounds useful for a web server

economic growth in unregulated capitalism is steady
no fed or pensions distorting market causing bad investments

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

#34761

On 12/2/14 2:37 AM, Albert van der Horst wrote:
> The BAG utility and coroutine calls allow for a very
> simple memoizer. A memoizer is a help that returns
> values, if they are already known by previous
> calculation. This happens all the time in a (brain damaged)
> recursive Fibonacci calculation.
>
> It is again a one screener.
>
> \ -------------------------------------------------------------
> ( memoize                                       ) \ AvdHB4mar18
> WANT BAG                WANT BAG-WHERE
> 1000 CONSTANT CSIZE
> CSIZE BAG keys          CSIZE BAG values
> keys !BAG               values !BAG
> \ The memoizer works on a one input one output function.
> : memoize DUP keys BAG-WHERE DUP IF NIP keys - values + @
>    RDROP ELSE  DROP DUP   CO   SWAP keys BAG+!
>    DUP values BAG+! THEN ;
>
>
> \ -------------------------------------------------------------
>
> :keys" and "values" are parallel arrays, a technique often used
> in early FORTRAN before there where structs. It means that
> related items have the same offset.
>
>
> This is an example of usage, simply put memoize as the first word
> in your word with (n --n ) stack diagram.
>
> (Fibonacci numbers, again).
> : fib DUP 2 <  IF DROP  1 EXIT THEN DUP 1- RECURSE SWAP
>      2 -  RECURSE + ;
> : fib2 memoize DUP 2 <  IF DROP  1 EXIT THEN DUP 1- RECURSE SWAP
>      2 -  RECURSE + ;
>
> WANT FORMAT
> WANT MARK-TIME
> keys !BAG
> values !BAG
> MARK-TIME 35 fib . CR
> ELAPSED  35 "For the %d fib, it takes %d microseconds.%n" .FORMAT
> MARK-TIME 35 fib2 . CR
> ELAPSED  35 "For the %d fib, memoized it takes %d microsec'.%n" .FORMAT
>
>
> Some tips:
>
> In quite a few systems CO may be defined as
> : CO R> R> DROP >R ;
>
> For those who don't yet have stolen bags from the ciforth
> library:
>
> \-------------------------
> ( BAG !BAG BAG? BAG+! BAG@- BAG-REMOVE BAG-HOLE BAG-INSERT )
> \ Warning uses $@ as as @+
> ( Build a bag with X items. )
> : BUILD-BAG   HERE CELL+ , CELLS ALLOT ;
> ( Create a bag "x" with X items. )
> : BAG   CREATE HERE CELL+ , CELLS ALLOT DOES> ;
> : !BAG   DUP CELL+ SWAP ! ;   ( Make the BAG empty )
> : BAG?   $@ = 0= ;   ( For the BAG : it IS non-empty )
> : BAG+!   DUP >R @ ! 0 CELL+ R> +! ;   ( Push ITEM to the BAG )
> : BAG@- 0 CELL+ NEGATE OVER +! @ @ ;   ( From BAG: pop ITEM )
> : BAG-REMOVE    ( Remove entry at ADDRESS from BAG. )
>> R   DUP CELL+ SWAP  OVER R@ @ SWAP -   MOVE -1   CELLS R> +! ;
> : BAG-HOLE      ( Make hole at ADDRESS in BAG. )
>> R   DUP CELL+   OVER R@ @ SWAP -   MOVE   0 CELL+ R> +! ;
> ( Insert VALUE at ADDRESS in BAG. )
> : BAG-INSERT   OVER SWAP BAG-HOLE   ! ;
> ( |BAG| DO-BAG .BAG BAG-WHERE IN-BAG? BAG- SET+ SET- ) \ AvdH
> : |BAG|   $@ SWAP - 0 CELL+ / ; ( For BAG : NUMBER of items )
> \ Loop over a bag, see ``.BAG'' for an example.
> : DO-BAG  POSTPONE $@ POSTPONE SWAP POSTPONE ?DO ; IMMEDIATE
> : LOOP-BAG 0 CELL+ POSTPONE LITERAL POSTPONE +LOOP ; IMMEDIATE
> : .BAG   DO-BAG I ? LOOP-BAG ; ( Print BAG )
> ( For VALUE and BAG : ADDRESS of value in bag/nill.)
> : BAG-WHERE DO-BAG DUP I @ = IF DROP I UNLOOP EXIT THEN
>      LOOP-BAG  DROP 0 ;
> ( For VALUE and BAG : value IS present in bag.)
> : IN-BAG? BAG-WHERE 0= 0= ;
> ( Remove VALUE from BAG. )
> : BAG-   DUP >R   BAG-WHERE   R> BAG-REMOVE ;
> ( Add/remove VALUE to bag, used as a SET, i.e. no duplicates.)
> : SET+   2DUP IN-BAG? IF 2DROP ELSE BAG+! THEN ;
> : SET-   2DUP IN-BAG? IF BAG- ELSE 2DROP THEN ;
> \-------------------------
>
> Oh, and this is the result of the test:
>
> 14930352
> For the 35 fib, it takes 1801359 microseconds.
> 14930352
> For the 35 fib, memoized it takes 182 microseconds.
>
> Groetjes Albert

*sigh* No stack comments anywhere. Very hard to read, even though the 
definitions are short and look well-factored, because it's unclear what 
the inputs and outputs are.

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]

#34764

In article <LfCdnVD5DKD3l-PJnZ2dnUU7-c2dnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 12/2/14 2:37 AM, Albert van der Horst wrote:
>> The BAG utility and coroutine calls allow for a very
>> simple memoizer. A memoizer is a help that returns
>> values, if they are already known by previous
>> calculation. This happens all the time in a (brain damaged)
>> recursive Fibonacci calculation.
>>
>> It is again a one screener.
>>
>> \ -------------------------------------------------------------
>> ( memoize                                       ) \ AvdHB4mar18
>> WANT BAG                WANT BAG-WHERE
>> 1000 CONSTANT CSIZE
>> CSIZE BAG keys          CSIZE BAG values
>> keys !BAG               values !BAG
>> \ The memoizer works on a one input one output function.
>> : memoize DUP keys BAG-WHERE DUP IF NIP keys - values + @
>>    RDROP ELSE  DROP DUP   CO   SWAP keys BAG+!
>>    DUP values BAG+! THEN ;
>>
>>
>> \ -------------------------------------------------------------
>>
>> :keys" and "values" are parallel arrays, a technique often used
>> in early FORTRAN before there where structs. It means that
>> related items have the same offset.
>>
>>
>> This is an example of usage, simply put memoize as the first word
>> in your word with (n --n ) stack diagram.
>>
>> (Fibonacci numbers, again).
>> : fib DUP 2 <  IF DROP  1 EXIT THEN DUP 1- RECURSE SWAP
>>      2 -  RECURSE + ;
>> : fib2 memoize DUP 2 <  IF DROP  1 EXIT THEN DUP 1- RECURSE SWAP
>>      2 -  RECURSE + ;
>>
>> WANT FORMAT
>> WANT MARK-TIME
>> keys !BAG
>> values !BAG
>> MARK-TIME 35 fib . CR
>> ELAPSED  35 "For the %d fib, it takes %d microseconds.%n" .FORMAT
>> MARK-TIME 35 fib2 . CR
>> ELAPSED  35 "For the %d fib, memoized it takes %d microsec'.%n" .FORMAT
>>
>>
>> Some tips:
>>
>> In quite a few systems CO may be defined as
>> : CO R> R> DROP >R ;
>>
>> For those who don't yet have stolen bags from the ciforth
>> library:
>>
>> \-------------------------
>> ( BAG !BAG BAG? BAG+! BAG@- BAG-REMOVE BAG-HOLE BAG-INSERT )
>> \ Warning uses $@ as as @+
>> ( Build a bag with X items. )
>> : BUILD-BAG   HERE CELL+ , CELLS ALLOT ;
>> ( Create a bag "x" with X items. )
>> : BAG   CREATE HERE CELL+ , CELLS ALLOT DOES> ;
>> : !BAG   DUP CELL+ SWAP ! ;   ( Make the BAG empty )
>> : BAG?   $@ = 0= ;   ( For the BAG : it IS non-empty )
>> : BAG+!   DUP >R @ ! 0 CELL+ R> +! ;   ( Push ITEM to the BAG )
>> : BAG@- 0 CELL+ NEGATE OVER +! @ @ ;   ( From BAG: pop ITEM )
>> : BAG-REMOVE    ( Remove entry at ADDRESS from BAG. )
>>> R   DUP CELL+ SWAP  OVER R@ @ SWAP -   MOVE -1   CELLS R> +! ;
>> : BAG-HOLE      ( Make hole at ADDRESS in BAG. )
>>> R   DUP CELL+   OVER R@ @ SWAP -   MOVE   0 CELL+ R> +! ;
>> ( Insert VALUE at ADDRESS in BAG. )
>> : BAG-INSERT   OVER SWAP BAG-HOLE   ! ;
>> ( |BAG| DO-BAG .BAG BAG-WHERE IN-BAG? BAG- SET+ SET- ) \ AvdH
>> : |BAG|   $@ SWAP - 0 CELL+ / ; ( For BAG : NUMBER of items )
>> \ Loop over a bag, see ``.BAG'' for an example.
>> : DO-BAG  POSTPONE $@ POSTPONE SWAP POSTPONE ?DO ; IMMEDIATE
>> : LOOP-BAG 0 CELL+ POSTPONE LITERAL POSTPONE +LOOP ; IMMEDIATE
>> : .BAG   DO-BAG I ? LOOP-BAG ; ( Print BAG )
>> ( For VALUE and BAG : ADDRESS of value in bag/nill.)
>> : BAG-WHERE DO-BAG DUP I @ = IF DROP I UNLOOP EXIT THEN
>>      LOOP-BAG  DROP 0 ;
>> ( For VALUE and BAG : value IS present in bag.)
>> : IN-BAG? BAG-WHERE 0= 0= ;
>> ( Remove VALUE from BAG. )
>> : BAG-   DUP >R   BAG-WHERE   R> BAG-REMOVE ;
>> ( Add/remove VALUE to bag, used as a SET, i.e. no duplicates.)
>> : SET+   2DUP IN-BAG? IF 2DROP ELSE BAG+! THEN ;
>> : SET-   2DUP IN-BAG? IF BAG- ELSE 2DROP THEN ;
>> \-------------------------
>>
>> Oh, and this is the result of the test:
>>
>> 14930352
>> For the 35 fib, it takes 1801359 microseconds.
>> 14930352
>> For the 35 fib, memoized it takes 182 microseconds.
>>
>> Groetjes Albert
>
>*sigh* No stack comments anywhere. Very hard to read, even though the
>definitions are short and look well-factored, because it's unclear what
>the inputs and outputs are.

The BAG is in library format, i.e. it is intended
to be loaded. It is not part of the memoization I
present and not intended to be documented or discussed.

But ..

There are stack comments, but not in a format
familiar to you. My stack comments reveal more about the
actual working of the words than the silly (my opinion!)
( n n -- ud ) diagrams.

What is unclear about

( For VALUE and BAG : ADDRESS of value in bag/nill.)

If I compress that to ( n addr -- addr ) are you happy?

Let's see:
I use
BAG ( Create a bag "x" with X items. )
!BAG  ( Make the BAG empty )
BAG-WHERE ( For VALUE and BAG : ADDRESS of value in bag/nill.)
BAG+!  ( Push ITEM to the BAG )

I'm pretty sure a competent Forther can recreate the
BAG-package inasfar needed for memoize from this spec in any
Forth in no time.

That is my goal, which only comes into play if just
clipping the BAG screens and load it fails.


>>
>Cheers,
>Elizabeth
-- 
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]

#34767

On 12/3/14 3:17 AM, Albert van der Horst wrote:
>> *sigh*  No stack comments anywhere. Very hard to read, even though the
>> >definitions are short and look well-factored, because it's unclear what
>> >the inputs and outputs are.
 >
> The BAG is in library format, i.e. it is intended
> to be loaded. It is not part of the memoization I
> present and not intended to be documented or discussed.

Does that mean it's not supplied in source? If there is source, stack 
comments are helpful. If not, somewhere you need detailed use documentation.

> But ..
>
> There are stack comments, but not in a format
> familiar to you. My stack comments reveal more about the
> actual working of the words than the silly (my opinion!)
> ( n n -- ud ) diagrams.
>
> What is unclear about
>
> ( For VALUE and BAG : ADDRESS of value in bag/nill.)
>
> If I compress that to ( n addr -- addr ) are you happy?

Actually, yes. The descriptive comment says what the items are. The 
"compressed" stack comment says exactly what's on the stack, what data 
type, and in what order. Both are needed.

> Let's see:
> I use
> BAG ( Create a bag "x" with X items. )
> !BAG  ( Make the BAG empty )
> BAG-WHERE ( For VALUE and BAG : ADDRESS of value in bag/nill.)
> BAG+!  ( Push ITEM to the BAG )
>
> I'm pretty sure a competent Forther can recreate the
> BAG-package inasfar needed for memoize from this spec in any
> Forth in no time.
>
> That is my goal, which only comes into play if just
> clipping the BAG screens and load it fails.

Yes, but "library code" needs to be readable by a ranger of Forthers, 
from "competent" to beginner.

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]

#34769

In article <oeudnQunCtXAwuLJnZ2dnUU7-bednZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 12/3/14 3:17 AM, Albert van der Horst wrote:
<SNIP>
>> What is unclear about
>>
>> ( For VALUE and BAG : ADDRESS of value in bag/nill.)
>>
>> If I compress that to ( n addr -- addr ) are you happy?
>
>Actually, yes. The descriptive comment says what the items are. The
>"compressed" stack comment says exactly what's on the stack, what data
>type, and in what order. Both are needed.

The Stallman convention translates trivially to a stack diagram:
For VALUE and BAG   :  ADDRESS of value in bag/nill.
    cell      cell  -- cell

From the usage it is clear that value can be anything. BAG is the
address of a word CREATEd by BAG, ADDRESS is such that @ will result
in  -- VALUE

So a separate stack diagram is not needed. In this way beginners
are not lured into the illusion that with a stack diagram they have
documented. Replacing ""-- sum" with "returns SUM over all odd primes
in the range 0 to n inclusive", also helps to realize that n can be
prime too but that it is not to be counted. The likes of Benett too
advocate to write down such a spec (or a more advanced version of
it) before implementing.

>Yes, but "library code" needs to be readable by a ranger of Forthers,
>from "competent" to beginner.

In my book library code needs to be understood by implementors.
Only the usage of library code needs to be understood by programmers,
be it beginner or advanced.

Trying to find usage information by reading code should not be
necessary.

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

#34781

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
> In my book library code needs to be understood by implementors.
> Only the usage of library code needs to be understood by programmers,

That isn't nice.  In a utopia, libraries would be well enough documented
for application programmers to figure out everything they need to
reading the manual.  In the real world, app programmers often have to
read library source code in order to understand how to use the
libraries.  In fact a chunk of the productivity gain of using FOSS
instead of closed-source software comes from precisely that ability.  So
it's preferable for language implementers to think of the libraries as a
showcase for how to use the language.

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

#34791

On Thu, 04 Dec 2014 12:42:36 -0800, Paul Rubin
<no.email@nospam.invalid> wrote:

>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> In my book library code needs to be understood by implementors.
>> Only the usage of library code needs to be understood by programmers,
>
>That isn't nice.  In a utopia, libraries would be well enough documented
>for application programmers to figure out everything they need to
>reading the manual.  In the real world, app programmers often have to
>read library source code in order to understand how to use the
>libraries.

Arguing that source is good for libraries is simply saying that the
documentation is inadequate. The solution is to improve the 
documentation, not to release the source code.

I read too much FOSS and proprietary code in C. The libraries for
which I only have to read the documentation and header files are
a great relief. The SQLite3 amalgamation is a model of how to do it.
Far too much FOSS code lacks documentation - this makes it difficult
to use.

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]

#34773

I like to use to some pre-amble comments that precede the 
word - just normal written English, not too wordy to give
an idea of what the does/is used for.

I also expand the stack sigs a little to be a little more
explicit. For example, a word that transmits a character
out of a serial port might be:

serial_send ( addr n -- )

Which, if your controller uses memory-mapped IO would be
technically accurate (addr representing the address of
the serial port to write to), but I would probably write
something like:

serial_send ( port_addr char -- )

...which I think is much more descriptive, but doesn't 
really adhere to any standard stack notation.

:-)

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

#34777

On 12/4/14 1:47 AM, Mark Wills wrote:
> I like to use to some pre-amble comments that precede the
> word - just normal written English, not too wordy to give
> an idea of what the does/is used for.
>
> I also expand the stack sigs a little to be a little more
> explicit. For example, a word that transmits a character
> out of a serial port might be:
>
> serial_send ( addr n -- )
>
> Which, if your controller uses memory-mapped IO would be
> technically accurate (addr representing the address of
> the serial port to write to), but I would probably write
> something like:
>
> serial_send ( port_addr char -- )
>
> ...which I think is much more descriptive, but doesn't
> really adhere to any standard stack notation.
>
>

More information is always a good thing. :-)

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]

#34768

On Wednesday, December 3, 2014 2:17:47 PM UTC+1, Albert van der Horst wrote:
> In article <LfCdnVD5DKD3l-PJnZ2dnUU7-c2dnZ2d@supernews.com>,
> Elizabeth D. Rather <erather@forth.com> wrote:
[..]
> There are stack comments, but not in a format
> familiar to you. My stack comments reveal more about the
> actual working of the words than the silly (my opinion!)
> ( n n -- ud ) diagrams.

The fact that Elizabeth is asking (and she is not the first
one to do so) should be cause for serious self-reflection.
 
> What is unclear about
> 
> ( For VALUE and BAG : ADDRESS of value in bag/nill.)
> 
> If I compress that to ( n addr -- addr ) are you happy?

The first sentence is complete nonsense (really!)  while the 
second is a standard Forth comment.
 
> Let's see:
> I use
> BAG ( Create a bag "x" with X items. )

I guess uppercase is significant. But why do you use
"x" and not "X", and why is it not `bag "NAME" with X items?'

> !BAG  ( Make the BAG empty )

Is BAG an input or an output? Is a bag a name ( "x" ) or some
token returned when a bag is created? (I now need to read the
definition of BAG and construct an hypothesis).
The convention is that "!" needs a number and an address which
sends me further into the woods. CLEAR-BAG ?  0BAG ? 0!BAG ?

> BAG-WHERE ( For VALUE and BAG : ADDRESS of value in bag/nill.)

You explained this above. It means ( n addr1 -- addr2 ). So executing
"x" apparently returns an address.

> BAG+!  ( Push ITEM to the BAG )

Is this ( n -- addr ) or ( n addr -- ) or ( n "x" -- ) ?
The main problem with your convention is that it is not clear
what is input or output. Apparently the ":" is not a convention.

! ( Add/remove VALUE to bag, used as a SET, i.e. no duplicates.) 
! : SET+   2DUP IN-BAG? IF 2DROP ELSE BAG+! THEN ; 
! : SET-   2DUP IN-BAG? IF BAG- ELSE 2DROP THEN ; 

It is clear from the code that there are at least two things
on the stack, but how does that relate to the uppercased 
"SET" ? This is literary style where you should have said 
VALUE and BAG, but as the BAG is used as a set, you cut out
some superfluous words (probably also because a screen has
limited line length and you didn't want two lines :-)

> I'm pretty sure a competent Forther can recreate the
> BAG-package inasfar needed for memoize from this spec in any
> Forth in no time.

A competent Forth programmer will recreate the bag faster
than s/he can understand your code. 

A competent Forth programmer would value your comments and
considerations (absent) a lot more than your actual code.
An (as yet) incompetent Forth programmer would need the stack
comments (absent) to be able to read and use the source.
 
Please note that I appreciate that you show this fine code.
Consider that is just possible that it is not documented in 
a superior way for all people. 

-marcel

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

#34770

In article <6a78ecbd-4518-468f-96c2-c5a1ebf5e58a@googlegroups.com>,
 <mhx@iae.nl> wrote:
>On Wednesday, December 3, 2014 2:17:47 PM UTC+1, Albert van der Horst wrote:
>> In article <LfCdnVD5DKD3l-PJnZ2dnUU7-c2dnZ2d@supernews.com>,
>> Elizabeth D. Rather <erather@forth.com> wrote:
>[..]
>> There are stack comments, but not in a format
>> familiar to you. My stack comments reveal more about the
>> actual working of the words than the silly (my opinion!)
>> ( n n -- ud ) diagrams.
>
>The fact that Elizabeth is asking (and she is not the first
>one to do so) should be cause for serious self-reflection.

No, not in this case. I've given this at least as much
thought as she has. Her arguments may shake me, but not
her authority.

>
>> What is unclear about
>>
>> ( For VALUE and BAG : ADDRESS of value in bag/nill.)
>>
>> If I compress that to ( n addr -- addr ) are you happy?
>
>The first sentence is complete nonsense (really!)  while the
>second is a standard Forth comment.

Return and : take the place of --. Uppercase values are
stack items be it input or output)
>
>> Let's see:
>> I use
>> BAG ( Create a bag "x" with X items. )
>
>I guess uppercase is significant. But why do you use
>"x" and not "X", and why is it not `bag "NAME" with X items?'
If you are asked to create box with 8 items, is 8 an input
or an output to you?
 If you try to understand the spec, instead
of expecting a stack diagram it becomes much clearer.

>
>> !BAG  ( Make the BAG empty )
>
>Is BAG an input or an output? Is a bag a name ( "x" ) or some
>token returned when a bag is created? (I now need to read the
>definition of BAG and construct an hypothesis).

Why wouldn't you ask this question if the defining word was
VARIABLE? Why would you in the sentence "Make the variable zero"
think that variable-the-defining-word is mend?

So I can make it clearer than that. You pass a bag on the stack
and then I make it empty for you.

>The convention is that "!" needs a number and an address which
>sends me further into the woods. CLEAR-BAG ?  0BAG ? 0!BAG ?
>
>> BAG-WHERE ( For VALUE and BAG : ADDRESS of value in bag/nill.)
>
>You explained this above. It means ( n addr1 -- addr2 ). So executing
>"x" apparently returns an address.
>
>> BAG+!  ( Push ITEM to the BAG )
>
>Is this ( n -- addr ) or ( n addr -- ) or ( n "x" -- ) ?
>The main problem with your convention is that it is not clear
>what is input or output. Apparently the ":" is not a convention.

All items are input, unless there it should be obvious that
there are returns like so:
  for X return its SQUARE
  for N:"It IS an even number"

Maybe I should have copied the Stallman convention,
because nobody remembers those post from long ago.

>
>! ( Add/remove VALUE to bag, used as a SET, i.e. no duplicates.)
>! : SET+   2DUP IN-BAG? IF 2DROP ELSE BAG+! THEN ;
>! : SET-   2DUP IN-BAG? IF BAG- ELSE 2DROP THEN ;
>
>It is clear from the code that there are at least two things
>on the stack, but how does that relate to the uppercased
>"SET" ? This is literary style where you should have said
>VALUE and BAG, but as the BAG is used as a set, you cut out
>some superfluous words (probably also because a screen has
>limited line length and you didn't want two lines :-)
>
>> I'm pretty sure a competent Forther can recreate the
>> BAG-package inasfar needed for memoize from this spec in any
>> Forth in no time.
>
>A competent Forth programmer will recreate the bag faster
>than s/he can understand your code.
>
>A competent Forth programmer would value your comments and
>considerations (absent) a lot more than your actual code.
>An (as yet) incompetent Forth programmer would need the stack
>comments (absent) to be able to read and use the source.
>
>Please note that I appreciate that you show this fine code.
>Consider that is just possible that it is not documented in
>a superior way for all people.

I hope that you appreciate that the BAG code was there to
allow people to try out the memoize code, if they don't
want to run a ciforth. (In that case it is just WANT BAG).
I honestly don't think that the bag code needs more
explanation in order to understand the memoize code.

>
>-marcel
>

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]

#34778

On 12/3/14 11:31 PM, Albert van der Horst wrote:
> In article <6a78ecbd-4518-468f-96c2-c5a1ebf5e58a@googlegroups.com>,
>   <mhx@iae.nl> wrote:
>> On Wednesday, December 3, 2014 2:17:47 PM UTC+1, Albert van der Horst wrote:
>>> In article <LfCdnVD5DKD3l-PJnZ2dnUU7-c2dnZ2d@supernews.com>,
>>> Elizabeth D. Rather <erather@forth.com> wrote:
>> [..]
>>> There are stack comments, but not in a format
>>> familiar to you. My stack comments reveal more about the
>>> actual working of the words than the silly (my opinion!)
>>> ( n n -- ud ) diagrams.
>>
>> The fact that Elizabeth is asking (and she is not the first
>> one to do so) should be cause for serious self-reflection.
>
> No, not in this case. I've given this at least as much
> thought as she has. Her arguments may shake me, but not
> her authority.

The issue isn't how much thought you've given to your own code, but the 
fact that you are publishing it and hoping that people will adopt and 
use it. You are getting some feedback from your audience, from people 
who would like better documentation.

If you are writing code solely for yourself and do not expect anyone 
else ever to read it, you're certainly welcome to use whatever 
documentation style you like (including none). If you expect other 
people to read your code, it would be wise to respect their needs.

...
>> Please note that I appreciate that you show this fine code.
>> Consider that is just possible that it is not documented in
>> a superior way for all people.
>
> I hope that you appreciate that the BAG code was there to
> allow people to try out the memoize code, if they don't
> want to run a ciforth. (In that case it is just WANT BAG).
> I honestly don't think that the bag code needs more
> explanation in order to understand the memoize code.

You are perfectly right that the code doesn't need more comments for 
you. You wrote it, afte all. Other people are telling you that they 
think it needs more. If you want people to try it, the way to achieve 
that is to listen to their needs.

I respect the fact that you at least provide some usage comments. Some 
people don't even do that, and then take offense when someone says 
"Forth is unreadable". I spent over 30 years working in an environment 
with multiple programmers, most of them outstanding Forth programmers, 
who needed to share code with other Forth programmers, and the 
documentation standards we developed and that other people have 
contributed to, and used around the world, work to make code sharing 
easy. We are talking about communication, after all, and a style that 
reflects only the speaker's idea of what's clear and not the listener's, 
will communicate poorly.

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]

#34790

In article <xfCdncTLbrFcMx3JnZ2dnUU7-TmdnZ2d@supernews.com>,
Elizabeth D. Rather <erather@forth.com> wrote:
>On 12/3/14 11:31 PM, Albert van der Horst wrote:
>> In article <6a78ecbd-4518-468f-96c2-c5a1ebf5e58a@googlegroups.com>,
>>   <mhx@iae.nl> wrote:
>>> On Wednesday, December 3, 2014 2:17:47 PM UTC+1, Albert van der Horst wrote:
>>>> In article <LfCdnVD5DKD3l-PJnZ2dnUU7-c2dnZ2d@supernews.com>,
>>>> Elizabeth D. Rather <erather@forth.com> wrote:
>>> [..]
>>>> There are stack comments, but not in a format
>>>> familiar to you. My stack comments reveal more about the
>>>> actual working of the words than the silly (my opinion!)
>>>> ( n n -- ud ) diagrams.
>>>
>>> The fact that Elizabeth is asking (and she is not the first
>>> one to do so) should be cause for serious self-reflection.
>>
>> No, not in this case. I've given this at least as much
>> thought as she has. Her arguments may shake me, but not
>> her authority.
>
>The issue isn't how much thought you've given to your own code, but the
>fact that you are publishing it and hoping that people will adopt and
>use it. You are getting some feedback from your audience, from people
>who would like better documentation.

You're on the wrong track here. I comment about the issue whether
I uphold my opinion that my way of documenting is superior.

>
>If you are writing code solely for yourself and do not expect anyone
>else ever to read it, you're certainly welcome to use whatever
>documentation style you like (including none). If you expect other
>people to read your code, it would be wise to respect their needs.

No only expect I others to read my code, I try to convince the Forth
world of a superior way of documenting.
I should have added a reference to the Stallman convention:

http://home.hccnet.nl/a.w.m.van.der.horst/forthlectureD.html

<SNIP>

Sigh! I accept the following criticism on the memoize stuff.

1.
I can't understand the memoize stuff. This may be because the
underlying bags are not sufficiently documented to *understand the
memoize stuff:*

2.
I tried to run the memoize stuff. I don't use ciforth. I loaded
the bags stuff and it didn't run. "Neither was I able to adapt
it to my Forth based on the source given." Also acceptable
"it was too hard, .. unfamiliar..."

If the criticism is: "I don't like the Stallman convention"
then that I accept ... and will not act upon.

>
>Cheers,
>Elizabeth

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]

#34792 — van der Horsts Stallman convention (was: A poor mans memoizer.)

albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>No only expect I others to read my code, I try to convince the Forth
>world of a superior way of documenting.
>I should have added a reference to the Stallman convention:
>
>http://home.hccnet.nl/a.w.m.van.der.horst/forthlectureD.html

Note that in the Lisp and C code written by Richard Stallman, the
functions still have their formal paramater lists in addition to the
comments.  You are proposing to delete the stack comments, and replace
them with your comments that combine stack comments and description.
In order to do that, you put additional restrictions on the comment
that Stallman probably does not adhere to in general (it's easier to
write descriptions if you don't have to adhere to these restrictions).

Looking at an Emacs Lisp help text for a function, "C-h f
match-string", the formal parameters do not only appear in source
code, but even in the documentation away from the source code:

|match-string is a compiled Lisp function in `subr.el'.
|(match-string NUM &optional STRING)
|
|Return string of text matched by last search.
|NUM specifies which parenthesized expression in the last regexp.
| Value is nil if NUMth pair didn't match, or there were less than NUM pairs.
|Zero means the entire text matched by the whole regexp or whole string.
|STRING should be given if the last search was by `string-match' on STRING.

It seems like Stallman does not think that the description replace the
formal parameter list, even with his convention.

Likewise, I think that the stack comment on its own is useful even if
it can be extracted out of your description given your restrictons.

- 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 2014: http://www.euroforth.org/ef14/

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

#34799 — Re: van der Horsts Stallman convention

On 12/5/14 2:23 AM, Anton Ertl wrote:
> albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>> No only expect I others to read my code, I try to convince the Forth
>> world of a superior way of documenting.
>> I should have added a reference to the Stallman convention:
>>
>> http://home.hccnet.nl/a.w.m.van.der.horst/forthlectureD.html
>
> Note that in the Lisp and C code written by Richard Stallman, the
> functions still have their formal paramater lists in addition to the
> comments.  You are proposing to delete the stack comments, and replace
> them with your comments that combine stack comments and description.
> In order to do that, you put additional restrictions on the comment
> that Stallman probably does not adhere to in general (it's easier to
> write descriptions if you don't have to adhere to these restrictions).

This is an important point: the comments *supplement* the formal 
parameter list (stack comment in Forth), they do not replace it.

> Looking at an Emacs Lisp help text for a function, "C-h f
> match-string", the formal parameters do not only appear in source
> code, but even in the documentation away from the source code:
>
> |match-string is a compiled Lisp function in `subr.el'.
> |(match-string NUM &optional STRING)
> |
> |Return string of text matched by last search.
> |NUM specifies which parenthesized expression in the last regexp.
> | Value is nil if NUMth pair didn't match, or there were less than NUM pairs.
> |Zero means the entire text matched by the whole regexp or whole string.
> |STRING should be given if the last search was by `string-match' on STRING.
>
> It seems like Stallman does not think that the description replace the
> formal parameter list, even with his convention.
>
> Likewise, I think that the stack comment on its own is useful even if
> it can be extracted out of your description given your restrictons.

Yes, I agree with Anton.

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]

#34815 — Re: van der Horsts Stallman convention (was: A poor mans memoizer.)

In article <2014Dec5.132334@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>No only expect I others to read my code, I try to convince the Forth
>>world of a superior way of documenting.
>>I should have added a reference to the Stallman convention:
>>
>>http://home.hccnet.nl/a.w.m.van.der.horst/forthlectureD.html
>
>Note that in the Lisp and C code written by Richard Stallman, the
>functions still have their formal paramater lists in addition to the
>comments.  You are proposing to delete the stack comments, and replace
>them with your comments that combine stack comments and description.
>In order to do that, you put additional restrictions on the comment
>that Stallman probably does not adhere to in general (it's easier to
>write descriptions if you don't have to adhere to these restrictions).

The Forth Stallman convention is named in honour. They are Forth rules
inspired by comment rules given bu Stallman, not just applying LISP
rules.imitating it.

<SNIP>

>- anton

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]

#34771

Albert van der Horst wrote:

[%X]

>>*sigh* No stack comments anywhere. Very hard to read, even though the
>>definitions are short and look well-factored, because it's unclear what
>>the inputs and outputs are.
> 
> The BAG is in library format, i.e. it is intended
> to be loaded. It is not part of the memoization I
> present and not intended to be documented or discussed.
> 
> But ..
> 
> There are stack comments, but not in a format
> familiar to you. My stack comments reveal more about the
> actual working of the words than the silly (my opinion!)
> ( n n -- ud ) diagrams.
> 
> What is unclear about
> 
> ( For VALUE and BAG : ADDRESS of value in bag/nill.)
> 
> If I compress that to ( n addr -- addr ) are you happy?
> 
> Let's see:
> I use
> BAG ( Create a bag "x" with X items. )
> !BAG  ( Make the BAG empty )
> BAG-WHERE ( For VALUE and BAG : ADDRESS of value in bag/nill.)
> BAG+!  ( Push ITEM to the BAG )
> 
> I'm pretty sure a competent Forther can recreate the
> BAG-package inasfar needed for memoize from this spec in any
> Forth in no time.
> 
> That is my goal, which only comes into play if just
> clipping the BAG screens and load it fails.
 
In following my coding style standard, I have two types of commenting for 
each word. The first is the normal stack comment in the standardised style 
used within the standards document. The second is a glossary text entry, 
again in the style of the standards document. I include both types in each 
definitions source code. Such documentation style works with products like 
DocGen to assist in extracting just the names and comments for use in other 
documentation.

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

#34789 — Should Forth Be Recommended Here?

http://aviation.stackexchange.com/questions/9995/where-do-i-start-learning-about-avionics-programming

Maybe some of you who have had experience in this field could answer this?

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

#34794 — Re: Should Forth Be Recommended Here?

Celeros wrote:

> http://aviation.stackexchange.com/questions/9995/where-do-i-start-learning-about-avionics-programming
> 
> Maybe some of you who have had experience in this field could answer this?

It would seem sensible as his interest is more towards the space end of the 
aerospace industry. Most of the airliners and flying warfare machines will 
use languages like C, Ada and SPARK, and work hard for compliance with 
DO-178b & C, amongst other standards. Spacecraft are more likely to use 
Forth (although not necessarily exclusively).

-- 
********************************************************************
Paul E. Bennett IEng MIET.....<email://Paul_E.Bennett@topmail.co.uk>
Forth based HIDECS Consultancy.............<http://www.hidecs.co.uk>
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web