caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: John Max Skaller <skaller@ozemail.com.au>
To: Jun.Furuse@inria.fr
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] First order compile time functorial polymorphism in Ocaml
Date: Tue, 24 Jun 2003 03:53:07 +1000	[thread overview]
Message-ID: <3EF73E83.30000@ozemail.com.au> (raw)
In-Reply-To: <lwel1lqi7m.wl@inria.fr>

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


  reply	other threads:[~2003-06-23 17:53 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-22 18:25 John Skaller
2003-06-22 19:03 ` Michal Moskal
2003-06-23  3:52   ` John Max Skaller
2003-06-23  9:58     ` Michal Moskal
2003-06-23 10:27       ` Markus Mottl
2003-06-23 10:35         ` Michal Moskal
2003-06-23 10:08     ` Markus Mottl
2003-06-23  8:07 ` Francois Rouaix
2003-06-23  9:03   ` Roberto Di Cosmo
2003-06-23 17:37   ` John Max Skaller
2003-06-23  9:03 ` Jun.Furuse
2003-06-23 17:53   ` John Max Skaller [this message]
2003-06-23 18:02 ` Jacques Carette
2003-06-24  1:00   ` Jacques Garrigue
2003-06-24 12:45   ` John Max Skaller
2003-06-24 14:34     ` Jacques Carette
2003-06-24 23:45       ` Jacques Garrigue
2003-06-25  2:27         ` John Max Skaller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EF73E83.30000@ozemail.com.au \
    --to=skaller@ozemail.com.au \
    --cc=Jun.Furuse@inria.fr \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).