[Haskell-cafe] Some thoughts on Type-Directed Name Resolution

[Steve Horne]

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.