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

Jan Burse <>
Tue Apr 24 01:05:09 CEST 2012

Richard O'Keefe schrieb:
> No.  They are not done because they CANNOT be done
> because there can be multiple record types with the
> same name and it is IMPOSSIBLE to discover from a
> run-time value which of those record types was meant.

Well I am not advocating the unversal solution, I am an
advocate of the La La Land solution which is not universal,
and I didn't know that the universal solution is impossible
in Erlang. In La La Land a universal solution is available
via the reflection facility (*). But lets turn back to Erlang.
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 guess
this is also what your first example shows. Maybe they
can transgress modules, but can only be accessed via
tuple expressions outside of their module. Is this
the modus operandi?

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.

Small question. Since records are local to modules.
Wouldn't the type inference become a little bit
more simpler? 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,
the inferenced type would be #error. A useful type
lattice could be:

      /  |    |   \
     R1  R2  ...  RN
      \  |    |   /

Where R1, R2, .., Rn are the module local record types.
And the end-user can drop the record name in setter/getter
expressions when the inference is neither #error
nor #undef. The whole approach is "useless" if the type
inferencer will tell #error or #undef most of the time.



More information about the erlang-questions mailing list