[Haskell-cafe] Records (was Re: [Haskell] Improvements to GHC)
cgibbard at gmail.com
Thu Nov 17 17:52:38 EST 2005
On 17/11/05, Benjamin Franksen <benjamin.franksen at bessy.de> wrote:
> On Thursday 17 November 2005 19:21, Cale Gibbard wrote:
> > Sebastian Sylvan wrote:
> > >Personally I think that the dot is way to good of a symbol to be
> > >"wasted" on function composition. I mean, how often do you really
> > > use function composition in a way which doesn't obfuscate your
> > > code? I use ($) way more often than (.). Some people do use it more
> > > often than I
> > Function composition is a very important and fundamental operation on
> > functions, and I use it all the time. Haskell is supposed to be a
> > functional language. I'd vote against any motion to make it less
> > convenient. Of course, it really shouldn't be (.) but a small circle
> > centred on the line, which isn't on ordinary keyboards. (°) looks
> > closer, but is much less convenient to type. (I need to type
> > "<Compose> 0 ^" in order to get that character.) Spelling it as (.)
> > really is the best easy-to-type approximation.
> Yes, yes, yes. I'd rather use a different operator for record selection.
> For instance the colon (:). Yes, I know it is the 'cons' operator for a
> certain concrete data type that implements stacks (so called 'lists').
> However I am generally opposed to wasting good operator and function
> names as well as syntactic sugar of any kind on a /concrete/ data type,
> and especially not for stacks aka lists.
However, the way things are currently, all symbols starting with ':'
are constructors of concrete data types, as that's how infix data
constructors are distinguished. Also, I must point out that lists are
a pretty important structure in lazy functional programming, taking
the place of loops in an imperative language, and their importance
shouldn't be taken so lightly. Given how much they are used, giving
them a little syntax sugar and good looking data constructors doesn't
seem all that far off. On the other hand, I would like to see list
comprehensions generalised to monad comprehensions again.
> For a hypothetical Haskell2 I'd propose to get rid of all special 'list'
> constructs and re-use the good symbols and names for /abstract/
> interfaces to sequences and collections resp. (in case of the colon)
> for record selection.
However, you can't abstract data constructors. If cons was abstracted,
then you couldn't use it in pattern matching, which is problematic.
> Just my 2 cent.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe