Dear Imants, Thanks. Unfortunately, I am not sure I get it. It seems to me that it generates a homogeneous list of either nodes with single leaver or just leaves. Or how would the ['a', ['b', 'c', []], 'd'] input look like, when using your proposed approach? Ali On Thu, Jul 23, 2015 at 1:10 AM, Imants Cekusins wrote:

how about this:

data Tree a = L a | N [Tree a] deriving Show

l::a -> Tree a l = L

n::a -> Tree a n x = N [L x]

m::(a->Tree a) ->[a]-> Tree a m f list = N $ f <$> list

run it like this: m l [2,3] m n [2,3]

any good? _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

Dear All, I used to work at the University. Whenever a student asked me a question, I first focused on the question and tried to answer it. Sometimes the question was tough, maybe because there wasn't any easy solution to the problem. In those situations I used to say to my students: “Problem well spotted, unfortunately I cannot give you an answer / there is no easy solution to this problem.” However, I have never started questioning the questions of my students, especially when I could not give them an answer. According to the Wiki on beginners@haskell.org: "Here, there is no such thing as a 'stupid question.'" If you start questioning my question, then I really do not know where to go... You might as well say: The whole question is pointless, just use Data.Tree and be done with it! It is really not part of the original question, and I sooo not want to get into a discussion over this: It is important to have language support for helping humans to input data, without a full-blown parser. Examples would be user-defined implicit type conversions and user-defined literals in other statically typed languages. 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? Thanks, Ali On Thu, Jul 23, 2015 at 9:41 AM, Imants Cekusins wrote:

.. on the other hand, if facing this problem: - import large trees from concise human-readable representation as string

, it is probably possible to write a parser which does just that.

After all json parser works somehow ;)

Just saying that you could do this in Haskell, given enough interest. _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

Dear Bob, Thanks. OK, so you are saying that there is no easy way of doing it with nested tuples either. Well, that's disappointing. :( The custom parser is violating the third requirement ("without copying the data into some other datastructure first"). It is a learning exercise: I am trying to understand how to achieve certain things things in Haskell. I deliberately picked this exercise because it is very challenging to do it in certain statically typed languages, and I was curious how difficult it would be to solve it in Haskell. In my opinion, you can learn a lot about programming languages in general by re-implementing algorithms in them and comparing the difficulties you encountered on the way. Best wishes, Ali On Thu, Jul 23, 2015 at 9:38 PM, Bob Ippolito wrote:

You should not try and use the built-in lists or tuples to represent a tree data structure. That's not what they're good at. You probably could make tuples work and write functions using GHC.Generics to work with it as a tree data structure, but it definitely won't be easy or elegant. If you want a more economic syntax for expressing the tree you can provide shorter names for Leaf and Node (one char isn't too bad), or else you're stuck with using a parser. You may not have to write a parser though, perhaps JSON or YAML would work fine for this. If it needs to go in the source file, there's always TemplateHaskell and QuasiQuotes.

On Thu, Jul 23, 2015 at 9:48 AM, Ali Baharev wrote:

...

Dear All,

I used to work at the University. Whenever a student asked me a question, I first focused on the question and tried to answer it. Sometimes the question was tough, maybe because there wasn't any easy solution to the problem. In those situations I used to say to my students: “Problem well spotted, unfortunately I cannot give you an answer / there is no easy solution to this problem.” However, I have never started questioning the questions of my students, especially when I could not give them an answer.

According to the Wiki on beginners@haskell.org: "Here, there is no such thing as a 'stupid question.'" If you start questioning my question, then I really do not know where to go...

You might as well say: The whole question is pointless, just use Data.Tree and be done with it!

It is really not part of the original question, and I sooo not want to get into a discussion over this: It is important to have language support for helping humans to input data, without a full-blown parser. Examples would be user-defined implicit type conversions and user-defined literals in other statically typed languages.

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?

Thanks,

Ali

On Thu, Jul 23, 2015 at 9:41 AM, Imants Cekusins wrote:

...

.. on the other hand, if facing this problem: - import large trees from concise human-readable representation as string

, it is probably possible to write a parser which does just that.

After all json parser works somehow ;)

Just saying that you could do this in Haskell, given enough interest. _______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

---

Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

Ali, On 23 July 2015 at 07:24, Ali Baharev 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 wrote:

In general you don't produce large trees (or any data structure) by hand.

On 23 July 2015 at 16:05, Thomas Koster 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 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?

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

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. 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