I don't use the user stack, myself, but one advantage that the
current implementation has over "just using a PMC" is that you don't
have to go out and get the global PMC you're storing things in.
We already have at least one language implementation that used to
work just fine using the stack, but has been crippled with various
deprecations over the last few years.
Would it be difficult and/or desirable to change our user stack
implementation to:
1) Automatically create a global ResizablePMCArray and put it in a
well known location.
2) Provide some PIR sugar so that if a particular token (e.g.
$USERSTACK, .USERSTACK) is mentioned as an argument, it is fetched
from the global and put into a local register. (and thereafter, the
local register is used, as long as it's in the same sub.)
3) eliminate the special cased opcodes for dealing with the user stack.
This would also allow more direct manipulation of the stack for
nefarious purposes. (Though, you could just call that "introspection"
and chalk it up to a feature.)
This is predicated on the assumption that *someone* wants the user
stack, though.
On Mar 1, 2006, at 7:40 AM, Bob Rogers wrote:
From: Chip Salzenberg <[EMAIL PROTECTED]>
Date: Mon, 27 Feb 2006 09:46:42 -0800
On Fri, Feb 24, 2006 at 12:57:24AM +0100, Leopold Toetsch wrote:
That's indeed an (indirect) answer to the 'do we really need it'
part ;)
Is there any other client of the user stack that can't be easily
replaced by
some kind of *Array? It'd be nice to lop off such a low-value
feature.
--
Chip Salzenberg <[EMAIL PROTECTED]>
I can think of two more strikes against it:
1. In error handling code, it's a pain to restore the stack state.
You have to (a) take note of the depth before starting, and (b)
emit EH
code to pop back to that level. This is made more difficult by the
fact
that . . .
2. Stack entries are "strongly typed," i.e. you have to know the
INSP type of the thing you pushed in order to pop it, or you get an
error. This is in stark contrast to the new calling protocol,
which is
willing to convert.
Neither of these are fatal, but both make the user stack harder to
use than it could be. IMHO, it seems easier to flush it than to
fix it.
-- Bob
