[Haskell-beginners] Traversing generic trees

[Thomas Koster]

Ali,

On 23 July 2015 at 07:24, Ali Baharev <ali.baharev at gmail.com> wrote:
> I have started learning Haskell recently, and I try to reimplement
> interesting algorithms that are challenging to do in other languages.
..
> The pretty
> printing is not very pretty but the part that I am really not happy
> with is the lot of code duplication in giving the tree.

On Wed, Jul 22, 2015 at 11:51 PM, elliot <elliot at citrusbytes.net> wrote:
> In general you don't produce large trees (or any data structure) by hand.

On 23 July 2015 at 16:05, Thomas Koster <tkoster at gmail.com> wrote:
> I am a Haskell novice myself, so don't take my advice as expert
> opinion, but it sounds like you may have the wrong expectation about
> what Haskell offers regarding "shorter", "cleaner", "purer" code. I
> think Elliot was right to question your question.
>
> To get started, you should read this influential article by J. Hughes
> [1][2].
>
> [1] Hughes, J. "Why Functional Programming Matters", The Computer
> Journal 32 (2), pp. 98-107, 1989.
> [2] http://www.cse.chalmers.se/~rjmh/Papers/whyfp.html

On 24 July 2015 at 02:48, Ali Baharev <ali.baharev at gmail.com> wrote:
> I used to work at the University.
...
> I have never started questioning the questions of my students,
> especially when I could not give them an answer.
...
> OK, let's get back to the original question.
>
> Apparently, there is no easy way to solve it with nested lists.
> However, no one has touched the nested tuples so far. How can I write
> a toString function that works similarly to mine but destructures
> arbitrarily nested tuples?

Sorry, my point was not to defend Elliot's useless response (he didn't
actually respond to the list anyway). I admit that "to question your
question" was a poor phraseology.

>From your original email, your question regarding the efficacy of
nested lists or tuples for implementing a tree data structure seems to
have been motivated by a desire to reduce the amount of typing in a
tree constant.

The question itself has already been answered by others with "neither
of these are appropriate." But now what?

My point is that this exercise of saving some characters in the
definitions of constants by fiddling with the data structure will not
really lead to any useful intuitions about Haskell. Instead, Hug89
demonstrates two concepts (higher-order functions and laziness) that
really do show you what makes non-strict functional languages like
Haskell exceptional. Not only that, Hughes does this by talking you
through some functions for lists, trees and numerical algorithms,
which all sound very relevant to your learning project.

--
Thomas Koster