[Haskell-beginners] Traversing generic trees

Ali Baharev ali.baharev at gmail.com
Thu Jul 23 21:11:11 UTC 2015


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 <bob at redivi.com> 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 <ali.baharev at gmail.com> 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 at 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 <imantc at gmail.com> 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 at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>> _______________________________________________
>> Beginners mailing list
>> Beginners at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>


More information about the Beginners mailing list