<br><br><div class="gmail_quote">2012/1/8 Gábor Lehel <span dir="ltr">&lt;<a href="mailto:illissius@gmail.com">illissius@gmail.com</a>&gt;</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">
&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Later on you write that the names of record fields are only accessible<br>
&gt;&gt; from the record&#39;s namespace and via record syntax, but not from the<br>
&gt;&gt; global scope. For Haskell I think it would make sense to reverse this<br>
&gt;&gt; decision. On the one hand, it would keep backwards compatibility; on<br>
&gt;&gt; the other hand, Haskell code is already written to avoid name clashes<br>
&gt;&gt; between record fields, so it wouldn&#39;t introduce new problems. Large<br>
&gt;&gt; gain, little pain. You could use the global-namespace function as you<br>
&gt;&gt; do now, at the risk of ambiguity, or you could use the new record<br>
&gt;&gt; syntax and avoid it. (If you were to also allow x.n syntax for<br>
&gt;&gt; arbitrary functions, this could lead to ambiguity again... you could<br>
&gt;&gt; solve it by preferring a record field belonging to the inferred type<br>
&gt;&gt; over a function if both are available, but (at least in my current<br>
&gt;&gt; state of ignorance) I would prefer to just not allow x.n for anything<br>
&gt;&gt; other than record fields.)<br>
&gt;<br>
&gt;<br>
&gt; Perhaps you can give some example code for what you have in mind - we do<br>
&gt; need to figure out the preferred technique for interacting with old-style<br>
&gt; records. Keep in mind that for new records the entire point is that they<br>
&gt; must be name-spaced. A module could certainly export top-level functions<br>
&gt; equivalent to how records work now (we could have a helper that generates<br>
&gt; those functions).<br>
<br>
</div>Let&#39;s say you have a record.<br>
<br>
data Record = Record { field :: String }<br>
<br>
In existing Haskell, you refer to the accessor function as &#39;field&#39; and<br>
to the contents of the field as &#39;field r&#39;, where &#39;r&#39; is a value of<br>
type Record. With your proposal, you refer to the accessor function as<br>
&#39;Record.field&#39; and to the contents of the field as either<br>
&#39;Record.field r&#39; or &#39;r.field&#39;. The point is that I see no conflict or<br>
drawback in allowing all of these at the same time. Writing &#39;field&#39; or<br>
&#39;field r&#39; would work exactly as it already does, and be ambiguous if<br>
there is more than one record field with the same name in scope. In<br>
practice, existing code is already written to avoid this ambiguity so<br>
it would continue to work. Or you could write &#39;Record.field r&#39; or<br>
&#39;r.field&#39;, which would work as the proposal describes and remove the<br>
ambiguity, and work even in the presence of multiple record fields<br>
with the same name in scope.<br>
<br>
The point is that I see what you gain by allowing record fields to be<br>
referred to in a namespaced way, but I don&#39;t see what you gain by not<br>
allowing them to be referred to in a non-namespaced way. In theory you<br>
wouldn&#39;t care because the non-namespaced way is inferior anyways, but<br>
in practice because all existing Haskell code does it that way, it&#39;s<br>
significant.<br></blockquote><div><br></div><div>My motivation for this entire change is simply to be able to use two record with field members of the same name. This requires *not* generating top-level functions to access record fields. I don&#39;t know if there is a valid use case for the old top-level functions once switched over to the new record system (other than your stated personal preference). We could certainly have a pragma or something similar that generates top-level functions even if the new record system is in use.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br></div><div><div class="h5">
&gt;<br>
&gt;&gt;<br>
&gt;&gt; All of that said, maybe having TDNR with bad syntax is preferable to<br>
&gt;&gt; not having TDNR at all. Can&#39;t it be extended to the existing syntax<br>
&gt;&gt; (of function application)? Or least some better one, which is ideally<br>
&gt;&gt; right-to-left? I don&#39;t really know the technical details...<br>
&gt;&gt;<br>
&gt;&gt; Generalized data-namespaces: Also think I&#39;m opposed. This would import<br>
&gt;&gt; the problem from OO languages where functions written by the module<br>
&gt;&gt; (class) author get to have a distinguished syntax (be inside the<br>
&gt;&gt; namespace) over functions by anyone else (which don&#39;t).<br>
&gt;<br>
&gt;<br>
&gt; Maybe you can show some example code? To me this is about controlling<br>
&gt; exports of namespaces, which is already possible - I think this is mostly a<br>
&gt; matter of convenience.<br>
<br>
</div></div>If I&#39;m understanding correctly, you&#39;re suggesting we be able to write:<br>
<br>
data Data = Data Int where<br>
    twice (Data d) = 2 * d<br>
    thrice (Data d) = 3 * d<br>
    ...<br>
<br>
and that if we write &#39;let x = Data 7 in x.thrice&#39; it would evaluate to<br>
21. I have two objections.<br>
<br>
The first is the same as with the TDNR proposal: you would have both<br>
code that looks like<br>
&#39;data.firstFunction.secondFunction.thirdFunction&#39;, as well as the<br>
existing &#39;thirdFunction $ secondFunction $ firstFunction data&#39; and<br>
&#39;thirdFunction . secondFunction . firstFunction $ data&#39;, and if you<br>
have both of them in the same expression (which you will) it becomes<br>
unpleasant to read because you have to read them in opposite<br>
directions.<br></blockquote><div><br></div><div>This would not be possible because the functions can only be accessed from the namespace - you could only use the dot (or T.firstFunction). It is possible as per your complaint below:</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The second is that only the author of the datatype could put functions<br>
into its namespace; the &#39;data.foo&#39; notation would only be available<br>
for functions written by the datatype&#39;s author, while for every other<br>
function you would have to use &#39;foo data&#39;. I dislike this special<br>
treatment in OO languages and I dislike it here.<br>
<div class="im"><br></div></blockquote></div>