Mixed stuff

[Matthew Tuck]

Hans-Dieter Dreier wrote:

> > Well every type has to be laid out so that it can support get/sets,
> > since it is unknown whether implementations will use a variable or
> > computation.
> I would think that the compiler knows the implementation (at least the
> signature, that is, whether it is a method call or a data member) of all
> accessible items in the superclass. Then it would not need to generate
> get/set calls unless necessary. Using calls to access an item that can be
> directly accessed carries a *huge* performance penalty.

Well for a start this would increase fragility, since at the language
level you can treat it can be a get/set or physical field.

It's also hard to know just whether it can set it out using just a
field.  This is because these get/sets could be the target of a dynamic
dispatch, which you can't tell.  This is especially true if you allow
multiple implementations.  So if it's part of a dynamic dispatch it must
be a get/set.  The compiler can find out this sort of information
through optimisation, but it's hard to just know.

>> I did a search on fragile superclass.  The answer is that Java does not
>> ...
> I don't like this - it seems to make incremental linking difficult if not
> impossible. Actually, in my model there is no link time (other than for
> loading dynamic libraries), so it wouldn't be applicable.

I'm assuming by "no link time" you refer to at run time.  That being
said, everything at run time is dynamic in Java.  I was referring to
compile time linking - sorry if I was vague.  The important thing is you
don't need to recompile the class.  Offset information is determined at
link time, also can MI instance layout information.

I'm not really sure how it would affect incremental linking though.  The
process is by definition incremental linking.

> I think it is
> important that the compiler/editor is able to access objects even if their
> class has not yet been fully compiled (some methoids are missing) - this
> would be impossible.

Well a compiler should be able to do some sort of compile on an
incomplete object - per method incremental compilation is quite
possible.  This sort of decision would be delayed until final code
generation time.  Now this can be all done incrementally if you want (in
a sense interpreting ASTs would be the cleanest incremental
compilation).  But if you're going to make decisions at laying out
object offsets, you're allways going to introduce fragility, no matter
when you do it.

> Example: If you have an index to all the objects of some kind and you
> don't want this index to interfere with GC. That is, objects may be
> collected even if they are mentioned in the index, using weak references.
> Those would be set to NULL when the object is being collected, in order to
> avoid dangling pointers.  I don't think weak references are an important
> feature. Implementing them afterwards would have a heavy impact on GC,
> however.

No, I know what they are.  =)  I just wondered how they were relevant to
implementing elimination optimisations.

>> Do you still have it around as an example?
> Sure. The syntax is quite simple:Program ::= Expr | Expr Infix Expr
> Expr ::= [Prefix...] [Operand] [Postfix...]

You might say Smalltalk is something similar to this in style, however I
think the standard syntactic notations are easier to read.  Bad error
messages are a small price to pay for this.  If you're using a
semi-structured or structured view this should be all academic though.

> In those old days everything had to be extremely compact. The whole thing
> (interpreter, runtime and interpreted program) had to fit into 128 KB
> memory.  This is why no precompilation was done (parsing overhead was 5%,
> so the benefit would have been limited anyway).

I suspect the advantage of precompilation is more related to reduced
size of the AST over the source.  But the real reason I want to use ASTs
is that they are easy to edit, use, and globally optimise.

> The CString was created on the stack (which I didn't know by then),
> passed to the constructor of SomeClass, assigned to some SomeClass member
> and then discarded, leaving a dangling pointer behind. A silly mistake, to
> be sure, but if you're not familiar with the conventions...

And that too should be and can be prevented with GC.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
             mailto:matty@box.net.au (ICQ #8125618)
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/