- Generics - Haskell.org

patch applied (generics): The reduce functions for SYB are more honest: no more explicit pattern matching.
by Alexey Rodriguez Yakushev 31 May '07

31 May '07

Wed May 30 09:42:35 PDT 2007 Alexey Rodriguez <alexey(a)cs.uu.nl> * The reduce functions for SYB are more honest: no more explicit pattern matching. M ./comparison/SYB1_2/Reduce.lhs -21 +34

1 0

patch applied (generics): Added three tests: GShow, FoldTree, Paradize for SmashA.
by Oleg Kiselyov 31 May '07

31 May '07

Wed May 30 19:44:19 PDT 2007 oleg(a)okmij.org * Added three tests: GShow, FoldTree, Paradize for SmashA. A ./comparison/SmashA/CompanyDats.hs A ./comparison/SmashA/FoldTree.hs A ./comparison/SmashA/GShow.hs A ./comparison/SmashA/Paradise.hs M ./comparison/SmashA/Syb4A.hs -1 +14 A ./comparison/SmashA/TreeDats.hs

1 0

patch applied (generics): Smash the rest of your boilerplate.
by Oleg Kiselyov 31 May '07

31 May '07

Wed May 30 18:33:23 PDT 2007 oleg(a)okmij.org * Smash the rest of your boilerplate. A ./comparison/SmashA/ A ./comparison/SmashA/Syb4A.hs

1 0

patch applied (generics): add GShow and Paradize benchmarks
by Oleg Kiselyov 29 May '07

29 May '07

Tue May 29 00:57:49 PDT 2007 oleg(a)okmij.org * add GShow and Paradize benchmarks M ./comparison/Smash/CompanyDats.hs -5 +5 A ./comparison/Smash/CompanyTDats.hs A ./comparison/Smash/GShow.hs A ./comparison/Smash/Paradise.hs M ./comparison/Smash/Syb4.hs -3 +39

1 0

patch applied (generics): adding Smash
by Oleg Kiselyov 29 May '07

29 May '07

Sat May 26 02:21:59 PDT 2007 oleg(a)okmij.org * adding Smash A ./comparison/Smash/ A ./comparison/Smash/CompanyDats.hs A ./comparison/Smash/FoldTree.hs A ./comparison/Smash/Syb4.hs A ./comparison/Smash/TreeDats.hs M ./comparison/TreeDatatype.hs +3

1 0

`Smash-your-boilerplate' described [Was: Experiments and paper]
by oleg＠pobox.com 14 May '07

14 May '07

I have added the description of the `Smash-your-boilerplate' approach to the Generic programming area on Haskell wiki: http://www.haskell.org/haskellwiki/Applications_and_libraries/Generic_progr… http://www.haskell.org/haskellwiki/Applications_and_libraries/Generic_progr… That description was written back in November last year, and somehow wasn't posted. Johan Jeuring's recent message gave just the push it needed. > We're thinking about writing a paper for the Haskell Workshop > describing our evaluations. ... Some of you contributed to the > stuff that is on the webpage, or in the repository. So we can imagine > some of you would like to coauthor such a paper. I would be interested in doing that.

1 0

Experiments and paper
by Johan Jeuring 11 May '07

11 May '07

Dear generics-subscribers, We intend to develop a common library for generic programming. A first step towards such a design is to evaluate the existing approaches. We started on this last year, but activities slowed down a bit, presumably due to other obligations. Since January, Alex Gerdes and Alexey have picked up the evaluation again. Some of you might have followed the darcs submissions of Alexey and Alex in the last couple of months: we have implemented a set of examples for almost all library approaches now. A few approaches remain to be done, but we can hopefully do so in the next couple of weeks. We hope you can have a look at the implementations, or maybe at the implementation of the examples in your favourite approach. The implementations of the examples can be obtained via darcs get http://www.cs.uu.nl/~alexey/repos/generics/ We are planning to push these patches to the haskell.org darcs repository http://darcs.haskell.org/generics in the coming days, would that be a problem for any of you? We will push the code under a different directory called `comparison', so none of the existing files will be affected. We noticed that some of the pages on the haskell wiki about the libraries have disappeared after restructuring the libraries and tools pages. We've restored them. We're thinking about writing a paper for the Haskell Workshop describing our evaluations. The deadline for the HW is June 15, so that gives us a bit more than a month. Some of you contributed to the stuff that is on the webpage, or in the repository. So we can imagine some of you would like to coauthor such a paper. Please let us know if that is the case, so that we can give you permissions for the svn repository for the paper (which at the moment is almost empty). All the best, Johan

2 1

SYB vs HList (again)
by oleg＠pobox.com 11 May '07

11 May '07

S. Alexander Jacobson wrote: > I'd like be able to do something like this: > > $(label Salary Int) -- template haskell to define salary label > main = do > person <- readFile "blah" >>= return . read > print $ person # salary > > In this case, haskell would assume that person has only one label, > salary. The read function would ignore all the other labels. If I > changed the code to this: > > $(label Salary Int) -- template haskell to define salary label > $(label Name String) > > main = do > person <- readFile "blah" >>= return . read > print $ person # salary > print $ show (person::Name .*. Salary) > > Then the code would assume that a person has both a name and a salary. I see. You would like the pattern of using a data structure would tell the reader which data structure it should have read. This reminds me of how `read' is supposed to be used, although it doesn't quite work when polymorphism is involved (cf. Num-erals). This is an interesting problem; I should think about it. BTW, in the second example, you supply an annotation `Name .*. Salary'. If you're willing to do that, the problem can be solved then. I mean a function asShapeOf that is operationally an identity. You would use it like let _ = person `asShapeOf` (undefined::Name .*. Salary) or let _ = person `asShapeOf` (Name .*. Salary) If you find that approach appropriate, it could be easily implemented. > Separately, I would really like hrecords not to have order dependency. > It seems strange to me that (Foo .*. Bar .*. HNil) is a different type > from (Bar .*. Foo .*. HNil). That is indeed strange, and inevitable to the way record polymorphism is attained. One normally does not care about this distinction, because many (most) of polymorphic record consumers are sufficiently polymorphic and so accept either type. That is, if a function accepts any subtype of the particular record type, then the issue of the order of record fields should not arise. One may think of the type of a record with permuted fields as being a subtype of the original record type. There are however many cases where the record type should be closed. Most frequently that case arises when we want to store records in a data structure (e.g., a list). This is also the case of functions like (==) which takes two arguments of the same type (and won't take a subtype). In the OOHaskell library, we have a coercion function (Actually, we have a bunch of such functions, which compute either a meet or a join of several record types). That function will rearrange the fields if necessary (as well as remove extra fields). In HList, it could be implemented via h2projectByLabels. So, one may write [rec1, coerce rec2, coerce rec3] and not to care of the order of fields in rec2 or rec3. Granted, the current implementations of the coercion functions are quite inefficient; I've been meaning to re-write them for more than a year. Perhaps now is the time...

2 1

FW: [Haskell-cafe] SYB vs HList (again)
by Simon Peyton-Jones 16 Mar '07

16 Mar '07

Dear generics mailing list This message from Alex should be of interest, if you have not already seen it. (Alex: this group is trying to create a single library --- or perhaps a couple with well-articulated tradeoffs --- for generic programming. Maybe you should join it.) Simon -----Original Message----- From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of S. Alexander Jacobson Sent: 14 March 2007 23:40 To: haskell-cafe(a)haskell.org Subject: [Haskell-cafe] SYB vs HList (again) Right now I am looking at using either SYB (Scrap Your Boilerplate) or HList Records to eliminate boilerplate for: * parsing URLEncoded strings into application data structures * generating XML/JSON from application data structures * handling adding new fields to serialized data structures * creating indexed collections of application data structures I am looking for insights from people here on which approach they think is better and why. Here are my current thoughts on the issue == Both HList and SYB require data structures redesign == HLists require you to define Labels and basically only use label values that are themselves either scalar or HLists. SYB basically requires the same thing except that you use data/newtype to define labels instead of HLists more cumbersome label constructions. == Defaults: HList gives you compile time errors, SYB only runtime errors == SYB does not seem to provide a way of having the compiler tell you that you are accessing a field that is unavailable in the type. HList will give you a type error if you do that. I don't know exactly how HList handles default values but I assume you can restrict use of those values to explicit deserialization contexts. Is that correct? == HList allows more informality == With HList you can specify the type of a record ad hoc using obj::(Record Foo .*. Bar .*.Baz). SYB requires that you define data structures in separate data declarations. It would be really nice if there was some way to tell Haskell that HLists have no more fields than the ones you happen to be getting and setting in your code. Effectively that would mean you get data structure inference not just function type inference which would be really cool! That is probably not possible but it couldn't hurt to ask (Oleg?). == SYB doesn't require template haskell to make it usable == With SYB you create field labels using newtype (or data) declarations e.g. data Salary = S {salary::Float} With HList, label declarations are really verbose e.g. data SalaryLabel deriving(Typeable) type Salary = Field (Proxy SalaryLabel) Int salary = proxy :: Proxy FooLabel You can make this more concise using TemplateHaskell but TH looks alien and adds fear to the use of any code. == Performance issues == SYB requires a linear traversal of all field elements using dynamic to get or transform a value. HList traverses an HCons list. I don't how bad this is as compared with traditional data structure access using pattern matching or field labels. My current bias is towards using HList because if we are going to force a conversion to a new data structure convention I'd rather have the typesystem on my side. With SYB it is too easy to let haskell field labels creep in to your data definitions and end up with subtle errors to correct. Any opinions on these issues would be very appreciated. -Alex- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

2 1

Generic programming comparison suite
by Alexey Rodriguez Yakushev 12 Feb '07

12 Feb '07

Hi everyone, I have been working on an initial benchmarking suite for generic programs, based on the programs that Stephanie, James, Johan and others have committed to the repository. Also most of the ideas here have been collected from the discussion that was carried out in the list, so thanks to all! We plan to be use this as the starting point for the suite that will allow us to compare the different approaches. The main ideas of this benchmarking suite are the following: * The benchmark suite consists of a set of tests in the form of generic programs, i.e. gshow/gread, gmap, geq, etc. * Each test consists of a set of modules written by different users, i.e. library writers, power users and end users. * Each test tries to solve a particular problem for the end-user, using the different generic programming approaches. * The end-user code for a test (the application of a specialized generic function to a data type) is the same across approaches. API differences (e.g. class based approaches vs. type representation argument) would be hidden behind a wrapper that the end-user code will use. * The rest of the code (generic function definition) for a test usually varies across approaches. * There will be a test per generic function proposed in the mailing list. However we will not include tests that give the same information that a previous test already does for all approaches. Such a test cannot be used to distinguish approaches. For example a generic zip test won't be included if it doesn't say anything more than a generic map. * The comparison results will use the wiki template. I would like to emphasize the decision of using the same end-user code in the different versions of a test. This ensures that, for example, all variants of equality are really doing the same thing for the end-user. This becomes more useful when you consider Stephanie's foldTree example versus the reduce function. Though they feel similar, these functions would be used in different ways by the end user since they have different ways to specialise their behaviour. This suggests that these two functions should not be compared against each other, instead they are two different test cases. I think that requiring the reuse of end-user code gives a nice criterion for telling which things are comparable, and it will be useful should we become interested in comparing performance as well. The tests that will become part of the suite are: * gshow/gread * greduce (generic reduce function) * foldTree * raise aka paradise aka update * generic map * generic equality * serialization (though similar to gshow/gread, the output is influenced by the data type structure, this might tell interesting things). * gmin (though I am not sure on how much more than gread this tells) The tests that will not become part of the suite are: * generic zip. Generic map is already a function that is defined on kinds different than * , and generic equality already has two arguments (difficult to define in some approaches). Tests I plan to look into: * Oleg's int2float You can get a "branch" of the generics repository by typing > darcs get http://www.cs.uu.nl/~alexey/repos/generics/ The testsuite is in the "comparison" directory. To run the tests, type: > runghc tests.hs The end-user code/drivers are in "comparison/TestGEq", "comparison/ TestGShow", etc. And the approach varying code is in "comparison/LIGD/", "comparison/ SYB1_2", etc. At the moment the SYB gshow code prints parenthesis around nullary constructors so you will get a failure since LIGD doesn't. This is something that the original code already did and I plan to fix it. I guess that the best license would be the BSD license that Manuel proposed, if the original authors agree, of course. We would like to push it to the official repository eventually, but meanwhile we would like to hear your comments. Cheers, Alexey

1 0