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

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

multi-threading in Forth?

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

Contents

  multi-threading in Forth? Michael L Gassanenko <m_l_g3@yahoo.com> - 2011-08-02 02:01 -0700
    Re: multi-threading in Forth? mhx@iae.nl (Marcel Hendrix) - 2011-08-02 11:22 +0200
      Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-02 15:26 +0200
      Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-04 01:06 +0400
        Re: multi-threading in Forth? mhx@iae.nl (Marcel Hendrix) - 2011-08-04 06:36 +0200
          Re: multi-threading in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-04 08:25 +0100
            Re: multi-threading in Forth? coos haak <chforth@hccnet.nl> - 2011-08-04 13:42 +0200
              Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-04 14:35 +0200
                Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-04 08:30 -0500
                  Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-04 15:38 +0200
                    Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-04 09:12 -0500
                      Re: multi-threading in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-04 16:50 +0100
                      Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-04 23:52 +0400
                        Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-05 08:50 -0500
                    Re: multi-threading in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-04 16:49 +0100
                      Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-04 19:23 +0200
                      Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-05 10:57 -0500
                Re: multi-threading in Forth? stephenXXX@mpeforth.com (Stephen Pelc) - 2011-08-04 14:16 +0000
                  Re: multi-threading in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-04 16:51 +0100
                    Re: multi-threading in Forth? stephenXXX@mpeforth.com (Stephen Pelc) - 2011-08-04 17:14 +0000
                    Re: multi-threading in Forth? "Rod Pemberton" <do_not_have@noavailemail.cmm> - 2011-08-06 03:46 -0400
                  Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-04 19:11 +0200
                    Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-05 08:43 -0500
                      Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-06 01:49 +0400
                        Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-06 03:13 -0500
                          Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-09 04:41 +0400
                            Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-09 11:01 +0400
                            Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-10 09:02 -0500
                              Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-11 01:10 +0400
                        Re: multi-threading in Forth? Ouatu Bogdan <ouatubi@gmail.com> - 2011-08-10 13:22 +0000
                      Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-06 01:12 +0200
                        Re: multi-threading in Forth? coos haak <chforth@hccnet.nl> - 2011-08-06 02:37 +0200
                          Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-06 12:54 +0200
                            Re: multi-threading in Forth? alextangent <blog@rivadpm.com> - 2011-08-06 12:15 +0100
                        Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-05 22:23 -0500
                        Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-06 03:17 -0500
                      Re: multi-threading in Forth? Julian Fondren <ayrnieu@gmail.com> - 2011-08-05 19:02 -0500
                        Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-06 04:01 -0500
                          return-address manipulation (was: multi-threading in Forth?) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-06 16:35 +0000
                            Re: return-address manipulation Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-08-07 11:45 +0100
                              Re: return-address manipulation Josh Grams <josh@qualdan.com> - 2011-08-08 09:40 +0000
                                Re: return-address manipulation Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-08-08 12:17 +0100
                                  Re: return-address manipulation Josh Grams <josh@qualdan.com> - 2011-08-08 12:29 +0000
                                    Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-09 03:54 +0400
                              Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-09 02:52 +0400
                                Re: return-address manipulation Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2011-08-09 20:54 +0100
                                  Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-11 09:00 +0400
                            Re: return-address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-09 14:49 -0500
                              Re: return-address manipulation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-08-10 09:03 +0000
                                Re: return-address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-10 05:13 -0500
                              Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-11 09:24 +0400
                                Re: return-address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-11 04:09 -0500
                              Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-11 09:36 +0400
                                Re: return-address manipulation mlg3 <m_l_g3@yahoo.com> - 2011-08-11 09:54 +0400
                                Re: return-address manipulation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-11 04:16 -0500
                          Re: multi-threading in Forth? Julian Fondren <ayrnieu@gmail.com> - 2011-08-07 01:43 -0500
                        Re: multi-threading in Forth? Spam@ControlQ.com - 2011-08-06 12:36 -0400
                          Re: multi-threading in Forth? Julian Fondren <ayrnieu@gmail.com> - 2011-08-07 01:13 -0500
                            Re: multi-threading in Forth? mlg3 <m_l_g3@yahoo.com> - 2011-08-09 02:35 +0400
                          Re: multi-threading in Forth? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-08-07 10:08 +0000
                        Re: multi-threading in Forth? Josh Grams <josh@qualdan.com> - 2011-08-07 13:45 +0000
                    Re: multi-threading in Forth? mhx@iae.nl (Marcel Hendrix) - 2011-08-05 17:17 +0200
                      Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-05 19:23 +0200
                    Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-05 10:53 -0500
                      Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-05 19:18 +0200
                        Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-06 09:59 -0500
                          Re: multi-threading in Forth? Spam@ControlQ.com - 2011-08-06 12:28 -0400
                      Re: multi-threading in Forth? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2011-08-06 11:29 +0000
              Re: multi-threading in Forth? Mark Wills <markrobertwills@yahoo.co.uk> - 2011-08-04 16:47 +0100
                Re: multi-threading in Forth? Julian Fondren <ayrnieu@gmail.com> - 2011-08-04 13:54 -0500
                Re: multi-threading in Forth? coos haak <chforth@hccnet.nl> - 2011-08-04 22:02 +0200
    Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-02 08:23 -0500
      Re: multi-threading in Forth? Zbiggy <zbigniew2011REMOVE@gmail.REMOVE.com> - 2011-08-02 15:30 +0200
        Re: multi-threading in Forth? Elizabeth D Rather <erather@forth.com> - 2011-08-02 08:53 -0500
          Re: multi-threading in Forth? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-08-03 03:53 -0500

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

#4644 — Re: return-address manipulation

Gerry Jackson wrote: <j1lqbi$u2h$1@dont-email.me>
> A few months ago I made an effort to understand some return stack 
> manipulation techniques,

> To apply the technique I used the Spykerman Sudoku solver as a testbed
> where I recoded a few words to see if it was easy, more readable etc.
>
> To give an example, I recoded the word that displays the Sudoku grid.
> The original code was:
>
>: .sudokugrid
>    CR CR
>    sudokugrid
>    81 0 do
>      dup i + c@ . ." "
>      i 1+
>        dup 3 mod 0= if
>           dup 9 mod 0= if
>              CR
>              dup 27 mod 0= if
>                dup 81 < if ." ------+-------+------" CR then
>              then
>           else
>             ." ! "
>           then
>        then
>      drop
>    loop
>    drop
>    CR
> ;
>
> which, to me least, is not a good example of well-written Forth as it is 
> difficult to read, but could probably be rewritten to be more readable 
> in conventional Forth (perhaps someone would like to try?).

: |  ." ! " ;
: ---- ." ------+-------+------" CR ;
: ...  3 0 do dup char+ swap c@ . loop ;
: .gridline  ... | ... | ... CR ;
: .row  3 0 do .gridline loop ;
: .sudokugrid
  CR CR sudokugrid
  .row
  ----
  .row
  ----
  .row
  drop CR ;

--Josh

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

#4645 — Re: return-address manipulation

On 08/08/2011 10:40, Josh Grams wrote:
> Gerry Jackson wrote:<j1lqbi$u2h$1@dont-email.me>
>> A few months ago I made an effort to understand some return stack
>> manipulation techniques,
>
>> To apply the technique I used the Spykerman Sudoku solver as a testbed
>> where I recoded a few words to see if it was easy, more readable etc.
>>
>> To give an example, I recoded the word that displays the Sudoku grid.
>> The original code was:
>>
>> : .sudokugrid
>>     CR CR
>>     sudokugrid
>>     81 0 do
>>       dup i + c@ . ." "
>>       i 1+
>>         dup 3 mod 0= if
>>            dup 9 mod 0= if
>>               CR
>>               dup 27 mod 0= if
>>                 dup 81<  if ." ------+-------+------" CR then
>>               then
>>            else
>>              ." ! "
>>            then
>>         then
>>       drop
>>     loop
>>     drop
>>     CR
>> ;
>>
>> which, to me least, is not a good example of well-written Forth as it is
>> difficult to read, but could probably be rewritten to be more readable
>> in conventional Forth (perhaps someone would like to try?).
>
> : |  ." ! " ;

I don't know why the author of the original used the '!' character, 
better would be

: | ." | " ;

> : ---- ." ------+-------+------" CR ;
> : ...  3 0 do dup char+ swap c@ . loop ;
> : .gridline  ... | ... | ... CR ;
> : .row  3 0 do .gridline loop ;
> : .sudokugrid
>    CR CR sudokugrid
>    .row
>    ----
>    .row
>    ----
>    .row
>    drop CR ;
>
> --Josh

Nice one! Very readable. Had the original been written like that I 
wouldn't have bothered recoding that particular word. However my 
offering still serves as an example of using return stack manipulation.

-- 
Gerry

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

#4646 — Re: return-address manipulation

Gerry Jackson wrote: <j1ogjq$efi$1@dont-email.me>
> On 08/08/2011 10:40, Josh Grams wrote:

>> : |  ." ! " ;
>
> I don't know why the author of the original used the '!' character, 
> better would be
>
>: | ." | " ;

I thought at first that maybe the vertical bar wasn't in the usual set
of graphic characters, but it is.  So I don't know why either.

> My offering still serves as an example of using return stack
> manipulation.

Yes, and it was interesting reading; thanks for that.  I haven't ever
gotten around to really looking carefully at his backtracking stuff
before.

--Josh

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

#4650 — Re: return-address manipulation

Josh Grams wrote:
> Gerry Jackson wrote: <j1ogjq$efi$1@dont-email.me>
>> On 08/08/2011 10:40, Josh Grams wrote:
> 
>>> : |  ." ! " ;
>> I don't know why the author of the original used the '!' character, 
>> better would be
>>
>> : | ." | " ;
> 
> I thought at first that maybe the vertical bar wasn't in the usual set
> of graphic characters, but it is.  So I don't know why either.
> 
>> My offering still serves as an example of using return stack
>> manipulation.
> 
> Yes, and it was interesting reading; thanks for that.  I haven't ever
> gotten around to really looking carefully at his backtracking stuff
> before.
> 
> --Josh

Prelude
=======

As I wrote in another post,

0 value lp@
: lp! to lp@ ;
: enter >r ;
: l@ lp@ @ ;
: >l/ldrop r> swap lp@ >r >r rp@ lp! enter rdrop r> lp! ;
: l>/lrest l@  lp@ dup cell+ @ lp! r> swap >r enter r> lp! ;

: pro postpone r> postpone >l/ldrop ; immediate
: cont l>/lrest >r ;


data execution (V.A.Tuzov's technique)
======================================

defer num
defer str
defer ls
\ bracket-backtick (_not_ tick!!)
: [`] ' >body postpone literal ; immediate
: save* r> [`] num @ >r [`] str @ >r [`] ls @ >r enter r> is ls r> is 
str r> is num ;
: .str count type space ;

: list 10 num 20 num C" abc" str ;

: print [ reveal ] save* ['] . is num ['] .str is str ['] print is ls ." 
( " execute ." ) " ;
' list print
\ --> ( 10 20 abc )  ok

: list2 1 num 2 num ['] list ls c" end" str ;
' list2 print
\ --> ( 1 2 ( 10 20 abc ) end )  ok

: num, postpone literal postpone num ;
: str, count postpone cliteral postpone str ;
: ls, postpone literal postpone ls ;
: concat save* ['] num, is num ['] ls, is ls ['] str, is str
   2>r :noname 2r> swap execute execute postpone ; ;
' list ' list2 concat dup print cr xt-see
\ ==> ( 10 20 abc 1 2 ( 10 20 abc ) end )
\ noname :
\  10 num 20 num c" abc" str 1 num 2 num 139981497499032 ls
\  c" end" str ; ok

To test expressive power of this method, Tuzov implemented
all Lisp functions in this style. (He used dynamic code
generation and a garbage-collected heap,
and the GC was also written using data execution.)
The conclusion was that data execution can do everything
that the lambda calculus can do.


data execution + backtracking
=============================

Problem: print all subsets of a set.

: stack pro depth 1+ 1 ?do depth i - pick cont loop ;
\ : .depth ." [" depth 1 .r ." ] " ;
\ : .s .depth stack . ;
\ : u.s .depth stack u. ;
: .braces ." { " r> enter ." } " ;
: .{} .braces stack count type space ;
: el r@ enter drop ;

\ when we will execute this description of a set, it will
\ generate the subsets on the stack [1]
: subsets pro c" foo" el c" bar" el c" baz" el cont ;
: .subsets subsets cr .{} ;

.subsets
{ foo bar baz }
{ foo bar }
{ foo baz }
{ foo }
{ bar baz }
{ bar }
{ baz }
{ }  ok

\ [1] I could add syntax sugar by defining defer { defer , defer }
\ and assigning them as in the previous section; the definition
\ would read:
\ : subsets { c" foo" , c" bar" , c" baz" , } ;

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

#4648 — Re: return-address manipulation

Gerry Jackson wrote:
> AMONG ... EACH ... ITERATE ... control 
> structure (but I never got that far - I'm not sure that structure can be 
> implemented in Forth alone).

It can.
http://www.forth.org.ru/~mlg/BacFORTH-90/pgasmil1-96.html
[Search for ": (AMONG)" or ": ITERATE"]

Probably Google can translate it (but do not trust it too much: 
sometimes it tells you that "hay eats horse").

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

#4669 — Re: return-address manipulation

On 08/08/2011 23:52, mlg3 wrote:
> Gerry Jackson wrote:
>> AMONG ... EACH ... ITERATE ... control structure (but I never got that
>> far - I'm not sure that structure can be implemented in Forth alone).
>
> It can.
> http://www.forth.org.ru/~mlg/BacFORTH-90/pgasmil1-96.html
> [Search for ": (AMONG)" or ": ITERATE"]
>
> Probably Google can translate it (but do not trust it too much:
> sometimes it tells you that "hay eats horse").
>

Thanks for the link. Google translate wasn't much good, it failed to 
translate whole paragraphs. Babelfish did much better but generated 
strange English that is difficult to read - but I expect I'll manage, 
after all Forth is Forth and I can probably figure things out. Much of 
it seems to be similar to your EuroForth paper.

I see that papers on backtracking are dated in the mid 1990's, have the 
ideas stood the test of time? Are they still in use or has something 
better been devised. What is the current status of backtracking in Forth?

-- 
Gerry

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

#4715 — Re: return-address manipulation

Gerry Jackson wrote:
> On 08/08/2011 23:52, mlg3 wrote:
>> Gerry Jackson wrote:
>>> AMONG ... EACH ... ITERATE ... control structure (but I never got that
>>> far - I'm not sure that structure can be implemented in Forth alone).
>>
>> It can.
>> http://www.forth.org.ru/~mlg/BacFORTH-90/pgasmil1-96.html
>> [Search for ": (AMONG)" or ": ITERATE"]
>>
>> Probably Google can translate it (but do not trust it too much:
>> sometimes it tells you that "hay eats horse").
>>
> 
> Thanks for the link. Google translate wasn't much good, it failed to 
> translate whole paragraphs. Babelfish did much better but generated 
> strange English that is difficult to read - but I expect I'll manage, 
> after all Forth is Forth and I can probably figure things out. Much of 
> it seems to be similar to your EuroForth paper.
> 
> I see that papers on backtracking are dated in the mid 1990's, have the 
> ideas stood the test of time? Are they still in use or has something 
> better been devised. What is the current status of backtracking in Forth?
> 

I do not use Forth at work anymore.

SP-Forth has a backtracking package.

The MPE VFX compiler correctly supports return address
manipulations, thus proving in practice that it is possible
to correctly support them in optimizing compilers.


In general, backtracking uses the principle
"call the continuation to transfer control forwards,
a return from the continuation will transfer the control back".

After using this principle once, we have backtrackable code,
the L stack plays the role of the R stack, and CONT EXIT is
used instead of EXIT . Instead of NEST we have NEST then PRO.
So, for backtrackable code there is a different call and
a different exit.

And the number of states at the stack diagram doubles:
( before        --> after-success )
( after-failure <-- on-return )

What will happen if one backtrackable word will call _its_
continuation using the convention for backtrackable code?

We get backtracking^2, and introduce one more stack
for continuations^2. And each backtrackable^2 word
is described with 8 stack states.

Surprisingly, programming with backtrackable^2 words
described with 8 stack states is no more difficult
than programming with backtrackable^1 words of 4 stack
states. This is because you follow the "at most two different
non-empty stack states" principle.

Can we convert success^1 to success^2 and vice versa?

I had control structures that did that. They used copying
of return stack areas and required -NOCUT to store relative
addresses on the return stack.

start pro raise: generator -raise b_consumer cont emerge

was equivalent to

among generator every b_consumer iterate

(in fact, raise was implemented via among), and

reduce: b^2_word -reduce

had no such analog.

Hypothesis 1
backtracking^3 will not give us more expressive power
than backtracking^2

Hypothesis 1a
(same as above), provided that we use the "at most
two non-empty states" principle.

Hypothesis 2
raise and reduce allow us to do everything that
may be done with raise^3 and reduce^3.

I do not know how to prove or refute any of these,
and even what "same expressive power" would
formally mean in that context.

It is easy to define the analogs of PRO and CONT for
backtracking^2 or backtracking^3. But I did not
implement AMONG^2.


In general, I have no formalism for AMONG (it CMOVEs
areas of the return stack, and the formalism is based
on functional equivalence, and there is no functional
equivalent for AMONG).

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

#4668 — Re: return-address manipulation

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
> 
>>A maintenance programmer has a reasonable expectation that a
>>heavyweight technique will only be used when demanded by a heavyweight
>>problem.  When they find otherwise there's a kind of cognitive
>>dissonance (talk about 10-dollar words!) that forces a break in
>>concentration.  It also forces them to step away from the problem they
>>were trying to solve in order to learn how your custom control
>>structures work.
> 
> You are assuming that the maintenance programmer is not familiar with
> the idiom.

Yes.  That is true, and trivially so: the maintenace programmer must
have, at one time, been unaware of this idiom.

> The same argument could be used against any programming technique
> and any programming language: Just assume that the programmer has to
> learn the technique/language first, and your argument will eliminate
> the technique/language from consideration.  I don't think that this
> argument is useful.

Every techinique has some learning cost associated with it.  Of
course, if it is a really useful technique, its cost can be amortized
over the period in which it is used.  It's a cost/benefit analysis, as
usual.

There's a lot to be said for convention.

Andrew.

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

#4677 — Re: return-address manipulation

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> It also forces them to step away from the problem they
>>>were trying to solve in order to learn how your custom control
>>>structures work.
...
>Every techinique has some learning cost associated with it.  Of
>course, if it is a really useful technique, its cost can be amortized
>over the period in which it is used.  It's a cost/benefit analysis, as
>usual.

Yes, but your argument implied that the technique has to amortise
itself immediately, not over time.  Because if the maintenance
programmer has already learned the technique, there is no need "to
step away from the problem they were trying to solve in order to learn
how your custom control structures work".

- 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 2011: http://www.euroforth.org/ef11/

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

#4680 — Re: return-address manipulation

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:
>>>> It also forces them to step away from the problem they
>>>>were trying to solve in order to learn how your custom control
>>>>structures work.
> ...
>>Every techinique has some learning cost associated with it.  Of
>>course, if it is a really useful technique, its cost can be amortized
>>over the period in which it is used.  It's a cost/benefit analysis, as
>>usual.
> 
> Yes, but your argument implied that the technique has to amortise
> itself immediately, not over time.

You might have inferred that, but I did not intend to imply it.  Such
an argument would not make very much sense.

Andrew.

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

#4716 — Re: return-address manipulation

Andrew Haley wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>
>>> A maintenance programmer has a reasonable expectation that a
>>> heavyweight technique will only be used when demanded by a heavyweight
>>> problem.  When they find otherwise there's a kind of cognitive
>>> dissonance (talk about 10-dollar words!) that forces a break in
>>> concentration.  It also forces them to step away from the problem they
>>> were trying to solve in order to learn how your custom control
>>> structures work.
>> You are assuming that the maintenance programmer is not familiar with
>> the idiom.
> 
> Yes.  That is true, and trivially so: the maintenace programmer must
> have, at one time, been unaware of this idiom.

Sounds like your maintenance programmer is alone rather than
within a team, and was hired long after the last guy familiar
with the code left the company.

In such situation, any project will be a problem.

By the way, if your guys wrote a multi-threading application,
and you fired them, and then hired a maintenance programmer
(even if it's one who claimed to know multi-threading),
you will have a similar problem.

In fact, you will have that problem even if your guys
used a 3-rd party library and you fired them. The maintenance
programmer comes and sees that the code tree does not compile
because some component is missing...


> 
>> The same argument could be used against any programming technique
>> and any programming language: Just assume that the programmer has to
>> learn the technique/language first, and your argument will eliminate
>> the technique/language from consideration.  I don't think that this
>> argument is useful.
> 
> Every techinique has some learning cost associated with it.  Of
> course, if it is a really useful technique, its cost can be amortized
> over the period in which it is used.  It's a cost/benefit analysis, as
> usual.
> 
> There's a lot to be said for convention.
> 
> Andrew.

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

#4722 — Re: return-address manipulation

mlg3 <m_l_g3@yahoo.com> wrote:
> Andrew Haley wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>
>>>> A maintenance programmer has a reasonable expectation that a
>>>> heavyweight technique will only be used when demanded by a heavyweight
>>>> problem.  When they find otherwise there's a kind of cognitive
>>>> dissonance (talk about 10-dollar words!) that forces a break in
>>>> concentration.  It also forces them to step away from the problem they
>>>> were trying to solve in order to learn how your custom control
>>>> structures work.
>>>
>>> You are assuming that the maintenance programmer is not familiar with
>>> the idiom.
>> 
>> Yes.  That is true, and trivially so: the maintenace programmer must
>> have, at one time, been unaware of this idiom.
> 
> Sounds like your maintenance programmer is alone rather than
> within a team, and was hired long after the last guy familiar
> with the code left the company.

It doesn't sound like that to me.  Whether you're in a team or not,
you stil have to learn new idioms.

Andrew.

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

#4717 — Re: return-address manipulation

Andrew Haley wrote:
> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>
>>> A maintenance programmer has a reasonable expectation that a
>>> heavyweight technique will only be used when demanded by a heavyweight
>>> problem.  When they find otherwise there's a kind of cognitive
>>> dissonance (talk about 10-dollar words!) that forces a break in
>>> concentration.  It also forces them to step away from the problem they
>>> were trying to solve in order to learn how your custom control
>>> structures work.
>> You are assuming that the maintenance programmer is not familiar with
>> the idiom.
> 
> Yes.  That is true, and trivially so: the maintenace programmer must
> have, at one time, been unaware of this idiom.
> 

Tell me why your maintenance programmer will need to modify
namely custom control structures? The code works, if it did
not work, the project would not have been released in the
first place. Return address manipulations may be found in
google or asked about in comp.lang.forth.

Your maintenance programmer has a lot of components he
knows nothing about, and will never know. He nevertheless
will manage to maintain your code. He does not need to
know how everything works to do it. This is called
professionalism.

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

#4719 — Re: return-address manipulation

mlg3 wrote:
> Return address manipulations may be found in
> google or asked about in comp.lang.forth.

In fact Google is helpless at finding Forth code.
A simpler search engine works better.

For example, for the request

": among" rdrop

yandex.ru finds the SP-Forth library
http://www.forth.org.ru/~profit/lib/bac4th.f
and SPIIRAS proceedings
http://www.proceedings.spiiras.nw.ru/data/src/2002/01/01/spyproc-2002-01-01-15.pdf
and, if asked for "more", reports 3 more results from forth.org.ru

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

#4723 — Re: return-address manipulation

mlg3 <m_l_g3@yahoo.com> wrote:
> Andrew Haley wrote:
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>>
>>>> A maintenance programmer has a reasonable expectation that a
>>>> heavyweight technique will only be used when demanded by a heavyweight
>>>> problem.  When they find otherwise there's a kind of cognitive
>>>> dissonance (talk about 10-dollar words!) that forces a break in
>>>> concentration.  It also forces them to step away from the problem they
>>>> were trying to solve in order to learn how your custom control
>>>> structures work.
>>> You are assuming that the maintenance programmer is not familiar with
>>> the idiom.
>> 
>> Yes.  That is true, and trivially so: the maintenace programmer must
>> have, at one time, been unaware of this idiom.
> 
> Tell me why your maintenance programmer will need to modify
> namely custom control structures? The code works, if it did
> not work, the project would not have been released in the
> first place. Return address manipulations may be found in
> google or asked about in comp.lang.forth.

All successful projects are maintained: features are added, bugs are
fixed.

> Your maintenance programmer has a lot of components he knows nothing
> about, and will never know. He nevertheless will manage to maintain
> your code. He does not need to know how everything works to do
> it. This is called professionalism.

Of course.  As I said, it's a cost/benefit analysis.  Obfuscatory
techniques increase the cost of maintenance, and should usually be
avoided.  Professional programmers seek to reduce maintenance costs.

Andrew.

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

#4632

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:

>
> What is CALL ?
>

  : call >r ;

m_l_g3 calls it ENTER

> They're both hard to understand and maintain.  What's wrong with
>
>    -too-small if  -not-forth if  type space  then then
>
> ?  Golly, even a Forth beginner could understand what that does .  We
> can't have that!  :-)
>

  : -too-small ( c-addr u -- c-addr u 0 | -1 )
    ... ;

  : -too-small ( c-addr u -- c-addr u f )
    ... ;

Neither word follows the "consume all inputs" norm, but compared to what
I went with...

> Yes.  Conventional is good.  The maintenance programmer's time is
> valuable.  Think about it for a moment: on first sight, how long would
> it take the reader to figure out what these programs do?  Remember,
> you're writing code to be read.
>
> There's an old saying that appears in many forms, one of which is
> "Don't use a ten dollar word when a nickel one will do."  This is good
> advice when writing English, and terrific advice when programming.
> People learning English often use heavyweight synonyms and complex
> structures they've learned.  That's good while learning, but it's also
> a sure sign of someone not very fluent with the language.
>
> A maintenance programmer has a reasonable expectation that a
> heavyweight technique will only be used when demanded by a heavyweight
> problem.  When they find otherwise there's a kind of cognitive
> dissonance (talk about 10-dollar words!) that forces a break in
> concentration.  It also forces them to step away from the problem they
> were trying to solve in order to learn how your custom control
> structures work.
>
> This is not general advice against custom control structures, which
> are one of Forth's strengths.  But it's important to realize that,
> while they can simplify code and make it more readable, there is a
> cost.  A wise programmer balances costs and benefits, and uses
> powerful techniques sparingly.

Thanks for this :-) The middle paragraphs are persuasive enough for me.

> Andrew.

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

#4624

On Fri, 5 Aug 2011, Julian Fondren wrote:

> Date: Fri, 05 Aug 2011 19:02:15 -0500
> From: Julian Fondren <ayrnieu@gmail.com>
> Newsgroups: comp.lang.forth
> Subject: Re: multi-threading in Forth?
> 
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>> I think so.  There is the matter of whether, say, return stack
>> manipulation is more useful than tail call optimization.  I'd choose
>> tail call optimization every time, but IME code that (ab)uses the
>> return stack for control flow is hard to understand and maintain.
>> Whatever the problem, there's almost always a better way to do it than
>> fiddling with the R-stack.
>
> Can you elaborate on your IME?  I'm not being flippant; I'm privately
> becoming more and more confident that fiddling with the return stack is
> a huge readability and therefore maintainability win, so I'd appreciate
> a course correction.

I would suggest that you implement a generic stack, and re-write >R R> and 
R@ in terms of that code.  You could then use the faux "return stack" in 
the manner you expect, and with impunity ... or simply drop the return 
stack use and replace it with your own stack implementation ... and that 
would be completely portable.

Cheers,
Rob Sciuk

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

#4631

Spam@ControlQ.com writes:

> I would suggest that you implement a generic stack, and re-write >R R>
> and R@ in terms of that code.  You could then use the faux "return
> stack" in the manner you expect, and with impunity ... or simply drop
> the return stack use and replace it with your own stack implementation
> ... and that would be completely portable.

If this were possible, then I could use >R R> R@ with impunity _right
now_, without going to the trouble of reimplementing , as I'd know that
I could write a straightforward compatibility layer for a future system.
I would have the attitude towards return-address manipulation that I
have toward PLACE APPEND ++ SKIP SCAN and others.

But this isn't the case.  I can't roll my own return addresses just by
rolling my own stack.

  \ documentation synonyms.
  : >ra ( -- r-addr )  postpone >r ; immediate
  : ra> ( r-addr -- )  postpone r> ; immediate
  : ra@ ( -- r-addr )  psotpone r@ ; immediate


Look at these words:

  : call ( r-addr -- ) >ra ;
  : cont ( -- r-addr ) ra@ magic-number + ;

  : x ( -- r-addr ) cont ahead ." It's like an XT." then ;
  x call

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

#4647

Julian Fondren wrote:
> Spam@ControlQ.com writes:
> 
>> I would suggest that you implement a generic stack, and re-write >R R>
>> and R@ in terms of that code.  You could then use the faux "return
>> stack" in the manner you expect, and with impunity ... or simply drop
>> the return stack use and replace it with your own stack implementation
>> ... and that would be completely portable.
> 
> If this were possible, then I could use >R R> R@ with impunity _right
> now_, without going to the trouble of reimplementing , as I'd know that
> I could write a straightforward compatibility layer for a future system.
> I would have the attitude towards return-address manipulation that I
> have toward PLACE APPEND ++ SKIP SCAN and others.
> 
> But this isn't the case.  I can't roll my own return addresses just by
> rolling my own stack.
> 
>   \ documentation synonyms.
>   : >ra ( -- r-addr )  postpone >r ; immediate
>   : ra> ( r-addr -- )  postpone r> ; immediate
>   : ra@ ( -- r-addr )  psotpone r@ ; immediate
> 
> 
> Look at these words:
> 
>   : call ( r-addr -- ) >ra ;
>   : cont ( -- r-addr ) ra@ magic-number + ;
> 
>   : x ( -- r-addr ) cont ahead ." It's like an XT." then ;
>   x call

it's done a bit differently.

: enter >r ;  ok
: generator 0 begin dup 11 < while dup r@ enter 1+ repeat drop rdrop ;  ok
: filter dup 1 and if drop rdrop then ;  ok
: test1 generator . ;  ok
test1 0 1 2 3 4 5 6 7 8 9 10  ok
: test2 generator filter . ;  ok
test2 0 2 4 6 8 10  ok
.s <0>  ok

To nest such generators and filters we need the words PRO and CONT that 
need an extra stack, but the exercise to define an extra stack in Forth 
is just boring.


: pro r> r> >l enter ldrop ;
: cont l> >r r@ enter r> >l ;

; == exit -- this is a convenient notational convention

Statement:
x r[ y ; ] == nest[ r> S1( x ) enter y ; ]

It is evident, but if you'd like a proof,
nest[ r> S1( x ) enter y ; ] ==
r[ ... ] r> S1( x ) r[ y ; ] >r ; ==
x '[ ... ] r[ y ; ] >r ; ==
x r[ y ; ] r[ ... ] ; ==
x r[ y ; ] ... == x r[ y ; ]

So,

pro == nest[ r> r> >l nest[ >r ; ] ldrop ; ] ==
== r[ ... ] r> r> >l r[ ldrop ; ] >r ; ==
== nest[ r> r>   >l r[ ldrop ; ]  >r ; ] ==
== r>  >l r[ ldrop ; ]

A useful factor:
 >l/ldrop == >l r[ ldrop ; ]

Using it,
pro == r> >l/drop

cont == nest[ l> >r r@ nest[ >r ; ] r> >l ; ] ==
== nest[ l> >r r@ r[ r> >l ; ] >r ; ]

A useful factor:
l>/lrest == l> >r r@ r[ r> >l ; ]

Using it,
cont == nest[ l>/lrest >r ; ]

But we don't need a second stack to implement >l/ldrop and l>/lrest.
If we need only these two words, we may implement the L stack
as a list allocated on the return stack.
(I am not optimistic about the reader's emotions here.
Anton, can at least you continue to read?)

0 value lp@
: lp! to lp@ ;
: enter >r ;
: l@ lp@ @ ;
: >l/ldrop r> swap lp@ >r >r rp@ lp! enter rdrop r> lp! ;
: l>/lrest l@  lp@ dup cell+ @ lp! r> swap >r enter r> lp! ;

: pro postpone r> postpone >l/ldrop ; immediate
: cont l>/lrest >r ;

\ a simple generator-filter-consumer example
: 0-10 pro 11 0 do i cont loop ; ( --> i -- --> )
: //2 pro dup 1 and 0= if cont else drop then ; ( i --> i -- --> )
: test1 0-10 . ;
: test2 0-10 //2 . ;

test1 0 1 2 3 4 5 6 7 8 9 10  ok
test2 0 2 4 6 8 10  ok


\ it is compatible with exceptions:
: catch lp@ >r catch r> lp! ;
: 0-10x pro 0-10 ['] cont catch if ." x " then ;
: test3 0-10x dup . //2 1 throw ;

test3 0 x 1 2 x 3 4 x 5 6 x 7 8 x 9 10 x  ok


PS the stack diagram for such words includes four states,
( before --> to-continuation -- from-continuation --> on-return )
or
( before --> to-continuation ) ( on-return <-- from-continuation )

Among these four states, at most two may be non-empty and different.
e.g. (style: only passed data on the stack)
filter ( x --> x -- --> )
generator ( x --> x -- --> )
consumer ( x --> -- --> )
or (style: state on the stack)
generator ( --> x -- x --> )
filter ( x --> x -- x --> x )
consumer ( x --> -- --> x )

And if you write a filter, please remember that in addition to the 
control paths
( before --> to-continuation ) and
( from-continuation --> on-return )
there is also
( before --> on-return ).

: //2 pro dup 1 and 0= if cont ELSE DROP then ; ( i --> i -- --> )

: //2 pro
  ( i ) dup 1 and 0= if ( i ) cont ( ) else ( i ) drop ( ) then
;

(The same consideration applies to some generators.)

PPS
Yes it _is_ exotic. Forth is exotic too, but this is more exotic than Forth.

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

#4633

In article <alpine.BSF.2.00.1108061232060.37413@yoko.controlq.com>,
 <Spam@ControlQ.com> wrote:
>On Fri, 5 Aug 2011, Julian Fondren wrote:
>
>> Date: Fri, 05 Aug 2011 19:02:15 -0500
>> From: Julian Fondren <ayrnieu@gmail.com>
>> Newsgroups: comp.lang.forth
>> Subject: Re: multi-threading in Forth?
>>
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> I think so.  There is the matter of whether, say, return stack
>>> manipulation is more useful than tail call optimization.  I'd choose
>>> tail call optimization every time, but IME code that (ab)uses the
>>> return stack for control flow is hard to understand and maintain.
>>> Whatever the problem, there's almost always a better way to do it than
>>> fiddling with the R-stack.
>>
>> Can you elaborate on your IME?  I'm not being flippant; I'm privately
>> becoming more and more confident that fiddling with the return stack is
>> a huge readability and therefore maintainability win, so I'd appreciate
>> a course correction.
>
>I would suggest that you implement a generic stack, and re-write >R R> and
>R@ in terms of that code.  You could then use the faux "return stack" in
>the manner you expect, and with impunity ... or simply drop the return
>stack use and replace it with your own stack implementation ... and that
>would be completely portable.

It is so easy, it doesn't really deserve its own screen:
----------------------------

--------------------------
>
>Cheers,
>Rob Sciuk
>


--
Newsgroups: comp.lang.forth
Subject: Re: multi-threading in Forth?
Summary:
Expires:
References: <j1cd95$2md$1@dont-email.me> <b5SdnSwRyaUTbqbTnZ2dnUVZ8sidnZ2d@supernews.com> <8662mb5rw8.fsf@gmail.com> <alpine.BSF.2.00.1108061232060.37413@yoko.controlq.com>
Sender:
Followup-To:
Reply-To:
Distribution:
Organization: Dutch Forth Workshop
Keywords:
Cc:

In article <alpine.BSF.2.00.1108061232060.37413@yoko.controlq.com>,
 <Spam@ControlQ.com> wrote:
>On Fri, 5 Aug 2011, Julian Fondren wrote:
>
>> Date: Fri, 05 Aug 2011 19:02:15 -0500
>> From: Julian Fondren <ayrnieu@gmail.com>
>> Newsgroups: comp.lang.forth
>> Subject: Re: multi-threading in Forth?
>>
>> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>> I think so.  There is the matter of whether, say, return stack
>>> manipulation is more useful than tail call optimization.  I'd choose
>>> tail call optimization every time, but IME code that (ab)uses the
>>> return stack for control flow is hard to understand and maintain.
>>> Whatever the problem, there's almost always a better way to do it than
>>> fiddling with the R-stack.
>>
>> Can you elaborate on your IME?  I'm not being flippant; I'm privately
>> becoming more and more confident that fiddling with the return stack is
>> a huge readability and therefore maintainability win, so I'd appreciate
>> a course correction.
>
>I would suggest that you implement a generic stack, and re-write >R R> and
>R@ in terms of that code.  You could then use the faux "return stack" in
>the manner you expect, and with impunity ... or simply drop the return
>stack use and replace it with your own stack implementation ... and that
>would be completely portable.

It is so easy, it hardly deserve its own screen:
----------------------------
SCR # 94
 0 ( STACK PUSH POP -- a_free_stack ) \ AvdH A1sep26
 1 : STACK CREATE HERE CELL+ , CELLS ALLOT DOES> ;
 2 100 STACK DEBUG-STACK
 3 : PUSH DEBUG-STACK @ SWAP OVER ! 1 CELLS +  DEBUG-STACK ! ;
 4 : POP DEBUG-STACK @ 1 CELLS - DUP @ SWAP DEBUG-STACK ! ;
 5
 6
 7
 8
 9
10
11
12
13
14

--------------------------

WANT STACK
: >R PUSH ; : R> POP ;  : R@  R> DUP >R ;
94 LOAD  \ Ignore redefinition warnings
: >S PUSH ; : S> POP ;  : S@  S> DUP >S ;
94 LOAD  \ Ignore redefinition warnings
: >T PUSH ; : T> POP ;  : T@  T> DUP >T ;

>
>Cheers,
>Rob Sciuk
>

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 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web