Record comprehension

[Kent Boortz]

>>Well, that would be because a record is really just a tuple with the name of
>>the record type as the first member. Thus
>>#tester{first=first,second=second,third=third} is really just
>>{tester,first,second,third}. Though I'm a little surprised that the lookup
>>of H#tester.second didn't cause a runtime error due to H not being the right
>>kind of record.
>
> Yes, it is a bit surprising.
> I believe the main reason is that testing whether a variable is
> actually of the proper record type requires type analysis, which is
> something the current compiler doesn't do. For all other types, the
> runtime system will perform basic type checks, but since there is no
> record type, the runtime system can't do much.

There is no "type analysis" but the compiler could generate code that
before an operation check the arity of the tuple as well as that the
first element of the tuple is the right atom. It is worse, in some
situations there is a test, in others not. I don't remember the
details but there are some code to optimize record handling in
"sys_pre_expand" that translate record matching to different type of
code depending on how many arguments of the record are
updated/matched. And the preprocessor is so early in the compilation
process that your coding style will effect the generated output, if
there will be a test for record type or not. I have some examples
somewhere, I will try to find it.

Changing this behaviour now may break existing code that by mistake or
intentionally use this misfeature ;-)

kent