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

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

LOCALS| and {:

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

Contents

  LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-16 11:59 +0100
    Re: LOCALS| and {: "Alex McDonald" <blog@rivadpm.com> - 2013-08-16 12:31 +0100
    Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-16 13:31 +0000
    Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-16 21:50 +0200
    Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-17 08:51 +0000
      Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-18 20:10 +0100
        Re: LOCALS| and {: Coos Haak <chforth@hccnet.nl> - 2013-08-18 23:32 +0200
        Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-18 15:47 -0700
          Re: LOCALS| and {: "Alex McDonald" <blog@rivadpm.com> - 2013-08-19 15:10 +0100
        Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 09:46 +0000
          Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-22 20:15 +0100
        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 07:17 -0500
          Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 14:18 +0000
            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 10:25 -0500
              Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-19 15:39 +0000
                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-19 11:26 -0500
              Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-20 11:25 +0000
                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-20 10:05 -0500
                  Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-21 14:38 +0200
                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 11:48 -0500
                      Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-21 16:50 +0000
                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 12:18 -0500
                          Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-22 12:33 +0000
                            Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-22 15:26 +0200
                              Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 12:25 -0500
                                Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-23 02:24 +0200
                                  Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 03:12 -0500
                                    Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-24 01:22 +0200
                                      Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 02:56 -0500
                                  Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 01:49 -0700
                                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 03:52 -0500
                                      Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 08:10 -0700
                                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 13:00 -0500
                                          Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-23 13:46 -0700
                                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 03:01 -0500
                                              Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-24 03:24 -0700
                                                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 12:51 -0500
                                                  Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-25 11:44 -0700
                                                  Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
                                    Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
                                    Re: LOCALS| and {: "WJ" <w_a_x_man@yahoo.com> - 2013-08-30 02:42 +0000
                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 12:24 -0500
                              Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-23 11:50 +0000
                                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 08:13 -0500
                                  Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-23 13:55 +0000
                                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-23 13:05 -0500
                                      Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-24 10:36 +0000
                                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-24 13:05 -0500
                                          Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-24 22:44 +0200
                                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-25 04:29 -0500
                                              Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-25 20:15 +0200
                                                Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-25 15:51 -0500
                                                  Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-25 23:27 +0200
                                                    Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-26 03:19 -0500
                                                      Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-26 20:38 +0200
                                                        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-27 11:52 -0500
                                                          Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-28 03:52 +0200
                                                            Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-28 11:55 -0500
                                              Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-26 11:36 +0000
                                              Re: LOCALS| and {: David Thompson <dave.thompson2@verizon.net> - 2013-08-28 22:27 -0400
                        Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-21 10:36 -0700
                    Re: LOCALS| and {: stephenXXX@mpeforth.com (Stephen Pelc) - 2013-08-21 17:22 +0000
                      Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-21 12:34 -0500
                        Re: LOCALS| and {: mhx@iae.nl - 2013-08-21 23:05 -0700
                          Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-22 03:15 -0500
                            Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-22 14:49 -0700
                              Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-23 02:07 +0200
                                Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-26 20:51 -0700
                                  Re: LOCALS| and {: Bernd Paysan <bernd.paysan@gmx.de> - 2013-08-27 15:55 +0200
                                    Re: LOCALS| and {: mhx@iae.nl - 2013-08-27 10:22 -0700
                                      Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-27 17:33 +0000
                                      Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-27 23:02 +0000
                                        Re: LOCALS| and {: mhx@iae.nl - 2013-08-27 22:02 -0700
                                    Re: LOCALS| and {: Paul Rubin <no.email@nospam.invalid> - 2013-08-27 11:08 -0700
                                    Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-27 21:16 -0700
                              Re: LOCALS| and {: "WJ" <w_a_x_man@yahoo.com> - 2013-08-30 02:56 +0000
                Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 20:10 +0000
            Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 01:49 +0000
              Re: LOCALS| and {: anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-08-20 07:14 +0000
          Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-21 10:28 +0100
      Re: LOCALS| and {: "Elizabeth D. Rather" <erather@forth.com> - 2013-08-18 10:04 -1000
        Re: LOCALS| and {: Ian van Breda <igvb@btopenworld.com> - 2013-08-19 20:08 +0100
          Re: LOCALS| and {: albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-08-20 01:54 +0000
      Re: LOCALS| and {: Mark Wills <markrobertwills@yahoo.co.uk> - 2013-08-20 02:19 -0700
        Re: LOCALS| and {: Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-08-20 04:37 -0500
    Re: LOCALS| and {: Coos Haak <chforth@hccnet.nl> - 2013-08-17 13:58 +0200
    Re: LOCALS| and {: hughaguilar96@yahoo.com - 2013-08-17 18:49 -0700
    Re: LOCALS| and {: "Ed" <invalid@invalid.com> - 2013-08-23 17:37 +1000

Page 1 of 5  [1] 2 3 4 5  Next page →

#25242 — LOCALS| and {:

In the Forth standards proposal a new form of LOCALS| is introduced in the
form of {: .  See the Forth Standards Committee, Forth 200x Draft 11.1, 29th
February, 2012.

I have found the use of LOCALS| invaluable, partly because it greatly
simplifies stack manipulation and partly because it allows intermediate
values to be named, considerably improving documentation and software
maintenance.

Having got used to using LOCALS| it is somewhat confusing to find that names
are reversed in {: .  Although not explicitly stated, it appears that {: :}
is intended to be used at the front of definitions.

It is suggested that LOCALS| also be divided between 'arg' values and 'val'
values.  However, using a | as a separator is more difficult in LOCALS| as
it is also used as a terminator.  An easy way out is to use a || as
separator between arg values and val values.

For example, in the code snippet for my definition, PROCESS-PRODUCTION,
there are three arguments, of which one is a modification of the initial
stack arguments   

    \ Setting derives-lambda flags
        \ Expects: index for enclosing nonterminal; production index; index
        \  for start of production in GrammarTable
: PROCESS-PRODUCTION ( n-index1 n-index2 n-index3 -- )
    ProductionLambdas [[ SWAP ]]           \ Address of production flag
    LOCALS| productionLambda grammarIndex hostIndex || setPattern
        grammarAddress nontermLambda |

Normally, this would need three zeroes preceding the three val variables

    0 0 0  LOCALS| setPattern grammarAddress nontermLambda productionLambda
    grammarIndex hostIndex |

The order for the three val values is immaterial.

The advantages of this:
(1) The number of uninitialized variables are unlimited while the number of
    initialised locals can still be up to eight - plenty for normal use.
(2) There are no limitations on the number of rows allowed for the names of
    the variables - I like to use full names for the variables so often
    cover more that one line.
(3) There are often some stack operations before any LOCALS| are defined.
(4) In its incarnation on the return stack (system-specific), it is faster
    in execution, as the val variables need not be put on the stack
    explicitly.
(5) This brings both {: and LOCALS| into line with each other.
(6) Not all the arguments in a LOCALS| list need be named explicitly.

One definition that is useful is +TO which increments a variable LOCALS|
variable.
            moveCount BufferCount +  TO BufferCount
is better as
            moveCount +TO BufferCount
This is particularly in counting of indefinite loops.

Ian van Breda

[toc] | [next] | [standalone]

#25245

on 16/08/2013 11:58:59, Ian van Breda wrote:
> In the Forth standards proposal a new form of LOCALS| is introduced in
> the form of {: . See the Forth Standards Committee, Forth 200x Draft
> 11.1, 29th February, 2012.
> 
> I have found the use of LOCALS| invaluable, partly because it greatly
> simplifies stack manipulation and partly because it allows
> intermediate values to be named, considerably improving documentation
> and software maintenance.
> 
> Having got used to using LOCALS| it is somewhat confusing to find that
> names are reversed in {: . 

This is to provide a better match with stack diagrams, which it
resembles.

> Although not explicitly stated, it appears
> that {: :} is intended to be used at the front of definitions.

No. The definition allows : x 20 30 {: a :} ( a is 30, 20 on stack ) ...
;

> 
> It is suggested that LOCALS| also be divided between 'arg' values and
> 'val' values. However, using a | as a separator is more difficult in
> LOCALS| as it is also used as a terminator. An easy way out is to use
> a || as separator between arg values and val values.

There's no such specification for LOCALS| . It's only a feature of {: . 

My Forth doesn't support | , since it's not really needed. 

: x 0 {: a b :} ... ; is the same as : x {: a | b :} 0 to b ... ; with
the added advantage of setting the value; uninitialised values aren't
usable without initialising, which the first does quite nicely in one
step.

[snipped; addressed by above] 

> 
> One definition that is useful is +TO which increments a variable
> LOCALS| variable.
> moveCount BufferCount +  TO BufferCount
> is better as
> moveCount +TO BufferCount
> This is particularly in counting of indefinite loops.

Some Forths support a +TO word, although personally I've never found it
that useful, even though locals are values. 
 
> 
> Ian van Breda
> 
> 
> 

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

#25252

Ian van Breda <igvb@btopenworld.com> writes:
>Having got used to using LOCALS| it is somewhat confusing to find that names
>are reversed in {: .

Having gotten used to stack effect comments, many found it confusing
that names are reversed in LOCALS|.  That's why many refused to use
"LOCALS| this read can you |" and instead used "{ you can read this }".

{ then was changed to {: to avoid a name conflict.

>Although not explicitly stated, it appears that {: :}
>is intended to be used at the front of definitions.

One can use it there, but also elsewhere.

>It is suggested that LOCALS| also be divided between 'arg' values and 'val'
>values.

No, the | is not for LOCALS|, but for {:.  LOCALS| is not loved much,
so I doubt that we will see extensions for it in the standard.

>(1) The number of uninitialized variables are unlimited while the number of
>    initialised locals can still be up to eight - plenty for normal use.

Locals are limited to sixteen in the draft, including initialized and
uninitialized locals.  There is no additional limit on initialized
locals.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#25267

Ian van Breda wrote:

> Having got used to using LOCALS| it is somewhat confusing to find that
> names are reversed in {:

Everybody else was confused that LOCALS| names are reversed (compared to a 
stack effect), and therefore didn't use LOCALS|, but something similar to 
{:, usually just { (the colon was added to avoid conflicts with people who 
use { for comments).

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

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

#25278

On Fri, 16 Aug 2013 11:59:02 +0100, Ian van Breda
<igvb@btopenworld.com> wrote:

>Having got used to using LOCALS| it is somewhat confusing to find
>that names are reversed in {: .

The notation is nearly 30 years old now. Informed rumour tells
me that it was originally designed by Don Colbourn. When I
measured the use of LOCALS| ... | and { ... } in systems that
have both, the brace notation was used far more than than
LOCALS|.

I suspect that the popularity is caused by the brace notation
looking like a stack comment. The extra features are nice too.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#25290

Stephen Pelc wrote on 17/08/2013 09:51:
> 
> The notation is nearly 30 years old now. Informed rumour tells
> me that it was originally designed by Don Colbourn. When I
> measured the use of LOCALS| ... | and { ... } in systems that
> have both, the brace notation was used far more than than
> LOCALS|.
> 
> I suspect that the popularity is caused by the brace notation
> looking like a stack comment. The extra features are nice too.
> 

When the ANS Standard was published I immediately realised that LOCALS| made
a big difference to the way in which Forth was coded, especially in limiting
the sometimes complex stack operations that can occur.  This does not get
rid on the stack operations completely but are rather simpler to handle.
However, the main advantage is in the use of named arguments.  Indeed, my
parser would have been, I feel, impossible without LOCALS| - there are 160
LOCALS| lists in the parser code.

LOCALS| and {: are pretty similar.  It is just a matter of whether you work
from the top of the stack down (LOCALS|) or work up from a definite point in
the stack upwards ( {: ).  This is a classic problem with stacks.  See for
example GET-ORDER, do be put the first wid or last on the stack?  Obviously,
I disagree with Hugh Aguilar that LOCALS| was 'total screwed up'.

The logic of my suggestion is, firstly, that ANS included LOCALS| but not
{: and works perfectly well, leaving aside the question of the stack order,
which is a minor matter.  Secondly, it is very easy to implement 'val's in
LOCALS|.  Thirdly, the 'val's are faster than the 'arg's taken off the
stack.  And, fourthly, this makes the two locals methods closely equivalent.

It is important, though, that the LOCALS|/{: should cover more that one line
of source text, to allow named variables that are easy to read later.

Ian
 

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

#25292

Op Sun, 18 Aug 2013 20:10:02 +0100 schreef Ian van Breda:

<snip>
> LOCALS| and {: are pretty similar.  It is just a matter of whether you work
> from the top of the stack down (LOCALS|) or work up from a definite point in
> the stack upwards ( {: ).  This is a classic problem with stacks.  See for
> example GET-ORDER, do be put the first wid or last on the stack?
It's no problem, the count of wid's is on the top with the first wordlist
to be searched right under it, look it up in the standard.

Therefore ALSO may be implemented as follows:
: ALSO GET-ORDER OVER SWAP 1+ SET-ORDER ;

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#25294

On Sunday, August 18, 2013 12:10:02 PM UTC-7, Ian van Breda wrote:
> Obviously,
> I disagree with Hugh Aguilar that LOCALS| was 'total screwed up'.

Well, LOCALS| and {: have the order of names exactly opposite of each other, so one of them must be "totally screwed up" aka "backwards" --- they can't both be correct. :-)

Most likely, LOCALS| has its names in backwards order because nobody at Forth Inc. could figure out how to reverse the order of a list of names, which is necessary for implementing {: correctly. {: is slightly more complicated to implement than LOCALS| --- but doing things in a way that makes sense is always worthwhile --- making sense should have been more of a priority for the ANS-Forth committee.

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

#25303

on 18/08/2013 23:47:54, hugh aguilar wrote:
> {: is
> slightly more complicate d to implement than LOCALS| 

Not true; it has exactly the same implementation cost in my Forth. The
offsets "up the rstack" where locals are kept are simply reversed. 

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

#25301

Ian van Breda <igvb@btopenworld.com> writes:
> leaving aside the question of the stack order,
>which is a minor matter.

If it's a minor matter for you, great, just use {: and you get the
uninitialised locals thrown in.  For me the order is a major matter,
that's why I have never used LOCALS|.

>It is important, though, that the LOCALS|/{: should cover more that one line
>of source text, to allow named variables that are easy to read later.

That capability was apparently not deemed important by some system
implementors and consequently did not make it into the standard.  This
is explicit for {:, but it's also implicit for LOCALS|.

Testing a few systems, I find that

: foo
    locals| x
    y |
    x . y . ;

works on VFX 4.60 when the definition is in a file, but not when you
input it from the command line; it works in SwiftForth 3.4.4.  It does
not work in Gforth 0.7.0.  Both VFX and Gforth have pretty bad error
handling for this code.

: bar { x
    y }
    x . y . ;

does not work in SwiftForth 3.4.4 (nor with {:...:} instead of {...}).
It works with vfxlin when the input comes from a file, but not when it
comes from the command line.  And it works in Gforth.

So, if you think it is important, make a proposal for making this
feature standard.  I am not really keen on implementing this for
LOCALS|, which nobody should use anyway, so you may want to propose it
only for "{:".  Or maybe LOCALS| across lines is a good occasion for
removing LOCALS| from Gforth.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#25367

Anton Ertl  wrote on 19/08/2013 10:46:

> 
> If it's a minor matter for you, great, just use {: and you get the
> uninitialised locals thrown in.  For me the order is a major matter,
> that's why I have never used LOCALS|.
> 
No, because LOCALS| was incorporated in the ANS Standard and I adopted it.
> 
> So, if you think it is important, make a proposal for making this
> feature standard.  I am not really keen on implementing this for
> LOCALS|, which nobody should use anyway, so you may want to propose it
> only for "{:".  Or maybe LOCALS| across lines is a good occasion for
> removing LOCALS| from Gforth.
> 
Not at all, since LOCALS| will do just was well.

When the ANS Standard was first published, I found it to be the first usable
standard after polyForth.  I therefore adopted it, along with Chris
Stephens' 'See Flow' for diagnostics, seen as an absolute 'must'.  There
were some major omissions, particularly in multitasking, especially TERMINAL
and BACKGROUND tasks, and time-slicing.

One of the important features of ANS was the use of LOCALS|; bear in mind
that {: was not in the ANS Standard and LOCALS| were therefore seen as 'the
only game in town'.  This greatly simplified working with the stack and made
it similar to other common languages, as well as simplifying the source
code.  I therefore adopted it in my code: to change this now would break too
much code for me.

My suggestions are very simple: to bring the two schemes into line.

1) Allow for more that one line in both LOCALS| and {: .  It is important to
allow for compound words for the locals names, where necessary, and which I
find essential. 

2) Allow for LOCALS| to use 'val's as well as in {: .  This is very easy to
do by using a || separator and makes the code nearly identical in the two
cases (in my version).  Limiting the number to eight LOCALS| 'arg' values is
fine, as least in the Mac Classic incarnation.

I have to disagree profoundly with that the statement, 'which nobody should
use [LOCALS|] anyway'; this surely is just a matter of style.  LOCALS|
simply works from the top of the stack down, while {: starts form an
somewhat arbitrary point upwards.  I prefer to work backwards from the top
of the stack, which I find easier to do.  I just happen to have started with
the ANS version, which I continue to use.

Ian

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

#25302

Ian van Breda <igvb@btopenworld.com> wrote:
> 
> It is important, though, that the LOCALS|/{: should cover more that
> one line of source text, to allow named variables that are easy to
> read later.

Color me skeptical.  I'm guessing that if you really need to do this
your definitions are too long.  I haven't seen your code, so I might
be wrong about this.

Andrew.

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

#25304

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>Ian van Breda <igvb@btopenworld.com> wrote:
>> 
>> It is important, though, that the LOCALS|/{: should cover more that
>> one line of source text, to allow named variables that are easy to
>> read later.
>
>Color me skeptical.  I'm guessing that if you really need to do this
>your definitions are too long.

Possibly.  However, the number of locals was raised from 8 to 16.  If
we write one {: ... :} definition with 16 locals on an 80 char line,
an average local name must not be longer than 3.7 chars.  That's quite
short in many cases, especially if you have 16 locals.  So we either
need locals definitions across lines (as in VFX when the source is in
a file), or support for multiple locals definitions (as in Gforth).

Sure, you could say that 16 locals indicates that the definition is
too long, but enough people found it useful to vote it into the
standard (IIRC Windows calls were an argument for it).  In any case,
it's wrong to try to subvert this decision by keeping other limits
around.  It will not make the code better if programmers use the same
high number of locals, but with very short names.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#25306

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>Ian van Breda <igvb@btopenworld.com> wrote:
>>> 
>>> It is important, though, that the LOCALS|/{: should cover more that
>>> one line of source text, to allow named variables that are easy to
>>> read later.
>>
>>Color me skeptical.  I'm guessing that if you really need to do this
>>your definitions are too long.
> 
> Possibly.  However, the number of locals was raised from 8 to 16.  If
> we write one {: ... :} definition with 16 locals on an 80 char line,
> an average local name must not be longer than 3.7 chars.  That's quite
> short in many cases, especially if you have 16 locals.  So we either
> need locals definitions across lines (as in VFX when the source is in
> a file), or support for multiple locals definitions (as in Gforth).
> 
> Sure, you could say that 16 locals indicates that the definition is
> too long, but enough people found it useful to vote it into the
> standard (IIRC Windows calls were an argument for it).  In any case,
> it's wrong to try to subvert this decision by keeping other limits
> around.  It will not make the code better if programmers use the same
> high number of locals, but with very short names.

Humm.  I'm not trying to subvert anything, just making an observation.
There's no need to spread a Windows call over many lines.

The problem I see with the line of reasoning you've employed here
(this ... therefore that is reasonable ... threfore we should do that)
is that it leads, in hundreds of tiny steps, to a complex system.

Andrew.

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

#25308

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>The problem I see with the line of reasoning you've employed here
>(this ... therefore that is reasonable ... threfore we should do that)
>is that it leads, in hundreds of tiny steps, to a complex system.

Ah, the slippery slope argument.  I guess it's true in general,
although not necessarily in this case.

If you go the way of simplifying at the cost of usability (plus
throwing in some gratuitious incompatibilities), you arrive at
ColorForth; OTOH, if you have goals like usability, portability,
interoparability, you arrive at something like Gforth, which is much
more complex (and it builds on other complex systems).

Howerver, there is implementation complexity and interface complexity.
A system with fewer restrictions has a simpler interface, even if the
implementation may be more complex; of course, if you expose the
implementation to the user, as we like to do in Forth, a more complex
implementation increases the complexity for those users who look into
that part.

Anyway, back to the concrete issue: { ... } in Gforth works across
lines, because it works through the ordinary parser: { puts a special
wordlist on the search order that defines every word that's not found
there as local.  I think the mechanism is quite elegant, although
probably not easy to understand at first; more complex than a parsing
one-line-only "{"?  Maybe, but hard to compare.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

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

#25309

Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
> Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>The problem I see with the line of reasoning you've employed here
>>(this ... therefore that is reasonable ... threfore we should do that)
>>is that it leads, in hundreds of tiny steps, to a complex system.
> 
> Ah, the slippery slope argument.  I guess it's true in general,
> although not necessarily in this case.
> 
> If you go the way of simplifying at the cost of usability (plus
> throwing in some gratuitious incompatibilities), you arrive at
> ColorForth; OTOH, if you have goals like usability, portability,
> interoparability, you arrive at something like Gforth, which is much
> more complex (and it builds on other complex systems).

Hmmm.

> Howerver, there is implementation complexity and interface
> complexity.  A system with fewer restrictions has a simpler
> interface, even if the implementation may be more complex; of
> course, if you expose the implementation to the user, as we like to
> do in Forth, a more complex implementation increases the complexity
> for those users who look into that part.

That's right.  A very unusual thing about Forth is that nothing about
the implementation is hidden.  This is desirable because a Forth user
gets much of their power from an accurate understanding of the system.
Forth is one of the very few systems where a complete understanding is
a realistic goal for its users.

Therefore, IMHO, any increase of implementation complexity in a Forth
system has a negative effect because it pushes away the goal of
empowering the user by giving them a complete understanding.  Of
course this negative effect may be justified by a feature's additional
utility, but it needs a strong justification.

> Anyway, back to the concrete issue: { ... } in Gforth works across
> lines, because it works through the ordinary parser: { puts a
> special wordlist on the search order that defines every word that's
> not found there as local.  I think the mechanism is quite elegant,
> although probably not easy to understand at first; more complex than
> a parsing one-line-only "{"?  Maybe, but hard to compare.

That's true, I'm sure.

Andrew.

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

#25320

On Mon, 19 Aug 2013 10:25:29 -0500, Andrew Haley
<andrew29@littlepinkcloud.invalid> wrote:

>Humm.  I'm not trying to subvert anything, just making an observation.
>There's no need to spread a Windows call over many lines.

According to a client, they use on call that has 22 parameters.

There's plenty of sample Windows code (in any language) that spreads
a Windows call over multiple lines.

Stephen

-- 
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads

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

#25322

Stephen Pelc <stephenXXX@mpeforth.com> wrote:
> On Mon, 19 Aug 2013 10:25:29 -0500, Andrew Haley
> <andrew29@littlepinkcloud.invalid> wrote:
> 
>>Humm.  I'm not trying to subvert anything, just making an observation.
>>There's no need to spread a Windows call over many lines.
> 
> According to a client, they use on call that has 22 parameters.
> 
> There's plenty of sample Windows code (in any language) that spreads
> a Windows call over multiple lines.

OK.  I'm glad I have nothing to do with such code.

I think I've wondered before if pushing ginormous numbers of args onto
the stack is the wrong thing to do, and that the code would be cleaner
with a parameter block for such args.  The sheer impossibility of
dealing with 22 anonymous args is frightening.  How does one even know
that all of the args are in the right place?  But I haven't seen the
code, so I might well be wrong.

Does the caller of the Forth word that calls Windows really push 22
args onto the stack?  Where do these 22 args come from?

(NB: Not trying to have an argument, but I don't see how it could
work.)

Andrew.

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

#25346

Andrew Haley wrote:
> OK.  I'm glad I have nothing to do with such code.

The X11 call with the most arguments is XGeometry (13!).  There are some 
with varargs, where you can essentially have as many as you like, but in 
practice, this never happens.  The largest Windows call I've used in MINOS 
is CreateFont, which has 14 arguments.

> I think I've wondered before if pushing ginormous numbers of args onto
> the stack is the wrong thing to do, and that the code would be cleaner
> with a parameter block for such args.

Indeed, a structure with named entries to fill in.

> The sheer impossibility of
> dealing with 22 anonymous args is frightening.  How does one even know
> that all of the args are in the right place?  But I haven't seen the
> code, so I might well be wrong.

You try until it works ;-).

> Does the caller of the Forth word that calls Windows really push 22
> args onto the stack?  Where do these 22 args come from?

As far as I've seen Windows functions, most of these args are just 
constants, selecting the function you actually want to call...

> (NB: Not trying to have an argument, but I don't see how it could
> work.)

The 14 argument function worked pretty straight-forward:

: ?? ( bitset n -- c-flag )  rshift 1 and ;
: assign ( addr u family flags width height -- )
  { family flags w h }
  name-string $0! \ make zero-terminated string
  name-string $@ dup IF  drop  ELSE  nip  THEN \ 0 if no name
  family
  ANTIALIASED_QUALITY CLIP_DEFAULT_PRECIS OUT_TT_PRECIS DEFAULT_CHARSET
  flags 2 ??  flags 1 ??  flags 0 ??
  0 0 0 w h CreateFont id ! ;

Of course, when programming such an API, you have absolutely make sure to 
wear a soft cussion on your forehead, so that you won't damage anything when 
facepalming yourself ;-).

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

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

#25349

Bernd Paysan <bernd.paysan@gmx.de> wrote:
> Andrew Haley wrote:
> 
>> The sheer impossibility of
>> dealing with 22 anonymous args is frightening.  How does one even know
>> that all of the args are in the right place?  But I haven't seen the
>> code, so I might well be wrong.
> 
> You try until it works ;-).
> 
>> Does the caller of the Forth word that calls Windows really push 22
>> args onto the stack?  Where do these 22 args come from?
> 
> As far as I've seen Windows functions, most of these args are just 
> constants, selecting the function you actually want to call...
> 
>> (NB: Not trying to have an argument, but I don't see how it could
>> work.)
> 
> The 14 argument function worked pretty straight-forward:
> 
> : ?? ( bitset n -- c-flag )  rshift 1 and ;
> : assign ( addr u family flags width height -- )
>  { family flags w h }
>  name-string $0! \ make zero-terminated string
>  name-string $@ dup IF  drop  ELSE  nip  THEN \ 0 if no name
>  family
>  ANTIALIASED_QUALITY CLIP_DEFAULT_PRECIS OUT_TT_PRECIS DEFAULT_CHARSET
>  flags 2 ??  flags 1 ??  flags 0 ??
>  0 0 0 w h CreateFont id ! ;
> 
> Of course, when programming such an API, you have absolutely make sure to 
> wear a soft cussion on your forehead, so that you won't damage anything when 
> facepalming yourself ;-).

Right!  :-)

But wouldn't it be much better to create a struct with most of this
stuff preloaded, anyway?  Then you can just fill in the blanks.  I
suppose in a way that's what this word is doing, but it is fugly.  The
problem seems to be that the meaning of any argument is determined
only by its position in a list, which is OK with 3 or 4 args, but
after that it gets insane.

It seems to me that this is screaming for a Forth - C interface that
doesn't just push things onto the stack, but gives them names.  Locals
aren't a solution to that problem, because you'd still have to say

lpszFace fdwPitchAndFamily fdwQuality fdwClipPrecision fdwOutputPrecision fdwCharSet fdwStrikeOut fdwUnderline fdwItalic fnWeight nOrientation nEscapement nWidth nHeight CreateFont

Argh...

Andrew.

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

Page 1 of 5  [1] 2 3 4 5  Next page →

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

csiph-web