<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 07/02/2012 22:56, Richard O'Keefe wrote:
<blockquote
cite="mid:38328CAD-4980-4209-8851-4EF581C06366@cs.otago.ac.nz"
type="cite">
<pre wrap="">
On 8/02/2012, at 2:11 AM, Steve Horne wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Yes, but why SHOULD there be a specific typing direction?
ML manages perfectly fine without it.
</pre>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:38328CAD-4980-4209-8851-4EF581C06366@cs.otago.ac.nz"
type="cite">
<pre wrap="">
- #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?
</pre>
</blockquote>
Parsers don't need to care much about left-to-right vs.
right-to-left. There can be stack size issues in principle, but that
hasn't stopped Haskell offering both left-associative and
right-associative infix operators. The ordering has significance in
certain ways in functional languages WRT e.g. currying, but that
isn't really relevant here. In any case, currying is left-to-right
anyway - the left-most argument is curried first.<br>
<br>
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...<br>
<ol>
<li>Searching for all possible names within a particular context
is easier, and generally more likely to be what is needed, than
searching for all possible contexts that contain a particular
name.</li>
<li>It's easier to type the context, then the marker, then
select/type the name than it is to type the marker then the
context, then cursor back to before the marker, *then* select
the name, then cursor back to after the context.<br>
</li>
</ol>
<blockquote
cite="mid:38328CAD-4980-4209-8851-4EF581C06366@cs.otago.ac.nz"
type="cite">
<pre wrap="">Why sacrifice readability (field name precedes record) for the sake
of, well, for the sake of what exactly escapes me.
</pre>
</blockquote>
It doesn't sacrifice readability. The left-to-right order has been
chosen by most programming languages, and also used in many other
contexts, because many people find it very natural to start from the
most general and step down to the more specific in a left-to-right
direction. For example,
<chapter>.<section>.<subsection>, or
<foldername>/<foldername>/<filename>.<br>
<br>
The left-to-right order isn't especially important in general - but
for intellisense it is.<br>
<br>
<blockquote
cite="mid:38328CAD-4980-4209-8851-4EF581C06366@cs.otago.ac.nz"
type="cite">
<blockquote type="cite">
<pre wrap="">
Also, even when I used COBOL (late eightees, early nineties) I'm pretty sure it supported "record.field".
</pre>
</blockquote>
<pre wrap="">
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?)
</pre>
</blockquote>
If I checked, I wouldn't have said "pretty sure" would I? Those
words are generally acknowledged as indicating that someone is
working from fallible memory.<br>
<br>
That said, I did take a look in an old COBOL book. I didn't find
either the dot or the "OF". I vaguely remember that the original
COBOL textbook I had actually considered the SORT command so
intrinsically difficult that it was outside of the scope of the
book. For various reasons, I find it difficult to take COBOL
seriously at all, though I wish I had kept that original textbook
that didn't cover SORT - it was a much better joke than the book I
kept.
<blockquote
cite="mid:38328CAD-4980-4209-8851-4EF581C06366@cs.otago.ac.nz"
type="cite">
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
Yes, but C++ also dares to be different, and there's a principled
reason for having multiple selection operators in C++. There are
multiple namespaces involved. For a smart pointer, for example, .
and -> access different namespaces. :: accesses a different
namespace too - containing the mostly the same names, but treating
them a different way so that arguably you access different things
via those names (or perhaps different aspects of the same things).<br>
<br>
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. Therefore, logically, a
type can be a module. "Module" can be considered a general term for
a container of named items, basically. But I've already raised the
point about simply deciding that record types and record values are
modules before.<br>
<br>
<blockquote
cite="mid:38328CAD-4980-4209-8851-4EF581C06366@cs.otago.ac.nz"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
On not breaking existing code, I'm with you. I once got beaten up
rather badly for arguing against PEP 238 (changing the semantics of
integer division in Python). Although Python seems to have survived,
I still believe it was the wrong thing to do.<br>
<br>
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.<br>
<br>
I even wondered about adapting the field update syntax so that it no
longer does updates, giving something like...<br>
<br>
<value> { <fieldname> }<br>
<br>
This might even be extended as a shorthand for tuples of fields.
Perhaps it's biggest problem are that it's suggestive of [] for
array indexing, which of course Haskell doesn't support, and that
it's too close the the record-update syntax for an expression that
doesn't return a record, and therefore maybe confusing.<br>
<br>
One question, though, is... does using the dot in itself break
existing code?<br>
<br>
Take my view about record types and values being modules and I'm not
convinced it does. Function composition has functions to the left
(and right, of course). Neither a record type nor a record value is
a function.<br>
<br>
Provided the dot has a record type or record value to the left and a
field name to the right, there shouldn't be any conflict with
existing function composition.<br>
<br>
<blockquote
cite="mid:38328CAD-4980-4209-8851-4EF581C06366@cs.otago.ac.nz"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
If we don't have traditional field-selection for a principled reason
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
Actually, traditional field selection only selects the field. The
update is handled by an assignment operator - it really doesn't make
sense to try to tie those two operators together. Arguably, the
field selection doesn't even read the field - it returns a field
identifying thingy (possibly not the correct technical term) which
will convert (causing the read) later, when it's found to be an
rvalue rather than an lvalue.<br>
<br>
In principle, Haskell *could* try something similar, using
first-class values for field-ids that are statically typed for the
record and field types. For modelling imperative code in a pure
functional way, it would be possible to do something like this in
Haskell now for use with the State monad, though the notation
wouldn't be so clean.<br>
<br>
On accessing more than two fields at once, pattern matching isn't
going away.<br>
<br>
On selecting one field for a read, one of the reasons for the
proposal is because quite a few people find that defining a function
in a global (or whole-module) scope is a poor way to handle field
selection - in particular because you can't have the same field name
in several types due to the naming conflict.<br>
<br>
<blockquote
cite="mid:38328CAD-4980-4209-8851-4EF581C06366@cs.otago.ac.nz"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:38328CAD-4980-4209-8851-4EF581C06366@cs.otago.ac.nz"
type="cite"><br>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<br>
Ah - so we're possibly in violent agreement, at least on some
points.<br>
<br>
I very much dislike the one-sided dots, for example, irrespective of
whether they are dots or spelled some other way. I'd rather see...<br>
<br>
<tt><type> <op> <name> : expression for field
access function<br>
<value> <op> <name> : as above, but with the
record argument curried in<br>
</tt><br>
Using "<type> <op> <name>" may seem verbose when
we currently have "<name>", but with a new record notation
that doesn't provide module-wide field access functions, field names
themselves can be made shorter - at the moment, they often need a
type-name prefix anyway for readability and namespace collision
avoidance, just as a convention instead of using an operator.<br>
<br>
A new record notation would be needed, with the same semantics as
the existing one except not making the existing field access
functions available with a module-level scope. However, if one of
the goals of TDNR is to avoid field-name conflicts and namespace
pollution, this is I think unavoidable whatever approach is taken.
The only alternative would be to deprecate the existing field access
functions completely, which is I think unrealistic. A weaker
deprecation of the existing notation might work - warn if it's used,
but allow the warning to be disabled, and don't threaten to ever
remove the notation) but the <br>
<br>
I haven't given a lot of thought to updates. Partly, I suspect that
the existing field update notation would support an
intellisense-like feature anyway - treat the braces in much the same
way as parens for function calls in other languages.<br>
<br>
</body>
</html>