Re: Local variables controversial?



>Local variables controversial?

> 6 of 7
>Date: Thurs 21 Jul 2005 20:33
>From: "Julian V. Noble"

>Elizabeth D Rather wrote:

>> "Julian V. Noble" <jvn@xxxxxxxxxxxx> wrote in message
>> news:42DFC964.9448E800@xxxxxxxxxxxxxxx

>>> As several thoughtful people have already answered this, I will keep my
>>> own take brief.

>> Indeed. Jeff Fox has quoted my statements on the subject pretty accurately,
>> so I won't repeat them.

>>> IMO locals simplify code that would otherwise require major stack
>>> juggling.
>>> If you are working with geometrical entities you might need, e.g., to
>>> specify
>>> the end points of a line in the plane. That's 4 coordinates, meaning that
>>> if you keep them on the stack the stack is minimally 4 deep, not to mention
>>> intermediate results you might need to put on the stack. If you need to
>>> use the end points several times within a word you are sunk. It gets very
>>> long.

>>> Well, you can put the coordinates in an array, or you can CREATE a
>>> defining word for end points, to get them off the stack and keep them someplace
>>> where they can be reused. But those are permanent data structures, i.e.
>>> "garbage"
>>> that might ultimately need to be "collected" (i.e. their memory reclaimed)
>>> in a memory-limited environment.

>> Graphics always comes up when locals are discussed. I have done quite a lot
>> of graphics work in the past, though not recently. I can summarize my
>> approach (originally developed by Chuck Moore):

>> 1. A vector is represented on the stack as 2 cells, with X on the top and Y
>> beneath (then Z, if it's 3D). It's more convenient to keep X on top because
>> it usually changes faster.

>> 2. Write some vector operators to do common things in an optimized fashion
>> (meaning code). Usually V+, V-, V*/ (multiply a vector by a ratio of
>> scalars), maybe more. Yes, they're CPU-specific, but then, your graphics
>> hardware probably is, too. And they're well-defined and easy to port.

>> 3. Define a VECTOR data object whose size is one cell per coordinate, in the
>> appropriate order. They are automatically indexed by X or Y (or Z if there
>> is one). Thus:

>> 0 0 VECTOR UL 0 640 VECTOR UR 480 0 VECTOR LL 480 640 VECTOR UR

>> X UR @ \ Returns 640

>> Of course, you can always do a 2@ if you want to pick up both coordinates.
>> However, it's often convenient to work with one axis at a time (for example,
>> drawing and labeling an axis).

>> 3. Adopt a convention of keeping a "current position" of the cursor in a
>> vector. Then if you want to do something relative to it all you have to
>> specify is the amount of change.

>> 4. Adopt a convention whereby a VARIABLE is 0 or 1 depending on whether the
>> "beam" is on or off. If it's on and you move the cursor, you'll draw a line
>> in the current color.

>> There's more, but you get the idea. By looking at the overall design of the
>> graphics package, you can make your words work together in convenient ways
>> that don't ever require substandial stack thrashing OR local variables.

>> Cheers,
>> Elizabeth
>
>Well, sure. But the data structures you produce are permanent. If you want
>to write a word that draws simple boxes by specifying diagonally opposite
>corners, you have to give it 4 input parameters no matter what.

bj: I thought that was the whole point of the discussion, to
do things without globals! This looks like changing the rules.
Why use globals when you can use locals at the same cost?

>If you try to keep them on the stack you'll have to juggle. If the box drawing
>word is to be general, you have at least to give it the addresses of the
>corners, say UL0 and LR0--that is, another box might have corners UL1 and LR1.
>OK, you have reduced the stack to two deep. But then if you avoid LOCALS| |
>you will have to put in all the noise words of fetching and storing from/to
>your permanent data structures.

bj: Plus, you no longer have a reentrant word this way.
But you don't have a reentrant word with locals either,
unless they are stored at execution time rather than
compile time. Are UL0 etc. user variables?

>What I had in mind was something like

> : +line ( x y --) line crawl ; \ I envision a turtle that can crawl
> \ along a pre-defined curve--line
> \ is then a flag that sets the curve

> : box ( color line_width line_type xul yul xlr ylr -- )
> LOCALS| ylr xlr yul xul |
> to line_type
> to line_width
> to color
> xul yul to stylus
> xul ylr +line
> xlr ylr +line
> xlr yul +line
> xul yul +line
> ;

> \ if you define vectors UL and LR you would say
> \
> \ red 3 point semi-dash UL UR box

>No noise words at all, and no permanent memory structures except where
>I want them. The definition is also clear and self-documenting.

bj: Right. (And that is one the reasons that the debate
continues, apparently, because in traditional Forth
the code is neither self-documenting nor avoids globals.)

Bob Jaffray

>The program for determining whether lines cross in a plane is more
>complicated because 4 end-points (8 coordinates) must go on the
>initial stack.

>--
>Julian V. Noble
>Professor Emeritus of Physics
>jvn@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
>

.

Relevant Pages

  • Re: Local variables controversial?
    ... Graphics always comes up when locals are discussed. ... that don't ever require substandial stack thrashing OR local variables. ... xlr yul +line xul yul +line; ...
    (comp.lang.forth)
  • Re: Do buffers always start with the lowest memory address being the first element?
    ... The C standard does not assume a downward-growing stack, ... C allows but does not require that the array produced ... There is nothing stopping an actual C compiler on real hardware ... How are static locals in main ...
    (comp.lang.c)
  • Re: Local variables controversial?
    ... >> source that get translated into stack items at ... yet familiar with a Forth that implements locals. ... >of having hardware that executes Forth efficiently. ... >So there is controversy... ...
    (comp.lang.forth)
  • Re: Iczelions tutorials revisited.
    ... By "local" variables on the stack I assume something like this? ... access parameters and locals that way. ... The Windows API uses "stdcall" in which "callee cleans up stack" - the Windows functions end with "ret N". ... Being an old dos-head, I'm used to using cx as a "counter", and it annoys me that calling libc or the Windows API is allowed to trash it, but that's life... ...
    (alt.lang.asm)
  • Re: Named stack items
    ... If the compiler can determine that locals can be kept ... >>> on the paramemter stack rather than copied to the return stack, ... >>> parameter stack to the return stack. ... > The problem is already solved, at least in ANS Forth. ...
    (comp.lang.forth)
Loading