[erlang-questions] AST record syntax improvement

[James Churchman]

Doubt im alone in saying that the record syntax is not only poor, but very
acidic to erlang programming. It moves the balance of when you should stop
using a tuple and over to a record strongly to the "il keep using a tuple
thanks" end of things. There was one attempt ( maybe two ) to fix records
but it had a few problems :

the good points:
1) the accessor pattern was great, and ever better for accessing records in
records. something not easy in the regular syntax!!
2) its better than the normal record syntax!
3) it auto detected records, but just within that one function, by noticing
the first time it was used as a record.
4) it added 0 performance penalty for using this new syntax

the not so good points :-) :

1) it was very unreliable, totally unrelated to records erlang code would
randomly break and your left debugging a parse transform that's very deep,
half way threw, all your code.
2) updater code was kinda bad & weird and also made other valid erlang code
into something else
3) maybe a small point, but if you are shipping code to clients, they may
not like code that ships with dependancies on unsupported parse-transform
libraries
4) if you have one record that spans almost all your code in that module,
you still have to repeat the fact its a record at least once in every
function

here is is from all the way back in 2006

http://yarivsblog.blogspot.com/2006/10/recless-type-inferring-parse-transform.html

I know there has been some talk of a record replaclemnt in Erl/OTP but i am
planing on producing my own in the meantime, from a *simplified* AST parse
transform and the syntax would look like this:

> Accessing : Value = RecordTypeVariable.element1.sub_element_of_elemet_1
etc.. just like recless ( also without "=" match like
do_func(RecordTypeVariable.element1) )
> No multiple access, its not really needed in this case
> Updating : NewRec
= RecordTypeVariable(element1.sub_element_of_elemet_1="mynewvalue",element2="mynewvalue_for_element2").

This combines the record syntax with the fun syntax, so looks semi-familiar
and importantly will not produce a syntax error before the parse transform (
otherwise i could have the updater with {}).
The alternate is to mix with record syntax with the (no so popular) PMod
syntax like RecordTypeVar:rec_update(element1.elem1_sub_elem=....)

if the same record is used throughout, it would be possible, but entirly
optional, to set a "global record" for the module, so any var name matching
that "global record" would be auto set
eg :
-global_record(state,['State']). ( single quotes needed to make the capital
value an atom )

Producing a revers that generates the original record syntax for shipping to
clients would be useful i feel too!

So any thoughts on my updater syntax? or suggestions that could be better (
keeping i mind that it still has to pass the first step of parsing!)

James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110521/aef1231f/attachment.htm>