I vote for a separate namespace for record access functions. To me a
gameID in one record is always the same gameID in another record and
having to add prefixes to each access field sucks when records number
in the hundreds :-(.
My users now have to deal with tiGameID, blahBlahGameID, etc. and
they are all the same.
My previous big project was in Erlang and it uses more or less the
same approach to records as they are hacked on top of tuples. They
_are_ tuples in Erlang and you can access fields with element(x,
mytuple).
Still, record labels in Erlang are not considered global functions.
They are just... lables which makes a whole lot of sense and
simplifies ones work immensely!
Thanks, Joel /who has just coded about 250 packets as records/
On Nov 17, 2005, at 1:46 PM, David Roundy wrote:
On Thu, Nov 17, 2005 at 10:03:00AM +0100, Ketil Malde wrote:
2) Improving Haskell support for records.
Right - the problem is that nobody seems to agree exactly how to do
this. I like the fact that record access looks like (is?) a simple
function application, and conversely, dislike that the record update
syntax is different.
Whereas I take the opposite approach. The simple function
application is
often a bad function--one that may return bottom--and I'd rather be
able to
place hedges around dangerous functions like that. In contrast,
pattern
matching is safe. Record update (on the third hand) is unsafe, but
uses
similar syntax to pattern matching. It's a mess. The whole namespace
issue only exists for record access functions, which is a feature
that I'd
prefer to have dropped from the language anyways.
--
http://wagerlabs.com/
_______________________________________________
Haskell mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell
