From: skaller <skaller@tpg.com.au>
To: Alain.Frisch@ens.fr
Cc: "Yaron M. Minsky" <yminsky@cs.cornell.edu>,
Caml List <caml-list@inria.fr>
Subject: Re: [Caml-list] Big_int comparisons
Date: 03 Feb 2004 20:52:58 +1100 [thread overview]
Message-ID: <1075801977.17649.87.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.SOL.4.44.0402021312180.19457-100000@clipper.ens.fr>
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
prev parent reply other threads:[~2004-02-03 9:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-01 19:42 Yaron M. Minsky
2004-02-02 12:23 ` Alain.Frisch
2004-02-02 12:34 ` Yaron M. Minsky
2004-02-02 13:36 ` Alain.Frisch
2004-02-03 9:52 ` skaller [this message]
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=1075801977.17649.87.camel@localhost.localdomain \
--to=skaller@tpg.com.au \
--cc=Alain.Frisch@ens.fr \
--cc=caml-list@inria.fr \
--cc=yminsky@cs.cornell.edu \
/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).