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

[Richard O'Keefe]

On 8/02/2012, at 2:11 AM, Steve Horne wrote:

> 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.

Like Fortran, COBOL has changed a *lot* since 'a long time ago'.
And if you did want to be fair, I didn't praise any other aspect of COBOL,
only the naturalness and readability of its notation for accessing a field
of a record.

> 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.

Yes, but why SHOULD there be a specific typing direction?
ML manages perfectly fine without it.

- #1;
stdIn:1.1-1.3 Error: unresolved flex record
   (can't tell what fields there are besides #1)
- #1 (true,3);
val it = true : bool
- #1 (42,"stuff",false);
val it = 42 : int

If a right-to-left "typing direction" works well for #field record
in one language with constrained Hindley-Milner types, why would it
not work well for field¶ record in another language with constrained
Hindley-Milner types?

Why sacrifice readability (field name precedes record) for the sake
of, well, for the sake of what exactly escapes me.


> 
> Also, even when I used COBOL (late eightees, early nineties) I'm pretty sure it supported "record.field".

That certainly wasn't the case up to COBOL-85.  I don't have a copy of COBOL 2002,
so I can't speak for that, but COBOL 74 and COBOL 85 are the only candidates for those
dates, and they definitely did NOT support record.field.  Since '.' is the statement
terminator in COBOL, it's intrinsically unlikely.
(You did *check* a COBOL syntax summary, easily found on the web, before posting?  Which?)

> 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.

Yes, you are suffering from worse-than-usual memory, and it was common practice in some shops
to use the same field name in multiple records, so that the "CORRESPONDING" language feature
would have some point!
> 
> 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.

Using pointy brackets for generic parameters and :: for name scope were not familiar
when C++ introduced them.  And there was prior art in other languages for *both* of those.

One common prior practice, relevantly enough, was '.' for name scope.

> 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.

And if C++ can break with prior practice for a practical reason, Haskell can break with prior practice
for the same reason:  not breaking existing code, fitting into the existing language structure as well
as practical.
> 
> If we don't have traditional field-selection for a principled reason

We don't have it because we don't need it.  And we don't need it because traditional field selection
serves two roles:  *selecting* one field and *updating* one field.  It's a poor way to handle the
latter use case, because one often needs to update more than one field.  It's not _that_ good for
the former use case either, if you need to access more than two fields from the same record.

In another functional language that I use, I've noticed what seems to me a marked increase in
readability by switching _away_ from field selection to pattern matching.

> 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.

Nobody is arguing against names being scoped to records.
The argument is against using dot for it because dot has too many other uses.
We have already seen quite enough horribly confusing examples in this thread.