English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
[Caml-list] "high end" type theory for working programmers?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2002-05-03 (00:54)
From: Chris Hecker <checker@d...>
Subject: [Caml-list] "high end" type theory for working programmers?

The list has had a lot of discussions about type theory behind the module 
system, tuples, and the like lately.  Most of it has been over my head, 
which is fun, because it presents a challenge to try to figure out what 
people are saying.  I am wondering how much of it is useful for actually 
writing "regular" code (as opposed to compilers or theorem provers).  Are 
there books (or survey papers) on this stuff that are meant to educate 
working programmers, as opposed to language researchers?  For example, 
where should I go to learn what this means, and whether I care (just a 
randomly chosen sentence representative of stuff that's currently over my 
head from the past few days on the list):

"That functor is essentially the polymorphic identity functor, while the 
other variation was a polymorphic eta-expansion of the abstraction operator."

or another example:

"In this encoding, modules are only records, so module types are ordinary 
types, and there is no distinction between ordinary abstract types 
(introduced by explicit polymorphic abstraction) and ``abstract 
signatures''. There is, as far as I can tell, no need for kind polymorphism."

I started using caml to find out if a "higher level" language could make a 
difference in my programming productivity (writing video games).  As I 
continue with that experiment, I'm curious to know whether understanding 
this high end type theory stuff would help make me a better programmer, or 
just more able to understand the list lately.  Either is fine, but both 
would obviously be great.  :)


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