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

[Jan Burse]

Richard O'Keefe schrieb:
> Records are not objects.  Don't even_try_  to import OO
> concepts into a discussion of Erlang.  It's generally not
> going to make much sense.

Why do you think so? Objects are a superset of records.
Objects encapsulate state, behaviour and identity (Booch
teaching OO for dummies). If you use them to only encapsulate
state and no behaviour and no identity you get records.

So any properties I describe about objects in La La Land
also apply to their use in modelling records, as long as
these properties are not specific to behaviours or
identities of object.

 > There *is* a proposal for a data type that is distinct
 > from tuples and carries all the information you need
 > to do reflection at run time.  Joe Armstrong called such
 > values 'proper structs' and I called them 'frames', but
 > we basically agree on the semantics.

Frames are the grand mother of objects also in La La Land.
But the difference is probably the following. The objects
in La La Land carry their frame slot information not inside
object instances but in the class of an instance. So you can
for example have zillions of instances of a class Color,
that a Color class has a red, green and blue attribute is only
stored once in the class.

So if your are going about to implement frames via some
dictionary data structure (hash table in La La Land) you
will end up with a much bigger memory footprint. Also the
access will be probably much slower. Nevertheless frames
are still seen around. If not using prototypes, you have
them in JavaScript via associative arrays. Closure allows
them for each object, reminiscent of Lisp association lists.
The mess stops only when you clearly decide for a distinction
between classes and instances.

It could be that some newer interpreters, like the JavaScript
interpreter of Chrome, can deduce class information at runtime
in a JIT fashion, and eventually adapt the representation of
their associative arrays. But I am not 100% sure, and would
need to lookup a reference, I think I saw some mention like
this. So maybe something clever could be done without having
an explicit class/instance distinction. JIT can be viewed as
a special strategy of type inference, it collects information
at the call sites during program execution.

 > They aren't.  Many modules may use the same -record
 > declaration via -include.  And records may be passed
 > from one module to another that just holds onto them
 > and passes them back.

Ok, this is the modus operandi. Understood, you get multiple
local preprocessing declaration copies. Oki Doki.

Bye