From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id TAA32419; Mon, 23 Jun 2003 19:53:14 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id TAA32632 for ; Mon, 23 Jun 2003 19:53:13 +0200 (MET DST) Received: from mail2.tpgi.com.au (mail.tpgi.com.au [203.12.160.58]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id h5NHrAP26927; Mon, 23 Jun 2003 19:53:10 +0200 (MET DST) X-Envelope-From: skaller@ozemail.com.au Received: from ozemail.com.au (203-213-81-172-syd-ts13-2600.tpgi.com.au [203.213.81.172]) (authenticated bits=0) by mail2.tpgi.com.au (8.12.9/8.12.9) with ESMTP id h5NHr7WV013794; Tue, 24 Jun 2003 03:53:07 +1000 Message-ID: <3EF73E83.30000@ozemail.com.au> Date: Tue, 24 Jun 2003 03:53:07 +1000 From: John Max Skaller User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: Jun.Furuse@inria.fr CC: caml-list@inria.fr Subject: Re: [Caml-list] First order compile time functorial polymorphism in Ocaml References: <3EF5F48E.6010209@ozemail.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Kaspersky-Antivirus: Passed X-Spam: no; 0.00; ozemail:01 caml-list:01 functorial:01 furuse:01 generic:01 haskell:01 generics:01 g'caml:01 expressive:01 'type:99 toxteth:01 glebe:01 2037,:01 9660:01 0850:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Jun.Furuse@inria.fr wrote: > Yes, I agree that writing map or fold function over again and again is > trivial and boring. .. and leads to errors and poor design, when the design is based on laziness instead of modularity :-) > Your approach reminds me polytypic programming or so-called > "generic programming"[1] in Haskell. Its a jumbled up cut down verion of functorial polymorphism, which i think is also called polytypy. > I have also considered a bit about > the possibility of this "generic programming" in O'Caml. Actually, > I think our "generics" (= G'Caml) has already had allmost of all > the internal functionalities for so-called "generics" in Haskell > community. Hmm. Being a C++ programmer, saying 'generic' sounds too much like dependent name lookup in templates :( template void f(T t) { g(t); } Here, lookup on the dependent name g is delayed until the template is instantiated, then the search is done in the namespace in which the argument type is defined. This 'genericity' is both very powerful, and also not very robust. (I'd say it's not well-principled, but in practice it is very expressive). At least the idea with 'polymap' et al, is that it's based on type *structure* not overloading (in particular, separating the data from the shape). Using the 'type variable' to denote the data part is a bit of a hack. It isn't right. But in practice, it may be workable for a first order solution. -- John Max Skaller, mailto:skaller@ozemail.com.au snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners