Record selectors

[Vlad Dumitrescu (EAW)]

Hello again,

I reviewed this whole thread and found plenty of good ideas about ways to improve the record handling. And also a comprehensive list of possible drawbacks. One important point is that it's probably not an Ericsson priority to fix this.

That said and while at it, I think I have found another way to handle this (not entirely original), that might be even compatible with most existing codebase. I'd even would give a try at implementing it, if I wasn't sitting on Windows...

Well, picture this: 
	Sicily.
	1927. 
	A young fatherless boy decides to... 
Erm, sorry, that was not it! ;-D

Here we go: 

	- one problem today is that records are effectively module local (since they only exist as such at compile-time). One straightforward way to turn them into global types would be to create a module for each record type. [From now on, I will refer to them as "user-defined types" or "utypes"] This module (having the same name as the utype) might have a special flag to it, marking it as a type definition module and will export at least a function like for example:
	type_info() -> {field1, field2, field3}.
	Utype instances will look exactly as records do today {record_name, field1, field2, ..}

	- This module has to be accessible to the compiler, when compiling modules using the utype. [I think a way to mark this use may be necessary - a module attribute?] This removes the need for a global table inside the VM, because the compiler can optimize most utype accesses to "regular" tuple access. This also allows to write Person.name instead of Person#person.name in those cases.
	Where can we optimize? Where the type can be assessed at compile time - subsequent uses of variable X are "typed"
		- bla() where record(X, person) -> 
		- X = #person{}
		- Y = <as above>, X = Y
		- maybe other cases, but you get the idea
	In the other cases, one either needs to write Person#person.name, or if writing Person.name one accepts that it is syntactic sugar for something like erlang:access_field(Person) that will find record's name (person) and then use person:type_info() at runtime to select the right field. The compiler might warn for this.
	Matching would work in the same way, most of the times there would not be any penalty. 

	- Implementing utypes as a module also allows for other access ways than direct tuple access. I am not sure though if this wouldn't break compatibility. 
	- Ensuring that all users of an utype use the same version of it is still difficult, but on the other hand the same applies to any module in a system.

I hope it was clearly explained. I'd like very much to hear what you think. 

best regards,
Vlad