Cleanup: Clear
dpharris opened this issue · comments
A suggestion for generalizing CLEAR:
You have:
c | xn..x1 -- | clear | ABORT
and:
j | xn..x1 -- xn..x1 n | stack depth | DEPTH
I wonder if it would be better:
c | xn+1xn..x1 n -- xn+1 | clear n items | CLEAR
This would let one do:
to clear whole stack:
jc
to remove a []:
[1 34 23 45 2@]c
There is a new function b which does this. BW: Want to know why depth became opcode j? It is from the Swedish word for depth - djup :).
See commit 348c0df, only 6 minutes before your suggestion :)
Do you need b, c, and j? Since jb is equivalent to c?
If one could drop n items, but retain the tos:
b | xn...x1n x0 -- x0 | block drop, maintaining tos | Block drop
, then one could do 'poor man's parameters' using pick:
[1 2 3 4 5]{5p4p+p3*p2+p1*b}
leaves:
65
Do you need b, c, and j? Since jb is equivalent to c?
Not really. Just in the "add"-phase right now. There comes a "remove"-phase. It is a balance between frequency, symmetry and orthogonality. High frequency of usage allows compression over symmetry and orthogonality.
The alternative to block drop above is to store in a variable, drop and restore.
[1 2 3 4 5]5p4p+p3*p2+p1*0!b0@
Better suggestion: replace p(ick) with g(et) and add p(joke).
Poor-man's parameters, put dummy return value on the stack:
[0 1,2,3,4] 4g3g*g2+g1* 5p! 1-b
Actually if checking the forth word list "roll" is missing. It is a parameterized "rot". Strangely I hardly use that but without the return stack for temporary storage it might be handy.
Looking at your examples above it seems like you would like to have parameter binding. That is another type of virtual machine (with argument frames).
In any case "roll" will be added soon.
Yeah, and my example doesn't work, since it is relative to the tos, and not the frame.
The g(et) and p(oke) might be useful.
Right now there are many ways to clear the stack:
c
jb
j{d}l
A twist on usage of the stack marker could be to set a frame reference, i.e. [sets a frame value and then an access function could pick the value relative the frame, for instance ?. Alternatively, a frame marker, for instance $.
[1,2,3] 0? 1? + 2? *
$ 1,2,3 0? 1? + 2? *
I think the problem is that this gets into return stack territory.
On Feb 28, 2016 16:59, "Mikael Patel" notifications@github.com wrote:
Right now there are many ways to clear the stack:
c
jb
j{d}lA twist on usage of the stack marker could be to set a frame reference,
i.e. [sets a frame value and then an access function could pick the value
relative the frame, for instance ?. Alternatively, a frame marker, for
instance $.[1,2,3] 0? 1? + 2? *
$ 1,2,3 0? 1? + 2? *—
Reply to this email directly or view it on GitHub
#20 (comment)
.
After some sandboxing I added a frame marker and parameter access op-codes. It looks like this:
x1..xn n$ -- with n>0 marks stack frame with n-elements
x1..xn y1..ym n$ -- y1..ym with n<0 removes frame
n? -- xn copy parameter n
swap could be defined as:
{2$2?1?-2$}
Please see commit 97edb2c.
I like your proposal. I love the use of pos and neg parameter to $ --
inspired!
range: range(x min max) { return (x>min)&&(x<max); } is:
x min max {3$ ?3?1< ?3?2> & -3$}
This would appear to give a limited form of locals, too:
55 44 33 {22 11 5$ ?1 ?2 ?5 -5$ 66} leaves 11 22 33 66 on the stack?
? would appear to (mostly) replace pick, so could we use p for poke
relative to fp, then:
6 5 4 3 {0 0 6$ 6?5?_2p 4?3?_1p ?2?1+ -5$} would leave 42 on the stack
("the answer to everything")
ONE issue -- is it worth pushing the fp onto the stack, so that you can
restore it on -n$? This allows stacked calls.
Thanks,
David
The frame pointer is per block/script. It is pushed on the C runtime stack (in the locals to execute()).
55 44 33 {22 11 5$ ?1 ?2 ?5 -5$ 66}
Hum, several errors: 1) Correcting the prefix:
55 44 33 {22 11 5$ 1? 2? 5? -5$ 66} gives 55 44 33 570
- The "{" pushes the block address on the stack (570). The block is not executed.
55 44 33 { 22 11 5$ 1? 2? 5? -5$ 66}x gives 55 44 11 66
- Alternative forms:
55 44 33 22 11 5$ 1? 2? 5? -5$ 66 gives 55 44 11 66
{22 11 5$ 1? 2? 5? -5$}\a0! 55 44 33 0@x 66 also gives 55 44 11 66
I am not sure that these go through to you when the issue is closed.
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
David
On Mon, Feb 29, 2016 at 6:10 AM, Mikael Patel notifications@github.com
wrote:
55 44 33 {22 11 5$ ?1 ?2 ?5 -5$ 66}
Hum, several errors: 1) Correcting the prefix:
55 44 33 {22 11 5$ 1? 2? 5? -5$ 66} gives 55 44 33 570
The "{" pushes the block address on the stack (570). The block is not
executed.55 44 33 { 22 11 5$ 1? 2? 5? -5$ 66}x gives 55 44 11 66
55 44 33 22 11 5$ 1? 2? 5? -5$ 66 gives 55 44 11 66
{22 11 5$ 1? 2? 5? -5$}\a0! 55 44 33 0@x 66 also gives 55 44 11 66
—
Reply to this email directly or view it on GitHub
#20 (comment)
.
Hum, this should actually be a new issue. This has wondered off far from the issue title "Clear" :). Hard to keep track of this.