[erlang-questions] The compiler "eats" structures which are not separated by commas

[Jan Burse]

Richard O'Keefe schrieb:
>> So instead of talking about a miracoulous
>> proposals, it would be helpful to provide
>> a link and substantiate claims.

I wrote "a link" and "substantiate claims". What
I would like to know how the following claims
of yours:

Claim I:
 > If you had read the frames proposal, you would
 > have realised that the proposed implementation has
 > the first slot pointing to a descriptor, which can
 > be shared by any number of frames having the same slots.
 > This is precisely the same as an object pointing
 > to its class.

Claim II:
 > In exactly the same way, you can have 'zillions of instances'
 > of a frame <colour{red = R, green = G, blue = B}> where each
 > instance is four words: R, G, B and run time type information.
 > If I was to have any hope of getting frames accepted, I felt
 > I had to show that they would have no space penalty compared
 > with records.

Relate to your proposal. In particular I have
the following doubts about your claims:

Claim I:
Most OO languages don't have a <{k1~v1,k2~v2|F}> operation
that allows the creation of dynamic frames. Even if you
are putting key sequences, seen in code, into a constant
pool at compile time, when you don't have complete type
inference, you will not know in advance what the above
operation will generate as a keyset, and you will have a
miss on the constant pool and end up with a more costly
solution that doesn't exist in modern OO languages. This
will especially happen for your use case 3 where module
C adds an "annotation" to a frame from module P.
(See section 11, 2 of your frame proposal)

Maybe Self had such an architecture, but for example Java
has single inheritance and you can only instantiate objects
from this class hierarchy. Ordinary Java code hardly generates
dynamic classes by a simple source code statement. The
multiple inheritance hierarchy along the interfaces cannot
be used to instantiate objects. Scala has traits, which
allow kind of multiple inheritance and instances. There is
a tech report from Lausanne detailing how traits can be
rewritten to ordinary Java. One solution uses delegation,
the other I forgot about.

Claim II:
Here I must say some additional words to re-emphasize what
I mean by "have". When I talk of zillion objects I am not
only interrested in the memory footprint but also in the
performance of the primitive operations on these objects.
I think I mentioned that in my post. In Java, if not too much
polymorphism is involved, the accessing of a field is O(1),
both for write access and read access. Although your
memory representation, in those cases where the keyset
is in the constant pool, caters for small memory footprint.

But I doubt that the performance is that good. Let's
look at read access. The example you give to calculate
the magnitude of a complex number uses pattern matching
with frames. This is very appealing since Erlang has already
pattern matching for lists, tuples and records. But you
also write that the resulting code must check whether the
argument is really a frame, whether it has really a re
field and whether it has really a im field. This crosses
the O(1) complexity. Also you note by yourself that
frame_value/2 has cost O(lg n).
(See section 7.2, 4 of your frame proposal)

Bye