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

Jan Burse <>
Mon Apr 30 11:38:31 CEST 2012


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



More information about the erlang-questions mailing list