<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2/19/15 9:22 AM, Dudley Brooks
wrote:<br>
</div>
<blockquote cite="mid:54E61BD1.8040809@runforyourlife.org"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">And to clarify my point, I would say
that mathematically you do always have to "take care of" (worry
about) the base case first ... and you did! And in the code,
not just in your thinking: Using "x:xs", rather than "(head
xs)", in the first line acknowledges the base case by making
sure to eliminate it first -- "x:xs" works precisely because it
doesn't separate the *concerns*; it contains an implicit "if
this is not the base case". What it does (why it's useful
syntactic sugar) is let you separate (and reorder) the
*actions*. A guard using "x:xs" does not actually have the very
clean SOC which you recommend, with the result that the concept
"base case" is actually represented in *two* places in your
code.<br>
<br>
Question: Could you write it without the first line using
"x:xs" or some other construction which has an implicit "if this
is not the base case"? Probably yes ... probably some kind of
"where" clause might put it typographically at the end. But
that would be because Haskell's interpreter/compiler executes
the test in the "where" clause first. Checking whether we're
looking at the base case would still be the first major
execution step. I suspect that there's no way to escape that
... the most that can be done is to "look like" you're escaping
it.<br>
</div>
</blockquote>
<br>
In fact, you might say that this construction in Haskell let you
separate your concerns from your actions! ;^)<br>
<br>
<blockquote cite="mid:54E61BD1.8040809@runforyourlife.org"
type="cite">
<div class="moz-cite-prefix"> On 2/19/15 4:47 AM, Joel Neely
wrote:<br>
</div>
<blockquote
cite="mid:CAEEzXAhXDjakze=GbtQ6K+cyEZADZ_UGBppd3eG7wjzshZkDLg@mail.gmail.com"
type="cite">
<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">On Thu, Feb 19, 2015 at 3:02 AM,
Dudley Brooks <span dir="ltr"><<a moz-do-not-send="true"
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"><span class="">
<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
moz-do-not-send="true"
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 class=""><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>
_______________________________________________<br>
Beginners mailing list<br>
<a moz-do-not-send="true"
href="mailto:Beginners@haskell.org">Beginners@haskell.org</a><br>
<a moz-do-not-send="true"
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">Beauty of style and harmony and
grace and good rhythm depend on simplicity. - Plato</div>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>