Class metadata for PIR/assembly files

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

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

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

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,

Good.

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

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

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

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.

::, 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.

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

Dan