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

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

Re: [Poll] Computing favorities

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Poll] Computing favorities Roberto Waltman <usenet@rwaltman.com> - 2015-10-10 19:28 -0400
    Re: [Poll] Computing favorities lehs <skydda.barnen@gmail.com> - 2015-10-11 01:27 -0700
      Re: [Poll] Computing favorities franck.bensusan@gmail.com - 2015-10-11 07:24 -0700
        Re: [Poll] Computing favorities hughaguilar96@gmail.com - 2015-10-11 16:31 -0700
          Re: [Poll] Computing favorities Mark Wills <markwills1970@gmail.com> - 2015-10-12 01:55 -0700
            Re: [Poll] Computing favorities anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2015-10-12 09:14 +0000
        Re: [Poll] Computing favorities Howerd <howerdo@yahoo.co.uk> - 2015-10-12 01:04 -0700
      Re: [Poll] Computing favorities "WJ" <w_a_x_man@yahoo.com> - 2015-10-12 09:20 +0000
        Re: [Poll] Computing favorities lehs <skydda.barnen@gmail.com> - 2015-10-12 12:34 -0700
          Re: [Poll] Computing favorities hughaguilar96@gmail.com - 2015-10-12 17:07 -0700
            Re: [Poll] Computing favorities rickman <gnuarm@gmail.com> - 2015-10-12 21:20 -0400
    Re: [Poll] Computing favorities lehs <skydda.barnen@gmail.com> - 2015-10-13 13:05 -0700
      Re: [Poll] Computing favorities lehs <skydda.barnen@gmail.com> - 2015-10-13 13:08 -0700

#42554 — Re: [Poll] Computing favorities

Gordon Henderson wrote:

>>> Not sure of the relevance of this. I am running FreeBSD on a PC. The 
>>> loader is written in Forth.
>>
>>The relevance is that Sun hardware booted up using Forth.
>
>I ported the Sun OpenBootProm to some custom designed sparc hardware once
>upon about 2.6 decades ago... It was an interesting system that one purpose was
>to allow plug-in cards (which contained compiled Forth byte code) to run
>on either the older 68040 or newer Sparc CPU architecture at the time,
>although by the time I was using it, the 68040 was more or less obsolete.
>
>Each card could insert itself into the device tree and be initialised
>by the OBP before unix started up then (IIRC) the device information was
>passed into unix but that wasn't my job at the time...
>
>Despite using it, hacking it, writing lots of code in it, I'm still not a
>big fan of Forth.  I can see its advantages in some instances but I feel
>it needs a certian amount of latteral thinking to really get "into" it.

Happens ... See:
   http://yosefk.com/blog/my-history-with-forth-stack-machines.html

R.W.

[Added comp.lang.forth]

>It can produce very compact code though - so the Jupiter Ace which had only 1K
>of RAM (or was it 4K?) worked very well and the editor would de-compile the
>byte code, then re-compile it into the system.
>
>Gordon

[toc] | [next] | [standalone]

#42571

Den söndag 11 oktober 2015 kl. 01:28:14 UTC+2 skrev Roberto Waltman:
> Gordon Henderson wrote:
> 
> >>> Not sure of the relevance of this. I am running FreeBSD on a PC. The 
> >>> loader is written in Forth.
> >>
> >>The relevance is that Sun hardware booted up using Forth.
> >
> >I ported the Sun OpenBootProm to some custom designed sparc hardware once
> >upon about 2.6 decades ago... It was an interesting system that one purpose was
> >to allow plug-in cards (which contained compiled Forth byte code) to run
> >on either the older 68040 or newer Sparc CPU architecture at the time,
> >although by the time I was using it, the 68040 was more or less obsolete.
> >
> >Each card could insert itself into the device tree and be initialised
> >by the OBP before unix started up then (IIRC) the device information was
> >passed into unix but that wasn't my job at the time...
> >
> >Despite using it, hacking it, writing lots of code in it, I'm still not a
> >big fan of Forth.  I can see its advantages in some instances but I feel
> >it needs a certian amount of latteral thinking to really get "into" it.
> 
> Happens ... See:
>    http://yosefk.com/blog/my-history-with-forth-stack-machines.html
> 
> R.W.
> 
> [Added comp.lang.forth]
> 
> >It can produce very compact code though - so the Jupiter Ace which had only 1K
> >of RAM (or was it 4K?) worked very well and the editor would de-compile the
> >byte code, then re-compile it into the system.
> >
> >Gordon

In the link above Charles Moore is cited:

"I remain adamant that local variables are not only useless, they are harmful.

If you are writing code that needs them you are writing non-optimal code. Don't use local variables. Don't come up with new syntax for describing them and new schemes for implementing them. You can make local variables very efficient especially if you have local registers to store them in, but don't. It's bad. It's wrong.

It is necessary to have [global] variables. ... I don't see any use for [local] variables which are accessed instantaneously."

I agree to avoid locals in the final product - that isn't optimal - but there really are some psychological problems with Forth. The alongside thinking about optimal stack organization and optimal factoring *could* counteract on becoming process.

There couldn't be a less complex way to store the binaries in the computer memory than Forth. An intelligent human can high level communicate with the dumb computer almost in it's native language, and the communication results in a totally predictable code and execution. It's a good thing that the human govern over the stack, but a bad thing that this alongside thinking *might* stopping up the main process of realizing the idea of the program.

If there had been cheep memory at the time when Moore designed Forth, I'm almost sure he had played with the idea of implementing several datastacks to simplify the organization of the important parameter stack, where all the arithmetic is done.

I use such stacks, even if they are not optimally implemented (and even locals), as psychological aids in the becoming of programs. Then I can concentrate on the main ideas, which can be difficult as such to realize. Psychological aids are like oil in the machinery of thinking. Since I'm not a professional I don't have to walk the pirates plank when failing, so there are a lots of words of mine that never where completed because of parameter stack shambles.

When the program is functioning one will do what it takes to optimize.

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

#42574

Le dimanche 11 octobre 2015 10:27:22 UTC+2, lehs a écrit :
> In the link above Charles Moore is cited:
> 
> "I remain adamant that local variables are not only useless, they are harmful.
> 
> If you are writing code that needs them you are writing non-optimal code. Don't use local variables. Don't come up with new syntax for describing them and new schemes for implementing them. You can make local variables very efficient especially if you have local registers to store them in, but don't. It's bad. It's wrong.
> 
> It is necessary to have [global] variables. ... I don't see any use for [local] variables which are accessed instantaneously."
> 
> I agree to avoid locals in the final product - that isn't optimal - but there really are some psychological problems with Forth. The alongside thinking about optimal stack organization and optimal factoring *could* counteract on becoming process.
> 
> There couldn't be a less complex way to store the binaries in the computer memory than Forth. An intelligent human can high level communicate with the dumb computer almost in it's native language, and the communication results in a totally predictable code and execution. It's a good thing that the human govern over the stack, but a bad thing that this alongside thinking *might* stopping up the main process of realizing the idea of the program.
> 
> If there had been cheep memory at the time when Moore designed Forth, I'm almost sure he had played with the idea of implementing several datastacks to simplify the organization of the important parameter stack, where all the arithmetic is done.
> 
> I use such stacks, even if they are not optimally implemented (and even locals), as psychological aids in the becoming of programs. Then I can concentrate on the main ideas, which can be difficult as such to realize. Psychological aids are like oil in the machinery of thinking. Since I'm not a professional I don't have to walk the pirates plank when failing, so there are a lots of words of mine that never where completed because of parameter stack shambles.
> 
> When the program is functioning one will do what it takes to optimize.

Hello,

I didn't know about this citation of Charles Moore.
Is this from where all those discussions about locals usage come from ?

Well ... I disagree with this position. Here is mine (sorry, a long one) : 

Everybody needs and manages locals : a local is just an temporary information
local to a word that will die with this word.

The parameter stack has a good name : it holds parameters of a word and 
is used to compute the value(s) returned. And, sometimes, the computation 
of the returned value(s) is not easy and need one or more temporary 
values : a local.

There are perhap's others, but I can think about 8 ways to manage 
a local into a word : 

X) Declaring a global variable.

0) Bad factoring of the word into subwords just to not use a local.

1) Use an auxiliary stack to store the local.

2) Use words like >R, R>, ... to store the local on the return stack.

3) Use the parameter stack to keep the local while computing the result 
of a word, using stack operations.

4) Use words like I, J, ...

5) Use a named local (whatever the syntax is).

6) Use good factoring of the word into factors (or use of a quotation). 

I have sorted this list according what I think of them (worst to best).

1&2) For me, 1) and 2) to manage locals are not good :
- Locals are ordered and the programmer must keep this order in mind.
- They must be explicity removed before leaving the word.
- They need caution when used with other syntax (loops, ...).
- They are less performant.

imo, >R, R>, ... are archaic, non performant words to manage a word locals.
I can't find any good reason to use them.
Perhap's one : this is fun to write (but not to read or debug).

3) Using the stack is mostly a coding style but there will always be situations 
where it is not possible or too confusing.
My personal coding style is to use the parameter stack to hold and compute the
returns value and to use locals when this computation leads to too many 
stack juggling (for instance, when a >R comes on my mind).
Also, this stack juggling is often less performant than a named local.

4) I and J are named locals, but they also have restrictions with 
other syntax constructions.
But, at least, they are automatically handled by the word and you
don't bother where they are stored.

5) A named local : 
- Is not ordered
- Is autoamtically handled by the word (creation, where, and destruction).
- Does not interfere with other syntaxes.
- They are fast.
- The name gives crucial information to the ones that will read the code.

imo, it is the best choice after a good factoring of the word.

6) Factoring.
Before using a local, factoring a word should always be the first choice.
But a good factor should : 
- Have a functional name and its proper life and purpose.
- Make sense into the word list.
- Should be reusable outside the parent word.

I will not factorize a word and polluate the word list just in order to not 
use a local. Doing this is, for me, a bad choice (0) because it has a
global impact for a local problem.

X) But, the worst of all, for me, is probably declaring a global variable.
Not only this polluate the dictionary but declaring a global variable to 
resolve a local problem is, imo, a mistake : this is prone to side effects
, links the word's behaviour to external manipulations and is totally
irrevelant in a multi-tasking context. 

If functional programming learned me one thing, it is that, when you give 
the same input to a word, it should always return the same result. 
You test it one time, it will work forever... And this is never guaranted
if the word uses a global variable.
Even if they are sometimes necessary, global variables are at the opposite 
of what I think is good programming.

That's it.
 
But let me be clear : I will never say to use a named local when a local is 
not needed and the parameter stack is enough (or a good factoring is possible) to compute the result. 

Of course, if someone does not factor words or write something like : 
: plus(a, b) a b + ;
instead of
: plus + ;
he will loose all what makes Forth strenght.

If this is what Charles Moore had in mind, I fully agree with him. 

But, because of this risk, deciding that named locals are bad and 
using >R, R> words to manage a word locals (or worse, using a global variable) is, for me, a nonsense.
If they are other reasons for this position, I would be very interested to 
hear them (and even change my mind if they are good reasons).

Again, sorry for the size of this (non Forth-ish ?) post...

Regards,
Franck

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

#42582

On Sunday, October 11, 2015 at 7:24:07 AM UTC-7, franck....@gmail.com wrote:
> Le dimanche 11 octobre 2015 10:27:22 UTC+2, lehs a écrit :
> > In the link above Charles Moore is cited:
> > 
> > "I remain adamant that local variables are not only useless, they are harmful.
> ...
> Of course, if someone does not factor words or write something like : 
> : plus(a, b) a b + ;
> instead of
> : plus + ;
> he will loose all what makes Forth strenght.
> 
> If this is what Charles Moore had in mind, I fully agree with him. 
> 
> But, because of this risk, deciding that named locals are bad and 
> using >R, R> words to manage a word locals (or worse, using a global variable) is, for me, a nonsense.
> If they are other reasons for this position, I would be very interested to 
> hear them (and even change my mind if they are good reasons).
> 
> Again, sorry for the size of this (non Forth-ish ?) post...
> 
> Regards,
> Franck

Your post was very Forthish --- everything you said was relevant to Forth --- I agree with you.

It is a bad idea to make categorical imperatives such as: "I remain adamant that local variables are not only useless, they are harmful."

Overuse of locals, as typically done by recalcitrant C programmers, is definitely harmful (such as your PLUS example above). On the other hand, if a programmer is using >R to put multiple data on the return-stack, then he should consider using locals instead --- I generally only use >R for one datum --- and, the use of global variables is very bad for all of the reasons that you stated.

In my Stundurd document I discuss when locals should be used and when they shouldn't be used. I have quotations that have access to the parent function's locals --- but, on the other hand, I don't recommend that local variables be used willy-nilly --- I'm not trying to turn Forth into Algol.
http://www.forth.org/Stundurd.txt

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

#42595

On Monday, 12 October 2015 00:31:51 UTC+1, hughag...@gmail.com  wrote:
> Overuse of locals, as typically done by recalcitrant C programmers, is definitely harmful (such as your PLUS example above). On the other hand, if a programmer is using >R to put multiple data on the return-stack, then he should consider using locals instead --- I generally only use >R for one datum --- and, the use of global variables is very bad for all of the reasons that you stated.

Here here. Couldn't agree more.

Use of locals can speed up your code:

1) You can reduce (or entirely remove) stack thrashing
2) The locals may be placed in CPU registers, depending on compiler
   ability.

Some folk need to get out of the 70s and at least into, say, the 90s!

The only thing I don't like about locals is the ass-backwards syntax.
Fixed in 200x IIRC. The other thing is, I wouldn't have made it so
that locals are initialised from the stack. You don't always want 
that; sometimes your local will want to be initialised from the 
result of a call to a word. Of course, you can do that with 200x
locals, however, you'd need to supply a dummy 0 on the stack to 
initialise the local variable. That adds confusion and is superfluous
imo. It's a minor niggle however.

In my system locals are not initialised from the data stack at
all. They're just initialised to 0. You use SET to load them with
values:

: do-a-thing ( -- )
  locals{ tom dick harry }
  do-this set tom
  do-that set dick
  do-the-other set harry 
  tom dick harry or or if okay else tilt then ;

Simple simple simple.

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

#42598

Mark Wills <markwills1970@gmail.com> writes:
>The other thing is, I wouldn't have made it so
>that locals are initialised from the stack. You don't always want=20
>that; sometimes your local will want to be initialised from the=20
>result of a call to a word. Of course, you can do that with 200x
>locals, however, you'd need to supply a dummy 0 on the stack to=20
>initialise the local variable. That adds confusion and is superfluous
>imo. It's a minor niggle however.
>
>In my system locals are not initialised from the data stack at
>all. They're just initialised to 0. You use SET to load them with
>values:
>
>: do-a-thing ( -- )
>  locals{ tom dick harry }
>  do-this set tom
>  do-that set dick
>  do-the-other set harry=20
>  tom dick harry or or if okay else tilt then ;

Simpler to program in Gforth:

: do-a-thing ( -- )
  do-this { tom }
  do-that { dick }
  do-the-other { harry }
  tom dick harry or or if okay else tilt then ;

If you want to be Forth-2012 compliant, You can do it your way with
slightly different syntax:

: do-a-thing ( -- )
  {: | tom dick harry :}
  do-this to tom
  do-that to dick
  do-the-other to harry
  tom dick harry or or if okay else tilt then ;

Also, you might want to choose an example where avoiding locals would
result in a lot of stack juggling, unlike here:

: do-a-thing ( -- )
  do-this do-that do-the-other or or if okay else tilt then ;

- 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.rigwit.co.uk/EuroForth2015/

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

#42594

On Sunday, 11 October 2015 15:24:07 UTC+1, franck....@gmail.com  wrote:
> Le dimanche 11 octobre 2015 10:27:22 UTC+2, lehs a écrit :
> > In the link above Charles Moore is cited:
> > 
> > "I remain adamant that local variables are not only useless, they are harmful.
> > 
> > If you are writing code that needs them you are writing non-optimal code. Don't use local variables. Don't come up with new syntax for describing them and new schemes for implementing them. You can make local variables very efficient especially if you have local registers to store them in, but don't. It's bad. It's wrong.
> > 

> > It is necessary to have [global] variables. ... I don't see any use for [local] variables which are accessed instantaneously."
> > 
> > I agree to avoid locals in the final product - that isn't optimal - but there really are some psychological problems with Forth. The alongside thinking about optimal stack organization and optimal factoring *could* counteract on becoming process.
> > 
> > There couldn't be a less complex way to store the binaries in the computer memory than Forth. An intelligent human can high level communicate with the dumb computer almost in it's native language, and the communication results in a totally predictable code and execution. It's a good thing that the human govern over the stack, but a bad thing that this alongside thinking *might* stopping up the main process of realizing the idea of the program.
> > 
> > If there had been cheep memory at the time when Moore designed Forth, I'm almost sure he had played with the idea of implementing several datastacks to simplify the organization of the important parameter stack, where all the arithmetic is done.
> > 
> > I use such stacks, even if they are not optimally implemented (and even locals), as psychological aids in the becoming of programs. Then I can concentrate on the main ideas, which can be difficult as such to realize. Psychological aids are like oil in the machinery of thinking. Since I'm not a professional I don't have to walk the pirates plank when failing, so there are a lots of words of mine that never where completed because of parameter stack shambles.
> > 
> > When the program is functioning one will do what it takes to optimize.
> 
> Hello,
> 
> I didn't know about this citation of Charles Moore.
> Is this from where all those discussions about locals usage come from ?
> 
> Well ... I disagree with this position. Here is mine (sorry, a long one) : 
> 
> Everybody needs and manages locals : a local is just an temporary information
> local to a word that will die with this word.
> 
> The parameter stack has a good name : it holds parameters of a word and 
> is used to compute the value(s) returned. And, sometimes, the computation 
> of the returned value(s) is not easy and need one or more temporary 
> values : a local.
> 
> There are perhap's others, but I can think about 8 ways to manage 
> a local into a word : 
> 
> X) Declaring a global variable.
> 
> 0) Bad factoring of the word into subwords just to not use a local.
> 
> 1) Use an auxiliary stack to store the local.
> 
> 2) Use words like >R, R>, ... to store the local on the return stack.
> 
> 3) Use the parameter stack to keep the local while computing the result 
> of a word, using stack operations.
> 
> 4) Use words like I, J, ...
> 
> 5) Use a named local (whatever the syntax is).
> 
> 6) Use good factoring of the word into factors (or use of a quotation). 
> 
> I have sorted this list according what I think of them (worst to best).
> 
> 1&2) For me, 1) and 2) to manage locals are not good :
> - Locals are ordered and the programmer must keep this order in mind.
> - They must be explicity removed before leaving the word.
> - They need caution when used with other syntax (loops, ...).
> - They are less performant.
> 
> imo, >R, R>, ... are archaic, non performant words to manage a word locals.
> I can't find any good reason to use them.
> Perhap's one : this is fun to write (but not to read or debug).
> 
> 3) Using the stack is mostly a coding style but there will always be situations 
> where it is not possible or too confusing.
> My personal coding style is to use the parameter stack to hold and compute the
> returns value and to use locals when this computation leads to too many 
> stack juggling (for instance, when a >R comes on my mind).
> Also, this stack juggling is often less performant than a named local.
> 
> 4) I and J are named locals, but they also have restrictions with 
> other syntax constructions.
> But, at least, they are automatically handled by the word and you
> don't bother where they are stored.
> 
> 5) A named local : 
> - Is not ordered
> - Is autoamtically handled by the word (creation, where, and destruction).
> - Does not interfere with other syntaxes.
> - They are fast.
> - The name gives crucial information to the ones that will read the code.
> 
> imo, it is the best choice after a good factoring of the word.
> 
> 6) Factoring.
> Before using a local, factoring a word should always be the first choice.
> But a good factor should : 
> - Have a functional name and its proper life and purpose.
> - Make sense into the word list.
> - Should be reusable outside the parent word.
> 
> I will not factorize a word and polluate the word list just in order to not 
> use a local. Doing this is, for me, a bad choice (0) because it has a
> global impact for a local problem.
> 
> X) But, the worst of all, for me, is probably declaring a global variable.
> Not only this polluate the dictionary but declaring a global variable to 
> resolve a local problem is, imo, a mistake : this is prone to side effects
> , links the word's behaviour to external manipulations and is totally
> irrevelant in a multi-tasking context. 
> 
> If functional programming learned me one thing, it is that, when you give 
> the same input to a word, it should always return the same result. 
> You test it one time, it will work forever... And this is never guaranted
> if the word uses a global variable.
> Even if they are sometimes necessary, global variables are at the opposite 
> of what I think is good programming.
> 
> That's it.
>  
> But let me be clear : I will never say to use a named local when a local is 
> not needed and the parameter stack is enough (or a good factoring is possible) to compute the result. 
> 
> Of course, if someone does not factor words or write something like : 
> : plus(a, b) a b + ;
> instead of
> : plus + ;
> he will loose all what makes Forth strenght.
> 
> If this is what Charles Moore had in mind, I fully agree with him. 
> 
> But, because of this risk, deciding that named locals are bad and 
> using >R, R> words to manage a word locals (or worse, using a global variable) is, for me, a nonsense.
> If they are other reasons for this position, I would be very interested to 
> hear them (and even change my mind if they are good reasons).
> 
> Again, sorry for the size of this (non Forth-ish ?) post...
> 
> Regards,
> Franck

Hi Franck,

SwiftForth has R-BUF to deal with Windows APIs without using locals.
From core.f :
{ ------------------------------------------------------------------------
Return stack workspace allocation

A provision to allocate temporary data space on the return stack
makes many windows-related programming tasks easier.  The space is
allocated in bytes by the R-ALLOC function which returns the
address of the space allocated. The space is automatically
de-allocated when the calling routine executes a return.

The trick is that R-ALLOC intercepts its return address before
completing, and by calling R-GO-ON to do its return, pushes a
new return address for the eventual return from its caller
to come back to and thereby restore the return stack.

Do not use this after a >R operation or inside a DO..LOOP !
------------------------------------------------------------------------ }

I think locals are bad because they add a syntactic layer that makes everything else more complicated. R-BUF provides similar functionality without doing that.
But you only need either locals or R-BUF when interfacing to something like Windows...

Best regards,
Howerd

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

#42597

lehs wrote:

> In the link above Charles Moore is cited:
> 
> "I remain adamant that local variables are not only useless,
> they are harmful.
> 
> "If you are writing code that needs them you are writing
> non-optimal code. Don't use local variables. Don't come up
> with new syntax for describing them and new schemes for
> implementing them. You can make local variables very efficient
> especially if you have local registers to store them in, but
> don't. It's bad. It's wrong.

I.e., wicked, sinful, intolerable, and heathenish.

Chuck seems to have been an obsessive-compulsive type,
a perfectionist who felt very insecure when he could
not examine and understand every byte and bit of a
software system.

If you don't use locals, then in order to keep the code
readable and avoid stack-juggling you must do an extreme
amount of factoring.  This creates a problem.  You have
defined such a multitude of words that you cannot remember all
of them and what they do.  And in order to try to help
yourself remember the words and what they do, you have to rack
your brains and waste a lot of time coming up with just the
right names for the words.

Just about every language uses locals extensively. If Chucky
is right, then there are no programs in those languages that
contain optimal code.  I find it impossible to believe that
code in C that uses locals is always non-optimal. It is very
difficult to find any Forth compiler that can come close to
matching the speed of programs produced by a top-notch C compiler.
And C code tends to be more readable than Forth code.

So when little Chucky whined that locals are evil, and that
those who use them are moral reprobates, what he really meant
was that they worried and frightened him.

It seems to me that Chucky would be out of his element
if he were assigned the task of writing a program larger
and more complex than one that flushes a toilet.


"We should forget about small efficiencies, say about 97% of
the time: premature optimization is the root of all evil."
--- Donald Knuth


: BOXTEST ( length width height -- )
    6 > ROT 22 > ROT 19 > AND AND
    IF ." Big enough " THEN ;

Wow.  Talk about code that is not "optimal".
Using Chucky's Forth, logical operators are not short-circuiting.
Extremely crude and primitive and cumbersome.
Easy for the language implementor, difficult for the language user.
The resulting program is not efficient, and programming in the
language is grossly inefficient.

And tell me quickly, what is the minimal value for width?

: boxtest { len wd ht -- }
  len 22 >
  wd 19 >
  ht 6 >
  and and  if ." Big enough." then ;

Which is more readable and understandable?
Which is more maintainable?
With which, by inspection, do you have a better chance of
determining its correctness?

From Structure and Interpretation of Computer Programs:

"First, we want to establish the idea that a computer language
is not just a way of getting a computer to perform operations,
but rather that it is a novel formal medium for expressing
ideas about methodology.  Thus, programs must be written
for people to read, and only incidentally for machines to
execute."

-- 
Therefore, a dying empire and its fearful elite is always willing to resort to
massive violence against the citizens of the empire in order to turn them into
slaves.  www.kolumbus.fi/aquilon/america-middle-class-and-the-end-of-growth.htm

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

#42604

Den måndag 12 oktober 2015 kl. 11:22:53 UTC+2 skrev WJ:
> lehs wrote:
> 
> > In the link above Charles Moore is cited:
> > 
> > "I remain adamant that local variables are not only useless,
> > they are harmful.
> > 
> > "If you are writing code that needs them you are writing
> > non-optimal code. Don't use local variables. Don't come up
> > with new syntax for describing them and new schemes for
> > implementing them. You can make local variables very efficient
> > especially if you have local registers to store them in, but
> > don't. It's bad. It's wrong.
> 
> I.e., wicked, sinful, intolerable, and heathenish.
> 
> Chuck seems to have been an obsessive-compulsive type,
> a perfectionist who felt very insecure when he could
> not examine and understand every byte and bit of a
> software system.
> 
> If you don't use locals, then in order to keep the code
> readable and avoid stack-juggling you must do an extreme
> amount of factoring.  This creates a problem.  You have
> defined such a multitude of words that you cannot remember all
> of them and what they do.  And in order to try to help
> yourself remember the words and what they do, you have to rack
> your brains and waste a lot of time coming up with just the
> right names for the words.
> 
> Just about every language uses locals extensively. If Chucky
> is right, then there are no programs in those languages that
> contain optimal code.  I find it impossible to believe that
> code in C that uses locals is always non-optimal. It is very
> difficult to find any Forth compiler that can come close to
> matching the speed of programs produced by a top-notch C compiler.
> And C code tends to be more readable than Forth code.
> 
> So when little Chucky whined that locals are evil, and that
> those who use them are moral reprobates, what he really meant
> was that they worried and frightened him.
> 
> It seems to me that Chucky would be out of his element
> if he were assigned the task of writing a program larger
> and more complex than one that flushes a toilet.
> 
> 
> "We should forget about small efficiencies, say about 97% of
> the time: premature optimization is the root of all evil."
> --- Donald Knuth
> 
> 
> : BOXTEST ( length width height -- )
>     6 > ROT 22 > ROT 19 > AND AND
>     IF ." Big enough " THEN ;
> 
> Wow.  Talk about code that is not "optimal".
> Using Chucky's Forth, logical operators are not short-circuiting.
> Extremely crude and primitive and cumbersome.
> Easy for the language implementor, difficult for the language user.
> The resulting program is not efficient, and programming in the
> language is grossly inefficient.
> 
> And tell me quickly, what is the minimal value for width?
> 
> : boxtest { len wd ht -- }
>   len 22 >
>   wd 19 >
>   ht 6 >
>   and and  if ." Big enough." then ;
> 
> Which is more readable and understandable?
> Which is more maintainable?
> With which, by inspection, do you have a better chance of
> determining its correctness?
> 
> From Structure and Interpretation of Computer Programs:
> 
> "First, we want to establish the idea that a computer language
> is not just a way of getting a computer to perform operations,
> but rather that it is a novel formal medium for expressing
> ideas about methodology.  Thus, programs must be written
> for people to read, and only incidentally for machines to
> execute."
> 
> -- 
> Therefore, a dying empire and its fearful elite is always willing to resort to
> massive violence against the citizens of the empire in order to turn them into
> slaves.  www.kolumbus.fi/aquilon/america-middle-class-and-the-end-of-growth.htm

We shouldn't be so jealous on Moore. His wonderful invention should make us happy not angry. And he sure got the right to have an opinion, specially in this topic.

But in my opinion he is wrong about locals. Locals make things happening and make code readable. I guess you have to be a marvelous programmer to work for Moore. Or you had to walk the plank. Maybe..? :)

But ordinary programmers can be helped by locals, occasionally.

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

#42611

On Monday, October 12, 2015 at 12:34:54 PM UTC-7, lehs wrote:
> Den måndag 12 oktober 2015 kl. 11:22:53 UTC+2 skrev WJ:
> > ...
> 
> We shouldn't be so jealous on Moore. His wonderful invention should make us happy not angry. And he sure got the right to have an opinion, specially in this topic.

It is not worth responding to WJ as he is just a troll. When he refers to Charles Moore as "little Chucky" he is trying to bait us. AFAIK, WJ doesn't program in Forth at all --- all of the source code that he posts is in other languages (mostly Gauche Scheme).

As you say, he does have a right to have an opinion, especially on the subject of Forth.
 
> But in my opinion he is wrong about locals. Locals make things happening and make code readable. I guess you have to be a marvelous programmer to work for Moore. Or you had to walk the plank. Maybe..? :)
> 
> But ordinary programmers can be helped by locals, occasionally.

I said earlier that Charles Moore was wrong to say: "I remain adamant that local variables are not only useless, they are harmful." Such categorical imperatives are almost never a good idea, as there are always extenuating circumstances.

It is not a good idea however to denounce a person for being wrong based on out-of-context quotes. Whether he is really this adamant in practice, I don't know. Also, I don't know when this quote was said; if it was in the 1970s, he may have changed his opinion since then; I know I have learned a lot of new things since the 1970s, and changed my opinion on several subjects. In my Stundurd document I made a reference to this meme:
http://memegenerator.net/instance/53401411

It is also not a good idea to become a hero-worshiping fan-boy or groupie. This was what originally offended me about Elizabeth Rather, way back in 2009 when I first arrived on comp.lang.forth. When I said that ANS-Forth should have D/ and that I needed it for my continued-fraction program, she said this:

On Friday, November 20, 2009 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 

Here is another example:

On Monday, October 12, 2015 at 12:22:47 AM UTC-7, Elizabeth D. Rather wrote:
> Every Forth I've ever used since 1971 has had a multitasker. Designs 
> have evolved in detail over the years, but the basic principles of 
> Chuck's design have been solid. Like all Chuck's designs, his 
> multitaskers are quite different from conventional computer-science 
> designs (simpler, smaller, and faster), but are rock solid and have been 
> utterly reliable in challenging real-time applications with lifetimes of 
> 10 years or more. The basic principles of the SwiftOS Multitasker are 
> described in Forth Application Techniques.
> ...
> Cheers,
> Elizabeth

On comp.lang.forth we really have too much hot air on the subject of "thinking differently" and not enough actual thinking --- we are supposed to be programmers, not cheerleaders for Chuck Moore the one-man programming wonder.

It may be that people can always find quotes from Charles Moore that make it seem as if he is supporting their opinion (similar to how people can always find quotes from the Bible that make it seem as if God is supporting their opinion). I have never met Charles Moore, so I don't know what he is like. Given all these quotes that people are always trotting out, it seems likely that he would absolutely hate my Stundurd Forth and would say: "Everybody on comp.lang.forth is right about you! You really know nothing about Forth! Your Stundurd is not Standard, so you're not a Forth programmer!" On the other hand, the fact that he never shows up on comp.lang.forth seems to imply that he is not in total agreement with the comp.lang.forth crowd who are endlessly claiming that he is in total agreement with them and trot out quotes from him to prove it.

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

#42614

On 10/12/2015 8:07 PM, hughaguilar96@gmail.com wrote:
> On Monday, October 12, 2015 at 12:34:54 PM UTC-7, lehs wrote:
>> Den måndag 12 oktober 2015 kl. 11:22:53 UTC+2 skrev WJ:
>>> ...
>>
>> We shouldn't be so jealous on Moore. His wonderful invention should make us happy not angry. And he sure got the right to have an opinion, specially in this topic.
>
> It is not worth responding to WJ as he is just a troll. When he refers to Charles Moore as "little Chucky" he is trying to bait us.

OMG!  The irony is just too precious!!!

Notice I snipped the many paragraphs of troll style ranting about Ms. 
Rather.

Meanwhile he ignores my posts where I try to have a rational discussion 
with him.  Clearly he is very upset with me.

-- 

Rick

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

#42625

Charles Moore said: Let there be simplicity! And there was simplicity. And he saw that simplicity was alright. Then come the devil with locals...

But what about this? 

*Global* stacks:

: clst ( ad -- )  dup ! ;
: stdrops ( m ad -- )  swap cells negate swap +! ; 
: stdrop ( ad -- ) -cell swap +! ;
: >st ( n ad -- )  cell over +! @ ! ;
: st> ( ad -- n )  dup @ @ -cell rot +! ;
: >st> ( n ad -- m )  dup @ @ -rot @ ! ;
: st@ ( ad -- n )  @ @ ;
: st! ( n ad -- )  @ ! ;
: st+! ( n ad -- )  @ +! ;
: stpick ( m ad -- xm )  @ swap cells - @ ;
: stpatch ( n m ad -- )  @ swap cells - ! ;
: stpatad ( n m ad -- )  @ swap cells - +! ;
: stdepth ( ad -- n )  dup @ swap - lcell rshift ;

: .st \ ad -- 
  dup @ cell+ swap cell+
  ?do i @ . cell
  +loop ;

: >st# \ xn ... x1 n ad -- 
  swap 0
  ?do cell over +! swap over @ !
  loop drop ;

: stack \ size -- 
  allocate throw dup constant clst ;

256 stack castackstrophe-eliminator

1 2 3 4 5 5 >st# castackstrophe-eliminator
castackstrophe-eliminator .st

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

#42626

Den tisdag 13 oktober 2015 kl. 22:05:58 UTC+2 skrev lehs:
> Charles Moore said: Let there be simplicity! And there was simplicity. And he saw that simplicity was alright. Then come the devil with locals...
> 
> But what about this? 
> 
> *Global* stacks:
> 
> : clst ( ad -- )  dup ! ;
> : stdrops ( m ad -- )  swap cells negate swap +! ; 
> : stdrop ( ad -- ) -cell swap +! ;
> : >st ( n ad -- )  cell over +! @ ! ;
> : st> ( ad -- n )  dup @ @ -cell rot +! ;
> : >st> ( n ad -- m )  dup @ @ -rot @ ! ;
> : st@ ( ad -- n )  @ @ ;
> : st! ( n ad -- )  @ ! ;
> : st+! ( n ad -- )  @ +! ;
> : stpick ( m ad -- xm )  @ swap cells - @ ;
> : stpatch ( n m ad -- )  @ swap cells - ! ;
> : stpatad ( n m ad -- )  @ swap cells - +! ;
> : stdepth ( ad -- n )  dup @ swap - lcell rshift ;
> 
> : .st \ ad -- 
>   dup @ cell+ swap cell+
>   ?do i @ . cell
>   +loop ;
> 
> : >st# \ xn ... x1 n ad -- 
>   swap 0
>   ?do cell over +! swap over @ !
>   loop drop ;
> 
> : stack \ size -- 
>   allocate throw dup constant clst ;
> 
> 256 stack castackstrophe-eliminator
> 
> 1 2 3 4 5 5 >st# castackstrophe-eliminator
> castackstrophe-eliminator .st

Correction:
 1 2 3 4 5 5 castackstrophe-eliminator >st#
> castackstrophe-eliminator .st

[toc] | [prev] | [standalone]

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

csiph-web