[erlang-questions] The compiler "eats" structures which are not separated by commas
Tue Apr 24 04:17:56 CEST 2012
On 24/04/2012, at 11:05 AM, Jan Burse wrote:
> So you basically are telling me that the function:
> record_info(fields, Record) -> [Field]
> Can be found in multiple modules and yielding different
> fields for the same record name. In case the same record
> name is defined differently in different modules.
> Sounds like records cannot transgress modules,
I don't know what you mean by 'transgress'; modules are
not rules that can be transgressed.
Record values can certainly cross module boundaries and
this is common and intentional and works just fine AS LONG AS
both modules -include the same .hrl file.
> Such a limitation I have never heard of in La La Land.
> There are some problems when objects are serialized, but
> generally there is no limitation to the extend of an object,
> unless explicitly expressed by a modifier keyword.
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.
(By the way, "Programming La La Land" did not mean "where
people do OOP". It meant "where people are happy with
objects that do not satisfy a suitable class invariant.")
There is no restriction on the lifetime of a record value
in Erlang, nor is there any problem with crossing module
boundaries, being sent to another process, sent across a
network, stored in a data base, &c. It's just that 'record'
isn't a type (or a type family), it's a *preprocessor*
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.
> Small question. Since records are local to modules.
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.
> Wouldn't the type inference become a little bit
> more simpler?
Ask Kostis. As far as I know, the Dialyzer handles records
tolerably well. But of course now we are talking about
"compile time", not "run time".
> Or can there be ambiguous cases where
> a variable may hold sometimes a record from an outside
> module and sometimes a local record, and here you go.
Of course there can. Left as a trivial exercise for the
Since the Dialyzer can handle union types, I don't see
why this would lead to an #error type.
If you are the Jan Burse who did Jekejeke Prolog, you are
a *master* of Java and know a very great deal about Prolog.
I'm sure you could master the Erlang reference manual.
More information about the erlang-questions