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

[Michael Turner]

"Here I must say some additional words to re-emphasize what I mean by "have"."

I hope you don't have any additional words to re-emphasize what you
mean by "Bye."

-michael turner

On Fri, Apr 27, 2012 at 8:47 AM, Jan Burse <janburse@REDACTED> wrote:
> 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
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions