Browse thread
[Caml-list] Big_int comparisons
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | skaller <skaller@t...> |
| Subject: | Re: [Caml-list] Big_int comparisons |
On Mon, 2004-02-02 at 23:23, Alain.Frisch@ens.fr wrote: > On Sun, 1 Feb 2004, Yaron M. Minsky wrote: > > > Does anyone know why there's no support for Big_int comparisons? > > A solution could be to allow attaching custom generic operations to > non-custom blocks The problem with this is you end up re-implementing Python, i.e. having a 'vector' of generic functions for each type. Another 'useful' generic operator is of course 'get next' for containers (C++ iterators, Python sequence operators ..) Now, Ocaml does provide the tools to deal with this in most cases: functors (provided the genericity is not required to be run-time). The problem then would seem to be that its hard to write functors for every data structure, sub-data structure of the data stucture, etc. At least part of the reason is that the functors provide abstract types, so building a functor to provide, for example, a comparator so you can put them in sets isn't immediately compatible with other generic operations such as pattern matching. It seems like the 'private' keyword is a step forward here: a way to control representation invariants during construction (or mutation) which doesn't prevent convenient algrebraic type destructors like pattern matching being used: even though, in principle, these operations may not retain their semantics, for example a type int * int representing a rational number admits the destructor fst v which is not in fact a projection (since the type is not a product). -- John Max Skaller, mailto:skaller@tpg.com.au snail:25/85c Wigram Rd, Glebe, NSW 2037, Australia. voice:61-2-9660-0850. Checkout Felix: http://felix.sf.net ------------------- 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