<div dir="ltr"><div class="gmail_extra">Hi Joe,<br><br><div class="gmail_quote">On Fri, Jan 31, 2014 at 8:49 AM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com" target="_blank">erlang@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>On Fri, Jan 31, 2014 at 7:50 AM, Michael Turner <span dir="ltr"><<a href="mailto:michael.eugene.turner@gmail.com" target="_blank">michael.eugene.turner@gmail.com</a>></span> wrote:<br>
</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">One thing I've gotten out of this excellent thread: given what some<br>
people (but not Joe, I guess) want out of a programming environment,<br></blockquote><div><br></div></div><div><div>What I want in a programming environment would take a book to describe.</div><div><br></div><div>For starters, I would like it to be precisely documented.</div>
<div><br></div><div>It should be textual not GUI based - the reason for this is automation - I cannot</div><div>easily automate things if they are GUI based. I can automate things if they are text based.</div><div>Also It's very difficult to describe what to do in a GUI - the descriptions need pictures</div>
<div>to tell you what to do.</div><div><br></div><div>I currently think Knuth was right.</div></div></div></div></div></blockquote><div><br></div><div>With all due respect to you and Donald Knuth, there is something in your text (above and below) that makes me feel confused. Maybe it's just me and then it's ok (for the rest of the world, at least), but maybe not. I don't know if I will be able to express what this confusion is about, but I will try. Maybe you meant something else than I understood and I'd love to get it right.</div>
<div><br></div><div>It got a bit long, sorry about that. Look for "****" for the TL;DR</div>
<div><br></div><div>---</div><div>Why does automating something have anything to do with that thing being textual or graphical? vim runs in a console, but also as gVim (graphical). The same can be said about emacs and XEmacs. Eclipse can be run in headless mode (but I admit that there are rather few tools that work in that mode). To me, a tool can be automatable at two levels: it can be run from the command line and it might return meaningful data that some other tool can process further. I don't see what this has anything to do with the tool being textual or graphical. These parts are just the presentation layer...</div>
<div><br></div><div>Whether we want it or not, to the human brain images are lower level than text or speech. We can't read text files directly, we interpret the graphical representation of that text, be it on a console or a window. Some people can handle abstractions in their heads more easily than others. The latter category will need help, possibly in the form of tools to visualize the code (or whatever). If you are from the former category, more power to you, but that doesn't mean that it works for all people. It feels a bit like Usain Bolt saying "Bicycles? They are utterly useless, I can run faster than that and it's better to one's health".</div>
<div><br></div><div>In my opinion, what a programming environment brings to the table is multiple ways to look at the code, to quickly see what is going on. It also provides a toolbox of utilities that can be used to process the code. I find it largely irrelevant if the environment is a GUI or not, I only need it to give me the information I need in the format that is best suited for me. </div>
<div><br></div><div>It's the same kind of help one gets from a debugger: one could run the code in one's head and look for where the problem is, but it's much more effective with a tool that shows the system's exact state, not to mention that one can ask for a colleague or two to look at it. </div>
<div><br></div><div>Taking a TeX example, wouldn't you find it helpful to have a window alongside your editor that show in real time how the document is rendered, without the need to run "tex mydoc.tex | pdfview&" (or whatever) yourself once in a while? Once you start to use more and more complicated macros, wouldn't be useful to be able to see the documentation for these, maybe to be able choose between a couple of similarly named ones? </div>
<div><br></div><div>Or in Erlang (and doing some wishful thinking), wouldn't it be useful if one could actually _see_ in real time the network of processes in a node, how they are linked/monitoring each other, how they communicate, which ones are growing large or seem deadlocked, zoom out for a bird-eye view or in for details? Or more realistically, running some tests and get diagrams of the process communication, where selecting a message could show details and the code where it is sent and received? In my humble opinion, it sure would beat scrolling through wades of logs and code... </div>
<div><br></div><div>As a user, one shouldn't need to understand how the environment works (you think Eclipse is complex, I think Emacs is; it's a matter of what we are accustomed to). Of course, this changes when I need to do something that the environment doesn't support. But even so, there is always the fallback of doing it as if no IDE was available, so I don't think that having an IDE can make things worse.</div>
<div><br></div><div>That said, existing IDEs have widely different pros and cons, weaknesses and strengths. None is perfect and one of the main reasons that none can be perfect for everybody is that each developer has different needs and expectations. Make it too narrow and only few will use it. Make it too broad and the plethora of setting to tweak will make most people ignore them (thus the development effort is wasted).</div>
<div><br></div><div>****</div><div>My vision for an IDE is that there should be a core of (narrow) tools cooperating to provide a broad functionality for processing source code and delivering useful data from the code base, tools that are agnostic of any way of interacting with it or of presenting the results. Think of it as syntax_tools on super-steroids. These tools can then be used by emacs, or Eclipse, or vim, or from scripts, or whatever. I am aiming for that with erlide, but it's a long way to go.</div>
<div>****</div><div><br></div><div>---</div>
<div>Knuth could do this amazing thing with TeX (practically no bugs) for all the reasons you stated, but also because he set very strict boundaries for what TeX is and can do. Basically, he not only froze the specifications, he set them in stone. If that would have been enough, would there have been a need for XeTeX, pdfTeX, laTeX and other tools that extend and improve the basic TeX? Would it have been possible to keep the bug levels as low if these extensions and improvements had been part of the core TeX? <br>
</div><div><br></div><div>Your example of "hello \end" being easy to understand is misleading. So is "echo 'hello'" or "printf 'hello'" or "System.out.println("hello");" (the latter with some boilerplate removed). What is interesting is whether a real-life example is easy to understand. You say "it's just a matter of understanding what the primitives do", but isn't this exactly the difficult part with everything? "Just understanding" might mean a lot of work and time and effort... Given a complex document typeset in plain TeX (i.e without any macro libraries and containing Unicode text), the code is going quickly to get more that one can hold in one's head and I doubt that it's going to be just as easy to understand, even if one would understand perfectly what each primitive does. I venture to state that it would probably be just as easy or difficult as it would be for any well-designed programming language. As a matter of fact, because TeX macros can define their own syntax too, it might make the result more difficult to read (given that not all macros are written by Donald Knuth himself).</div>
<div><br></div><div>best regards,<br></div><div>Vlad</div><div><br></div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>The version numbering of TeX (using successive digits of Pi) is brilliant</div><div><span style="line-height:16.895999908447266px;font-size:11.428571701049805px;background-color:rgb(249,249,249);font-family:sans-serif">TeX it at version 3.14159265 - Knuth also pays a reward (in cash) for every new bug. The reward</span></div>
</div><div><span style="line-height:16.895999908447266px;font-size:11.428571701049805px;background-color:rgb(249,249,249);font-family:sans-serif">doubles for each new error.</span></div><div><span style="line-height:16.895999908447266px;font-size:11.428571701049805px;background-color:rgb(249,249,249);font-family:sans-serif"><br>
</span></div><div><span style="background-color:rgb(249,249,249)"><font color="#000000" face="sans-serif"><span style="font-size:11.428571701049805px;line-height:16.895999908447266px">This scheme means that the project will be </span><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">abandoned</span><span style="font-size:11.428571701049805px;line-height:16.895999908447266px"> if there are more then 15 or so bugs - because the</span></font></span></div>
<div><span style="background-color:rgb(249,249,249)"><font color="#000000" face="sans-serif"><span style="font-size:11.428571701049805px;line-height:16.895999908447266px">version number would be too long, and the cost too great - and it probably should be </span></font></span><font color="#000000" face="sans-serif"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">abandoned</span></font></div>
<div><span style="background-color:rgb(249,249,249)"><font color="#000000" face="sans-serif"><span style="font-size:11.428571701049805px;line-height:16.895999908447266px">if it had this number of errors.</span></font></span></div>
<div><span style="background-color:rgb(249,249,249)"><font color="#000000" face="sans-serif"><span style="font-size:11.428571701049805px;line-height:16.895999908447266px"><br></span></font></span></div><div><span style="background-color:rgb(249,249,249)"><font color="#000000" face="sans-serif"><span style="font-size:11.428571701049805px;line-height:16.895999908447266px">Knuths way of working - Literate programming - with patch files - enforces an </span><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">incredibly</span><span style="font-size:11.428571701049805px;line-height:16.895999908447266px"> disciplined way</span></font></span></div>
<div><span style="background-color:rgb(249,249,249)"><font color="#000000" face="sans-serif"><span style="font-size:11.428571701049805px;line-height:16.895999908447266px">of working. TeX (as a literate program) is just about the only example I know of a large complex program</span></font></span></div>
<div><span style="background-color:rgb(249,249,249)"><font color="#000000" face="sans-serif"><span style="font-size:11.428571701049805px;line-height:16.895999908447266px">that is understandable and has no known errors.</span></font></span></div>
<div><span style="background-color:rgb(249,249,249)"><font color="#000000" face="sans-serif"><span style="font-size:11.428571701049805px;line-height:16.895999908447266px"><br></span></font></span></div><div><span style="background-color:rgb(249,249,249)"><font color="#000000" face="sans-serif"><span style="font-size:11.428571701049805px;line-height:16.895999908447266px">TeX was produced without fancy editors and revision control systems and IDEs and all that stuff.</span></font></span></div>
<div><br></div><div><font color="#000000" face="sans-serif"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px;background-color:rgb(249,249,249)">The only downside of Knuths way is that it takes a long time to write the program.</span></font></div>
<div><font color="#000000" face="sans-serif"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px;background-color:rgb(249,249,249)"><br></span></font></div><div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">At a guess 80% of software costs are in maintenance of legacy code - so in the long term </span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">Knuthian development pays off. Being early to market with buggy software is however the</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">way to make money. What earns you most money in the short term costs you most in the long term.</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px"><br></span></span></font></div><div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">TeX is interesting in a sense that (say) eclipse is not. I feel it is possible to learn how TeX works</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px"><br></span></span></font></div><div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">(aside I have started on this journey</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px"> "Hello \end"</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">is a minimal TeX program that I can understand. All I need to do is understand what</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">the primitives do, and then how the macro expansion works, ...</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">)</span></span></font></div><div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px"><br>
</span></span></font></div><div><font color="#000000" face="sans-serif"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px;background-color:rgb(249,249,249)">There is no way I can understand something like eclipse - there is no documentation of what it does and how</span></font></div>
<div><font color="#000000" face="sans-serif"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px;background-color:rgb(249,249,249)">it works - only documentation of how to use it.</span></font></div>
<div><font color="#000000" face="sans-serif"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px;background-color:rgb(249,249,249)"><br></span></font></div><div><font color="#000000" face="sans-serif"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px;background-color:rgb(249,249,249)">I only like doing things I can understand.</span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px"> </span></span></font></div><div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">emacs is in the TeX category - I can "in principle" read the code and see what it does</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px"><br></span></span></font></div><div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">(another aside - reading code to see what it does is highly overrated - reading my own code</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">that I wrote years ago is difficult - reading other peoples code is doubly difficult - reading undocumented</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">code in a language I don't really understand to fix a bug that I didn't want to fix into order to solve a problem</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">that I do want to solve is an incredible waste of time - and that's why I like Kuthian rigour in software)</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px"><br></span></span></font></div><div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">Nowhere have I said that this is easy - but I believe that IDEs etc make matters worse by hiding</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">what should not be hidden. If it's such a mess that it needs tool support to write then the solution is</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">to clean up the mess not provide tools to hide the mess.</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px"><br></span></span></font></div><div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">As I said - I could write a book on this :-)</span></span></font></div>
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px"><br></span></span></font></div><div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">Cheers</span></span></font></div>
<span><font color="#888888">
<div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px"><br></span></span></font></div><div><font color="#000000" face="sans-serif"><span style="background-color:rgb(249,249,249)"><span style="font-size:11.818181991577148px;line-height:16.895999908447266px">/Joe</span></span></font></div>
</font></span><div><div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
and what some people like in programming languages (Joe, for example),<br>
somebody should do an Erlide for Elixir.<br>
<br>
Regards,<br>
Michael Turner<br>
Executive Director<br>
Project Persephone<br>
K-1 bldg 3F<br>
7-2-6 Nishishinjuku<br>
Shinjuku-ku Tokyo 160-0023<br>
Tel: <a href="tel:%2B81%20%283%29%206890-1140" value="+81368901140" target="_blank">+81 (3) 6890-1140</a><br>
Fax: <a href="tel:%2B81%20%283%29%206890-1158" value="+81368901158" target="_blank">+81 (3) 6890-1158</a><br>
Mobile: <a href="tel:%2B81%20%2890%29%205203-8682" value="+819052038682" target="_blank">+81 (90) 5203-8682</a><br>
<a href="mailto:turner@projectpersephone.org" target="_blank">turner@projectpersephone.org</a><br>
<a href="http://www.projectpersephone.org/" target="_blank">http://www.projectpersephone.org/</a><br>
<br>
"Love does not consist in gazing at each other, but in looking outward<br>
together in the same direction." -- Antoine de Saint-Exupéry<br>
<div><div><br>
<br>
On Fri, Jan 31, 2014 at 3:25 PM, kraythe . <<a href="mailto:kraythe@gmail.com" target="_blank">kraythe@gmail.com</a>> wrote:<br>
> Well I think after seeing the arguments and the response of the community I<br>
> am trending seriously towards Erlang. I will probably make the mental<br>
> investment to learn and become good with emacs. And then move on from there.<br>
> I may still have a ton of questions. I would still, for example, love to<br>
> know who to 'reload' my application once it is started.<br>
><br>
><br>
> On Fri, Jan 31, 2014 at 12:24 AM, kraythe . <<a href="mailto:kraythe@gmail.com" target="_blank">kraythe@gmail.com</a>> wrote:<br>
>><br>
>> Well I think after seeing the arguments and the response of the community<br>
>> I am trending seriously towards Erlang. I will probably make the mental<br>
>> investment to learn and become good with emacs. And then move on from there.<br>
>> I may still have a ton of questions. I would still, for example, love to<br>
>> know who to 'reload' my application once it is started.<br>
>><br>
>> Robert Simmons Jr. MSc. - Lead Java Architect @ EA<br>
>> Author of: Hardcore Java (2003) and Maintainable Java (2012)<br>
>> LinkedIn: <a href="http://www.linkedin.com/pub/robert-simmons/40/852/a39" target="_blank">http://www.linkedin.com/pub/robert-simmons/40/852/a39</a><br>
>><br>
>><br>
>> On Thu, Jan 30, 2014 at 10:29 PM, Richard A. O'Keefe <<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>><br>
>> wrote:<br>
>>><br>
>>><br>
>>> On 31/01/2014, at 7:49 AM, Steve Strong wrote:<br>
>>> > On Thursday, 30 January 2014 at 19:10, kraythe . wrote:<br>
>>> >> 1) Code completion. Sorry but I can't be bothered to type the same<br>
>>> >> flipping method name in its entirety 40 times.<br>
>>><br>
>>><br>
>>> There are three causes for "completion" in languages like<br>
>>> Prolog and Erlang:<br>
>>><br>
>>> (a) Definitions with multiple clauses.<br>
>>> Your editor should be able to turn "add a clause" into a<br>
>>> single command.<br>
>>><br>
>>> (b) Recursion.<br>
>>> Your editor should be able to turn "add a recursive call"<br>
>>> into a single command (basically the same as (a), just<br>
>>> different stuff wrapped around it).<br>
>>><br>
>>> A programming style using higher order procedures can<br>
>>> eliminate a lot of this.<br>
>>><br>
>>> (c) Repetitive patterns of code.<br>
>>><br>
>>> A programming style using higher order procedures can<br>
>>> eliminate a lot of this.<br>
>>><br>
>>> There's a thing I find myself saying more and more often:<br>
>>><br>
>>> Why can't I see the structure?<br>
>>><br>
>>> I was reviewing a page or two of Prolog code for someone the<br>
>>> other day. By the end of three hours, I'd made some progress,<br>
>>> but I was troubled. The code was clean, but it wasn't OBVIOUS.<br>
>>> What finally dawned on me would have been instantly obvious to<br>
>>> a real functional programmer: the code was an interweaving of<br>
>>> a "compute argmax of a partial function over a finite domain"<br>
>>> and "here is this partial function". Actually introducing the<br>
>>> higher order function in question let me explore several ways<br>
>>> of implementing that *without* any effect on the rest of the<br>
>>> code. Breaking the specific partial function out and naming<br>
>>> it let me see that memoising *that* function -- which hadn't<br>
>>> previously existed -- stood an excellent chance of reducing<br>
>>> the overall cost of the algorithm down *hugely*.<br>
>>><br>
>>> So I say, if you find yourself _wanting_ a method name to<br>
>>> appear 40 times in a day's work, you are doing something<br>
>>> badly wrong.<br>
>>><br>
>>> For another data point, as part of building up my Smalltalk<br>
>>> skills, I used to pick up Java code and rewrite it in Smalltalk.<br>
>>> There were two invariable results: first, the code would<br>
>>> shrink by about a factor of six, and second, it would become<br>
>>> painfully obvious that the original code was really really<br>
>>> bad design, and that in a *good* OO design, most of the<br>
>>> classes wouldn't just shrink, they'd disappear. A good part<br>
>>> of this is down to Smalltalk's support for and extensive use<br>
>>> of higher order functions from day 1.<br>
>>><br>
>>> ><br>
>>> > 3) Syntax coloring. (VIM color codes a file so that is there, emacs I<br>
>>> > don't know AT ALL.)<br>
>>> To which Steve Strong replied<br>
>>> > I don't know of any editor that doesn't do this -<br>
>>> > even github displays syntax colouring on erlang files.<br>
>>><br>
>>> My own text editor doesn't do syntax colouring.<br>
>>> Frankly, I hate syntax colouring. I could give you<br>
>>> a long rant about why. One big issue is that the<br>
>>> name is a lie. It's *lexical* colouring; the colour<br>
>>> depends on what kind of token something is. But I<br>
>>> can *see* that. If you offered me an editor where<br>
>>> calls to functions whose definitions had been edited<br>
>>> recently were brightly coloured, or where the functions<br>
>>> imported from a particular module were brightly coloured,<br>
>>> or where slicing was used to colour the places where a<br>
>>> particular variable could be *changed* and *used*, I'd<br>
>>> find that really really helpful. Why waste colour<br>
>>> telling me something that is already obvious at a glance?<br>
>>> I once came across a compiler (written in Finland) where<br>
>>> several passes had had to be woven together because of<br>
>>> the language it was written in, so they had coloured<br>
>>> each declaration and statement according to which pass<br>
>>> it was logically part of. Now _that's_ good use of colour!<br>
>>><br>
>>> ><br>
>><br>
>><br>
><br>
><br>
</div></div><div><div>> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div></div>