Scrap your boilerplate and Variants
Hello, According to Johan timeline, we should have started discussing SyB last week. I was to busy last week, so I could not do much work on it, but this week I have some more available time so I have started summarizing SyB in: http://www.haskell.org/haskellwiki/Libraries_and_tools/Generic_programming/S... The summary is not complete, please feel free to edit it and add your own comments. I found it slightly awkard to fit SyB into the template because there are many papers and variants. I wonder if there is a better way to summarize SyB (perhaps splitting into the different variants?). Since SyB does actually have users and I guess some of them may have subscribed to this list, I guess this is the approach where they can comment the most and say what they like/don't like about SyB. For example they can comment about Error Messages, Usability and Performance. Other issues that they may be interested to comment on are on what do they use SyB for (what is the typical generic function that they write) and if they ever had a situation where they though of a function that should be generic, but it turned out that they could not encode it with SyB. More generally, I think it would be very good to collect opinions of users and not just people that do generic programming research. Cheers, Bruno Oliveira
I have just committed the code for the alternative formulation of SYB3. It requires neither higher-rank types nor mutually recursive instances. Therefore, the code works even in Hugs (the original SYB3 code does not work in Hugs). The files are in the directory SYB31/. The `final' code is dat2.hs (dat1.hs is the `intermediate' step, which makes it easy to understand `dat2.hs'). The code has comments that describe which part of the code is the `Library', which part of the code is the `generic function' (independent of the data structure), and which part of the code overrides some general processing of the generic function. The code has two examples; one of them is gsize, from the original SYB3 paper. I'd like to suggest two corrections to the SyB page: first, rank-2 types are not necessarily required for all flavors of SYB second, the original SYB3 imposes one more requirement: mutually recursive instances. It is rarely mentioned -- but not universally implemented (Hugs does not have it). SYB31 shows that one can get by without that requirement. At the ICFP05 talk, Simon Peyton-Jones asserted that recursive instances are essential. I have publicly expressed doubts. Simon Peyton-Jones said: if you think otherwise, show me the code. And so I did.
At the ICFP05 talk, Simon Peyton-Jones asserted that recursive instances are essential. I have publicly expressed doubts. Simon Peyton-Jones said: if you think otherwise, show me the code. And so I did.
... and I keep replying that you are exploiting the folklore trick of eliminating function-typed arguments by means of an extra type-code that must be interpreted by a sort of apply type class. I cannot speak for SPJ, but I would say for myself that this extra step of deferred interpretation is not like a "fix" for our approach; it greatly *modifies* our approach and takes the important idea of function combinators largely out of it. Your "flavor" may actually still be quite desirable, but that's another question :-) Ralf
Hello Oleg,
I have just committed the code for the alternative formulation of SYB3. It requires neither higher-rank types nor mutually recursive instances. Therefore, the code works even in Hugs (the original SYB3 code does not work in Hugs). The files are in the directory SYB31/. The `final' code is dat2.hs (dat1.hs is the `intermediate' step, which makes it easy to understand `dat2.hs'). The code has comments that describe which part of the code is the `Library', which part of the code is the `generic function' (independent of the data structure), and which part of the code overrides some general processing of the generic function. The code has two examples; one of them is gsize, from the original SYB3 paper.
I'd like to suggest two corrections to the SyB page: first, rank-2 types are not necessarily required for all flavors of SYB
second, the original SYB3 imposes one more requirement: mutually recursive instances. It is rarely mentioned -- but not universally implemented (Hugs does not have it). SYB31 shows that one can get by without that requirement. At the ICFP05 talk, Simon Peyton-Jones asserted that recursive instances are essential. I have publicly expressed doubts. Simon Peyton-Jones said: if you think otherwise, show me the code. And so I did.
I think we need to define first what do we consider by an SyB-like approach. I see that Ralf Lammel does not entirely agree that your code addressed exactly the same problems because, as I understand it, you miss the combinators like `everywhere` and `everything`. However, and also as Ralf Lammel points out your library may still be useful. I guess the question here is if this should be considered a variant of SyB. Perhaps we can settle this question by imposing that variants need to define `everywhere` and `everithing` combinators (or mechanism that achieve the same with the same amount of work)? Even if in the end we decide that this is a different approach altogether, we can discuss it as a different proposal. Cheers, Bruno Oliveira
It is certainly true that we start to have various SYB variants that the numbering scheme becomes clumsy :-) So it is actually good that some of the Bonn/Oxford work nicely uses qualifiers like revolutions etc. :-) I do agree with Bruno that some of the SYB flavors are so much different that they need to be characterized more or less separately. Oleg's flavor shouldn't have any fundamental issues with everywhere as far as I can see. (Bruno? Oleg?) I am only alerted by the fact that this flavor uses type codes to pass around functions (this is at least what I see in the initial email Oleg sent to me and SPJ after ICFP 2005). Best, Ralf
-----Original Message----- From: generics-bounces@haskell.org [mailto:generics-bounces@haskell.org] On Behalf Of Bruno Oliveira Sent: Wednesday, October 25, 2006 5:37 AM To: oleg@pobox.com Cc: generics@haskell.org Subject: Re: [Hs-Generics] Re: Scrap your boilerplate and Variants
Hello Oleg,
I have just committed the code for the alternative formulation of SYB3. It requires neither higher-rank types nor mutually recursive instances. Therefore, the code works even in Hugs (the original SYB3 code does not work in Hugs). The files are in the directory SYB31/. The `final' code is dat2.hs (dat1.hs is the `intermediate' step, which makes it easy to understand `dat2.hs'). The code has comments that describe which part of the code is the `Library', which part of the code is the `generic function' (independent of the data structure), and which part of the code overrides some general processing of the generic function. The code has two examples; one of them is gsize, from the original SYB3 paper.
I'd like to suggest two corrections to the SyB page: first, rank-2 types are not necessarily required for all flavors of SYB
second, the original SYB3 imposes one more requirement: mutually recursive instances. It is rarely mentioned -- but not universally implemented (Hugs does not have it). SYB31 shows that one can get by without that requirement. At the ICFP05 talk, Simon Peyton-Jones asserted that recursive instances are essential. I have publicly expressed doubts. Simon Peyton-Jones said: if you think otherwise, show me the code. And so I did.
I think we need to define first what do we consider by an SyB-like approach. I see that Ralf Lammel does not entirely agree that your code addressed exactly the same problems because, as I understand it, you miss the combinators like `everywhere` and `everything`.
However, and also as Ralf Lammel points out your library may still be useful. I guess the question here is if this should be considered a variant of SyB.
Perhaps we can settle this question by imposing that variants need to define `everywhere` and `everithing` combinators (or mechanism that achieve the same with the same amount of work)?
Even if in the end we decide that this is a different approach altogether, we can discuss it as a different proposal.
Cheers,
Bruno Oliveira
_______________________________________________ Generics mailing list Generics@haskell.org http://www.haskell.org/mailman/listinfo/generics
Hello,
It is certainly true that we start to have various SYB variants that the numbering scheme becomes clumsy :-) So it is actually good that some of the Bonn/Oxford work nicely uses qualifiers like revolutions etc. :-)
I do agree with Bruno that some of the SYB flavors are so much different that they need to be characterized more or less separately.
Oleg's flavor shouldn't have any fundamental issues with everywhere as far as I can see. (Bruno? Oleg?) I am only alerted by the fact that this flavor uses type codes to pass around functions (this is at least what I see in the initial email Oleg sent to me and SPJ after ICFP 2005).
Ok, sorry, I just understood it (wrongly apparently) like that after reading your previous email. However I am curious about how to write everywhere and/or everything in this style. Am i right to say that Oleg's "gmapq" is recurring on the children, unlike the original SyB where it only traverses the top-layer? If this is the case then gmapq plays the role of both everything and the original gmapq combinators of SyB. Is this the difference? Cheers, Bruno
participants (3)
-
Bruno Oliveira -
oleg＠pobox.com -
Ralf Lammel