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

[Jan Burse]

Michael Turner schrieb:
> Richard is right: if there's anything corresponding to the concept of
> "object" in Erlang, it's "process", not "record." Note my "if".
> Processes are well-defined in Erlang. So are records. "Object" never
> got a consensus definition in software engineering. Pontificate all
> you want on what you consider the essence of object-oriented
> programming. You'll always get an objection -- from another OO
> pontiff, usually.

Thank you for misunderstanding me.

If you are only looking at what is currently in Erlang, you
might be right that process are more closes to objects than
records are. But the current discussion is not only about
the present but also about possible futures, in particular
proposals such as frames.

And inside this discussion I take OO as a constrast,
to compare with. In particular I prefer taking OO
as found in Java as a contrast, since this lives in
present and neither in the past or future. I am particular
interested in solving some inherent problem with frames,
that bothered me already in the 90's.

If it were possible to create a frame data structure
with very good footprint and performance properties, I
would have used it already back then. But when I looked
at it back then, I found some inherent limitations that
I guess cannot be overcome, except if you can walk on
water or turn water into wine, i.e. if there is a
miracle.

I guess there are theoretical papers around that
show these limitations inherent in polymorphism. If
I have time I can post some links here. So if somebody
claims to have solved this and that problem, either
indepedent of some programming language or inside some
programming language specification, I always get
suspicious.

And sorry my "bye" is not that "bye" that you would
like to think of. I am interested in sorting the thing
out, since I might learn something. 90's is already a
long time ago, and discoveries might have been made.
For example there have been some interesting developments
in data structures for functional programming languages,
that are immutable from the outside, but might use
destructive operations in the inside. Etc..

But statements as follows:

ROK wrote:
 > 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.

Are especially dangerous. They insuinate that late
binding (*) can be solved performance wise. I am primarily
concerned with the idea that some borders can be pushed
that have not already been push for example by my contrast
OO language Java. So I am awaiting clarification:

JB wrote:
 > In which proposal is this substantiated?

Bye

(*)
http://en.wikipedia.org/wiki/Late_binding