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

[Jan Burse]

ok@REDACTED schrieb:
> We could have a rule that says "take all the
> -record(name, { ..., field ... })
> declarations that are visible in the current module,
> and for each field name, construct a function
>
>      field(#rec1{...,field=X,...}) ->  X;
>      ...
>      field(#recn(...,field=X,...}) ->  X.
>
> "
> so that instead of Foo#rec.bar we could use a plain
> bar(Foo), which is much better syntax for a functional
> language than 'get' prefixes.  And the type language
> used by dialyzer could handle this.

This would not be the intention of a getBar(Foo). To
be universal so that a resolution a runtime can happen.
The intention would be that there are multiple getBar()
for each record type that has a bar field. And that
the resolution is done a compile time.

For a resolution at runtime we wouldn't even need
a type inference. Only access to the meta data of
the record type declaration. So the universal
getXXX() would be:

     getXXX({Name|Rest}) ->
        ... record_info(fields,Fields) ...
        ... determine index of XXX in Fields ...
        ... access Rest with index ...

(The above code is incomplete and I don't think a
{Name|Rest} pattern exists in Erlang, but I guess
the above can be coded).

I guess same could be said for a setXXX(), that a
universal one wouldn't need type inference and could
be coded in the same vain as the getXXX().

Only reason getXXX()/setXXX() is probably not done
is performance loss I guess, since by its universality
it must do a record info lookup since any record type
Name can come at runtime.

If there are multiple getXXX()/setXXX() as in Java
then there is no performance problem, only the type
inference problem. Well this is not exactly true.
Depending on the class hierarchie there can be also
late binding and various inline caching techniques
are then used:
http://en.wikipedia.org/wiki/Inline_caching

Bye