<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 2, 2013 at 5:43 AM, Richard A. O&#39;Keefe&nbsp; wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
A slogan I have programmed by since I first met C and recognised<br>
how vastly superior to PL/I it was for text manipulation _because_<br>
it didn&#39;t have a proper string type is &quot;Strings are Wrong!&quot;.<br></blockquote></div><br></div><div class="gmail_extra">I wonder if you notice the irony in your use of &#39;C&#39; as exemplar in this context?<br>


<br></div><div class="gmail_extra">C rode to fame on the back of Unix. And Unix&#39;s innovation &ndash; one of many &ndash; is that at the OS level the string type was made common fare &ndash; a universal type.&nbsp; So everything from file names to file contents to IPC is a string.<br>


<br></div><div class="gmail_extra">Of course when instructing a beginning programmer your basic premise &#39;Strings are Wrong!&#39; is most likely right.&nbsp; However if programs are seen as entities interacting with an &#39;external&#39; world, the currency at the portals is invariably string.&nbsp; And more than just noob programmers have got this wrong &ndash; think of the precious one-byte opcodes that Intel wastes on ascii and decimal arithmetic. So while this is true:<br>


<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">If bar is predefined, it *isn&#39;t* the string &#39;b&#39;:&#39;a&#39;:&#39;r&#39;:[].<br>
If bar is a number, it *isn&#39;t* a string.<br>
So &quot;other strings&quot; is quite misleading.<br></blockquote><div><br></div><div>&nbsp;in the innards of haskell, bar is a string<br></div>
<br></div><div class="gmail_extra"><br>On Sun, Sep 1, 2013 at 9:51 PM, Albert Y. C. Lai<span dir="ltr"></span> wrote:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">

When 3 and &frac12; are typed next to each other, i.e.,<br>

<br>
&nbsp; 3&frac12;<br>
<br>
it is addition.</blockquote></div><br><br><div class="gmail_extra">Well mathematicians are always eliding!<br><br></div><div class="gmail_extra">In 3&frac12; the elision amounts to +<br></div><div class="gmail_extra">In xy it amounts to *<br>


</div><div class="gmail_extra">And within 23 ie between the 2 and the 3, it amounts to <span style="font-family:&quot;Courier New&quot;,Courier,monospace"></span>ë x y -&gt; 10*x + y<br><br></div><div class="gmail_extra">


And Haskell elides function application<br><br></div><div class="gmail_extra"></div><div class="gmail_extra">When teaching gofer (in the early 90s) I found that undoing the elision of function application and making it explicit, made FP more withing reach of the kids.<br>


</div><div class="gmail_extra"><br>Idea inspired by Dijkstra <a href="http://www.the-magus.in/Publications/ewd.pdf" target="_blank">http://www.the-magus.in/Publications/ewd.pdf</a><br></div><div class="gmail_extra">And more recently summarized <a href="http://blog.languager.org/2013/08/applying-si-on-sicp.html" target="_blank">http://blog.languager.org/2013/08/applying-si-on-sicp.html</a><br>


</div><div class="gmail_extra"><br><br></div><div class="gmail_extra">Rusi<br></div><div class="gmail_extra">-- <br><a href="http://www.the-magus.in" target="_blank">http://www.the-magus.in</a><br><a href="http://blog.languager.org" target="_blank">http://blog.languager.org</a><br>


<br>
</div></div>