Leopold Toetsch wrote:
>
> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> > Leopold Toetsch wrote:
> >>
> >> Benjamin Goldberg <[EMAIL PROTECTED]> wrote:
> >>
> >> > I would suggest the opnames/categories "mutate," "alias," and
> >> > "create."
> >>
> >> IMHO, we could leave PASM syntax as it is and create opcode aliases
> >> inside the assembler ...
>
> > I would rather rename the ops, but make their old names aliases to the
> > new names.
>
> Yes.
>
> > But that would tempt people to do:
>
> > $P0 = new SomethingElse (42)
>
> > Which sadly wouldn't work, since neither the create ops, nor the "new"
> > op, generalize that way.
>
> That's fine for Arrays (setting the initial size) and for Subs (setting
> branch location).
Hmm, yes.
> Its kind of the current init_pmc vtable.
Err, not quite -- the proposed create ops first create a pmc, then call
set_integer_native; this is not in any way related to init_pmc.
Although, I suppose it could be -- if there existed an init_integer,
then it would be more logical for "$P0 = new SomethingElse (42)" to use
that, rather than create then set_integer_native.
Maybe we should have 5 init functions: init, init_pmc, init_integer,
init_double, init_string. (Hmm, what's that init_pmc_props thingy?)
> > But if the syntax is:
>
> > $P0 <== 42
>
> > , we would not be impling a generality which doesn't exist. Also, it
> > removes redundancy, since "42" already implies PerlInt, so we don't
> > need to spell that name out.
>
> PieThonInt, RubyInt?
Hmm. I that parrot should DTRT, and use CurrentLanguageInt. :)
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
