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

[Jan Burse]

Jan Burse schrieb:
 > Richard O'Keefe schrieb:
 >> Come ON:  given the representation described in frames.pdf,
 >> [...]
 > This only works in the non-polymorphic case.
 > [...]

Oops,
My previous post is rather a response to:

 > The limitations are presumably just constant factor ones, and in
 > a world where people happily use things like Java, constant factors
 > that are not _too_ big need not stop something being useful.

Otherwise I agree that something can be done, even despite
the complexity limitations. I also agree that something
can be done locally in some cases. And I also agree that
something can be done statically in some cases. No problem
with that, really.

But you were asking what I mean by:
 >> In which proposal is this substantiated?
 > In which proposal is WHAT substantiated?
 > The exploitability of type information?

I am still not sure whether a pandora box is openened.
I would like to see a concrete analysis in the case of
use case 3 where module C adds an annotation to a frame
from module P and where the code would be written as:

    p(<{k1~v1,k2-v2|F>) ->

What I know from other languages is that for annontations,
if it can be predicted that they might happen, and if
they are orthogonal to subtyping, simply a dict field is
introduced. So one could go with records instead of frames:

    p(#rec{k1=v1,k2=v2,ann=A}) ->

Or if subtyping really happens:

    p(#<{k1~v1,k2~v2,ann~A|F}>) ->

This lowers the degree of polymorphism inside the main
record. There are many such examples, for example client
data in widgets, client data in HTTP requests etc..
etc...

Bye