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

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

Forth programming style...

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

Contents

  Forth programming style... Mux <Yvo.Zoer@gmail.com> - 2015-07-21 15:40 -0700
    Re: Forth programming style... Julian Fondren <ayrnieu@gmail.com> - 2015-07-21 17:28 -0700
      Re: Forth programming style... Julian Fondren <ayrnieu@gmail.com> - 2015-07-21 17:39 -0700
        Re: Forth programming style... Mark Wills <markwills1970@gmail.com> - 2015-07-22 00:48 -0700
          Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-07-21 22:25 -1000
            Re: Forth programming style... onewingedshark@gmail.com - 2015-07-22 15:13 -0700
              Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-07-22 13:24 -1000
              Re: Forth programming style... stephen@mpeforth.com (Stephen Pelc) - 2015-07-23 08:28 +0000
          Re: Forth programming style... Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-22 02:38 -0700
            Re: Forth programming style... Mark Wills <markwills1970@gmail.com> - 2015-07-22 03:14 -0700
              Re: Forth programming style... humptydumpty <ouatubi@gmail.com> - 2015-07-22 03:45 -0700
                Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-07-22 08:37 -1000
                Re: Forth programming style... Paul Rubin <no.email@nospam.invalid> - 2015-07-22 12:51 -0700
                  Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-07-22 10:14 -1000
                    Re: Forth programming style... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-23 06:23 +0000
                    Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-23 16:59 -0700
                    Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-23 20:18 -0700
                  Re: Forth programming style... "HAA" <someone@microsoft.com> - 2015-07-28 21:06 +1000
                    Re: Forth programming style... "Alex McDonald" <blog@rivadpm.com> - 2015-07-28 12:38 +0100
              Re: Forth programming style... "HAA" <someone@microsoft.com> - 2015-07-23 00:02 +1000
              Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-22 21:21 -0700
                Re: Forth programming style... "WJ" <w_a_x_man@yahoo.com> - 2015-07-23 09:05 +0000
                  Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-23 16:47 -0700
                    Re: Forth programming style... Mark Wills <markwills1970@gmail.com> - 2015-07-24 01:24 -0700
                      Re: Forth programming style... franck.bensusan@gmail.com - 2015-07-24 03:48 -0700
                      Re: Forth programming style... Paul Rubin <no.email@nospam.invalid> - 2015-07-24 18:15 -0700
                      Re: Forth programming style... "HAA" <someone@microsoft.com> - 2015-08-01 13:21 +1000
              Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-22 21:48 -0700
              Re: Forth programming style... Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-22 22:28 -0700
                Re: Forth programming style... Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-02 00:43 +0200
              Re: Forth programming style... Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-02 00:22 +0200
                Re: Forth programming style... hughaguilar96@gmail.com - 2015-08-01 16:41 -0700
                  Re: Forth programming style... "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-01 22:01 -0400
                Re: Forth programming style... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-08-02 05:50 +0000
                  Re: Forth programming style... Bernd Paysan <bernd.paysan@gmx.de> - 2015-08-02 16:33 +0200
              Re: Forth programming style... "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-01 22:04 -0400
                Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-08-02 08:54 -0500
                  Re: Forth programming style... "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-08-03 04:51 -0400
                    Re: Forth programming style... "Elizabeth D. Rather" <erather@forth.com> - 2015-08-03 17:36 -0500
          Re: Forth programming style... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-22 10:16 +0000
        Re: Forth programming style... mhx@iae.nl - 2015-07-22 10:02 -0700
      Re: Forth programming style... anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-07-22 10:09 +0000
    Re: Forth programming style... Syd Rumpo <usenet@nononono.co.uk> - 2015-07-22 12:16 +0100
      Re: Forth programming style... Raimond Dragomir <raimond.dragomir@gmail.com> - 2015-07-22 07:59 -0700
    Re: Forth programming style... glidedog@gmail.com - 2015-07-23 04:24 -0700
    Re: Forth programming style... "Ala'a Alawi" <amalawi@gmail.com> - 2015-07-23 19:32 -0700
      Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-23 21:33 -0700
        Re: Forth programming style... borota@gmail.com - 2015-07-23 22:09 -0700
          Re: Forth programming style... hughaguilar96@gmail.com - 2015-07-23 22:57 -0700
          Re: Forth programming style... "Ala'a Alawi" <amalawi@gmail.com> - 2015-07-24 09:26 -0700
        Re: Forth programming style... "Ala'a Alawi" <amalawi@gmail.com> - 2015-07-24 09:26 -0700

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

#40730 — Forth programming style...

This has probably been discussed to death but I wanted to get an update on what people have adopted. Personally, I've subscribed to Chuck's '1-liner' method where I try to break bigger functions down into small, single line words that eventually get called to build the function.

Anyone?

-Mux

[toc] | [next] | [standalone]

#40731

On Tuesday, July 21, 2015 at 5:41:00 PM UTC-5, Mux wrote:
> This has probably been discussed to death but I wanted to get an update on what people have adopted. Personally, I've subscribed to Chuck's '1-liner' method where I try to break bigger functions down into small, single line words that eventually get called to build the function.
> 
> Anyone?
> 
> -Mux

Stack comments are a must.  ciforth's Stallman-style
comments may be superior, but I haven't used them for a
while to see.  But I *have* used kc5tja's style of no
stack comments,

  ( demonstration )
  : foo        some words ;
  : bar        some words ;
  : long-word  see it reads like an index ;

and, coming back to that code years later, I couldn't
make heads or tails of it, which is not a reaction I
enjoy having to my own code.  I still do like kc5tja's
emphasis on not caring if words 'redefine' earlier words,
as this takes advantage of Forth's dictionary to let you
be freer with your names.

And I think the remainder of Forth style is just having
good names and good factors.  I don't think definition
lengths matters so much, except to hint that you may be
missing a trick with your factors, or that your word may
being doing more than its name would suggest.

But if you want rules, these are the best:
https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
plus "don't bury your tools".  I guess that's from
Thinking Forth?  I don't remember the source.



Some discussion about the Forth Stallman convention:
https://groups.google.com/d/msg/comp.lang.forth/jIkvsMkdJjw/RfDIGh5_ot4J

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

#40732

On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
> But if you want rules, these are the best:
> https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J

From that:

> These rules are not for beginners learning their Forth ABCs but might be
> helpful to a person who has written a program and wants to make it
> clearer.

Rules for beginners would be more like:

1. Use stack comments!
2. Don't use locals!
3. Don't write definitions longer than 3-5 lines!
4. Here's a list of naming conventions.
5. Please still try to use a human language with your names.
6. Don't use vocabularies.
7. You probably don't need that cool feature from language X.
8. Don't let holier-than-thou Forth programmers make you
   wear a straitjacket.  After pulling your hair out for a
   while, you'll go raving mad and run off to learn Common
   Lisp or Haskell or something, and literally nobody wants
   that.

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

#40734

On Wednesday, 22 July 2015 01:39:02 UTC+1, Julian Fondren  wrote:
> On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
> > But if you want rules, these are the best:
> > https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
> 
> From that:
> 
> > These rules are not for beginners learning their Forth ABCs but might be
> > helpful to a person who has written a program and wants to make it
> > clearer.
> 
> Rules for beginners would be more like:
> 
> 1. Use stack comments!
> 2. Don't use locals!
> 3. Don't write definitions longer than 3-5 lines!
> 4. Here's a list of naming conventions.
> 5. Please still try to use a human language with your names.
> 6. Don't use vocabularies.
> 7. You probably don't need that cool feature from language X.
> 8. Don't let holier-than-thou Forth programmers make you
>    wear a straitjacket.  After pulling your hair out for a
>    while, you'll go raving mad and run off to learn Common
>    Lisp or Haskell or something, and literally nobody wants
>    that.

Rules 8 and 2 contradict each other! Rule 3 is good.

I would let beginners use locals. They reduce stackrobatics.
Locals greatly simplify the process of actually writing out
the code. You don't need to worry about the position of things
on the stack so much. When they have got a little more 
proficient and confident, get the beginner to return to his
code and see if he can "solve the puzzle" without locals.
Perhaps by factoring more. Show him the actual value of
factoring.

When I was starting out, writing Forth was like solving a
fricking rubics cube, because, as we know, in Forth, you're 
managing the flow of data (the stack) as well as code. It
meant that writing code could be damn right frustrating.
It was partly of my own making: inappropriate factoring.
That's where having a mentor present (i.e. classroom)
is invaluable. Eventually the penny drops and you realise
just how much factoring can simplify things. But I'm all 
for a gentle introduction to Forth, having been there 
myself. 

I'm convinced that most people that try Forth give
up in sheer frustration. Let's face it, if C or some other
"normal" language is your thing, then Forth is just plain
hard. More so if you're learning it on your own.

Here's some of my personal guidelines:
* code in lower case
* useCamelCase for word names
* use UPPERCASE for constants and sys calls
* words that store to memory shall be prepended with !
* words that fetch from memory shall be prepended with @
* words that write to IO shall be prepended with io!
* words that fetch from IO shall be prepended with io@
* no magic numbers (use constants)
* stack comments
* all words shall have a small english description

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

#40735

On 7/21/15 9:48 PM, Mark Wills wrote:
> On Wednesday, 22 July 2015 01:39:02 UTC+1, Julian Fondren  wrote:
>> On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
>>> But if you want rules, these are the best:
>>> https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
>>
>>  From that:
>>
>>> These rules are not for beginners learning their Forth ABCs but might be
>>> helpful to a person who has written a program and wants to make it
>>> clearer.
>>
>> Rules for beginners would be more like:
>>
>> 1. Use stack comments!
>> 2. Don't use locals!
>> 3. Don't write definitions longer than 3-5 lines!
>> 4. Here's a list of naming conventions.
>> 5. Please still try to use a human language with your names.
>> 6. Don't use vocabularies.
>> 7. You probably don't need that cool feature from language X.
>> 8. Don't let holier-than-thou Forth programmers make you
>>     wear a straitjacket.  After pulling your hair out for a
>>     while, you'll go raving mad and run off to learn Common
>>     Lisp or Haskell or something, and literally nobody wants
>>     that.
>
> Rules 8 and 2 contradict each other! Rule 3 is good.

I don't see a contradiction, probably because I don't understand what #8 
means, in practice.

> I would let beginners use locals. They reduce stackrobatics.
> Locals greatly simplify the process of actually writing out
> the code. You don't need to worry about the position of things
> on the stack so much. When they have got a little more
> proficient and confident, get the beginner to return to his
> code and see if he can "solve the puzzle" without locals.
> Perhaps by factoring more. Show him the actual value of
> factoring.

I strongly disagree. Having taught probably a thousand or more new Forth 
programmers, I find that a few days of intensive practice with stacks is 
sufficient for it to become straightforward and natural, rather like 
learning to ride a bicycle. If they start with locals, they tend to 
simply skip that learning process and will never feel comfortable using 
the stack.

> When I was starting out, writing Forth was like solving a
> fricking rubics cube, because, as we know, in Forth, you're
> managing the flow of data (the stack) as well as code. It
> meant that writing code could be damn right frustrating.
> It was partly of my own making: inappropriate factoring.
> That's where having a mentor present (i.e. classroom)
> is invaluable. Eventually the penny drops and you realise
> just how much factoring can simplify things. But I'm all
> for a gentle introduction to Forth, having been there
> myself.

Yes, I regret that there aren't enough classes. I encourage the folks 
who are teaching the scouts to have good Forth classes at the beginning!

> I'm convinced that most people that try Forth give
> up in sheer frustration. Let's face it, if C or some other
> "normal" language is your thing, then Forth is just plain
> hard. More so if you're learning it on your own.

Part of the problem is that many newbies are working with Forths that 
are not well-documented and from obsolete books like Starting Forth. A 
much better place to start, IMO, is from one of the free evaluation 
versions of the commercial Forths. These tend to have a better user 
interface and extensive documentation. Once one acquires some skill with 
the language, if he/she wants one of the non-commercial versions, or 
wants to write one, it'll be much easier.

> Here's some of my personal guidelines:
> * code in lower case
> * useCamelCase for word names
> * use UPPERCASE for constants and sys calls
> * words that store to memory shall be prepended with !
> * words that fetch from memory shall be prepended with @
> * words that write to IO shall be prepended with io!
> * words that fetch from IO shall be prepended with io@
> * no magic numbers (use constants)
> * stack comments
> * all words shall have a small english description
>

It's good for anyone to develop a consistent style. In our books (e.g. 
Forth Application Techniques, Forth Programmer's Handbook, product 
manuals) we describe the style guidelines we use at FORTH, Inc. We also 
recommend that groups working on a project agree on a group style, which 
all programmers in the group will use in their code. This makes it far 
easier for programmers in the group to read and share each others' code 
comfortably.

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]

#40751

On Wednesday, July 22, 2015 at 2:25:18 AM UTC-6, Elizabeth D. Rather wrote:
> 
> Part of the problem is that many newbies are working with Forths that 
> are not well-documented and from obsolete books like Starting Forth.

What books would you suggest then?
What tutorials? (Keeping in mind the desire to learn Forth, not particular implementations [unavoidable, in practice, but certainly worth minimizing.])
Are any of them for the new Forth 2012 Standard? -- http://lars.nocrew.org/forth2012/

I ask from the point of view of a programmer who hasn't *really* learned forth so much as learned about it. I like things *about* Forth, but haven't really used it (much like Lisp).

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

#40752

On 7/22/15 12:13 PM, onewingedshark@gmail.com wrote:
> On Wednesday, July 22, 2015 at 2:25:18 AM UTC-6, Elizabeth D. Rather wrote:
>>
>> Part of the problem is that many newbies are working with Forths that
>> are not well-documented and from obsolete books like Starting Forth.
>
> What books would you suggest then?
> What tutorials? (Keeping in mind the desire to learn Forth, not particular implementations [unavoidable, in practice, but certainly worth minimizing.])
> Are any of them for the new Forth 2012 Standard? -- http://lars.nocrew.org/forth2012/
>
> I ask from the point of view of a programmer who hasn't *really* learned forth so much as learned about it. I like things *about* Forth, but haven't really used it (much like Lisp).

I have written two: The Forth Programmer's Handbook (a reference based 
on Forth94) and Forth Application Techniques (a tutorial, also 
Forth94-compatible). Both are available as paper copies from Amazon. 
Handbook is also included electronically with all FORTH, Inc. products, 
including the free evaluation versions. Both books will work fine with 
the recent Forth2012, although they don't cover all the original 
additions. They both also include some features that are in common usage 
but not standardized, but these are clearly indicated. Application 
Techniques is the text for courses I have taught for many years, and 
includes many problem sets to help you with your practice.

Stephen Pelz has also written a book, available from MPE.

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]

#40757

On Wed, 22 Jul 2015 15:13:03 -0700 (PDT), onewingedshark@gmail.com
wrote:

>What books would you suggest then?

>What tutorials? (Keeping in mind the desire to learn Forth, not particular
>implementations [unavoidable, in practice, but certainly worth minimizing.])

See:
  www.mpeforth.com/books.htm

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]

#40736

miercuri, 22 iulie 2015, 10:48:54 UTC+3, Mark Wills a scris:
> On Wednesday, 22 July 2015 01:39:02 UTC+1, Julian Fondren  wrote:
> > On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
> > > But if you want rules, these are the best:
> > > https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
> > 
> > From that:
> > 
> > > These rules are not for beginners learning their Forth ABCs but might be
> > > helpful to a person who has written a program and wants to make it
> > > clearer.
> > 
> > Rules for beginners would be more like:
> > 
> > 1. Use stack comments!
> > 2. Don't use locals!
> > 3. Don't write definitions longer than 3-5 lines!
> > 4. Here's a list of naming conventions.
> > 5. Please still try to use a human language with your names.
> > 6. Don't use vocabularies.
> > 7. You probably don't need that cool feature from language X.
> > 8. Don't let holier-than-thou Forth programmers make you
> >    wear a straitjacket.  After pulling your hair out for a
> >    while, you'll go raving mad and run off to learn Common
> >    Lisp or Haskell or something, and literally nobody wants
> >    that.
> 
> Rules 8 and 2 contradict each other! Rule 3 is good.
> 
> I would let beginners use locals. They reduce stackrobatics.
> Locals greatly simplify the process of actually writing out
> the code. You don't need to worry about the position of things
> on the stack so much. When they have got a little more 
> proficient and confident, get the beginner to return to his
> code and see if he can "solve the puzzle" without locals.
> Perhaps by factoring more. Show him the actual value of
> factoring.
> 
> When I was starting out, writing Forth was like solving a
> fricking rubics cube, because, as we know, in Forth, you're 
> managing the flow of data (the stack) as well as code. It
> meant that writing code could be damn right frustrating.
> It was partly of my own making: inappropriate factoring.
> That's where having a mentor present (i.e. classroom)
> is invaluable. Eventually the penny drops and you realise
> just how much factoring can simplify things. But I'm all 
> for a gentle introduction to Forth, having been there 
> myself. 
> 
> I'm convinced that most people that try Forth give
> up in sheer frustration. Let's face it, if C or some other
> "normal" language is your thing, then Forth is just plain
> hard. More so if you're learning it on your own.
> 
> Here's some of my personal guidelines:
> * code in lower case
> * useCamelCase for word names
> * use UPPERCASE for constants and sys calls
> * words that store to memory shall be prepended with !
> * words that fetch from memory shall be prepended with @
> * words that write to IO shall be prepended with io!
> * words that fetch from IO shall be prepended with io@
> * no magic numbers (use constants)
> * stack comments
> * all words shall have a small english description

I strongly agree with all of that above.

I would add this:
"Stackrobatics" only for deep burried library words. Words that are
normally "write once" and don't have to look at them often. Words that 
you need only a stack comment to look at (or any other documentation)
to use properly.
For "application" words/logic use stack juggling only when the use it's 
obvious (one, two levels at most). For anything else use locals, or even 
global variables.

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

#40738

On Wednesday, 22 July 2015 10:38:32 UTC+1, Raimond Dragomir  wrote:
> miercuri, 22 iulie 2015, 10:48:54 UTC+3, Mark Wills a scris:
> > On Wednesday, 22 July 2015 01:39:02 UTC+1, Julian Fondren  wrote:
> > > On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
> > > > But if you want rules, these are the best:
> > > > https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
> > > 
> > > From that:
> > > 
> > > > These rules are not for beginners learning their Forth ABCs but might be
> > > > helpful to a person who has written a program and wants to make it
> > > > clearer.
> > > 
> > > Rules for beginners would be more like:
> > > 
> > > 1. Use stack comments!
> > > 2. Don't use locals!
> > > 3. Don't write definitions longer than 3-5 lines!
> > > 4. Here's a list of naming conventions.
> > > 5. Please still try to use a human language with your names.
> > > 6. Don't use vocabularies.
> > > 7. You probably don't need that cool feature from language X.
> > > 8. Don't let holier-than-thou Forth programmers make you
> > >    wear a straitjacket.  After pulling your hair out for a
> > >    while, you'll go raving mad and run off to learn Common
> > >    Lisp or Haskell or something, and literally nobody wants
> > >    that.
> > 
> > Rules 8 and 2 contradict each other! Rule 3 is good.
> > 
> > I would let beginners use locals. They reduce stackrobatics.
> > Locals greatly simplify the process of actually writing out
> > the code. You don't need to worry about the position of things
> > on the stack so much. When they have got a little more 
> > proficient and confident, get the beginner to return to his
> > code and see if he can "solve the puzzle" without locals.
> > Perhaps by factoring more. Show him the actual value of
> > factoring.
> > 
> > When I was starting out, writing Forth was like solving a
> > fricking rubics cube, because, as we know, in Forth, you're 
> > managing the flow of data (the stack) as well as code. It
> > meant that writing code could be damn right frustrating.
> > It was partly of my own making: inappropriate factoring.
> > That's where having a mentor present (i.e. classroom)
> > is invaluable. Eventually the penny drops and you realise
> > just how much factoring can simplify things. But I'm all 
> > for a gentle introduction to Forth, having been there 
> > myself. 
> > 
> > I'm convinced that most people that try Forth give
> > up in sheer frustration. Let's face it, if C or some other
> > "normal" language is your thing, then Forth is just plain
> > hard. More so if you're learning it on your own.
> > 
> > Here's some of my personal guidelines:
> > * code in lower case
> > * useCamelCase for word names
> > * use UPPERCASE for constants and sys calls
> > * words that store to memory shall be prepended with !
> > * words that fetch from memory shall be prepended with @
> > * words that write to IO shall be prepended with io!
> > * words that fetch from IO shall be prepended with io@
> > * no magic numbers (use constants)
> > * stack comments
> > * all words shall have a small english description
> 
> I strongly agree with all of that above.
> 
> I would add this:
> "Stackrobatics" only for deep burried library words. Words that are
> normally "write once" and don't have to look at them often. Words that 
> you need only a stack comment to look at (or any other documentation)
> to use properly.
> For "application" words/logic use stack juggling only when the use it's 
> obvious (one, two levels at most). For anything else use locals, or even 
> global variables.

I'm with Raimond :-)

I'm aware that (for some reason) there's a general dislike for local
variables among Forthers. It's almost like it's a measure of clever
you are: If you need locals you're not a "real" Forther. I'm all for
writing code that I and others can understand six months or six years
from now. That's actually quite hard to do in Forth, especially in
the lowest levels of an application. Locals in particular help code
be me much more readable. 

I must admit, there have been times when
I've looked at older Forth code that I have written, with a view to
modifying it in some way. You get bogged down with all those DUPs
SWAPS, >R R> "noise" that it really is simpler to scrap it, note the
stack effect, and re-write it from scratch. It's actually quicker!

I want to say something about phrases. I believe the concept of
phrases exist in Forth, much more than other programming languages.
I believe that very experienced Forth programmers can analyse code
and recognise common phrases and understand what they are doing at
an almost unconcious level, similar to an epxerienced music reader
reading a stave. I believe Elizabeth can do this. I, alas, cannot.
I have to read each word and conciously compute what is happening.
I have to execute the code in my head, word by word. I believe
Elizabeth and some of the others here (Stephen, Anton, Bernd, 
Hugh) do not. They understand it at a more unconcious, instinctual
level. Experience really pays off in Forth. 

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

#40740

On Wednesday, July 22, 2015 at 1:14:27 PM UTC+3, Mark Wills wrote:
> On Wednesday, 22 July 2015 10:38:32 UTC+1, Raimond Dragomir  wrote:
> > miercuri, 22 iulie 2015, 10:48:54 UTC+3, Mark Wills a scris:
> > > On Wednesday, 22 July 2015 01:39:02 UTC+1, Julian Fondren  wrote:
> > > > On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
> > > > > But if you want rules, these are the best:
> > > > > https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
> > > > 
> > > > From that:
> > > > 
> > > > > These rules are not for beginners learning their Forth ABCs but might be
> > > > > helpful to a person who has written a program and wants to make it
> > > > > clearer.
> > > > 
> > > > Rules for beginners would be more like:
> > > > 
> > > > 1. Use stack comments!
> > > > 2. Don't use locals!
> > > > 3. Don't write definitions longer than 3-5 lines!
> > > > 4. Here's a list of naming conventions.
> > > > 5. Please still try to use a human language with your names.
> > > > 6. Don't use vocabularies.
> > > > 7. You probably don't need that cool feature from language X.
> > > > 8. Don't let holier-than-thou Forth programmers make you
> > > >    wear a straitjacket.  After pulling your hair out for a
> > > >    while, you'll go raving mad and run off to learn Common
> > > >    Lisp or Haskell or something, and literally nobody wants
> > > >    that.
> > > 
> > > Rules 8 and 2 contradict each other! Rule 3 is good.
> > > 
> > > I would let beginners use locals. They reduce stackrobatics.
> > > Locals greatly simplify the process of actually writing out
> > > the code. You don't need to worry about the position of things
> > > on the stack so much. When they have got a little more 
> > > proficient and confident, get the beginner to return to his
> > > code and see if he can "solve the puzzle" without locals.
> > > Perhaps by factoring more. Show him the actual value of
> > > factoring.
> > > 
> > > When I was starting out, writing Forth was like solving a
> > > fricking rubics cube, because, as we know, in Forth, you're 
> > > managing the flow of data (the stack) as well as code. It
> > > meant that writing code could be damn right frustrating.
> > > It was partly of my own making: inappropriate factoring.
> > > That's where having a mentor present (i.e. classroom)
> > > is invaluable. Eventually the penny drops and you realise
> > > just how much factoring can simplify things. But I'm all 
> > > for a gentle introduction to Forth, having been there 
> > > myself. 
> > > 
> > > I'm convinced that most people that try Forth give
> > > up in sheer frustration. Let's face it, if C or some other
> > > "normal" language is your thing, then Forth is just plain
> > > hard. More so if you're learning it on your own.
> > > 
> > > Here's some of my personal guidelines:
> > > * code in lower case
> > > * useCamelCase for word names
> > > * use UPPERCASE for constants and sys calls
> > > * words that store to memory shall be prepended with !
> > > * words that fetch from memory shall be prepended with @
> > > * words that write to IO shall be prepended with io!
> > > * words that fetch from IO shall be prepended with io@
> > > * no magic numbers (use constants)
> > > * stack comments
> > > * all words shall have a small english description
> > 
> > I strongly agree with all of that above.
> > 
> > I would add this:
> > "Stackrobatics" only for deep burried library words. Words that are
> > normally "write once" and don't have to look at them often. Words that 
> > you need only a stack comment to look at (or any other documentation)
> > to use properly.
> > For "application" words/logic use stack juggling only when the use it's 
> > obvious (one, two levels at most). For anything else use locals, or even 
> > global variables.
> 
> I'm with Raimond :-)
> 
> I'm aware that (for some reason) there's a general dislike for local
> variables among Forthers. It's almost like it's a measure of clever
> you are: If you need locals you're not a "real" Forther. I'm all for
> writing code that I and others can understand six months or six years
> from now. That's actually quite hard to do in Forth, especially in
> the lowest levels of an application. Locals in particular help code
> be me much more readable. 
> 
> I must admit, there have been times when
> I've looked at older Forth code that I have written, with a view to
> modifying it in some way. You get bogged down with all those DUPs
> SWAPS, >R R> "noise" that it really is simpler to scrap it, note the
> stack effect, and re-write it from scratch. It's actually quicker!
> 
> I want to say something about phrases. I believe the concept of
> phrases exist in Forth, much more than other programming languages.
> I believe that very experienced Forth programmers can analyse code
> and recognise common phrases and understand what they are doing at
> an almost unconcious level, similar to an epxerienced music reader
> reading a stave. I believe Elizabeth can do this. I, alas, cannot.
> I have to read each word and conciously compute what is happening.
> I have to execute the code in my head, word by word. I believe
> Elizabeth and some of the others here (Stephen, Anton, Bernd, 
> Hugh) do not. They understand it at a more unconcious, instinctual
> level. Experience really pays off in Forth.

Hi!

I'll try first using stack.

Just an example of my recent coding.
Having to write a definition:

push ( addr len delta --  ;inside buffer at ADDR LEN push block of LEN-DELTA
size from ADDR to ADDR+DELTA )

I wanted to experiment with locals, so first definition was:

: push  { addr len delta -- }   addr addr delta + len delta - cmove> ;

I didn't like it, so reedited 'push' using stack:

: push  ( len delta addr -- )   dup 2swap /string cmove> ;

I decided to stay with stack.

Analyzing version using locals, I observed I was to much attracted to
use the thoughtless way of doing, it was so easy to do it, even not
observed the opportunity to use '/string'!

Even using '/string', I like more stack version than local version:

: push  { addr len delta -- }   addr addr len delta /string cmove> ;


Have a nice day,
humptydumpty

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

#40748

On 7/22/15 12:45 AM, humptydumpty wrote:
> On Wednesday, July 22, 2015 at 1:14:27 PM UTC+3, Mark Wills wrote:
>> On Wednesday, 22 July 2015 10:38:32 UTC+1, Raimond Dragomir  wrote:
>>> miercuri, 22 iulie 2015, 10:48:54 UTC+3, Mark Wills a scris:
>>>> On Wednesday, 22 July 2015 01:39:02 UTC+1, Julian Fondren  wrote:
>>>>> On Tuesday, July 21, 2015 at 7:28:08 PM UTC-5, Julian Fondren wrote:
>>>>>> But if you want rules, these are the best:
>>>>>> https://groups.google.com/d/msg/comp.lang.forth/BNjiUjmN2pw/SHwGuf4lqK4J
>>>>>
>>>>>  From that:
>>>>>
>>>>>> These rules are not for beginners learning their Forth ABCs but might be
>>>>>> helpful to a person who has written a program and wants to make it
>>>>>> clearer.
>>>>>
>>>>> Rules for beginners would be more like:
>>>>>
>>>>> 1. Use stack comments!
>>>>> 2. Don't use locals!
>>>>> 3. Don't write definitions longer than 3-5 lines!
>>>>> 4. Here's a list of naming conventions.
>>>>> 5. Please still try to use a human language with your names.
>>>>> 6. Don't use vocabularies.
>>>>> 7. You probably don't need that cool feature from language X.
>>>>> 8. Don't let holier-than-thou Forth programmers make you
>>>>>     wear a straitjacket.  After pulling your hair out for a
>>>>>     while, you'll go raving mad and run off to learn Common
>>>>>     Lisp or Haskell or something, and literally nobody wants
>>>>>     that.
>>>>
>>>> Rules 8 and 2 contradict each other! Rule 3 is good.
>>>>
>>>> I would let beginners use locals. They reduce stackrobatics.
>>>> Locals greatly simplify the process of actually writing out
>>>> the code. You don't need to worry about the position of things
>>>> on the stack so much. When they have got a little more
>>>> proficient and confident, get the beginner to return to his
>>>> code and see if he can "solve the puzzle" without locals.
>>>> Perhaps by factoring more. Show him the actual value of
>>>> factoring.
>>>>
>>>> When I was starting out, writing Forth was like solving a
>>>> fricking rubics cube, because, as we know, in Forth, you're
>>>> managing the flow of data (the stack) as well as code. It
>>>> meant that writing code could be damn right frustrating.
>>>> It was partly of my own making: inappropriate factoring.
>>>> That's where having a mentor present (i.e. classroom)
>>>> is invaluable. Eventually the penny drops and you realise
>>>> just how much factoring can simplify things. But I'm all
>>>> for a gentle introduction to Forth, having been there
>>>> myself.
>>>>
>>>> I'm convinced that most people that try Forth give
>>>> up in sheer frustration. Let's face it, if C or some other
>>>> "normal" language is your thing, then Forth is just plain
>>>> hard. More so if you're learning it on your own.
>>>>
>>>> Here's some of my personal guidelines:
>>>> * code in lower case
>>>> * useCamelCase for word names
>>>> * use UPPERCASE for constants and sys calls
>>>> * words that store to memory shall be prepended with !
>>>> * words that fetch from memory shall be prepended with @
>>>> * words that write to IO shall be prepended with io!
>>>> * words that fetch from IO shall be prepended with io@
>>>> * no magic numbers (use constants)
>>>> * stack comments
>>>> * all words shall have a small english description
>>>
>>> I strongly agree with all of that above.
>>>
>>> I would add this:
>>> "Stackrobatics" only for deep burried library words. Words that are
>>> normally "write once" and don't have to look at them often. Words that
>>> you need only a stack comment to look at (or any other documentation)
>>> to use properly.
>>> For "application" words/logic use stack juggling only when the use it's
>>> obvious (one, two levels at most). For anything else use locals, or even
>>> global variables.
>>
>> I'm with Raimond :-)
>>
>> I'm aware that (for some reason) there's a general dislike for local
>> variables among Forthers. It's almost like it's a measure of clever
>> you are: If you need locals you're not a "real" Forther. I'm all for
>> writing code that I and others can understand six months or six years
>> from now. That's actually quite hard to do in Forth, especially in
>> the lowest levels of an application. Locals in particular help code
>> be me much more readable.
>>
>> I must admit, there have been times when
>> I've looked at older Forth code that I have written, with a view to
>> modifying it in some way. You get bogged down with all those DUPs
>> SWAPS, >R R> "noise" that it really is simpler to scrap it, note the
>> stack effect, and re-write it from scratch. It's actually quicker!
>>
>> I want to say something about phrases. I believe the concept of
>> phrases exist in Forth, much more than other programming languages.
>> I believe that very experienced Forth programmers can analyse code
>> and recognise common phrases and understand what they are doing at
>> an almost unconcious level, similar to an epxerienced music reader
>> reading a stave. I believe Elizabeth can do this. I, alas, cannot.
>> I have to read each word and conciously compute what is happening.
>> I have to execute the code in my head, word by word. I believe
>> Elizabeth and some of the others here (Stephen, Anton, Bernd,
>> Hugh) do not. They understand it at a more unconcious, instinctual
>> level. Experience really pays off in Forth.
>
> Hi!
>
> I'll try first using stack.
>
> Just an example of my recent coding.
> Having to write a definition:
>
> push ( addr len delta --  ;inside buffer at ADDR LEN push block of LEN-DELTA
> size from ADDR to ADDR+DELTA )
>
> I wanted to experiment with locals, so first definition was:
>
> : push  { addr len delta -- }   addr addr delta + len delta - cmove> ;
>
> I didn't like it, so reedited 'push' using stack:
>
> : push  ( len delta addr -- )   dup 2swap /string cmove> ;
>
> I decided to stay with stack.
>
> Analyzing version using locals, I observed I was to much attracted to
> use the thoughtless way of doing, it was so easy to do it, even not
> observed the opportunity to use '/string'!
>
> Even using '/string', I like more stack version than local version:
>
> : push  { addr len delta -- }   addr addr len delta /string cmove> ;

This is a good example. Complex "stackrobatics" does *not* represent 
good Forth programming style, it's the sign of a newbie who hasn't made 
the effort to think out problems clearly in a stack-based medium. It 
takes commitment to the concept that the stack can be used simply and 
effectively, plus some practice in learning how. Indeed, riding a 
tricycle is easier than riding a two-wheeled bike, but the latter is 
more powerful, which is why kids are willing to make the effort.

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]

#40749

humptydumpty <ouatubi@gmail.com> writes:
> push ( addr len delta --  ;inside buffer at ADDR LEN push block of LEN-DELTA
> size from ADDR to ADDR+DELTA )
> I wanted to experiment with locals, so first definition was:
> : push  { addr len delta -- }   addr addr delta + len delta - cmove> ; ...
> Analyzing version using locals, I observed I was to much attracted to
> use the thoughtless way of doing, it was so easy to do it, even not
> observed the opportunity to use '/string'!

Locals are more useful when there are enough live values that it's hard
to get at them with stack operations.  Classic example is multiplying
two complex numbers, x=a+bi and y=c+di, so x*y = (ac-bd) + i(ad+bc):

  : z* { a b c d -- re im } a c * b d - a d * b c + ;

that can be done with stack juggling but who wants to bother?

The genius of Forth was realizing this situation doesn't occur all that
often.  But it does sometimes occur.  Chuck's code uses VARIABLEs rather
freely to deal with it when it arises.  That means you either burn RAM
by permanently allocating a cell for each such variable even when
they're not simultaneously in use, or else you have to carefully track
which ones might overlap during nested calls.  You also must handle the
possibility of such variables being used by multiple words.  Better is
to use stack-like allocation for them, plus temporary names, and that
which is what locals amounts to.

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

#40750

On 7/22/15 9:51 AM, Paul Rubin wrote:
> humptydumpty <ouatubi@gmail.com> writes:
>> push ( addr len delta --  ;inside buffer at ADDR LEN push block of LEN-DELTA
>> size from ADDR to ADDR+DELTA )
>> I wanted to experiment with locals, so first definition was:
>> : push  { addr len delta -- }   addr addr delta + len delta - cmove> ; ...
>> Analyzing version using locals, I observed I was to much attracted to
>> use the thoughtless way of doing, it was so easy to do it, even not
>> observed the opportunity to use '/string'!
>
> Locals are more useful when there are enough live values that it's hard
> to get at them with stack operations.  Classic example is multiplying
> two complex numbers, x=a+bi and y=c+di, so x*y = (ac-bd) + i(ad+bc):
>
>    : z* { a b c d -- re im } a c * b d - a d * b c + ;
>
> that can be done with stack juggling but who wants to bother?
>
> The genius of Forth was realizing this situation doesn't occur all that
> often.  But it does sometimes occur.  Chuck's code uses VARIABLEs rather
> freely to deal with it when it arises.  That means you either burn RAM
> by permanently allocating a cell for each such variable even when
> they're not simultaneously in use, or else you have to carefully track
> which ones might overlap during nested calls.  You also must handle the
> possibility of such variables being used by multiple words.  Better is
> to use stack-like allocation for them, plus temporary names, and that
> which is what locals amounts to.

I know that many languages and CS courses regard using VARIABLEs as 
anathema, but in many years of experience I have not found that to be an 
issue in Forth. Taking your concerns (which are the common ones) 
individually:

* "Burning" RAM by permanently allocating a cell:  As far as the 
internals of something like a complex multiply, Chuck would have written 
that in code, for performance, using registers. VARIABLEs are for values 
that are being used in various definitions in the program. For those 
variables, there are two situations: either you're on a PC, with a 
gazillion megabytes that you don't need, or you're on a microcontroller 
with limited RAM. In the first case, the relatively small number of 
VARIABLEs your application will need is a drop in the bucket. In the 
second, you need to look carefully at the RAM space your application 
needs, and design your overall program to make good use of it. "Good 
use" includes allocating variable for things that need to be used by 
more than one definition. A program that is going to involve complex 
numbers is getting them from somewhere, processing them, and then using 
them somewhere. In other words, they aren't really "local" to a single 
definition, but a property of the application, in which case they 
deserve readable names and permanent allocations. Besides, garbage 
collection is a source of degraded performance and instability, which 
you can ill afford in an embedded application.

* Name space management: that's an issue of overall program design. Use 
names that are meaningful in the context. Any Forth worth using will 
give you an error message when you redefine a name, and LOCATE will help 
you find it and resolve the conflict appropriately and quickly.

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]

#40756

"Elizabeth D. Rather" <erather@forth.com> writes:
>I know that many languages and CS courses regard using VARIABLEs as 
>anathema, but in many years of experience I have not found that to be an 
>issue in Forth.

I have.

>  As far as the 
>internals of something like a complex multiply, Chuck would have written 
>that in code, for performance, using registers.

An good example of avoiding locals by using factoring and good stack
management techniques?  If we have Forth compilers where you cannot
gain performance by using machine code for such tasks (and I think we
have, at least if SIMD instructions are not available), the remaining
reason for code would be that it's easier to do it with registers than
with the stack.  Is a Forth solution with locals preferable to a code
solution with registers?  IMO yes.

> Besides, garbage 
>collection is a source of degraded performance and instability, which 
>you can ill afford in an embedded application.

Locals in Forth are not garbage collected, so why do you bring that up
in a discussion of locals in Forth?

>* Name space management: that's an issue of overall program design. Use 
>names that are meaningful in the context. Any Forth worth using will 
>give you an error message when you redefine a name,

No Forth system worth using gives an error message when you redefine a
name.  Redefinitions are not only allowed in standard programs, the
fact that they do not produce errors, as well as the fact that old
uses still refer to the old name, and new uses refer to the new name
is a feature of Forth, and one in which it is pretty unique:
<http://www.complang.tuwien.ac.at/forth/language-features.html>

However, Forth systems usually show warnings on redefinitions.

- 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 2015: http://www.mpeforth.com/euroforth2015/euroforth2015.htm

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

#40765

On Wednesday, July 22, 2015 at 1:14:38 PM UTC-7, Elizabeth D. Rather wrote:
> I know that many languages and CS courses regard using VARIABLEs as 
> anathema, but in many years of experience I have not found that to be an 
> issue in Forth. 

You have spent your entire career at Forth Inc. denouncing general-purpose data-structures and reusable code-libraries. Here you are doing it again, hijacking a thread on Forth style.

The issue is reentrancy --- any reusable code has to be reentrant --- this is programming-101, well-known by every programmer in the world.

In my FMITE document (http://www.forth.org/FMITE.txt) I provided some quotes from you --- here are a couple that I think explain what in your background causes you to hate the concept of reusable code so much:

"Truly, I don't see the point of all this paranoia about reentrancy, particularly in systems without a multitasker. VARIABLE was *designed* for things that would be used in multiple definitions. I remember the horror of (*gasp*) global variables back in the 1960's in Fortran. But, frankly, in 30+ years of programming in Forth I never found them a problem. I think this is all about mythical dragons."

"In 1971-2 I managed a group of COBOL programmers and wrote a fair amt of COBOL myself. Yes, it was an interesting learning experience!"

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

#40768

On Wednesday, July 22, 2015 at 1:14:38 PM UTC-7, Elizabeth D. Rather wrote:
> As far as the 
> internals of something like a complex multiply, Chuck would have written 
> that in code, for performance, using registers. 

Here we have Elizabeth Rather telling us what Chuck would do. How would she know? Is she channeling him psychically?

In all likelihood, Elizabeth Rather doesn't know what complex numbers are.

In this thread, https://groups.google.com/forum/#!topic/comp.lang.forth/BcWvGxFFuzA%5B1-25%5D
I was complaining that there is no D/ available in ANS-Forth, which I needed in my continued-fraction program. We have this exchange:
On Friday, November 20, 2009 at 12:07:12 AM UTC-7, Elizabeth D Rather wrote:
> Hugh Aguilar wrote:
> ...
> > The problem is the ANS-Forth standard. Really, how obvious was the
> > need for double-precision arithmetic? This could have been an
> > extension to the language similar to floating-point. Compiler-writers
> > working on small microprocessors could decline to implement it if they
> > didn't want to.
> > 
> > I am frustrated with the ANS-Forth standard because I believe that the
> > bad design of the standard is the #1 reason for the failure of Forth
> > to become an important language. Forth was doing pretty well in the
> > 1980s, but we needed a standard. What we got was Forth-83, and then
> > ANS-Forth-94, both of which were badly designed. With some more
> > thoughtful leadership we could have succeeded.
> 
> There are D+, D-, M*, M/, and M*/ (and the unsigned operators).  These 
> were adequate in a very wide variety of projects over a 30 year period, 
> many of which were extremely computation-intensive and running on slow 
> 16-bit processors.
> 
> Forth's design is pragmatic: it has functions that have been needed and 
> that have proven their usefulness *in Forth*, not necessarily those that 
> have been required in other languages.  Generally speaking, Forth has 
> the most flexible set of *integer* arithmetic operators of any language. 
>   In particular, M*/ was one of Chuck's most brilliant innovations.  I'm 
> sure if Chuck were trying to do your continued fractions that is what he 
> would rely on.  Yes, that sometimes requires thinking differently, like 
> many other things in Forth.
> 
> Cheers,
> Elizabeth

This was actually my first-ever contact with Elizabeth Rather. Here she is channeling Chuck again, telling me how he would write my continued-fraction program. How would she know? Also, she is telling me that this "requires thinking differently" --- differently from what? --- in all likelihood, Elizabeth Rather doesn't know what continued-fractions are.

This reminds me of how people trying to sell a message will sometimes claim to be "channeling" a Pharaoh from ancient Egypt or a wise space-alien with a goofy name or a god worshiped by an obscure aboriginal group that none of their readers are familiar with --- always somebody who has more authority than they do but who is conveniently unavailable.

Elizabeth Rather is a total phony --- she has never written a computer program in her life --- ANS-Forth is a cult founded upon a priestess channeling an unavailable god.

Think about this: If you were a long-dead Pharaoh or a wise space-alien or Chuck Moore and you were actively trying to save humanity, why would you communicate only with one person rather than with everybody, and why would you pick an idiot?

Think about this: Maybe the gods aren't actively trying to save humanity because they don't really give a damn --- we are going to have to think for ourselves --- we are not going to progress until we stop faking it and get real.

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

#40867

Paul Rubin wrote:
> ...
> The genius of Forth was realizing this situation doesn't occur all that
> often.  But it does sometimes occur.  Chuck's code uses VARIABLEs rather
> freely to deal with it when it arises.  That means you either burn RAM
> by permanently allocating a cell for each such variable even when
> they're not simultaneously in use, or else you have to carefully track
> which ones might overlap during nested calls.  You also must handle the
> possibility of such variables being used by multiple words.  Better is
> to use stack-like allocation for them, plus temporary names, and that
> which is what locals amounts to.

Too complicated.  Use the Forth, Luke.

    0 value LVAR

    : word1
      LVAR >R
      ... do stuff with LVAR ...
      R> TO LVAR ;

    : word2
      LVAR >R
      ... do stuff with LVAR ...
      R> TO LVAR ;

What?  It lacks the eye-candy of ANS/200x locals?  Fortunately my
purpose is to offer a solution to the issues raised in the post - not
promote the concept of locals in Forth which Chuck firmly rejects.

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

#40868

on 28/07/2015 12:06:46, "HAA" wrote:
> Paul Rubin wrote:
>> ...
>> The genius of Forth was realizing this situation doesn't occur all that
>> often.  But it does sometimes occur.  Chuck's code uses VARIABLEs rather
>> freely to deal with it when it arises.  That means you either burn RAM
>> by permanently allocating a cell for each such variable even when
>> they're not simultaneously in use, or else you have to carefully track
>> which ones might overlap during nested calls.  You also must handle the
>> possibility of such variables being used by multiple words.  Better is
>> to use stack-like allocation for them, plus temporary names, and that
>> which is what locals amounts to.
> 
> Too complicated.  Use the Forth, Luke.
> 
> 0 value LVAR
> 
> : word1
> LVAR >R
> ... do stuff with LVAR ...
> R> TO LVAR ;
> 
> : word2
> LVAR >R
> ... do stuff with LVAR ...
> R> TO LVAR ;
> 
> What?  It lacks the eye-candy of ANS/200x locals?  Fortunately my
> purpose is to offer a solution to the issues raised in the post - not
> promote the concept of locals in Forth which Chuck firmly rejects.
> 
> 
> 

Well, there's BASE @ followed by BASE ! to address the problem of
"gratuitous base bashing" (which iirc is from Stephen Pelc). So it has a
history and pedigree.

What we need now is a real retro Forth conversation. I'll start with my
pet hate; >BODY ! on bodies one should never bang.

: inconstant create , does> @ ;
5 inconstant x
6 ' x >body !

 

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

#40745

Mark Wills wrote:
> ...
> I'm with Raimond :-)
>
> I'm aware that (for some reason) there's a general dislike for local
> variables among Forthers. It's almost like it's a measure of clever
> you are: If you need locals you're not a "real" Forther.

It's a measure of how well you were taught Forth :)  Some quotes from
Jeff Fox ...

"Stacks are great (for Forth) so use them. Chuck has said "Don't use locals."
You have a stack for data, this is Forth, locals are for a whole different picture."

"If it is your habit to use locals then it is likely that [you] don't understand why
locals disrupt Forth factoring, or don't care about that because C factoring
is fine with you."

> I'm all for
> writing code that I and others can understand six months or six years
> from now. That's actually quite hard to do in Forth, especially in
> the lowest levels of an application. Locals in particular help code
> be me much more readable.

This is the "I need to dumb down my code because [insert excuse here]."
argument.  It does Forth no favors.

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

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

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

csiph-web