
<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>I think the actual syntax is the least of your problems. The existing syntax looks like it does much because of the properties of erlang and of records. Records were added to give named fields to tuples and to be at least as fast as directly using the tuple operations. This means that everything had to be done at compile-time. And as erlang is dynamically typed without any typed declarations then all type information has to be given at each record operation.<br><br>Recless tried to be smart and get around this and only require the field names and not the record names. There are really only two ways of doing this properly:<br><br>1. Require that all field names are unique in all records.<br>2. Require some typing "help" so the system can work out which record types are being accessed.<br><br>The first is very difficult to work with in any large project. It would even be difficult for all OTP records. The second would mean requiring static type declarations to work properly and in all situations, which would be a fundamental change to the current Erlang language. It would, in fact, be a new language.<br><br>Another thing to be aware of is that pattern matching and '=' complicate the syntax. I personally don't think that<br><br><code><font size="3">NewProject = Project.owner.address.city = "Boston".</font><br><br><span style="font-family: times new roman,new york,times,serif;">is that much more intelligible.</span><br style="font-family: times new roman,new york,times,serif;"></code><br>The record replacement you mention is NOT a a replacement for records as they are too firmly entrenched into the whole system to be removed, or even modified. It is a new data type which does contains named fields but is a dynamic data structure. Like giving dicts a special syntax, or like hashmaps in other languages.<br><br>Robert<br><br>----- "James Churchman" <jameschurchman@gmail.com> wrote:

<br>> <div>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 :</div>

<div><br>> </div><div>the good points:</div><div>1) the accessor pattern was great, and ever better for accessing records in records. something not easy in the regular syntax!!</div><div>2) its better than the normal record syntax!</div>

<div>3) it auto detected records, but just within that one function, by noticing the first time it was used as a record.</div><div>4) it added 0 performance penalty for using this new syntax</div><div><br>> </div><div>the not so good points :-) :</div>

<div><br>> </div><div>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.</div><div>2) updater code was kinda bad & weird and also made other valid erlang code into something else</div>

<div>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</div><div>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</div>

<div><br>> </div><div>here is is from all the way back in 2006 </div><div><br>> </div><div><a href="http://yarivsblog.blogspot.com/2006/10/recless-type-inferring-parse-transform.html" target="_blank">http://yarivsblog.blogspot.com/2006/10/recless-type-inferring-parse-transform.html</a></div>

<div><br>> </div><div>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:</div>

<div><br>> </div><div>> Accessing : Value = RecordTypeVariable.element1.sub_element_of_elemet_1 etc.. just like recless ( also without "=" match like do_func(RecordTypeVariable.element1) )</div><div>> No multiple access, its not really needed in this case</div>

<div>> Updating : NewRec = RecordTypeVariable(element1.sub_element_of_elemet_1="mynewvalue",element2="mynewvalue_for_element2").</div><div><br>> </div><div>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 {}).</div>

<div>The alternate is to mix with record syntax with the (no so popular) PMod syntax like RecordTypeVar:rec_update(element1.elem1_sub_elem=....)</div><div><br>> </div><div>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</div>

<div>eg :</div><div>-global_record(state,['State']). ( single quotes needed to make the capital value an atom )</div><div><br>> </div><div>Producing a revers that generates the original record syntax for shipping to clients would be useful i feel too!</div>

<div><br>> </div><div>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!)</div><div><br>> </div><div>James</div>

<br>> _______________________________________________

erlang-questions mailing list

erlang-questions@erlang.org

http://erlang.org/mailman/listinfo/erlang-questions

</div></body></html>