Bug: Parameters and locals - ? And p(oke)

[dpharris]

n$ pushes frame-pointer onto stack.
n? Retrieves parameter n It can also ghe stack above the fp, Essentially giving local-variables.
-n $ copies removes n stack contents below f and Moves the top items down.

---

I like this a lot, can give quite a nice all syntax: c{$6 7 8 2?. 6?. -4$}0! [1 2 3 4] 0@x ==> 6 7 8 Note the first $ eats the []'s length, but one still needs the -4$ Note it allows for local variables, too.

I tried implementing 'p' as: case 'p': // xn..x1 y i -- xn..y..x1 xn | poke n = pop(); *(m_fp - n)=pop();
break;

This lets one poke into the frame, including locals: c{$ 6,7,8 2?. 88,5p 99,2p -4$}0! [1 2 3 4] 0@x ==> 88 7 8

[mikaelpatel]

The frame operator "n$" does not say anything about that it is "arguments". It is basically a stack indexing point. Works fine for parameters and locals. The "n?" operator is an access/read function and there is no corresponding write currently.

I have some "inner resistants" against this as it breaks the functional and immutable nature (compare with shell script parameters). The whole frame idea breaks the stack machine/post-fix approach in an attempt to "please" traditional in-fix/procedural notation; thinking in terms of variables and state change instead of chained functions and value flow.

There is much more philosophy going on here than meets the eye.

BW: "p" is unfortunately already used for pick.

[dpharris]

Yes, there has always been a tension over parameters. I just look on them another stack access method, that mitigates the need for mind bending sequences of rolls, swaps, etc. I am not sure it says anything about infix or 'procedural style'.

I can possible see an objection to poking stack values. That does get away from using a stack-based style.

Hey, its your project :-)

David PS - I tried to look up ColorForth as I thight it might have some ideas for minimal operator set, but couldn't find a complete description of it online. On Mar 1, 2016 00:59, "Mikael Patel" notifications@github.com wrote:

The frame operator "n$" does not say anything about that it is "arguments". It is basically a stack indexing point. Works fine for parameters and locals. The "n?" operator is an access/read function and there is no corresponding write currently.

I have some "inner resistants" against this as it breaks the functional and immutable nature (compare with shell script parameters). The whole frame idea breaks the stack machine/post-fix approach in an attempt to "please" traditional in-fix/procedural notation; think in terms of variables and state change instead of chained functions and value flow.

There is much more philosophy going on here than meets the eye.

— Reply to this email directly or view it on GitHub https://github.com/mikaelpatel/Arduino-Shell/issues/22#issuecomment-190620271 .

[mikaelpatel]

I do not object to an operator for assigning frame variables. It is needed if we walk down that path. My objection is more the frame vs stack flow.

The frame/local path is long and winding. It starts with the frame and single value return. Gets extended with multiple value return. And then locals. After a few day named parameters and the path is completed to the "dark side".

[dpharris]

:-) Yes, I understand. I am not a purist or should I say strict about adhering to Forth. I would like a system that is easy to understand and useful, and willing to draw on others. You have drawn on Postscript. (cool) immediately outputs "cool" the output-stream, but {(cool)} does that when the block is executed. I find this very easy to understand, not like Forth's may application of immediate/CT/RT.

I understand your designer's balance between simplicity, clarity and power. It is a delicate balancing act.

At the moment, one inefficiency is that the interpreter has to pass (read) over the { .. } blocks. A compile pass might whisk the block away automatically to memory, and only leave a pointer to it. However, that adds complication (hmm, the spelling of complication is very close to compilation :-p ).

At the moment Arduino-Shell is remarkably clear in its concepts and semantics.

On Tue, Mar 1, 2016 at 10:26 AM, Mikael Patel notifications@github.com wrote:

I do not object to an operator for assigning frame variables. It is needed if we walk down that path. My objection is more the frame vs stack flow.

The frame/local path is long and winding. It starts with the frame and single value return. Gets extended with multiple value return. And then locals. After a few day named parameters and the path is completed to the "dark side".

— Reply to this email directly or view it on GitHub https://github.com/mikaelpatel/Arduino-Shell/issues/22#issuecomment-190842509 .

[mikaelpatel]

Coffee and a Croissant often help clear the mist; get in to refection mode :)

I think I will meet you half way on the frame/locals. How about n_ pushes an address that can be used with fetch @ or store !? This would replace ? which could go back to what it often is defined as in forth @. or used for something more important.

Short remark on the current inefficiency with blocks (not compiled to branches). I was actually considering adding a small cache that would store the latest blocks start and end. A simple cache lookup should be faster than scanning through the block. This should be showing up in a few weeks when I get to the performance improvement phase. This should actually be an issue on its own :).

[dpharris]

Sounds good. If the caching is invisible to the user, then that would be a good thing.

[mikaelpatel]

Please see commit https://github.com/mikaelpatel/Arduino-Shell/commit/5934633cec9c43127d1b39008beccf18c7afdf9d.

[dpharris]

This seems to break if there are no extra items on the tos: c1 2 3 4 5 6 7 8 4$ 9 10 -4$ ==> 1 2 3 4 8 9 10 i.e. works c1 2 3 4 5 6 7 8 4$ 9 -4$ ==> 1 2 3 4 8 9 i.e works c1 2 3 4 5 6 7 8 4$ -4$ ==> crash

On Tue, Mar 1, 2016 at 11:16 AM, Mikael Patel notifications@github.com wrote:

Coffee and a Croissant often help clear the mist; get in to refection mode :)

I think I will meet you half way on the frame/locals. How about n_ pushes an address that can be used with fetch @ or store !? This would replace ? which could go back to what it often is defined as in forth @. or used for something more important.

Short remark on the current inefficiency with blocks (not compiled to branches). I was actually considering adding a small cache that would store the latest block start and end. A simple cache lookup should be faster than scanning through the block. This should be showing up in a few weeks when I get to the performance improvement phase. This should actually be an issue on its own :).

— Reply to this email directly or view it on GitHub https://github.com/mikaelpatel/Arduino-Shell/issues/22#issuecomment-190859002 .

[mikaelpatel]

That was a clean bug. Too much focus on return values. Anyway, should be fixed now. Thanks!