On Mon, Nov 27, 2006 at 10:13:21PM -0800, Allison Randal wrote:
> This fragment of a reply is the random bits that didn't make it into
> other topic-centered replies.
...and some quick responses before turning in for the night...
> >Currently Parrot uses '__init' as the method for initializing
> >new objects, thus I think 'init' is at least consistent with Parrot.
>
> Where it's inconsistent is in the arguments each takes, so you can't use
> the current 'init' methods as :vtable('init') methods. I'm half-way
> inclined to see that as a limitation in Parrot that needs to be fixed
> rather than a problem with these classes.
Having dealt with this in both PGE and at least two PAST
implementations, I certainly see it as a Parrot limitation.
Ultimately I want to have a method that can accept variable
arguments so that I can initialize a newly created object.
I chose 'init' because it seemed like the natural/obvious
name for such a method, but if there's a better name I'll
gladly switch. I haven't found the Parrot :vtable('init')
to be all that useful, since there's not a parameterized
version of it beyond passing a single PMC. And getting
arguments into a single PMC isn't all that fun or useful.
But come to think of it, if we had something like Capture PMCs
available as a standard type (and an easy way to generate
them in PIR), then the existing :vtable('init') would be
quite sufficient. To steal from Perl 6's C<< \(...) >>
capture syntax:
$P0 = new 'Foo::Bar', \(param1, param2, 'abc'=>param3)
.sub 'init' :vtable
.param pmc args
# initialize self based on array/hash components of args pmc
# ...
> >I've also thought about doing 'push' as a :vtable entry, and we can
> >still easily do that, but there are at least two items in favor of
> >keeping a method-based approach:
> >(2) when we get a high-level transformation language into TGE, it's
> >very likely that the operations on nodes will be method-based
> >and not opcode-based.
>
> Well, the operations will be in a middle-level-language syntax. Whether
> the MLL uses a methody syntax or a procedural syntax doesn't matter,
> since either can be translated to either syntax in PIR.
My point is simply that it's far easier to go from a MLL
(whatever syntax) to PIR method calls than to generate specific
Parrot opcodes, because method calls have a very regular
syntax that Parrot opcodes don't.
> - One more comment in this department: move PIR generation out of the
> POST node objects. A tree-grammar that outputs PIR code strings isn't a
> final solution, but it's a more maintainable intermediate step than
> mingled syntax tree representation and code generation (remember P6C?).
I never really dealt with P6C. :-), Still, I can see about
moving the code generation out of the POST node objects; I may
do it as a lower priority though, since I don't think that
aspect is driving many design or implementation decisions for
us at this point.
> >>- In PGE grammars, what is the "{ ... }" at the end of every proto
> >>declaration supposed to do?
> [...]
> >But in the end, I didn't allow simple semicolon terminators
> >simply because it wasn't valid Perl 6 syntax, and in many cases
> >I think that having subtle differences isn't ideal as people
> >may get confused about what is allowed where. But I don't have
> >a large objection to modifying the PGE::Grammar compiler to
> >represent empty declarations with semicolons as well as
> >yada-yada-yada blocks.
>
> Excellent.
"Excellent" as in ...?
[ ] "Go ahead and allow semicolons, since you don't have
a large objection."
[ ] "Your explanation is excellent, stick with the yadas
to avoid the subtle contrasts to Perl 6."
Pm
