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

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

How efficient are locals? How portable?

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

Contents

  How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-11 01:16 -0700
    Re: How efficient are locals? How portable? stephen@mpeforth.com (Stephen Pelc) - 2015-04-11 15:56 +0000
      Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-11 15:48 -0700
        Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-11 17:43 -0700
        Re: How efficient are locals? How portable? "HAA" <someone@microsoft.com> - 2015-04-14 18:40 +1000
        Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-22 19:23 +0000
          Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-22 13:28 -0700
            Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-22 22:29 +0000
              Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-22 16:01 -0700
                Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-22 23:20 +0000
                  Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 00:28 -0700
                  Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 02:30 -0700
                    Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-23 09:57 +0000
                      Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-23 11:28 +0000
                        Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-23 09:31 -0400
                      Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-23 13:32 +0000
                        Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 10:56 -0700
                          Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 11:12 -0700
                          Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-23 22:44 +0200
                            Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-23 23:24 -0700
                              Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 09:21 +0000
                                Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-24 11:44 +0000
                                Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-24 08:35 -0700
                                  Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 15:40 +0000
                                Re: How efficient are locals? How portable? mhx@iae.nl - 2015-04-24 10:28 -0700
                                  Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 17:43 +0000
                                    Re: How efficient are locals? How portable? mhx@iae.nl - 2015-04-24 22:44 -0700
                    Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-24 15:00 +0000
                      Re: How efficient are locals? How portable? Paul Rubin <no.email@nospam.invalid> - 2015-04-24 09:07 -0700
                  Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-23 07:30 -0700
                    Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-23 11:02 -0400
                    Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-23 16:30 +0100
                      Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-23 09:38 -0700
                        Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 15:57 +0100
                    Re: How efficient are locals? How portable? empty-buffers <empty.buffersYOU-DONT-WANT-THIS@gmail.NEITHER-THIS.com> - 2015-04-24 15:14 +0000
              Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-23 06:58 -0400
                Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-23 14:47 +0200
                Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-23 08:34 -1000
    Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-13 12:32 +0000
      Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-13 21:57 -0400
        Re: How efficient are locals? How portable? Paul Rubin <no.email@nospam.invalid> - 2015-04-13 19:25 -0700
        Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-14 01:43 -0700
          Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-14 01:45 -0700
            Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-14 10:12 -0700
              Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-14 13:09 -0700
          Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-15 14:18 -0700
            Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-15 22:13 -0700
              Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-15 23:14 -0700
            Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-16 01:12 -0700
              Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-16 01:23 -0700
              Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-16 14:28 -0400
                Re: How efficient are locals? How portable? rickman <gnuarm@gmail.com> - 2015-04-16 14:37 -0400
                Re: How efficient are locals? How portable? Mark Wills <markwills1970@gmail.com> - 2015-04-17 04:43 -0700
        Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-14 14:53 +0000
    Re: How efficient are locals? How portable? Julian Fondren <julian.fondren@gmail.com> - 2015-04-16 00:34 -0700
      Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-16 00:54 -0700
        Re: How efficient are locals? How portable? Julian Fondren <julian.fondren@gmail.com> - 2015-04-16 01:07 -0700
        Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-16 12:22 +0000
          Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-16 08:32 -0700
            Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-16 20:42 -0700
              Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-17 00:14 -0400
                Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-16 22:14 -0700
                  Re: How efficient are locals? How portable? Bernd Linsel <bl1@gmx.com> - 2015-04-17 17:43 +0200
                    Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 20:46 +0000
                      Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 06:54 +0000
                  Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-18 06:52 -0400
                    Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-18 22:14 -0700
                      Re: How efficient are locals? How portable? "WJ" <w_a_x_man@yahoo.com> - 2015-04-19 08:46 +0000
                      Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 06:04 -0400
                      Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-19 10:12 +0000
                Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 10:43 -0700
                  Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 16:28 -0400
                    Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-19 15:35 -0700
                      Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 19:14 -0400
                        Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 16:48 -0700
                        Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 09:51 +0000
                          Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-20 06:27 -0400
                            Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-20 13:04 +0000
                              Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 14:09 +0000
                              Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 07:17 -0400
                                Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-21 16:50 +0000
                                  Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 16:35 -0400
                                  Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-22 06:13 -0400
                                    Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-22 06:23 -0400
                                Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-21 17:18 +0000
                                  Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 16:38 -0400
                                    Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 10:12 +0000
                                      Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-22 06:26 -0400
                          Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-20 08:46 -1000
                            Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 23:02 -0700
                            Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 06:35 -0400
                              Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-21 06:41 -0400
                      Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 10:22 +0000
                        Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-20 23:28 -0700
                          Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-21 11:03 +0000
                            Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-21 07:20 -0700
                              Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-22 15:35 +0000
                                Re: How efficient are locals? How portable? franck.bensusan@gmail.com - 2015-04-23 10:55 -0700
                                  Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-24 07:15 +0000
                  Re: How efficient are locals? How portable? Bernd Linsel <bl1@gmx.com> - 2015-04-20 17:52 +0200
                    Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 09:03 -0700
                      Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 08:33 +0200
                        Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-22 02:20 -0700
                          Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-22 11:35 +0200
                    Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-20 17:50 +0000
              Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-17 01:45 -0700
                Re: How efficient are locals? How portable? Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-04-17 02:37 -0700
              Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-17 10:14 +0000
              Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-17 10:18 +0000
                Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-17 09:38 -0700
                  Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-17 21:25 +0100
              Re: How efficient are locals? How portable? "WJ" <w_a_x_man@yahoo.com> - 2015-04-18 07:51 +0000
                Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 08:45 -0700
                  Re: How efficient are locals? How portable? stephen@mpeforth.com (Stephen Pelc) - 2015-04-19 16:24 +0000
                    Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 09:58 -0700
                      Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-19 19:00 +0100
                      Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 12:27 -0700
                      Re: How efficient are locals? How portable? stephen@mpeforth.com (Stephen Pelc) - 2015-04-19 19:42 +0000
                        Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 13:49 -0700
                          Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 09:39 +0000
                  Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 17:59 -0400
                    Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 16:39 -0700
                      Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-20 04:58 -0400
                        Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 08:52 -0700
                          Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-20 18:04 +0100
                            Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-20 19:05 +0100
                              Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-24 10:06 -0700
                                Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 19:18 +0100
                                  Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-24 11:43 -0700
                                    Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-24 22:03 +0100
                                      Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-26 20:05 +0100
                                        Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-26 21:05 +0000
                                          Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-26 15:08 -0700
                                            Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 00:17 +0000
                                              Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-27 03:55 -0400
                                                Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-26 22:25 -1000
                                                  Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-29 08:53 -0400
                                                    Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-29 09:35 -0700
                                                    Re: How efficient are locals? How portable? mhx@iae.nl - 2015-04-29 10:14 -0700
                                                    Re: How efficient are locals? How portable? "Elizabeth D. Rather" <erather@forth.com> - 2015-04-29 09:00 -1000
                                                      Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-29 13:22 -0700
                                                        Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-05-10 22:50 -0700
                                                          Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-05-10 22:53 -0700
                                            Re: How efficient are locals? How portable? "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-26 23:04 -0400
                                              Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-26 20:51 -0700
                                              Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-27 09:38 +0000
                                                Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-27 23:18 -0700
                                                  Re: How efficient are locals? How portable? "Rod Pemberton" <bork@lllljunkqwer.cpm> - 2015-04-28 03:19 -0400
                                          Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-27 12:33 +0100
                                          Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-27 23:31 -0700
                                            Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-28 08:07 +0100
                                              Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-28 10:20 +0200
                                                Re: How efficient are locals? How portable? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-28 12:17 +0100
                                                  Re: How efficient are locals? How portable? Lars Brinkhoff <lars.spam@nocrew.org> - 2015-04-28 14:04 +0200
                                                    Re: How efficient are locals? How portable? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2015-04-28 14:49 +0100
                                                      Re: How efficient are locals? How portable? "Alex McDonald" <blog@rivadpm.com> - 2015-04-28 22:56 +0100
                          Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-20 23:22 -0700
          Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-17 13:44 -0700
            Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-18 00:31 +0200
            Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-18 14:22 +0000
              Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-18 22:51 -0700
                Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-19 01:25 -0700
                  Re: How efficient are locals? How portable? Coos Haak <chforth@hccnet.nl> - 2015-04-19 21:12 +0200
                    Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-19 12:56 -0700
                      Re: How efficient are locals? How portable? Doug Hoffman <glidedog@gmail.com> - 2015-04-19 17:53 -0400
                      Re: How efficient are locals? How portable? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-04-20 11:59 +0000
                        Re: How efficient are locals? How portable? albert@spenarnc.xs4all.nl (Albert van der Horst) - 2015-04-27 00:33 +0000
            Re: How efficient are locals? How portable? hughaguilar96@gmail.com - 2015-04-19 08:31 -0700
    Re: How efficient are locals? How portable? lehs <skydda.barnen@gmail.com> - 2015-04-30 02:35 -0700

Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9  Next page →

#38448

In article <553631e4$0$282$14726298@news.sunsite.dk>,
Doug Hoffman  <glidedog@gmail.com> wrote:
>On 4/20/15 9:04 AM, Albert van der Horst wrote:
>> In article <5534d47e$0$285$14726298@news.sunsite.dk>, Doug Hoffman
>> <glidedog@gmail.com> wrote:
>>> Agreed.  Your explanation is more complete.  Thanks.  But there is
>>> a reason we write our stack effect diagrams the way that we do: it
>>> is the way we think about the arrangement of the stack.
>>
>> It is more simple than that. If you want the stack to be ( 1 2 3 )
>> you type 1 2 3
>
>Actually, my mental image of the stack differs from the horizontal
>format above, and from the "stack of plates" Starting Forth image.
>
>I first learned RPN on Hewlett-Packard pocket calculators.  The HP
>manuals taught us to think of the stack as growing upwards.
>
>So your ( 1 2 3 ) in my mind becomes:
>
>1
>2
>3
>
>The advantage I find to this image is it matches the way I was first
>taught to do arithmetic and is especially helpful in remembering the
>order for subtraction and division.  So 1 2 3 / - becomes:
>
>1
>2
>3
>/
>
>1
>0
>-
>1
>
>Translating between the horizontal and vertical mental picture has
>become automatic for me and requires essentially no extra thought.

Don't think space, think time.

>
>-Doug
-- 
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]

#38454

On 4/21/15 12:50 PM, Albert van der Horst wrote:
> In article <553631e4$0$282$14726298@news.sunsite.dk>,
> Doug Hoffman  <glidedog@gmail.com> wrote:
>> On 4/20/15 9:04 AM, Albert van der Horst wrote:
>>> In article <5534d47e$0$285$14726298@news.sunsite.dk>, Doug Hoffman
>>> <glidedog@gmail.com> wrote:
>>>> Agreed.  Your explanation is more complete.  Thanks.  But there is
>>>> a reason we write our stack effect diagrams the way that we do: it
>>>> is the way we think about the arrangement of the stack.
>>>
>>> It is more simple than that. If you want the stack to be ( 1 2 3 )
>>> you type 1 2 3
>>
>> Actually, my mental image of the stack differs from the horizontal
>> format above, and from the "stack of plates" Starting Forth image.
>>
>> I first learned RPN on Hewlett-Packard pocket calculators.  The HP
>> manuals taught us to think of the stack as growing upwards.
>>
>> So your ( 1 2 3 ) in my mind becomes:
>>
>> 1
>> 2
>> 3
>>
>> The advantage I find to this image is it matches the way I was first
>> taught to do arithmetic and is especially helpful in remembering the
>> order for subtraction and division.  So 1 2 3 / - becomes:
>>
>> 1
>> 2
>> 3
>> /
>>
>> 1
>> 0
>> -
>> 1
>>
>> Translating between the horizontal and vertical mental picture has
>> become automatic for me and requires essentially no extra thought.
>
> Don't think space, think time.

I think, in this case, in a way that works for me, which happens to be 
the way Hewlett-Packard taught me.

-Doug

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

#38482

On 4/21/15 12:50 PM, Albert van der Horst wrote:
> In article <553631e4$0$282$14726298@news.sunsite.dk>, Doug Hoffman
> <glidedog@gmail.com> wrote:
>> On 4/20/15 9:04 AM, Albert van der Horst wrote:
>>> In article <5534d47e$0$285$14726298@news.sunsite.dk>, Doug
>>> Hoffman <glidedog@gmail.com> wrote:
>>>> Agreed.  Your explanation is more complete.  Thanks.  But
>>>> there is a reason we write our stack effect diagrams the way
>>>> that we do: it is the way we think about the arrangement of the
>>>> stack.
>>>
>>> It is more simple than that. If you want the stack to be ( 1 2 3
>>> ) you type 1 2 3
>>
>> Actually, my mental image of the stack differs from the horizontal
>>  format above, and from the "stack of plates" Starting Forth
>> image.
>>
>> I first learned RPN on Hewlett-Packard pocket calculators.  The HP
>>  manuals taught us to think of the stack as growing upwards.
>>
>> So your ( 1 2 3 ) in my mind becomes:
>>
>> 1 2 3
>>
>> The advantage I find to this image is it matches the way I was
>> first taught to do arithmetic and is especially helpful in
>> remembering the order for subtraction and division.  So 1 2 3 / -
>> becomes:
>>
>> 1 2 3 /
>>
>> 1 0 - 1
>>
>> Translating between the horizontal and vertical mental picture has
>>  become automatic for me and requires essentially no extra
>> thought.
>
> Don't think space, think time.

Here is the manual that taught me, or ruined me depending upon one's
point of view, in 1972.  See page 6 of the handbook:

http://sliderulemuseum.com/Calculators/HP35_OperatorsHandbook.pdf

HP adopts the convention of naming the first four stack locations X, Y,
Z, and T.  X is equivalent to Forth's top of stack.  This helps with a
function like F** where I can never remember which stack items are used
for what because HP labels the exponent key Y^X which I think makes
things obvious.

Not suggesting that anything be changed in standard Forth.  This is just
a bit of history trivia.

-Doug

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

#38486

On 4/22/15 6:13 AM, Doug Hoffman wrote:

> ...HP labels the exponent key Y^X

The HP-35 used X^Y apparently.  For whatever reason this was changed to
Y^X on later models.  Either way stack item use was clear.

-Doug

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

#38449

Doug Hoffman <glidedog@gmail.com> writes:
>I first learned RPN on Hewlett-Packard pocket calculators.  The HP
>manuals taught us to think of the stack as growing upwards.
>
>So your ( 1 2 3 ) in my mind becomes:
>
>1
>2
>3

But the top-of-stack is at the bottom here.

>The advantage I find to this image is it matches the way I was first
>taught to do arithmetic and is especially helpful in remembering the
>order for subtraction and division.  So 1 2 3 / - becomes:
>
>1
>2
>3
>/

Looks to me like you are using the input order, like the standard
Forth notation.

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

#38455

On 4/21/15 1:18 PM, Anton Ertl wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>> I first learned RPN on Hewlett-Packard pocket calculators.  The HP
>> manuals taught us to think of the stack as growing upwards.
>>
>> So your ( 1 2 3 ) in my mind becomes:
>>
>> 1
>> 2
>> 3
>
> But the top-of-stack is at the bottom here.

Is that any more peculiar than having the right-most item be the 
top-of-stack?

Btw, this is off-topic from locals ordering.

-Doug

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

#38483

Doug Hoffman <glidedog@gmail.com> writes:
>On 4/21/15 1:18 PM, Anton Ertl wrote:
>> Doug Hoffman <glidedog@gmail.com> writes:
>>> I first learned RPN on Hewlett-Packard pocket calculators.  The HP
>>> manuals taught us to think of the stack as growing upwards.
>>>
>>> So your ( 1 2 3 ) in my mind becomes:
>>>
>>> 1
>>> 2
>>> 3
>>
>> But the top-of-stack is at the bottom here.
>
>Is that any more peculiar than having the right-most item be the 
>top-of-stack?

No, it's fine, but not something I would describe as "growing
upwards".

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

#38485

On 4/22/15 6:12 AM, Anton Ertl wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>> On 4/21/15 1:18 PM, Anton Ertl wrote:
>>> Doug Hoffman <glidedog@gmail.com> writes:
>>>> I first learned RPN on Hewlett-Packard pocket calculators.  The
>>>> HP manuals taught us to think of the stack as growing upwards.
>>>>
>>>> So your ( 1 2 3 ) in my mind becomes:
>>>>
>>>> 1 2 3
>>>
>>> But the top-of-stack is at the bottom here.
>>
>> Is that any more peculiar than having the right-most item be the
>> top-of-stack?
>
> No, it's fine, but not something I would describe as "growing
> upwards".

OK.  So it is "growing sideways to the left".  No problem for me either way.

-Doug

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

#38424

On 4/19/15 11:51 PM, Anton Ertl wrote:
> Doug Hoffman <glidedog@gmail.com> writes:
>> On 4/19/15 6:35 PM, franck.bensusan@gmail.com wrote:
>>> Le dimanche 19 avril 2015 22:28:49 UTC+2, Doug Hoffman a écrit :
>>>> Yes.  Neon, a commercial Forth dialect first released in 1984 by
>>>> Kriya Systems, used { for locals *and* had the locals in the
>>>> correct order, *and* had local parameters initialized to zero.
>>>> Yerk and Mops, both derivatives of Neon, continued all of these
>>>> practices.
>>>>
>>>> : foo { a b \ c d -- } a . b . c . d . ;
>>>>
>>>> 1 2 foo 1 2 0 0
>>>>
>>>> -Doug
>>>
>>> Hello,
>>>
>>> Are you sure this is the correct order ?
>>
>> Yes.  See http://www.forth200x.org/locals.html  Actually the new
>> standard specifies {: ... :} and not { ... }.
>>
>>
>>> You mean that the first item on the stack will be stored into the
>>> last declared parameter ?
>>
>> Yes.
>>
>>> Why would this be the correct order ?
>>
>> Because that is how the standard specifies it.
>
> It does not end there (and it certainly was not the reason for Neon,
> almost 30 years earlier).  There's a reason why the standard and Neon
> specify it that way, see below.
>
>>> Is it just a convention or is there another reason ?
>>
>> I think that one strong impetus was to have a locals syntax that could
>> do double duty as a stack effect diagram.
>
> Only indirectly.  In Forth we have the convention to use a stack
> notation where the top-of-stack is rightmost.  I think that there is a
> reason for that (see below), but even if that was arbitrary, that's
> how we interpret a sequence of names for stack items.  When we write a
> stack comment, e.g. "( a b c )", c is the topmost stack item.  So when
> we write a local definition with multiple locals, putting the
> top-of-stack in the rightmost local goes with that convention, and
> putting it in the leftmost local goes against that convention and
> increases the mental load on the programmer who now has to rearrange
> things in his mind in addition to all the other things he has to keep
> in mind as well.
>
> So it's no wonder that the wrong-way Forth-94 LOCALS| c b a | syntax
> proved unpopular with many in the Forth community, and they preferred
> the right-way { a b c } syntax, and that was finally standardized
> (with some renaming) in Forth-2012.
>
> I also don't think that the order is arbitrary.  Note how both
> Postscript (which does not heed Forth conventions in most areas) and
> the Java VM documentation also use the TOS-right convention.  I think
> the reason for this convention is that it is more frequent to have
> multiple input operands than multiple output operands, so it's more
> important to make it easy to get the order of inputs right.  So if you
> specify the stack effect of MOVE as
>
> ( from to count -- )
>
> it's easier to arrange the input arguments than if you specify it as
>
> ( count to from == )

The fact that this discussion is occurring emphasizes that it isn't as 
obvious as partisans of either order seem to think. Back when Forth94 
made its difficult call, there existed several thousand users of the 
order adopted for LOCALS| which the TC didn't want to inconvenience. Now 
the pendulum seems to have swung the other way, and current standards 
are accommodating it, as standards should

I don't personally care, I hate locals :-)

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]

#38429

Earlier, I said this:

On Sunday, April 19, 2015 at 8:32:00 AM UTC-7, hughag...@gmail.com wrote:
> I paid over $400 for SwiftForth-v2, and it would crash if (LOCAL) was used. This was not a subtle bug; this was a complete system crash. How did Forth Inc. get all the way up to version-2 without noticing this bug? Obviously, they had never written a single word that used (LOCAL) --- they sold SwiftForth without any testing.

Now Elizabeth Rather says this:

On Monday, April 20, 2015 at 11:46:21 AM UTC-7, Elizabeth D. Rather wrote:
> I hate locals :-)
> 
> Cheers,
> Elizabeth

Explains a lot, don't you think?

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

#38435

On 4/20/15 2:46 PM, Elizabeth D. Rather wrote:

> [snip] I hate locals :-)

Locals are used 267 times in the current MacForth on VFX build.  It is a
wonderful program, full of useful features, and very responsive (read
fast).  Ward McFarland did his usual superb job in programming it.

-Doug

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

#38437

On 4/21/15 6:35 AM, Doug Hoffman wrote:
> On 4/20/15 2:46 PM, Elizabeth D. Rather wrote:
>
>> [snip] I hate locals :-)
>
> Locals are used 267 times in the current MacForth on VFX build.  It
> is a wonderful program, full of useful features, and very responsive
> (read fast).  Ward McFarland did his usual superb job in programming
> it.

To be precise, that is 267 definitions that contain at least one local
definition.  The actual number of local variables used far exceeds 267.

-Doug

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

#38410

franck.bensusan@gmail.com writes:
>Le dimanche 19 avril 2015 22:28:49 UTC+2, Doug Hoffman a =E9crit=A0:
>func: test(a, b) { a print " " print b println }
>
>>4 3 test
>3 4
>
>>test(3, 4)
>3 4
>
>Oforth uses this order because this must also work with methods and, with=
>=20
>methods, the receiver must always be on the top of the stack (and so,=20
>parameters, if any, are after).
>
>Integer method: check(a, b) { self print " " print a print " " print b prin=
>tln }
>
>>4 3 1 check
>1 3 4
>
>>1 check(3, 4)
>1 3 4

I see nothing preventing you from changing that to work like that:

Integer method: check(a, b) { self print " " print a print " " print b prin=
tln }

>3 4 1 check
1 3 4

>1 check(3, 4)
1 3 4

Self is not an implicit parameter, which makes it all the easier.  


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

#38432

>The Oforth order is the same as the other, and older, standard Forth
>LOCALS| ... | syntax.  LOCALS| is still valid, in terms of still being
>in the standard and is still supported by most Forths I believe. 

Ok, thank you.

>Your language is still quite new. You could make this change and the handful of users you have could change their few programs accordingly. If you wait >for years though, then making the change will be painful --- you will have a lot of users with a lot of code to change. 

Hi Hugh. Yes I'am thinking about it... but I have to be sure that this will 
not break something, especially, interactions between stack and object methods,
calls to external libraries (parameters are in LOCAL| order when 
calling a C function), ...


Le lundi 20 avril 2015 13:17:57 UTC+2, Anton Ertl a écrit :
> I see nothing preventing you from changing that to work like that:
> 
> Integer method: check(a, b) { self print " " print a print " " print b prin=
> tln }
> 
> >3 4 1 check
> 1 3 4
> 
> >1 check(3, 4)
> 1 3 4
> 
> Self is not an implicit parameter, which makes it all the easier.  
> 

Ok, but what should be the result if, for instance, I write : 

4 1 check(3)

With LOCAL| order, it will be :
1 check(3, 4)

With { or {: order, it will be :
1 check(4, 3)

Perhap's it's because I'am thinking "LOCAL|" order, but I would
expect the first result to be the good one.

I will think about it and see if I change the order.

But, after all, it might not be a real problem...
Using () notation for calling, I almost don't think about order anymore.
For instance : 
func: move(from, to count) { ... }

A caller can use this syntax, so there is no questions about order.
move(from, to, count)


May I suggest to change { and {: behavior and come back to LOCAL| order ?
Just kidding... :)

Thank you all for your answers and suggestions,

Franck

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

#38440

franck.bensusan@gmail.com writes:
>>The Oforth order is the same as the other, and older, standard Forth
>>LOCALS| ... | syntax.  LOCALS| is still valid, in terms of still being
>>in the standard and is still supported by most Forths I believe.=20
>
>Ok, thank you.

LOCALS| is obsolescent in Forth-2012 (i.e., the plan is to remove it
in the next standard).

>(parameters are in LOCAL| order when=20
>calling a C function), ...

That is a mistake.  Many Forth systems made that mistake, because it
was more straightforward to implement foreign function calls on IA-32
that way, but that advantage does not hold for modern calling
conventions that pass parameters in registers.  And even on IA-32 that
advantage is relatively small compared to the burden you put on
programmers who then have to reverse the parameters manually in
addition to all the other things they have to do.  In any case, a
number of systems have seen tha light and are supporting the correct
order (some also support the wrong one for legacy code).

>Le lundi 20 avril 2015 13:17:57 UTC+2, Anton Ertl a =E9crit=A0:
>> I see nothing preventing you from changing that to work like that:
>>=20
>> Integer method: check(a, b) { self print " " print a print " " print b pr=
>in=3D
>> tln }
>>=20
>> >3 4 1 check
>> 1 3 4
>>=20
>> >1 check(3, 4)
>> 1 3 4
>>=20
>> Self is not an implicit parameter, which makes it all the easier. =20
>>=20
>
>Ok, but what should be the result if, for instance, I write :=20
>
>4 1 check(3)
>
>With LOCAL| order, it will be :
>1 check(3, 4)
>
>With { or {: order, it will be :
>1 check(4, 3)

Not necessarily.  It depends on the way you define the relation
between arguments on the stack and arguments in parentheses, and has
nothing at all to do with {: vs. LOCALS| in this example:

You put the top-of-stack (1) in self.

a) If you say that parameters in parentheses correspond to the
leftmost parameters, and those on the stack to the rightmost
parameters, then

4 1 check(3)

is equivalent to

1 check(3,4)

b) If you say that parameters in parentheses correspond to the
rightmost parameters and those on the stack to the leftmost
parameters, then

4 1 check(3)

is equivalent to

1 check(4,3)

That is true for both LOCALS| and {: order, because here you have only
one argument on the stack that is moved to parentheses.

To see the difference between the orders, you need a different
example.  Let's have:

Integer method: check(a, b, c)

With {: order and option a), the following are all equivalent:

3 4 5 1 check
4 5 1 check(3)
5 1 check(3,4)
1 check(3,4,5)

You can do the example for the other combinations of order and a)/b)
yourself.

Which option should be selected?  I think selecting option a) would
work well with the {: order, because if you have constant arguments to
the left, you can put them in parentheses (without needing stack
juggling like would be used for typical pure-stack code).  E.g.,
instead of

( n1 ) i + cells a + @ 3 swap 4 1 check

you can write

( n1 ) i + cells a + @ 4 1 check(3)

>I will think about it and see if I change the order.
>>But, after all, it might not be a real problem...
>Using () notation for calling, I almost don't think about order anymore.
>For instance :=20
>func: move(from, to count) { ... }
>
>A caller can use this syntax, so there is no questions about order.
>move(from, to, count)

Sure, if you don't use the stack (in a programmer-visible way), but
instead use local variables exclusively, order becomes mostly
irrelevant, but then you are moving quite far away from Forth.

What are you missing when you do that?  I have no short answer for
that, but maybe others have.

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

#38446

Le mardi 21 avril 2015 13:37:55 UTC+2, Anton Ertl a écrit :
> Not necessarily.  It depends on the way you define the relation
> between arguments on the stack and arguments in parentheses, and has
> nothing at all to do with {: vs. LOCALS| in this example:
> 

Sorry, but I don't see how this could work.

This has something to do with {: vs LOCAL| unless you assume that the number 
of declared parameters is known and can be used by the interpreter to make
the right translation. 

But you can't rely on number of declared parameters. You could write either
 of those definitions : 

Integer method: check(a, b, c) { self a + b + c + }
Integer method: check(a, b) { self a + b + + }
Integer method: check(a) { self a + + + }
Integer method: check { self + + + }        // (pure Forth ? :) ).

All these methods are doing exactly the same thing and all these methods can 
be called with one of those syntaxes : 
1 check(2, 3, 4)
4 1 check(2, 3)
4 3 1 check(2)
4 3 2 1 check

Intepreter will translate them into the last one with the same result.
(using LOCAL| order, of course)
without information about the number of declared parameters.


> Integer method: check(a, b, c)
> 
> With {: order and option a), the following are all equivalent:
> 
> 3 4 5 1 check
> 4 5 1 check(3)
> 5 1 check(3,4)
> 1 check(3,4,5)
> 

Unless you use the number of declared parameters to make the right 
translation (which is not possible), the only thing possible for the
 interpreter is to translate :
 
5 1 check(3, 4) 
into
5 3 4 1 check
and not
3 4 5 1 check

==> For me, none of those could be equivalent.

Franck

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

#38505

franck.bensusan@gmail.com writes:
>Le mardi 21 avril 2015 13:37:55 UTC+2, Anton Ertl a =E9crit=A0:
>> Not necessarily.  It depends on the way you define the relation
>> between arguments on the stack and arguments in parentheses, and has
>> nothing at all to do with {: vs. LOCALS| in this example:
>>=20
>
>Sorry, but I don't see how this could work.
>
>This has something to do with {: vs LOCAL| unless you assume that the numbe=
>r=20
>of declared parameters is known and can be used by the interpreter to make
>the right translation.=20

Yes, I was assuming that, because until now I have only seen
definitions with explicit parameters from you.

>But you can't rely on number of declared parameters. You could write either
> of those definitions :=20
>
>Integer method: check(a, b, c) { self a + b + c + }
>Integer method: check(a, b) { self a + b + + }
>Integer method: check(a) { self a + + + }
>Integer method: check { self + + + }        // (pure Forth ? :) ).

Ok, but even in Forth we have stack effect comments, and nearly all
words have a fixed stack effect.  You could make something that
indicates the number of parameters or the stack effect a part of your
language.  The burden on the programmer from that is smaller than that
of reversing the order all the time; after all, they do it informally
already.

>All these methods are doing exactly the same thing and all these methods ca=
>n=20
>be called with one of those syntaxes :=20
>1 check(2, 3, 4)
>4 1 check(2, 3)
>4 3 1 check(2)
>4 3 2 1 check
>
>Intepreter will translate them into the last one with the same result.
>(using LOCAL| order, of course)
>without information about the number of declared parameters.

Ok, let's play through that with the {: order without knowledge of the
number of parameters; the calls would be:

1 check(2, 3, 4)
2 1 check(3, 4)
2 3 1 check(4)
2 3 4 1 check
Integer method: check(a, b, c) { self a + b + c + }
Integer method: check(b, c) { self + b + c + }
Integer method: check(c) { self + + c + }
Integer method: check { self + + + }

Looks ok, too, and no need for the compiler to know about the number
of parameters.

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

#38547

Le mercredi 22 avril 2015 17:54:49 UTC+2, Anton Ertl a écrit :
> Ok, but even in Forth we have stack effect comments, and nearly all
> words have a fixed stack effect.  You could make something that
> indicates the number of parameters or the stack effect a part of your
> language.  The burden on the programmer from that is smaller than that
> of reversing the order all the time; after all, they do it informally
> already.
> 
> Ok, let's play through that with the {: order without knowledge of the
> number of parameters; the calls would be:
> 
> 1 check(2, 3, 4)
> 2 1 check(3, 4)
> 2 3 1 check(4)
> 2 3 4 1 check
> Integer method: check(a, b, c) { self a + b + c + }
> Integer method: check(b, c) { self + b + c + }
> Integer method: check(c) { self + + c + }
> Integer method: check { self + + + }
> 
> Looks ok, too, and no need for the compiler to know about the number
> of parameters.
> 

To play, yes, why not... :)

All in all, after another day of reflexion, I think { or {: order would 
not be a good choice :
 
1) I will never ask a developper to declare the number of parameters.
 
2) I must have an order where number of declared parameters is not required
at compile time.
 
3) I didn't even talk about polymorphism : 
I don't know at compile time, which implementation to choose, so what will
be the number of parameters.
 
4) And this is just the beginning... I find a new concern each time I'am
thinking about it.
 
I think that this order does not work naturally with those 
stack + objects + calls all mixed together ...
 
On the other hand, a least for this situation, LOCAL| order is, imo, flawless : 
- Everything works everytime.
- No information needed about the number of declared parameters.
- No complicated calls.
- ...

Well, a least I tried to see if { or {: order could be a good solution... :)
 
Thanks you for your time.
 
Franck.

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

#38554

franck.bensusan@gmail.com writes:
>Le mercredi 22 avril 2015 17:54:49 UTC+2, Anton Ertl a =E9crit=A0:
>> Ok, let's play through that with the {: order without knowledge of the
>> number of parameters; the calls would be:
>>=20
>> 1 check(2, 3, 4)
>> 2 1 check(3, 4)
>> 2 3 1 check(4)
>> 2 3 4 1 check
>> Integer method: check(a, b, c) { self a + b + c + }
>> Integer method: check(b, c) { self + b + c + }
>> Integer method: check(c) { self + + c + }
>> Integer method: check { self + + + }
>>=20
>> Looks ok, too, and no need for the compiler to know about the number
>> of parameters.
>>=20
>
>To play, yes, why not... :)
>
>All in all, after another day of reflexion, I think { or {: order would=20
>not be a good choice :
>=20
>1) I will never ask a developper to declare the number of parameters.
>=20

Not necessary, as demonstrated above.

>2) I must have an order where number of declared parameters is not required
>at compile time.

Not required, as demonstrated above.

>=20
>3) I didn't even talk about polymorphism :=20
>I don't know at compile time, which implementation to choose, so what will
>be the number of parameters.

The system does not need to know the number of parameters, as
demonstrated above.

BTW, the programmer needs to know the number of parameters.  If the
call is really polymorphic, all the potential callees need to have the
same stack effect.

>=20
>4) And this is just the beginning... I find a new concern each time I'am
>thinking about it.

It seems to me that the "new concern" is always "number of
parameters", and the answer is, that you can have a system with {:
that does not need to know that, as demonstrated above.

>I think that this order does not work naturally with those=20
>stack + objects + calls all mixed together ...
>=20
>On the other hand, a least for this situation, LOCAL| order is, imo, flawle=
>ss :=20
>- Everything works everytime.
>- No information needed about the number of declared parameters.
>- No complicated calls.
>- ...

Same for the {: order, as demonstrated above.

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

#38417

Am 19.04.2015 um 19:43 schrieb hughaguilar96@gmail.com:
> On Thursday, April 16, 2015 at 9:14:20 PM UTC-7, Doug Hoffman wrote:
>> Many, including me, are still using { ... } for locals and may never stop.
>
> In Forth-200x the { is not defined as anything, so it is legal to use { for anything that you want, including locals. VFX has both { and {: for locals, so the programmer can use either one. There is 20+ years of legacy code using { for locals that will use { until it gets manually converted to use {: instead (a good job for an unpaid intern to do, as no company has money to pay a programmer to do such a tedious task). OTOH, Forth-200x loyalists will write new programs using {: because that is what Anton Ertl is encouraging them to do.
>
> SwiftForth uses { for multi-line comments. So, if any of that legacy code from 20+ years that uses { for locals is compiled under SwiftForth, it will fail to compile because the local definitions will be commented out, and any reference to the local will not work --- you will either get a confusing error message at compile-time, or possibly a program that compiles but doesn't work correctly at run-time. When this happens, Elizabeth Rather will tell you that you have a bug in your program, and you just aren't any good at Forth --- so you have to take time to debug your previously-working program that you likely haven't looked at in years or decades --- eventually you figure out what the problem is, and so you manually convert all of your { into {: for your locals.
>
> This is the chronic problem in ANS-Forth. The standard had a lot of "may or may not" statements. For example, the control-flow stack may or may not be the same as the data-stack. The result is that the programmer has to figure out what is the worst-case scenario (that the control-flow stack is the data-stack) and write his code with this assumption in order for his code to be portable. If you assume that the control-flow stack is distinct from the data-stack, your code is not going to work on SwiftForth --- when this happens, Elizabeth Rather will tell you that there is a bug in your program, and you just aren't any good at Forth.
>
> The ultimate effect of the ANS-Forth standard is that everybody is dragged down to the level of SwiftForth --- SwiftForth effectively is the standard, even though programming in a way that makes sense is theoretically allowed --- even people using other compilers have to limit themselves as if they were using SwiftForth, in order to have an ANS-Forth compliant program.
>
> This is what I said previously about entropy: "If you have a barrel of wine, and you pour a cup of sewage into it, the result is a barrel of sewage." SwiftForth is the cup of sewage that causes all Forth programming to be sewage, or to be non-standard.
>

my unpaid intern is called Pearl or awk:

s/\s+\{\s+/\{:/g s/\s+\}\s+/:\}/g

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

Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9  Next page →

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

csiph-web