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

[Richard O'Keefe]

On 9/02/2012, at 3:16 AM, Steve Horne wrote:

> On 07/02/2012 22:56, Richard O'Keefe wrote:
>> On 8/02/2012, at 2:11 AM, Steve Horne wrote:
>> 
>> 
>>> 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.
>> 
> For the only reason that any language feature should exist - because it is useful. In any language with a rich library, it is useful to get hints as to which names are available in a particular context. It saves on the need to memorize thousands - sometimes tens or even hundreds of thousands - of context-sensitive names and their spellings, and saves on getting distracted needing to hunt through manuals.

You have totally confused me.  All of those are good things.
NONE of them depends on whether it is field¶record (read
"field OF record") or record.field (read "record, oops, I
only want part of it".)

I think people are losing sight of the fact that code gets
read more often than it gets written (at least, if it is code
that is _worth_ writing).

If the complaint is that certain IDEs designed originally for
Java find it easier to give you a hint after "record.", then
I would point out that

 - there is no reason IDEs they cannot be redesigned.
   Type an expression, then select it if it's complex
   or don't bother if it's just an identifier, literal,
   or bracketed, then
   hit your choice of key (maybe Option-r, ® Reminds me of
   Record), pick your field from a menu, and the IDE
   drops field¶ in front of the selected expression and
   extends the selection to incorporate the field.
   There is no law of God, Nature, or Man that says the
   order in which you press the keys has to correspond
   to the order in which you read things.

 - languages like C++ and Ada and Java already have the
   problem that you can write f (x) where the sensible
   candidates for f depend on what x is.  That is, we
   ALREADY have a need for right context to resolve a
   left side identifier.  Hmm; I was thinking of overloading,
   but actually, Haskell and C have this problem too.
   For int x I want close(x) but for FILE* x I want fclose(x).
   You could write in a C IDE (x, y, z)<magic key> (hey, it
   could be © for Call) and have a menu of visible functions
   with that parameter profile pop up.

 - if you have thousands of context-sensitive identifiers
   visible in one module, you *desperately* need a better
   naming convention and shorter import lists.

 - I have Pharo open on my screen.  There are some 3077
   classes in it.  It insists on popping up these so-called
   "helpful" menus of names that match what I've typed so far.
   I find them distracting, and they tend to obscure what I
   am doing.  I *wish* they didn't do that.  But I have to
   admit that I've never actually seen a long list.  There
   are 30,674 'function names' around (both of the numbers
   are before any of my code is loaded).  Again, I start
   typing something that could be a function name, and up
   pops a list of candidates.  FEH!  Despite Smalltalk's lack
   of any kind of compile-time type checking (this is Pharo,
   not Strongtalk), again, I've never seen a long list.

So I don't see any reason to warp what people *read* away
from readability (function before argument) in order to pander
to the imagined limitations of writing tools.

 - if you have thousands of context-sen

> The point here is for intellisense-like features to work effectively in text editors. The context must come to the left for that to work because...

And that is the claim I just demolished.  The order in which things are entered and the order in which they
are display does not have to be the same.  That is, after all, one thing that "wizards" do for you.

> That said, I did take a look in an old COBOL book. I didn't find either the dot or the "OF".

That is extremely odd, because while COBOL accepts both "field OF record" and "field IN record",
people mostly use "OF".  That must have been the world's worst COBOL book.  (Not unlike the
Prolog textbook I met in a university book shop back when Prolog was new: every single example
was syntactically illegal.)
> 
> Haskell already has a . for selecting a name through a context - we call that context a module. According to Bertrand Meyer of Eiffel fame, a class is both a module and a type.

The Haskell, Ada, Lisp, and CAML designers disagree.

> 
> It would be nice to have some lexical disambiguation in this case - I might prefer some other spelling, so long as the context is on the left and the name is on the right. I was going to propose "?", but that's taken already for implicit parameters - which I don't know the first thing about so I can't guess possible conflicts.

It is by now difficult to find an operating system or editor that doesn't support Unicode.
A quick review of ISO 8859-{1..12,13..16} -- -12 doesn't exist -- shows that the section
character § is common to all of them except -6 (Arabic, but not Persian or Urdu) and -12 (Thai).

How about § then?  Surely at this late date we can allow ourselves *one* non-ASCII character?
The very name of it (*section* sign) suggests taking a part; and if you are totally in love
with dot, think of it as a dot with ponytails.

>> 
> Personally, I don't believe in absolutes, especially WRT readability. Pattern matching is good, but using a case expression just to extract a single field from a record is excessive, causing clutter. That's presumably why we already have the existing functions for reading single fields - but as already mentioned, these cause name-conflict and namespace-pollution issues.

I said pattern matching; I did not say case expressions!  What I was talking about
was turning
	f x y = ... x.a ... x.b .... x.a ... x.c ...
into
	f x={a=ping,b=pong,c=pung} y =
	   ... ping ... pong ... ping ... pung ...

The increase in readability came in part from the shorter function body but mostly
from knowing up front *which* fields were *going* to be relevant in the body.