From mboxrd@z Thu Jan  1 00:00:00 1970
Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id SAA04271; Thu, 15 Aug 2002 18:43:40 +0200 (MET DST)
Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id SAA03934 for <caml-list@pauillac.inria.fr>; Thu, 15 Aug 2002 18:43:39 +0200 (MET DST)
Received: from bastion.artisan.com (bastion.artisan.com [209.144.161.130])
	by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g7FGhcn04053
	for <caml-list@inria.fr>; Thu, 15 Aug 2002 18:43:38 +0200 (MET DST)
Received: from ypmaster.artisan.com (ypmaster [172.16.2.1])
	by bastion.artisan.com (8.9.2/8.9.2) with ESMTP id JAA24240;
	Thu, 15 Aug 2002 09:43:35 -0700 (PDT)
Received: from granite.artisan.com (granite [172.16.10.97])
	by ypmaster.artisan.com (8.9.2/8.9.2-arti) with ESMTP id JAA17097;
	Thu, 15 Aug 2002 09:43:34 -0700 (PDT)
Received: (from bpr@localhost)
	by granite.artisan.com (8.9.2/8.9.2) id JAA08249;
	Thu, 15 Aug 2002 09:43:34 -0700 (PDT)
X-Authentication-Warning: granite.artisan.com: bpr set sender to bpr@artisan.com using -f
From: Brian Rogoff <bpr@artisan.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15707.55862.181324.32529@granite.artisan.com>
Date: Thu, 15 Aug 2002 09:43:34 -0700
To: caml-list@inria.fr
Cc: skaller@ozemail.com.au
Subject: Re: [Caml-list] sorting Hashtbl.t
References: <200208120108.VAA16373@dewberry.cc.columbia.edu>
	<20020812101020.GV6002@barcelona.lrde.epita.fr>
	<3D5AD6CF.7030603@ozemail.com.au>
X-Mailer: VM 7.00 under Emacs 20.7.1
Sender: owner-caml-list@pauillac.inria.fr
Precedence: bulk

John Max Skaller writes:
> > 	From an algorithmic point of view, there is no way to sort an
> > hash table since there is no order attached to items. 
[...snip extended Hashtbl interface ...]
> Of course I can write this
> function myself, it's just inconvenient to have to
> keep doing so.

The only thing that really prevents you from doing this just once in a 
fairly neat and comfortable way is the restriction on multiple definitions
of the same module name in a given structure or signature, in this case, 
Make. Why don't later module names just shadow previous ones, as later
function definitions follow succeeding ones? If this were the case, then we 
could handle this problem with something like so 

(* exthash.mli -- NOT LEGAL OCaml *)
include Hashtbl 

val elements : ('a, 'b) Hashtbl.t -> 'b list

module type S = 
  sig 
    include S 
    val elements : ('a, 'b) Hashtbl.t -> 'b list
  end

module Make (H : HashedType) : S with type key = H.t

(* exthash.ml -- NOT LEGAL OCaml *)
include Hashtbl 

let elements ht = 
  let r = ref [] in 
  (Hashtbl.iter (fun _ y -> r := y::(!r)) ht; !r)  

module type S = 
  sig 
    include S (* S here refers to Hashtbl.S *)
    val elements : ('a, 'b) Hashtbl.t -> 'b list
  end

module Ext (H : HashedType) : S with type key = H.t = 
  struct 
    module Hashtbl =  Make(H)
    include Hashtbl
    let elements ht = 
      let r = ref [] in 
      (Hashtbl.iter (fun _ y -> r := y::(!r)) ht; !r)  
  end

but because of the restrictions we need to replace those includes with a
manual copying of all of the relevant code from the Hashtbl module. 

-- 

  I mean, if 10 years from now, when you are doing something quick and dirty, 
  you suddenly visualize that I am looking over your shoulders and say to 
  yourself, 'Dijkstra would not have liked this,' well that would be enough 
  immortality for me.

  Edsger Wybe Dijkstra 1930-2002

-- Brian
-------------------
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