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;}