Record selectors

Vlad Dumitrescu (EAW) <>
Mon Jan 13 11:03:53 CET 2003

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: 
	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 instead of 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, or if writing 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,

More information about the erlang-questions mailing list