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

[Richard O'Keefe]

On 24/04/2012, at 7:50 PM, Jan Burse wrote:

> 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).

Records
 - do not have identity distinct from their contents
 - do not encapsulate mutable state
 - do not have any associated behaviour
 - are not associated with anything even remotely like
   classes, inheritance, or delegation.

That is, NONE of the OO concepts apply to records.

> If you use them to only encapsulate
> state and no behaviour and no identity you get records.

This reminds me of a joke that I saw several times in the
"Pogo" comic strip by Walt Kelly; I don't know whether he
invented it or not.

	If the Mayor could read, I'd write him a nasty
	letter about this, if I could write.

> So any properties I describe about objects in La La Land

nononononononononno!  Remember, "programming La La Land"
(Macintosh Dictionary defines "La La Land" as "a fanciful
dreamworld") is *****NO***** the world of object oriented
programming.  It is the world in which programmers are
encouraged to create incompletely initialised data
structures that do not satisfy any useful invariant,
whether those data structures are objects or not.

> also apply to their use in modelling records, as long as
> these properties are not specific to behaviours or
> identities of object.

OR encapsulation of mutable state.  In short, you are saying,
yes, really you are, "Any properties I describe about objects
apply to records as long as they are not OBJECT properties".
A fat lot of use _that_ is!

Erlang is often characterised as an Actor language.  As such, 
the nearest equivalent of an object in Erlang is not a record
but a *process*.

Processes have
 - a persistent identity distinct from their state
 - encapsulate state which varies with time
 - are created in modules that equip them with state
 - messages they respond to (some versions of Actors, and
   early versions of Smalltalk, used something uncommonly
   like an Erlang 'receive' to indicate willingness to
   accept a message and select what to do based on its
   contents) which clearly counts as associated behaviour

Trying to apply object-oriented concepts to records .

> 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.

You were told before that "programming La La Land" had
nothing to do with objects.  Please remember that.  If you
had read the frames proposal, you would have realised that
the proposed implementation has the first slot pointing to
a descriptor, which can be shared by any number of frames
having the same slots.  This is precisely the same as an
object pointing to its class.

At this late date, I am sure that I don't have to point out
that there is a wildly popular object oriented language
that doesn't *have* classes.  Sadly, I don't mean 'Self'.
I mean, of course, JavaScript.  Logically, JavaScript
objects *do* carry their slot information inside object
instances.  Some implementations do very clever things at
run time, and I suppose there may have been an influence
from advanced JavaScript implementation techniques on the
frames proposal, although I thought I was inspired by Self.

> 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.

In exactly the same way, you can have 'zillions of instances'
of a frame <colour{red = R, green = G, blue = B}> where each
instance is four words: R, G, B and run time type information.
If I was to have any hope of getting frames accepted, I felt
I had to show that they would have no space penalty compared
with records.  (They could even take less per-instance space.)
> 
> So if your are going about to implement frames via some
> dictionary data structure (hash table in La La Land)

Would you kindly have the goodness to READ the frames proposal
before criticising it?  Frames are NOT dictionaries and
dictionaries in general are NOT the same as hash tables (in my
Smalltalk system I have four different implementations of
dictionaries, only one of which is a hash table).  The frames
proposal does not use hash tables.

> 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,

There are true compilers for JavaScript.
The Rhino JavaScript compiler compiles JavaScript sources to
Java .class files, for example.  You may perhaps be thinking
of this:

	in SpiderMonkey[, m]ost objects are represented by a
	shared structural description, called the object shape,
	that maps property names to array indexes using a
	hash table.  The object stores a pointer to the shape
	and the array of its own property values.

	(This is from the PLDI'09 paper about TraceMonkey.)

This is pretty much the representation in the 'frames' paper
except for the frame shape not being a hash table.