[erlang-questions] If you are homesick for object.selector

[ok@REDACTED]

> While I have no idea how the Erlang parsing process works, I assume it
> would not be very hard to write a pre-processor that does the following;
> 1. parse all code for occurrences of record assignments. (i.e.
> Person#person)
> 2. replace all occurrences of the Variable + "." with
> Variable#typeFromScope.) (i.e. replace "Person.[somevar]" with
> Person#person.somevar.

Why do you assume that?
The preprocessor would have to do more work than the normal
compiler does.

-record(foo, {a}).
-record(bar, {a}).

f(X) -> X#???.a.

There isn't any type in scope.  And this is far from
unusual in Erlang code.
>
> If you did forget to mention your type somewhere, compilation would still
> fail (which is what it should do IMO).
>
> Most of the frustration probably hides in the fact that the compiler
> should
> be able to derive that info from the code, as it has been mentioned
> before.

Should be able to derive it?  Please describe the algorithm.

I used to be an ML fan, and like Haskell a lot.
But there is one phenomenon common to programming
languages with type inference, unless you put a _lot_
of work into error reporting.  This is where a tiny
change to a module in one place (like, for example,
removing one call to a function, leaving others) causes
an error report somewhere else in the module (like the
compiler no longer being able to disambiguate a field).

These days we do have the Dialyzer, but it is an _optional_
tool, and it wasn't designed for this particular task.

I honestly don't see what's so bad about putting the
record name in the selector.  It was common practice in
Lisp-family languages to use things like
    (set-circle-area! my-circle (* (circle-area my-circle) 2))
For that matter, look at C structs like 'struct tm' with its
tm_sec, tm_min, tm_hour. tm_mday &c fields.