This fragment of a reply is the random bits that didn't make it into
other topic-centered replies.
Patrick R. Michaud wrote:
On Sun, Nov 26, 2006 at 08:30:32PM -0800, Allison Randal wrote:
Excellent. Just as a general overall response -- PAST-pm is by
no means "finished", so many of the items that seem to be missing
are simply cases of "I haven't gotten to them yet so they aren't
implemented yet."
Understood, it's a work in progress. Which makes this the perfect time
to influence it's future. :)
- There's no PAST::Label node type? How do you represent labels in the
HLL source?
I just haven't gotten to this part yet.
Okay, I'll add it when I need it, if you haven't already added it by then.
I don't have a problem with switching it to 'value', I went with
'name' primarily because every PAST::Node has a name and so it just
made sense to use it there. But let me make another weak argument
in favor of 'name'. If a HLL programmer writes
$a = 1.23456789E6;
then the rhs becomes a PAST::Val node. How should we represent the
value? The parse-to-past translation could evaluate the contents of
"1.23456789E1" and store the result in 'value' as (.Float) 12.3456789,
but unfortunately when convert that .Float back into a string for
use as PIR code it comes out as "12.3457" -- i.e., the code looks
like:
$P0 = new .Float
$P0 = 12.3457
set_global '$a', $P0
I decided that in a number of cases like this, what we really want
to retain in PAST::Val is a precise string representation of the
value that goes in the resulting output, and not a native
representation that may lose precision in translation through
POST/PIR. So, what we're really storing is the value's "name"
and not its "value". (I did say it was a weak argument.)
Fair. And agreed that PAST::Val should store the raw parsed constant,
not an evaluated form.
Anyway, we can switch to 'value' if that's ultimately better;
I was just thinking that 'name' might be equally appropriate.
Yeah, let's go with 'value'. The only case I can think of that might
need to use a value as a name is Ruby, where you can call a method on a
literal:
2.class
But in that case, I think you'd end up representing '2' as a constant
Var named '2' anyway (perhaps with a PIR value type of RubyLiteralInt).
"Ismy" means "isdeclaration" here, and I can go ahead and change it.
Excellent!
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.
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: (1) :vtable in subclassed items
still has some issues to be addressed (e.g., RT #40626), and
Yes, hold off on this fix until :vtable works, but put it into the draft
PDD.
(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.
Besides, using :vtable we can get both a method and a :vtable entry for
the price of one method definition.
Clear boundaries between components: (Fuzzy boundaries of abstraction
make it difficult to allow for other implementations of the AST/OST or
customization of the compiler object.)
- 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?).
A clear boundary between the OST and PIR generation will also push us
closer to the final solution.
- Provide distinct errors/exceptions for failures at each stage of
compilation to make it easy to figure out which stage is failing.
Agreed -- however, exception handling in Parrot still needs
implementation and better flushing out (this is what prompted
my question about the status of exception handling implementation
in last week's #parrotsketch, and my comment that I'm likely to
need them fairly soon.)
Yes, exceptions need work, and soon.
- 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.
Allison
