Patrick R. Michaud wrote:
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 # ...
It's a reasonable solution. Have to think a bit more about the syntax
for creating them. We have talked about giving PIR some short-cut syntax
for creating data structures, as syntactic sugar for the basic 'push'
and keyed set operations. It hasn't come to anything yet, but this could
be tied into it. Largely, it's the fundamental question of "Is PIR an
assembly language, or an MLL for humans?" The answer is probably "Both."
We can avoid modifying PIR's fundamental syntax by requiring the
initializer argument to be created separately:
$P0 = new 'SigHash'
$P0.set(param1, param2, 'abc'=>param3)
$P1 = new 'Foo::Bar', $P0
But, that's one more step than what you're doing now:
$P0 = new 'Foo::Bar'
$P0.init(param1, param2, 'abc'=>param3)
An improvement might be through changes to the OO model:
$P0 = find_type 'Foo::Bar' # returns a class object
$P1 = $P0.new(param1, param2, 'abc'=>param3) # new is a class method
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.
I would have disagreed a couple months ago, as opcodes were simpler to
generate in the old PAST/POST. But with the new implementation I agree.
- 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. :-)
Lucky you. :) It was great in the early days, and allowed for rapid
prototyping, but it grew...um...organically.
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.
Yes, a lower priority is fine. I suspect that Pheme will drive the
development of POST, since the Pheme compiler will be working with
it directly, rather than treating it as an invisible background step.
- 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."
I prefer option (A), allowing semicolons. The tricky thing is that we're
adopting syntax from one use case into another use case. The yadas make
perfect sense in the context of a Perl 6 program (where the yada means
that the code body will later be filled in), but they make no sense as
part of a Parrot parser (where the yada can't be filled in, and is just
an artifact).
Not an immediate priority, though. And, maybe Perl 6 will change and
solve the problem for us before we get there. ;)
Allison
