Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."
Today's Topics:
1. Re: Traversing generic trees (Ali Baharev)
2. Re: Traversing generic trees (Bob Ippolito)
3. Re: Traversing generic trees (Ali Baharev)
4. Re: Traversing generic trees (Bob Ippolito)
----------------------------------------------------------------------
Message: 1
Date: Thu, 23 Jul 2015 18:48:49 +0200
From: Ali Baharev <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Traversing generic trees
Message-ID:
<CAP9qzdaf=yh9ibuwsg1frtvqr6z0_fqfeoeacmwa8oocsdz...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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 [email protected]: "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 <[email protected]> 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
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
Message: 2
Date: Thu, 23 Jul 2015 12:38:34 -0700
From: Bob Ippolito <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Traversing generic trees
Message-ID:
<cacwmpm9xs5um_2zb5mqky9pma-9q_ynol5wcjjstt4o3_wj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <[email protected]> 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 [email protected]: "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 <[email protected]> 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
> > [email protected]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150723/344ccdf6/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 23 Jul 2015 23:11:11 +0200
From: Ali Baharev <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Traversing generic trees
Message-ID:
<cap9qzdzgh_bxwyxohp+e+t0ozyzqowlsupah1cogkokpdyq...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
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 <[email protected]> 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 <[email protected]> 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 [email protected]: "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 <[email protected]> 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
>> > [email protected]
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
------------------------------
Message: 4
Date: Thu, 23 Jul 2015 15:07:08 -0700
From: Bob Ippolito <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Traversing generic trees
Message-ID:
<CACwMPm9YhSC5-cNQ+9wy-g=a9pqsqxvnp5guq-5d5qfr9ru...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Well, you've picked the wrong beginner project :) This isn't really an
algorithm that you're implementing, you're trying to reuse Haskell syntax
to do something that it's not intended to do. Implementing algorithms in
Haskell is a breeze if you are using a sane representation, but you need to
use the right tools.
On Thu, Jul 23, 2015 at 2:11 PM, Ali Baharev <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]>
> 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 [email protected]: "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 <[email protected]>
> 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
> >> > [email protected]
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >> _______________________________________________
> >> Beginners mailing list
> >> [email protected]
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >
> >
> >
> > _______________________________________________
> > Beginners mailing list
> > [email protected]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
> >
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150723/2efc7482/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 85, Issue 16
*****************************************
