Contribution to the record- and write-your-own-guards debates

[Fredrik Linder]

Hello Folks!

I have spent the last two days investigating what values each field in a
couple of records in our system can have.

Good documentation could perhaps have helped me complete research this
earlier, but then I have to be certain that the documentation have been
updated correctly whenever a violation to this documetation has occurred.
And this I cannot. :-S

I so would have loved to see that field value restrictions was a part of the
record declaration. But then again, records are tuples (I know, but I guess
that's how most of us view them), and hence "not possible".

What I really would like to see is a new kind of data container, similiar to
records, with at least the following properties:

 o Named fields (atom names only)
 o Field value restriction (to be checked at assignment in run-time)
 o Non-destructable (as with all other types)
 o Generic field accessors (to be used as guards)
 o No default values (don't mix declaration with definition)
 o Un-ordered fields (field order is of absolutely no interest)

It would be nice if the field value restrictors and the value specification
in Richard's edoc followed the same specification. If this were implemented,
then edoc could be a way to assert function arguments and return values!
Great!

---

And when I'm already at it:

I often find myself forced to unnecessary nesting in my code due to the fact
that I am disallowed to write my own guards.

I usually write ADTs to conceil my data bearers, which is a practis I find
very good since it nicely divides my code into good working bricks. But
since I am disallowed to write my own guard-functions I cannot match
directly on those ADTs, but have to explicitly extract the information and
then match on these values instead.

This adds an unnecessary complexity level to my code.

Please, please, pretty please with sugar on top -- allow user-written
guards. I know what I am doing, so please allow me to do this.

Guard functions could perhaps be separately specified using
a -guards([guard1/1, guard2/0]}) construct. With the common behaviour that
the guard fails if the corresponsing code is not loaded.

Best Regards to You All
/Fredrik