<br><br><div class="gmail_quote">On Mon, Oct 29, 2012 at 4:09 PM, Richard O&#39;Keefe <span dir="ltr">&lt;<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On 30/10/2012, at 3:28 AM, Alexander Solla wrote:<br>
&gt; On Mon, Oct 29, 2012 at 6:52 AM, Michael Orlitzky &lt;<a href="mailto:michael@orlitzky.com">michael@orlitzky.com</a>&gt; wrote:<br>
</div><div class="im">&gt; In any language, a line longer than 80 characters usually (but not<br>
&gt; always) suggests that you might want to stop and rethink your design. In<br>
&gt; many cases a refactoring or two will greatly simplify the code and<br>
&gt; reduce your line length as a result.<br>
&gt;<br>
&gt; I disagree.  That might be true for imperative languages, where width is indicative of deep nesting and its associated problems.  But it is not true for a functional language, where it is merely indicative of a wide &quot;normal form&quot;.  Yes, the normal form can sometimes be refactored, but to what end?<br>

<br>
</div>Better code?  I have no idea of what &quot;a wide normal form&quot; might be, and less<br>
idea of why that would imply that a narrower and better form does not also<br>
exist.</blockquote><div><br></div><div>I made no implication that narrower forms are not useful, or even better, given that the structure is not incompatible with the syntax used to implement it.  (For example, I would much rather [1,2,3,4,5] over</div>
<div><br></div><div>&gt; [1</div><div>&gt; ,2</div><div>&gt; ,3</div><div>&gt; ,4</div><div>&gt; ,5</div><div>&gt; ]</div><div><br></div><div>but would likely prefer</div><div><br></div><div>&gt; [ &quot;alpha&quot;</div>
<div>&gt; , &quot;beta&quot;</div><div>.. </div><div>&gt; , &quot;omega&quot;</div><div>&gt; ]</div><div><br></div><div>over the alternative.</div><div><br></div><div>For example, I generally prefer using the combinators directly when dealing with functors, applicatives, and monads.  This can be written &quot;wide&quot;, but it can also be written in the style of:</div>
<div><br></div><div><font face="courier new, monospace">&gt; f&#39; = f &lt;$&gt; (a &gt;&gt;= g)</font></div><div><font face="courier new, monospace">&gt;        &lt;*&gt; (b &gt;&gt;= h)</font></div><div><font face="courier new, monospace">&gt;        &lt;*&gt; (c &gt;&gt;= i &gt;&gt;= k)</font></div>
<div><br></div><div>That is perfectly sensible.  But if I had to repeat this syntactic construct, I would probably do it wide:</div><div><br></div><div><font face="courier new, monospace">&gt; f&#39; = f &lt;$&gt; (a &gt;&gt;= g) &lt;*&gt; (b &gt;&gt;= h) &lt;*&gt; (c &gt;&gt;= i &gt;&gt;= k)</font></div>
<div><font face="courier new, monospace">&gt; g&#39; = g &lt;$&gt; (d &gt;&gt;= g) &lt;*&gt; (e &gt;&gt;= h) &lt;*&gt; (f &gt;&gt;= i &gt;&gt;= k)</font></div><div><br></div><div>The new row exposes a sort of &quot;tabular&quot; structure.  </div>
<div><br></div><div>This code is easy to edit, all at once, highlights differences, and exposes similarities that might be hidden if written in stanza format and have enough &quot;rows&quot; in that format.</div><div><br>
</div><div>Of course, a &quot;normal form&quot; merely a combinator, or rather, its definiens.</div><div><br></div><div>So one might ask, why not factor this out into a combinator?  That might well be appropriate, or it might not.  Either way, your program end up with a table for values which may vary (since, presumably, the definitions of f&#39; and g&#39; witness that you want to define f&#39; and g&#39;.), as in:</div>
<div><br></div><div><font face="courier new, monospace">&gt; f&#39; = comb f a b c</font></div><div><font face="courier new, monospace">&gt; g&#39; = comb g d e f</font></div><div><br></div><div>This cannot be made any narrower (up to naming). We  can call a normal form n-wide if its combinator requires n arguments.</div>
<div><br></div><div>How many combinators do we really want?  A combinator is what it will take to factor the &quot;wideness&quot; out of a tabular form, and all you get is a maybe narrower tabular form.</div><div><br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My own perspective is that if I can&#39;t fit it onto one slide in large<br>
type for my students to see it is too big.<br></blockquote><div><br></div><div>This is fair enough, but there are some types of extremely uninteresting code that don&#39;t go on slides and are naturally expressed as extremely wide tables.  Typically, it is data for use by the program -- the stuff the program traverses to output its answer.</div>
</div><br>