Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!]

On 15/09/2024 2:10 am, Paul Rubin wrote:

dxf <dxforth@gmail.com> writes:

Compiling under DX-Forth resulted in a code size of 23 and 26 bytes
respectively.  Under VFX ...

 
I can't help it if those compilers generate worse code for the locals
version.  Can you conveniently try lxf?

Windows NT/Forth (32 bit):

( 67 bytes, 19 instructions )
( 87 bytes, 24 instructions )
 

Not only were you able to read forth code, the result was more
efficient.

 
Sometimes it isn't too hard to read, sometimes it takes head scratching,
and sometimes I can't make any sense of it.  The function Anton posted
was an example that didn't make sense.  I remember thinking I might sit
down and try to figure it out to rewrite it, but it doesn't seem worth
the effort.

It would be no different were locals used.  It would still require one to
sit down and figure out what the code did.  The more experienced one is in
the language the easier it is.

Going back to the EMITS example:

- despite lack of comments you quickly deduced what it did
- stack operations were few and simple and still you didn't like it
- your ideal is that every stack operation should go, which is what
  you did

If one takes from forth that which makes it efficient, then one takes away
its reason for existence.  Unfortunately for forth, this is what locals
users are doing, whether they're aware of it or not.
 

Anyway, if efficiency was important for that example, I'd use CODE.

In other words forth is not important to you.  I understand.  You've stated
Python is your language of preference.  Forth is mine and I'll program it
the best way I know how.