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

[Jan Burse]

Richard O'Keefe schrieb:
> Come ON:  given the representation described in frames.pdf,
> if you see a slot reference ~foo(Bar) and you have type
> information (Bar is a frame with these fields having those
> types) similar to the information currently available about
> records, then the compiler would know just as much about that
> reference as a Pascal, C, or indeed Java compiler would know
> about Bar^.foo (Pascal), Bar->foo (C), or Bar.foo (Java).
> That would not stop the*same*  value being passed to a
> function that*didn't*  have the type information and being
> used there.

This only works in the non-polymorphic case. It can only
speed up your access in the non-polymorphic case and
then frames boil down to records. You still don't get
my argument that frames pose certain complexity limitations,
either access is O(1) (field access) and frames don't get
updated in their signature, or access is O(log n) and frames
get updated in their signature and are sparsely represented.

I don't see a way around this right now. Unfortunately
I did not yet find a paper detailing it. But you can think
about it for yourself. Assume you have the following
keys dispersed in your code:

      k1, ..., kn

Then the possible frame signatures are:

      k1,
      k2,
      ...
      kn
      k1, k2
      ...
      kn-1,kn
      ...
      k1, ..., kn

There are 2^n possible frame signatures for n keys. Now
you can easily construct some program that will visit
all these combinations and the program need only have
length proportional to n. I don't think some type
inference can push down the access time to these frames
O(1) (field access) and in the same time represent the
frames sparsely. Further type declaration is pretty
void for the example.

Bye