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

[Jan Burse]

Richard O'Keefe schrieb:
>> Also you note by yourself that
>> >  frame_value/2 has cost O(lg n).
> I also note that I just don't*care*  because in well-written code
> that operation should very seldom be used.

I guess the access can be made O(1). If a closed
frame pattern acess is used as in:

   p(<k1~t1,k2~t2>)

Then then usual speed can be archived and zillions
of objects can be quickly handled. But I guess
the above coding is not desired to support use
case 3, where module C adds an "annotation" to a
frame from module P. The programmer from module
P would then be required to code:

  p(<k1~t1,k2~t2|F>) -> ...

And this would be the well written code. I guess
the access via open frame patterns cannot be
anymore O(1). At least I don't see some approach
mentioned in your proposal. Especially annoying
for the performance would be the recreation of
the tail frame F. This can be circumvented when
only read access is needed, and no update, by
the following code:

  p(H) ->
       H=<k1~t1,k2~t2|_>, ...

In Java every method parameter, local variable
and field is assumed to be co-variant. For
class types this means that any of these place
holders can always hold a subclass. The access
is still O(1) for classes since they only have
single inheritance. For interface types the
situation is not that good, and more JIT work
is required to get back to O(1) if the call site
permits.

But I could write Java code that handles zillions
of Colors, and when I want I could also pass a
subclass, for example IndexedColor and code runs
exactly the same speed.

 > Frames make do without *any* static type information;
 > that's what the design is about.  But they can take
 > advantage of type information if available.

In which proposal is this substantiated?

Bye