This is pretty long as is, so I'm going to leave out all the things I
agree with.
On Fri, Sep 09, 2005 at 01:48:20PM +0200, Leopold Toetsch wrote:
> Chip writes:
> > * optional parameter interface: ":opt_count" -> ":opt_flag"
> > So ":opt_count" should be replaced with ":opt_flag", which sets
> > its target register to a boolean indicating whether the
> > immediately preceding parameter was passed or not, rather than a
> > count of optionals present.
>
> If there is an alternating sequence of (:optional, :opt_count)+, the
> :opt_count works exactly like :opt_flag, i.e. you get 0 or 1 depending
> on the presence of the preceeding optional argument.
>
> OTOH the current :opt_count is also usable to just count a bunch of
> preceeding optionals. Therefore this proposed change would just reduce
> the functionality of the current implementation.
I don't know how you did it, but you have figured out my brilliant
plan. I've been intending all along to disable more and more features
of Parrot until it becomes a subset of JVM. At that point we could
have imported Kaffe and declared victory. I would have succeeded,
too, if not for those meddling kids!
But seriously: I've been asking you to remove the counting feature
for, what, months now? And for a consistent reason: Future
development of the parameter passing interface will likely make it
inconvenient (read 'inefficient') to implement. And the current user
base (pretty much Patrick and the tcl guys) have said they don't mind
switching to a boolean.
----------------------------------------------------------------
> > * subroutine attribute spelling: "method" -> ":method"
>
> > .sub "foo" :multi(_,int) :method
>
> ACK. What about @MAIN, @IMMEDIATE, ...?
Same deal: the colon form will be standard, but the @ form should be
accepted until users have switched (or a few months, whichever comes
first). It's a totally minor point, I know, but I have a weakness for
the perl 5 modifier syntax.
("Everybody wants the colon", yeah, I know.)
----------------------------------------------------------------
> > * src/inter_run.c : runops_args() - argument limit
>
> > + Looks like this function fails if someone passes more than eight
> > parameters. Why? Buffer malloc is cheap.
>
> There are more argument limits currently due to limited register range.
> These will be fixed, when variable sized register frames are done.
OK, but please add a FIXME comment.
----------------------------------------------------------------
> > * DELETED opcode(s) can die
>
> The reason [for delay] is that deleting opcodes not only invalidates
> existing .PBCs but also needs adjusting a lot of examples/japh/*
There's no rush of course on the deletions, but I didn't think opcode
renumbering could break pasm code. I'd like to understand the interaction.
----------------------------------------------------------------
> > * Tests may not use literal get/set flags
> > + The values of the flags for get_params/set_args/etc. should not
> > escape in numeric form, even to the self-tests. If they're out
> > there in symbolic form, fine.
>
> Yep. Presumably the (successor of the) macro preprocessor should handle
> this.
I'm tempted to handwave vaguely in the direction of m4. What with GNU
m4, and presumably a BSD family version or two, it'd be one less thing
to (re)invent.
----------------------------------------------------------------
> context [structure] can only be refered to by continuations,
> therefore ref_count is neither bad nor unneeded.
Why not let GC handle the contexts too? Objects don't have to be
"first-class" or user-visible for GC to handle them, right?
----------------------------------------------------------------
> > + I think this comment speaks for itself:
> > + strcat(buf, s); /* XXX check avail len */
> > That's a security/coredump problem. It can't wait until later.
>
> Yep. As said, we need variable sized register frames first [...]
That would be waiting until later.
--
Chip Salzenberg <[EMAIL PROTECTED]>
