From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 5236DBBC4 for ; Wed, 4 Mar 2009 23:00:03 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvABAIKIrknYi40JmWdsb2JhbACBTpM0AQEBAQEICwoHEcNMhAgG X-IronPort-AV: E=Sophos;i="4.38,303,1233529200"; d="scan'208";a="22062376" Received: from mail-out9.nyct.net (HELO mail.nyct.net) ([216.139.141.9]) by mail2-smtp-roc.national.inria.fr with ESMTP; 04 Mar 2009 23:00:02 +0100 Received: from beast.local (pool-96-250-33-211.nycmny.east.verizon.net [96.250.33.211]) (authenticated bits=0) by mail.nyct.net (8.14.2/8.14.1) with ESMTP id n24Lxu4a058635 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 16:59:58 -0500 (EST) (envelope-from bhurt@spnz.org) Date: Wed, 4 Mar 2009 16:59:51 -0500 (EST) From: Brian Hurt X-X-Sender: bhurt@beast To: Yoann Padioleau Cc: Jon Harrop , caml-list@yquem.inria.fr Subject: Re: [Caml-list] stl? In-Reply-To: <87ab81yrog.fsf@aryx.cs.uiuc.edu> Message-ID: References: <91a2ba3e0903031340wcdc976cp52522eb35f7ccb73@mail.gmail.com> <200903032342.39527.jon@ffconsultancy.com> <87r61eyu5c.fsf@aryx.cs.uiuc.edu> <87ab81yrog.fsf@aryx.cs.uiuc.edu> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam: no; 0.00; stl:01 'foo':01 stl:01 chunks:01 ocaml's:01 functors:01 ocaml:01 hashtbl:01 functors:01 collateral:98 wrote:01 typing:01 caml-list:01 functions:01 functions:01 On Wed, 4 Mar 2009, Yoann Padioleau wrote: > My goal is not being backward compatible. Of course you can > keep your old function and define new functions ... > My goal is to evolve code, so I want to change the behavior of 'foo', > and I want to benefit from this new behavior, > but I want this evolution to have the less collateral effects on > the structure of the rest of the program. > > For instance I got a set of functions that were working on some 'a > stuff, and I was using somewhere a naive list as a first draft. Later > I want to optimize things, and put those 'a in a more efficient > data-structure, but if use the Map data-structure, then I will be > forced to change lots of things. Argh, damned. Well, wait, I will just > use the defunctorized interface of Hashbtl :) Especially in the realm of data structure libraries (like the STL), I really question the utility of this. Data structures vary wildly in the performance characteristics of their various operations. For example, accessing a arbitrary element of a map is O(log N), doing so in a list is O(N). But accessing the first element of a map is O(log N) in a map, but O(1) in a list. So if I write my algorithm to always only need the first element of the sequence, but never need an arbitrary element, then replacing a list with a map is a real bad idea- and I don't need to perform actual comparisons to tell this. Where this does come up is when what you're really doing is refactoring code. Say I originally thought that I was only going to need the first element, but it turns out that I'm doing a lot more arbitrary accesses than original thought. In this case, however, you're not just swapping this data structure out for that one, you're also changing more or less large chunks of the code to reflect the new assumptions. Ocaml's huge advantage here then is not functors, or objects, or even type variables- it's just strong static typing. This allows you to change things and just see where things break. > > Again, just imagine one second that 'a list were not present in OCaml, > and that the only way you had to make a list would be to use > a functorized interface of a List module. Would you like that ? > (that's what we are forced to do when using Map and that's why > I always use Hashtbl instead). Humorously enough, I'm doing exactly this. In a bunch of code I'm playing with, I've implemented an NeList module- nothing fancy, just a few dozen lines of code and the basic list operations, only the lists can not be empty. They always have to contain at least one element. But seriously, you hate functors that much? The overhead of doing: module StringMap = Map.Make(String);; is so high to you, that you simply don't do it? Mind if I ask why? Brian