From joost.visser at di.uminho.pt Wed Nov 1 07:04:22 2006 From: joost.visser at di.uminho.pt (Joost Visser) Date: Wed Nov 1 07:01:11 2006 Subject: [Hs-Generics] Strafunski description In-Reply-To: <4E9CCAA4-2845-44C0-A901-F7515D0A7C3F@cs.uu.nl> References: <4E9CCAA4-2845-44C0-A901-F7515D0A7C3F@cs.uu.nl> Message-ID: Hi, I filled out the template for Strafunski: http://www.haskell.org/haskellwiki/Libraries_and_tools/Strafunski Any suggestions how to link it in? Regards, Joost -- Dr. ir. Joost Visser | Departamento de Inform?tica phone +351-253-604461 | Universidade do Minho fax +351-253-604471 | mailto:Joost.Visser@di.uminho.pt mobile +351-91-6253618 | http://www.di.uminho.pt/~joost.visser From mrchebas at gmail.com Fri Nov 3 08:25:56 2006 From: mrchebas at gmail.com (Alexey Rodriguez) Date: Fri Nov 3 08:25:42 2006 Subject: [Hs-Generics] Sample code In-Reply-To: <5CA612F0-4F3C-4A89-852B-5B36F11BF16D@cs.uu.nl> References: <20061021085858.5F65EAC04@Adric.metnet.fnmoc.navy.mil> <66C8D3AF-0500-4D86-9F97-746164DD783D@cis.upenn.edu> <5CA612F0-4F3C-4A89-852B-5B36F11BF16D@cs.uu.nl> Message-ID: <4b39c80a0611030525s43facd0dncccd9cbd908d7948@mail.gmail.com> On 10/27/06, Johan Jeuring wrote: > > > Organizing this shootout is quite a task, I hope we'll find a > volunteer to organize it. (I'm afraid > my time is too divided to do it.) I am interested in learning more about the relationship between the various generic programming approaches. So I am interested in carrying out this shootout. However I will be busy until December this year so I would only be able to do the shootout from next year. So if no one steps up I will be happy to do it then. Cheers, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20061103/853d85e5/attachment.htm From bruno.oliveira at comlab.ox.ac.uk Sun Nov 5 16:00:02 2006 From: bruno.oliveira at comlab.ox.ac.uk (Bruno Oliveira) Date: Sun Nov 5 15:59:41 2006 Subject: [Hs-Generics] Support for abstract data types Message-ID: Hello all, Pablo Nogueira asked me to post this email in the mailing list since he had some problems trying to post himself. Here is the text: I would like to propose adding the entry "support for abstract data types" (or something related) to the template we are using for discussing generic programming approaches. Perhaps the entry would attract the attention of people with other definitions of generic programming in mind, such as users of the C++ Standard Template Library. C++ Templates are often roughly equated with a static version of parametric polymorphism, but in the STL data types are abstract, not algebraic. This is an important difference. As a start, I would propose that "support for abstract data types" could be classified into "none", "by polytypic extension", and "generic": 1. With the term "polytypic extension" I am contributing terminology to the debate on whether we should use "specialisation", "instantiation", or "redefinition". If I'm not mistaken, "polytypic extension" is used in the SYB papers to refer to the possibility of providing type-specific cases for a polytypic function in an ad-hoc way. 2. Support for data abstraction may be achieved non-generically "by polytypic extension". For example, in SYB one may manually define the instance of Data for an abstract data type: instance Data a => Data (Queue a) where gfoldl k z q = z ListToQueue `k` (QueueToList q) toConstr _ = error "toConstr" dataTypeOf = mkNorepType "Data.Queue.Queue" ... This is the extension of gfold. Perhaps instances like the above could be (or are already?) generated automatically for abstract types supporting some form of "toList" and "fromList" operations. Writing the above manually requires knowledge of the SYB implementation and would be brittle wrt to changes in SYB. I personally don't like it. Alternatively, a generic programmer may extend the polytypic function with a case for the abstract type using the proposed extensions of SYB3: instance Size a => Size (Queue a) where gsize = gsize . QueueToList I'll talk about Generic Haskell below. 3. Support for data abstraction is "generic" if generic programmers can write a single generic function definition for all (or many) abstract types. This is better than providing definitions *for each* abstract type. I hope you agree with me that the latter is not *generic* programming. I believe none of the existing generic programming approaches support this. Perhaps it is time to think about it when designing a generic library. In Generic Haskell, support for abstract types is more complicated because, unlike SYB, the language is designed to deal with types of arbitrary kind. Just to pinpoint a particular problem, there is a lack of parametrisation on type-class constraints. There follows some *pseudocode* examples to illustrate the point. Type-specific instances of generic functions would seem easy to define: gsize :: Queue a -> Int gsize = gsize . QueueToList gsize :: Ord a => OrdSet a -> Int gsize = gsize . OrdSetToList but a more generic version for types t::*->* equipped with a, say, overloaded "toList" operation would have to be parametric on the constraint "c", which might be "empty": gsize*> :: c a => t a -> Int gsize = gsize . toList To conclude this long email, I think data abstraction should be considered from the start in the design of a generic programming library. On the one hand, this should force us to see the internal representation of types as (1) a parameter (cause we want to be generic), and (2) as something more abstract than an encoding of the *implementation* of the type. On the other hand, perhaps polytypic programming can then be conveyed to an object-oriented setting without using naive encodings of algebraic data types as the "objects". From mrchebas at gmail.com Tue Nov 7 12:36:22 2006 From: mrchebas at gmail.com (Alexey Rodriguez) Date: Tue Nov 7 12:35:55 2006 Subject: [Hs-Generics] Support for abstract data types In-Reply-To: References: Message-ID: <4b39c80a0611070936i781f2291u690d5ec10a195162@mail.gmail.com> Hello, On 11/5/06, Bruno Oliveira wrote: > > Hello all, > > Pablo Nogueira asked me to post this email in the mailing list since he > had some problems trying to post himself. Here is the text: [...] Perhaps the entry would attract the attention of people with other > definitions > of generic programming in mind, such as users of the C++ Standard Template > Library. C++ Templates are often roughly equated with a static version of > parametric polymorphism, but in the STL data types are abstract, not > algebraic. This is an important difference. Just to make things clearer for me, what would the entry be for C++ STL? [...] > 3. Support for data abstraction is "generic" if generic programmers can > write > a single generic function definition for all (or many) abstract types. > This > is better than providing definitions *for each* abstract type. I hope > you > agree with me that the latter is not *generic* programming. I believe > none > of the existing generic programming approaches support this. Perhaps it > is > time to think about it when designing a generic library. > > In Generic Haskell, support for abstract types is more complicated > because, > unlike SYB, the language is designed to deal with types of arbitrary > kind. Just to pinpoint a particular problem, there is a lack of > parametrisation on type-class constraints. There follows some *pseudocode* > examples to illustrate the point. > > Type-specific instances of generic functions would seem easy to define: > > gsize :: Queue a -> Int > gsize = gsize . QueueToList > > gsize :: Ord a => OrdSet a -> Int > gsize = gsize . OrdSetToList > > but a more generic version for types t::*->* equipped with a, say, > overloaded > "toList" operation would have to be parametric on the constraint "c", > which > might be "empty": > > gsize*> :: c a => t a -> Int > gsize = gsize . toList At the moment Generic Haskell cannot handle abstract data types because it cannot have access to their representations, which is something that the compiler needs to generate a structural representation type and later to specialize a generic function to the ADT. However, the ADT provider could perfectly specify the things needed for GH, that is, a structural representation, and embedding projection pair. This fits nicely with ADTs because the embedding projection functions (especially the 'to' direction) can preserve the data type invariants that motivated the use of abstraction in the first place. This also fits nicely with the idea of Generic Views because ADTs was the motivation for Views in Wadler's original paper. Just to make things more concrete, this is what the Queue library writer would have written in order to enable generic programming on Queues: -- snippet -- -- We use a similar structure to lists: data repr(Queue a) = () `Sum` a `Prod` Queue a ep(Queue a) :: EP (Queue a) (repr(Queue a)) ep (EP fromQueue toQueue) fromQueue :: Queue a -> repr(Queue a) fromQueue q = case deQueue q of Just (e,q') -> Inr (e :*: q') Nothing -> Inl () toQueue (Inl (e :*: q)) = e `prependToQueue` q toQueue (Inr ()) = emptyQueue -- end of snippet -- The gsize function would be left as it is, while still enabling generic application to Queue and other abstract data types. This is not implemented in GH, but it should not be difficult to do so. To conclude this long email, I think data abstraction should be considered > from the start in the design of a generic programming library. On the one > hand, this should force us to see the internal representation of types as > (1) > a parameter (cause we want to be generic), and (2) as something more > abstract > than an encoding of the *implementation* of the type. On the other hand, > perhaps polytypic programming can then be conveyed to an object-oriented > setting without using naive encodings of algebraic data types as the > "objects". In our framework the representation of ADTs is dictated by the view chosen (and the structure provided by the ADT implementor). For other frameworks I suppose similar techniques would be used. To be honest, I am a bit confused as how the C++ STL programming style corresponds to generic programming as discussed in this list. In my view the STL stuff looks more related to type classes than to data type generic programming. Maybe you can clarify your point further. Cheers, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20061107/93032656/attachment-0001.htm From sweirich at cis.upenn.edu Thu Nov 9 10:42:10 2006 From: sweirich at cis.upenn.edu (Stephanie Weirich) Date: Thu Nov 9 10:41:36 2006 Subject: [Hs-Generics] patch applied (generics): SYB1&2 tests Message-ID: <20061109154210.GA986@cvs.haskell.org> Thu Oct 26 11:48:29 PDT 2006 sweirich@cis.upenn.edu * SYB1&2 tests A ./SYB1_2.examples/ A ./SYB1_2.examples/testsuite/ A ./SYB1_2.examples/testsuite/CompanyDatatypes.hs A ./SYB1_2.examples/testsuite/Makefile A ./SYB1_2.examples/testsuite/bits/ A ./SYB1_2.examples/testsuite/bits/Main.hs A ./SYB1_2.examples/testsuite/bits/Makefile A ./SYB1_2.examples/testsuite/bits/test.stdout A ./SYB1_2.examples/testsuite/foldTree/ A ./SYB1_2.examples/testsuite/foldTree/Main.hs A ./SYB1_2.examples/testsuite/foldTree/Makefile A ./SYB1_2.examples/testsuite/foldTree/test.stdout A ./SYB1_2.examples/testsuite/geq/ A ./SYB1_2.examples/testsuite/geq/Main.hs A ./SYB1_2.examples/testsuite/geq/Makefile A ./SYB1_2.examples/testsuite/geq/test.stdout A ./SYB1_2.examples/testsuite/gshow/ A ./SYB1_2.examples/testsuite/gshow/Main.hs A ./SYB1_2.examples/testsuite/gshow/Makefile A ./SYB1_2.examples/testsuite/gshow/test.stdout A ./SYB1_2.examples/testsuite/paradise/ A ./SYB1_2.examples/testsuite/paradise/Main.hs A ./SYB1_2.examples/testsuite/paradise/Makefile A ./SYB1_2.examples/testsuite/paradise/test.stdout From sweirich at cis.upenn.edu Thu Nov 9 10:47:16 2006 From: sweirich at cis.upenn.edu (Stephanie Weirich) Date: Thu Nov 9 10:46:42 2006 Subject: [Hs-Generics] patch applied (generics): LIGD tests Message-ID: <20061109154716.GA1074@cvs.haskell.org> Thu Nov 9 07:44:53 PST 2006 sweirich@cis.upenn.edu * LIGD tests A ./LIGD.examples/testsuite/ A ./LIGD.examples/testsuite/CompanyDatatypes.hs A ./LIGD.examples/testsuite/CompanyReps.hs A ./LIGD.examples/testsuite/LIGD.lhs A ./LIGD.examples/testsuite/Makefile A ./LIGD.examples/testsuite/bits/ A ./LIGD.examples/testsuite/bits/Main.lhs A ./LIGD.examples/testsuite/bits/Makefile A ./LIGD.examples/testsuite/bits/XBitz.hs A ./LIGD.examples/testsuite/bits/test.stdout A ./LIGD.examples/testsuite/foldTree/ A ./LIGD.examples/testsuite/foldTree/Main.hs A ./LIGD.examples/testsuite/foldTree/Makefile A ./LIGD.examples/testsuite/foldTree/test.stdout A ./LIGD.examples/testsuite/geq/ A ./LIGD.examples/testsuite/geq/Main.lhs A ./LIGD.examples/testsuite/geq/Makefile A ./LIGD.examples/testsuite/geq/test.stdout A ./LIGD.examples/testsuite/gshow/ A ./LIGD.examples/testsuite/gshow/CompanyDatatypes.hs A ./LIGD.examples/testsuite/gshow/Main.lhs A ./LIGD.examples/testsuite/gshow/Makefile A ./LIGD.examples/testsuite/gshow/test.stdout A ./LIGD.examples/testsuite/paradise/ A ./LIGD.examples/testsuite/paradise/Main.hs A ./LIGD.examples/testsuite/paradise/Makefile A ./LIGD.examples/testsuite/paradise/test.stdout From sweirich at cis.upenn.edu Thu Nov 9 10:56:37 2006 From: sweirich at cis.upenn.edu (Stephanie Weirich) Date: Thu Nov 9 10:57:46 2006 Subject: [Hs-Generics] patch applied (generics): LIGD tests In-Reply-To: <20061109154716.GA1074@cvs.haskell.org> References: <20061109154716.GA1074@cvs.haskell.org> Message-ID: <04B2710C-42A7-4936-86A9-D3461848B27E@cis.upenn.edu> Hi all, I've finally got my darcs permissions straightened out and had the chance to push the small testsuite that I worked out a little while ago. As I described in my last email, this set includes five examples in the the testsuite directory for both LIGD.examples and SYB1&2.examples. testsuite/ geq gshow bits foldTree paradise Each directory contains a Makefile, source code in Main.hs or Main.lhs, auxiliary files and sample output in test.stdout. Code that is common to many tests is in the ~/teststuite directory. Typing "make" in each directory should compile, run and diff the test. Unfortunately, I don't have a script to run all of the tests at once. I've tested these examples with ghc 6.5.20060608 on my Intel Mac, as well as with ghc on my windows machine at home. (I don't know which version of Ghc off hand.) If you have trouble compiling or running any of the examples, let me know. Feel free to add new examples to this testsuite, in a separate directory. Also feel free to update these examples if you can think of a better way to use that example to demonstrate a particular approach. (For example, gshow for LIGD doesn't currently produce the same output as show, so I don't think it is really demonstrating the expressiveness of LIGD.) Enjoy, Stephanie On Nov 9, 2006, at 10:47 AM, Stephanie Weirich wrote: > Thu Nov 9 07:44:53 PST 2006 sweirich@cis.upenn.edu > * LIGD tests > > A ./LIGD.examples/testsuite/ > A ./LIGD.examples/testsuite/CompanyDatatypes.hs > A ./LIGD.examples/testsuite/CompanyReps.hs > A ./LIGD.examples/testsuite/LIGD.lhs > A ./LIGD.examples/testsuite/Makefile > A ./LIGD.examples/testsuite/bits/ > A ./LIGD.examples/testsuite/bits/Main.lhs > A ./LIGD.examples/testsuite/bits/Makefile > A ./LIGD.examples/testsuite/bits/XBitz.hs > A ./LIGD.examples/testsuite/bits/test.stdout > A ./LIGD.examples/testsuite/foldTree/ > A ./LIGD.examples/testsuite/foldTree/Main.hs > A ./LIGD.examples/testsuite/foldTree/Makefile > A ./LIGD.examples/testsuite/foldTree/test.stdout > A ./LIGD.examples/testsuite/geq/ > A ./LIGD.examples/testsuite/geq/Main.lhs > A ./LIGD.examples/testsuite/geq/Makefile > A ./LIGD.examples/testsuite/geq/test.stdout > A ./LIGD.examples/testsuite/gshow/ > A ./LIGD.examples/testsuite/gshow/CompanyDatatypes.hs > A ./LIGD.examples/testsuite/gshow/Main.lhs > A ./LIGD.examples/testsuite/gshow/Makefile > A ./LIGD.examples/testsuite/gshow/test.stdout > A ./LIGD.examples/testsuite/paradise/ > A ./LIGD.examples/testsuite/paradise/Main.hs > A ./LIGD.examples/testsuite/paradise/Makefile > A ./LIGD.examples/testsuite/paradise/test.stdout > _______________________________________________ > Generics mailing list > Generics@haskell.org > http://www.haskell.org/mailman/listinfo/generics -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2427 bytes Desc: not available Url : http://www.haskell.org/pipermail/generics/attachments/20061109/2b9119fb/smime.bin From mrchebas at gmail.com Mon Nov 13 17:34:34 2006 From: mrchebas at gmail.com (Alexey Rodriguez Yakushev) Date: Mon Nov 13 17:33:43 2006 Subject: Fwd: [Hs-Generics] Support for abstract data types References: Message-ID: Begin forwarded message: > From: "Pablo Nogueira" > Date: November 9, 2006 18:35:58 GMT+01:00 > To: "Alexey Rodriguez" > Cc: "generics@haskell.org" > Subject: Re: [Hs-Generics] Support for abstract data types > > Before all, thank you for your reply. Would you send this email to the > generics@haskell.org list if you don't see it arriving there? I had > problems posting in the past and have got no reply from the > administrator. > > On 07/11/06, Alexey Rodriguez wrote: >> Just to make things clearer for me, what would the entry be for C+ >> + STL? > > STL supports generic programming on container (first-order) abstract > data types (ADTs) with iterators, where by generic I mean functions > that work for all such ADTs. You may see the iterator as the "common > representation" of ADTs used by the STL. Certainly, STL is not > designed to deal with higher-kinded ADTs. I just wanted to say that > support for ADTs should be considered as important. I'm not saying STL > is polytypic, but having a single function that works on all container > types with iterators is very generic to me, just like having generic > functions on the so-called spine view for algebraic data types is. > > In the approach with generic views and the example with Queues you > give, you are basically mapping a Queue into a list, which is a left > to right iterator. The important thing is that you would have to > specify how ADTs are represented as sums of products *per* ADT, so GH > fares not better than STL in this respect, where every iterator has to > be programmed per ADT. (If iterators were generated automatically then > STL would fare really well). > > At present, I believe GH supports ADTs by polytypic extension (my > suggested terminology). The generic programmer has to specify the way > an ADT is translated into sums of products. (Aside: you'll have > problems supporting constrained abstract data type such as Ord a => > OrdSet a. You won't be able to apply gsize whose instance for * -> * > is unconstrained.) > > I hope I'm not mistaken in thinking that STL is relevant in this list, > which is about generic programming, not just polytypic programming. > (Is SYB polytypic?) My point in the email is that support for abstract > data types should be taken seriously when designing a generic (or > polytypic) library, nothing more. I'm with you in that we should do > better than STL. > > P. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20061113/c11d6b6c/attachment.htm From mrchebas at gmail.com Mon Nov 13 17:34:47 2006 From: mrchebas at gmail.com (Alexey Rodriguez Yakushev) Date: Mon Nov 13 17:33:55 2006 Subject: Fwd: [Hs-Generics] Support for abstract data types References: Message-ID: Begin forwarded message: > From: "Pablo Nogueira" > Date: November 10, 2006 12:46:27 GMT+01:00 > To: "Alexey Rodriguez" > Subject: Re: [Hs-Generics] Support for abstract data types > > Hi Alexey > > Could you please forward my replies to generics@haskell.org? I still > can't post and stil haven't got a reply from the administrator :-( > > One minor addition: > >> toQueue (Inl (e :*: q)) = e `prependToQueue` q >> toQueue (Inr ()) = emptyQueue > > What is `prependToQueue'? It is not a queue operation given by a queue > interface. I take it is actually "enqueue . reverse". If this is the > case, what you propose looks impractical. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20061113/ca3b90dc/attachment-0001.htm From mrchebas at gmail.com Tue Nov 14 12:46:46 2006 From: mrchebas at gmail.com (Alexey Rodriguez) Date: Tue Nov 14 12:45:55 2006 Subject: Fwd: [Hs-Generics] Support for abstract data types In-Reply-To: <4b39c80a0611140946w76490cfct39850d738c2f5bf3@mail.gmail.com> References: <4b39c80a0611070936i781f2291u690d5ec10a195162@mail.gmail.com> <4b39c80a0611140946w76490cfct39850d738c2f5bf3@mail.gmail.com> Message-ID: <4b39c80a0611140946x3d813bcapc2188d2cf80e8b9f@mail.gmail.com> ---------- Forwarded message ---------- From: Alexey Rodriguez Date: Nov 14, 2006 5:46 PM Subject: Re: [Hs-Generics] Support for abstract data types To: Pablo Nogueira On 11/10/06, Pablo Nogueira wrote: > > Hi Alexey > > Could you please forward my replies to generics@haskell.org? I still > can't post and stil haven't got a reply from the administrator :-( > > One minor addition: > > > toQueue (Inl (e :*: q)) = e `prependToQueue` q > > toQueue (Inr ()) = emptyQueue > > What is `prependToQueue'? It is not a queue operation given by a queue > interface. I take it is actually "enqueue . reverse". If this is the > case, what you propose looks impractical. I assumed it to be an operation internal to the queue library, remember that the mapping is written by the Queue library writer, not the user. "prependToQueue" does not need to be exposed to the user. What is exposed is the structural representation type and the embedding projection, which the user exploits by using Queue-specialized generic functions. Cheers, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/generics/attachments/20061114/18f8e196/attachment.htm