<div dir="ltr">The trouble you're having with ghc is because you used Chars ('a', 'b', 'c') instead of Strings ("a", "b", "c") in the call to hanoi.<div>The errors say something like: expected [Char] (String) but got Char.</div><div>Also, you'll have to change the type signature (Move becomes String), but I think you took care of that already.</div><div><br></div><div>If you are comfortable with the map function, then you can use a related function mapM_ to print lines.</div><div>It basically allows you to map functions dealing with IO (and other stuff) on lists.</div><div>So you can do something like</div><div><br></div><div>      main = mapM_ putStrLn $ hanoi 3 "peg 1" "peg 3" "peg 2"</div><div>      -- Transferring from 1 to 3 using 2 in between</div><div><br></div><div>Hope this helps.<br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 19 February 2015 at 18:17, Joel Neely <span dir="ltr"><<a href="mailto:joel.neely@gmail.com" target="_blank">joel.neely@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:georgia,serif;font-size:small">Just to clarify the point of my earlier comment...</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">I suggest that the "separation of concerns" (SOC) principle has many applications. A common use shows up in the advice to represent each distinct concept exactly one place in the code, and to do so in a way that supports orthogonality (the freedom to mix-and-match).</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">In this case, I used it to separate the thought process of designing the code from the lexical layout of the code.</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">I have no business legislating the order in which someone else thinks about the cases (sometimes more than two!) encountered in decomposing a problem. However, in my experience, the order in which I think about parts of the code, and the order in which they are laid out in the source file, are separate concerns. And I have often found it useful to consider them separately.</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">For example, in some problems (and language implementations) it may help performance to ensure that the most frequent case is considered first, especially when there are multiple cases to consider or when the distinguishing conditions are costly to evaluate.</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">I find that making my guards (conditions) explicit allows me the freedom to order the alternatives in whatever way I find useful, without having to worry about introducing a defect in the code.</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">Incidentally, I also find it interesting to see the subtle effects that our terminology has on the way we approach problems. Thinking of a list as "it may be empty or not" takes my thoughts in a different direction than if I think "it may have a head or not".</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">By all means, think about your recursive functions any way you wish! Just please don't tell me that I must place them is a specific order in my code.</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">Regards,</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small">-jn-</div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div><div class="gmail_default" style="font-family:georgia,serif;font-size:small"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Feb 19, 2015 at 3:02 AM, Dudley Brooks <span dir="ltr"><<a href="mailto:dbrooks@runforyourlife.org" target="_blank">dbrooks@runforyourlife.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span>
    <div>On 2/18/15 5:29 PM, Mike Meyer wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Wed, Feb 18, 2015 at 7:16 PM,
            Dudley Brooks <span dir="ltr"><<a href="mailto:dbrooks@runforyourlife.org" target="_blank">dbrooks@runforyourlife.org</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000">
                <div>Hmm.  Well, I'd say that that's a feature of,
                  specifically, Haskell's pattern-matching strategy and
                  list-description syntax, rather than of recursion in
                  general or the structure of this particular problem. 
                  In other languages with recursion you might have no
                  choice except to start with the base case, even for
                  this problem, or else you'd get the same kind of error
                  you mention below (depending on the language).  I
                  think it's good when you're *learning* recursion to
                  always start with the base case(s).<br>
                </div>
              </div>
            </blockquote>
          </div>
        </div>
        <div class="gmail_extra">I disagree that this is a
          Haskell-specific feature. Any else-if like structure will have
          this property, no matter what language it's in. That Haskell
          provides a syntax as part of the function declaration is
          special, but that doesn't let you avoid the else-if construct
          when the problem requires it.</div>
      </div>
    </blockquote></span>
    I don't understand.  I don't believe I said anything about avoiding
    else-if, or about not avoiding it.  But I'm not quite sure what you
    mean.  Are you referring to<br>
    <br>
    if condition1<br>
    then instruction1<br>
    elseif condition2<br>
          then instruction2<br>
    <br>
    ?<br>
    <br>
    But what is condition1?  Wouldn't it probably be the base case, and
    instruction1 the procedure on the base case?<br>
    <br>
    Is there something special about "elseif" that guarantees that
    instruction1 *before* it won't crash if condition1 isn't the base
    case???  I'm probably totally missing your intention here.<br>
    <br>
    But anyway, isn't it actually just Haskell's syntax "x:xs" that lets
    the pattern be tested and bypassed without crashing on an empty
    list, so that it *can* fall through to the base case at the end?  If
    Haskell only had the syntax "(head xs), then that *would* crash on
    the empty list if the empty list had not previously been taken care
    of as a base case, as Joel Neely pointed out.<br>
    <br>
    I didn't mean that *no* other language might have such a syntactical
    construction.  (I didn't mean "specifically Haskell", I meant
    "specifically the pattern matching".  Sorry about the ambiguity.) 
    So if some other language has such a construction, then it's still
    the *syntax* that lets you cheat on the base case; it's not the
    structure of the problem itself nor the basic underlying notion of
    recursion.<br>
    <br>
    I would also argue that in Mr Neely's first example, while the
    *explicit* base case [] is at the end, nevertheless the first line
    still *implicitly* refers to the base case:  pattern matching on
    "x:xs" says "*if* the data has the structure x:xs", i.e. "if it is
    not a bunch of other stuff ... including *not the empty list*!)". 
    Certainly you couldn't merely do the recursive step first without a
    condition like this particular one.  The reason this syntax *seems*
    to let you avoid thinking about the base case first is because
    secretly it says "only try this step if we're not looking at the
    base case"!<span><br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">It may be my fondness for proof by
          induction, but I think doing the base case first is a good
          idea for another reason. The code for the recursive cases
          assumes that you can correctly handle all the "smaller" cases.
          If that's wrong because some assumption about the base case
          turns out to be false when you actually write it, then you
          have to rewrite the recursive cases for the correct base case.
          So it's better to make sure your base case is going to work
          before you start writing the code that's going to use it.</div>
      </div>
    </blockquote></span>
    I was a math major, not a CS major, so I'm also prejudiced in favor
    of base case first.  And, as stated above, I think we *are* actually
    *considering* the base case first!  (We're merely putting off
    telling what to *do* with that base case.)  I think that the
    "syntactic sugar" of some languages obscures (intentionally, for
    purposes of convenience) what's really happening mathematically.<br>
    <br>
  </div>

<br></div></div><span class="">_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org" target="_blank">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br></span></blockquote></div><span class=""><br><br clear="all"><div><br></div>-- <br><div>Beauty of style and harmony and grace and good rhythm depend on simplicity. - Plato</div>
</span></div>
<br>_______________________________________________<br>
Beginners mailing list<br>
<a href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div>Regards</div><div dir="ltr"><div><br></div><div>Sumit Sahrawat</div></div></div></div></div></div></div>
</div>