Class metadata for PIR/assembly files

0 views
Skip to first unread message

Dan Sugalski

unread,
Oct 21, 2003, 2:55:37 PM10/21/03
to perl6-i...@perl.org
Here's the scoop:

Metadata for classes is simple. In PIR/assembly, they're noted with
.things:

.class Foo
.is bar
.is baz
.does some_thing
.member x
.member y
.member z
.ssalc

Unless someone tells me that ssalc is horribly obscene in some relatively
common language, and we may still if the translation amuses me
sufficiently.

Keywords are simple for the metadata. .class starts the declaration, has a
single parameter the name. Class declarations end with .ssalc. Each .is
defines a parent class, each .does defines an interface the class
supports, and each .member defines a PMC member slot that each object.

If a class is defined in the bytecode, it gets instantiated when the
bytecode is created. (It's a constant class, though like any other class
is mutable at runtime so it's not that constant) There is no difference
between a class created with metadata and one created by executable code
piecemeal.

Classes, when instantiated, have a backing namespace that's identical to
the class name.

We will be adding version metadata to the classes, but that's going to be
deferred.

It's OK for the code that handles PIR and assembly to ignore this for the
moment, at least until the metadata segment is better defined. Which will
be soon, though I'd rather someone else do the bytecode modification as
it's been a long time since I've had my hand in there.

This would be a good time to comment on the metadata, as I'm about to go
finish defining the ops to create classes dynamically and actually finish
the fscking object.c. code to do it.

Dan

Joseph Ryan

unread,
Oct 21, 2003, 7:44:51 PM10/21/03
to Dan Sugalski, perl6-i...@perl.org
Dan Sugalski wrote:

Will there be a way to specify which methods belong to the class in the
metadata? Or will Method namespaces just have to match class names so
that a lookup can be done?

-Joe


Melvin Smith

unread,
Oct 21, 2003, 8:16:37 PM10/21/03
to Joseph Ryan, Dan Sugalski, perl6-i...@perl.org
At 07:44 PM 10/21/2003 -0400, Joseph Ryan wrote:
>Dan Sugalski wrote:
>
>>Here's the scoop:
>>
>>Metadata for classes is simple. In PIR/assembly, they're noted with
>>.things:
>>
>> .class Foo
>> .is bar
>> .is baz
>> .does some_thing
>> .member x
>> .member y
>> .member z
>> .ssalc
>
>Will there be a way to specify which methods belong to the class in the
>metadata? Or will Method namespaces just have to match class names so
>that a lookup can be done?

I was planning a .method directive. I like the feel of separate .field and
.method
directives. I like supporting 2 variations like C++, however this is only
an intermediate language so it really doesn't matter.

.class Foo
.method InlineMeth
(code)
.endmeth
.method NotInline ...
.endclass


.method Foo.NotInLine
(code)
.endmethod


Using out of line definitions with inline declarations means the compiler
can be single pass and simpler, however most decent compilers
will do a separate semantic pass so forward declarations are easy.

On the other hand, inline method definitions makes code emitting
a little simpler.

I see no real big technical problem with supporting both syntax, I think
it is more proof-of-concept than anything since eventually we will pass
an syntax tree form to the compiler instead.

-Melvin


Melvin Smith

unread,
Oct 21, 2003, 8:21:24 PM10/21/03
to Dan Sugalski, perl6-i...@perl.org
At 02:55 PM 10/21/2003 -0400, Dan Sugalski wrote:
>Here's the scoop:
>
>Metadata for classes is simple. In PIR/assembly, they're noted with
>.things:
>
> .class Foo
> .is bar
> .is baz
> .does some_thing
> .member x
> .member y
> .member z
> .ssalc
>
>Unless someone tells me that ssalc is horribly obscene in some relatively
>common language, and we may still if the translation amuses me
>sufficiently.

I'm sure ssalc must mean something bad somewhere. Technically
nothing is stopping us from using .end for everything since we
are using a LALR parser and don't need fancy error reporting,

>Classes, when instantiated, have a backing namespace that's identical to
>the class name.

Good.

So do we support :: or . for scope resolution? Or both?

>It's OK for the code that handles PIR and assembly to ignore this for the
>moment, at least until the metadata segment is better defined. Which will
>be soon, though I'd rather someone else do the bytecode modification as
>it's been a long time since I've had my hand in there.

Well we can hide this under PIR. Once PIR is set, we can
start by implementing on the fly class creation, then change
IMCC to emit metadata when the rest is in. That way
HL languages don't have to change later. For now we just have
IMCC emit newclass, etc. and manually construct the classes.

-Melvin


Dan Sugalski

unread,
Oct 22, 2003, 8:27:19 AM10/22/03
to Joseph Ryan, perl6-i...@perl.org
On Tue, 21 Oct 2003, Joseph Ryan wrote:

> Will there be a way to specify which methods belong to the class in the
> metadata? Or will Method namespaces just have to match class names so
> that a lookup can be done?

Hadn't planned on having any particular declaration of methods, no. If
there was one it'd at best be a note that the method does exist and
perhaps its signature, but not its body. I'd much prefer just leaving it
that subs (or methods, I can see having both) in the proper namespace are
what gets called, regardless of what's declared. Given how all the
languages we're primarily targeting act, that makes the most sense.

Dan

Dan Sugalski

unread,
Oct 22, 2003, 8:48:23 AM10/22/03
to Melvin Smith, perl6-i...@perl.org
On Tue, 21 Oct 2003, Melvin Smith wrote:

> I'm sure ssalc must mean something bad somewhere. Technically
> nothing is stopping us from using .end for everything since we
> are using a LALR parser and don't need fancy error reporting,

True enough. For machine-generated code it's irrelevant, so it doesn't
matter. Since it seems easier for people to have matching open/close
bracket things I went for the paired names. I doubt we'll have any nesting
inside the class declaration, though--I can't see any good reason for it.

> >Classes, when instantiated, have a backing namespace that's identical to
> >the class name.
>
> Good.
>
> So do we support :: or . for scope resolution? Or both?

::, I think. I think we decided a while back that the actual, in-stash
separator was a null byte, so we could have a language-neutral separator.
We can skip that for a bit, though.

> >It's OK for the code that handles PIR and assembly to ignore this for the
> >moment, at least until the metadata segment is better defined. Which will
> >be soon, though I'd rather someone else do the bytecode modification as
> >it's been a long time since I've had my hand in there.
>
> Well we can hide this under PIR. Once PIR is set, we can
> start by implementing on the fly class creation, then change
> IMCC to emit metadata when the rest is in. That way
> HL languages don't have to change later. For now we just have
> IMCC emit newclass, etc. and manually construct the classes.

Works. I should have the bytecode stuff spec'd today, with at least a
rudimentary implementation.

Dan

Reply all
Reply to author
Forward
0 new messages