On 06/02/2012 23:58, Richard O'Keefe wrote:
On 4/02/2012, at 12:13 AM, Gábor Lehel wrote:
All of this said, record.field is still the most readable, intuitive,
and familiar syntax for selecting a field from a record that I know
of.
Having learned COBOL and Algol 68 before Haskell was dreamed of,
I regard
field OF record
COBOL in particular isn't a well-known exemplar of readability. It's
widely seen as a bad joke. I have used COBOL myself, and largely agree
with that, with the proviso that I used COBOL a long time ago and have
repressed most of the details.
Redundancy can be important for readability, but you can have too much
of anything, and in COBOL the level of redundancy is most kindly
described as "cluttered with excessive verbosity".
To be fair, "field OF record" isn't bad in that sense. However, it would
defeat the purpose of TDNR - the record isn't first, and therefore
cannot be used (given a left-to-right typing direction) as a context to
offer member name suggestions.
Also, even when I used COBOL (late eightees, early nineties) I'm pretty
sure it supported "record.field". I don't remember using it, but then I
don't remember using "OF" either - a side effect of loading one record
at a time into working storage and effectively having a separate
variable for each field. Anyway, assuming I'm not suffering from
worse-than-usual memory, COBOL accepted this common convention.
On the more general point of choosing an alternative operator, I agree
to a point, but familiarity does count for something. Others will point
out that Haskell dares to be different, but it's possible to be too
daring and too different. Being different for the sake of being
different is for those teenagers who go on about being "random" and
whatever else they go on about these days. The success of languages like
Java, C# and C++ is based on familiarity.
I think Haskell should dare to be different when there's a point to that
- where necessary based on a principle. We have type classes rather than
OOP classes for a principled reason. We have the IO monad rather than
effectful functions for a principled reason.
If we don't have traditional field-selection for a principled reason, I
think that principle is a very weak one. If names can be scoped to
modules, to case expressions, to let expressions etc, why not to
records? Of course there's a difference, but IMO it's not an important one.
If we are going
to let compatibility with Pascal or C or the like be our guide to
readability and intuition, when are we going to switch from "!" and
"!!" for indexing to _[_]?
So far as I can see, there are two likely principles behind this choice
in Haskell - one weak and one quite strong. One is that we don't have
expressions with syntactic forms other than prefix functions and infix
binary operators, except for a few built-in constructs (case, let, ...)
which aren't functions. There are no special functions with special
parsing. I view this as a weak principle - not important to the paradigm.
OOP languages have supported built-in translations from special
notations to functions/methods for a long time. It's a familiar and
practical approach to, e.g., allowing programmers to define the
semantics of indexing on a new container type.
There is, however, the issue of overloaded notation and a possible
conflict with currying.
Python already uses [] for lists (and list comprehensions) as well as
for indexing. However, Pythons syntax and semantics differ from Haskells
in many ways. In particular, Python doesn't do currying. The difference
between currying in a list parameter and indexing a collection would be
much less clear in Haskell if it supported [] for indexing, probably
damaging readability and possibly (I haven't checked) causing ambiguity
that even the compiler couldn't resolve.
In this case again, perhaps Haskell is different for a principled reason
- choosing to support currying means that either lists or indexing need
a different syntax. IIRC, ML also "dares to be different" WRT indexing -
maybe because it too supports currying.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
