Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] First order compile time functorial polymorphism in Ocaml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: John Max Skaller <skaller@o...>
Subject: Re: [Caml-list] First order compile time functorial polymorphism in Ocaml
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<class T> 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