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 BAA16974; Tue, 4 Mar 2003 01:40:10 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f 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 BAA16575 for ; Tue, 4 Mar 2003 01:40:07 +0100 (MET) Received: from grace.speakeasy.org (grace.speakeasy.org [216.254.0.2]) by nez-perce.inria.fr (8.11.1/8.11.1) with SMTP id h240drH26960 for ; Tue, 4 Mar 2003 01:40:00 +0100 (MET) Received: (qmail 19068 invoked by uid 36130); 4 Mar 2003 00:39:50 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Mar 2003 00:39:50 -0000 Date: Mon, 3 Mar 2003 16:39:50 -0800 (PST) From: brogoff@speakeasy.net To: William Lovas cc: "caml-list@inria.fr" Subject: Re: [oliver: Re: [Caml-list] Strings as arrays or lists...] In-Reply-To: <20030303210554.GA5245@force.stwing.upenn.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam: no; 0.00; brogoff:01 oliver:01 caml-list:01 lovas:01 agitate:01 extensional:01 notations:01 char:01 expressing:01 unboxed:01 bigarrays:01 module's:01 unification:01 generic:01 implementor:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Mon, 3 Mar 2003, William Lovas wrote: > On Mon, Mar 03, 2003 at 12:10:45PM -0800, brogoff@speakeasy.net wrote: > > That's why I said "Agitate for extensional polyorphism!". You really want a > > way to overload similar notations. As you must now know, OCaml has no > > overloading. Extensional polymorphism gives you that overloading, on top of > > ML, in a way that even people who hate overloading should find fairly > > nonthreatening. > > You keep skirting around this question by saying that what he really wants > is extensional polymorphism, but overloading is not the only way to get the > same syntax for strings and arrays. Another way is to have them simply *be > the same thing*. That is, is there any deep reason not to do > > type string = char array Because strings are packed, and OCaml has no facility for expressing that the char array should be packed. I mentioned Clean earlier, and I'm pretty sure I mentioned that Clean strings are UNBOXED arrays of characters. No way to express that in OCaml now. If you really want that, you would ask for Bigarrays instead of arrays, but there may be performance problems there, as the Bigarray representation is tuned for different uses. > right up front, and inherit all the Array module's functions? We could > still keep a String library with all string-specific functions in it, but > we'd gain a unification of many function implementations, and the same > notation for random access to boot. Even if this were a good idea, which I don't think it is, I'd probably still have an Array module and a String module with different interfaces. The similarity between Arrays and Strings is that their elements are accessed by integers in constant time. > You mentioned that strings are packed -- meaning that they're more > efficient than generic arrays? It means that characters are packed; which means that you can put more of them into the array, which means that strings can be bigger than arrays. Of course, if we had 32bit chars that wouldn't be true. > But doesn't O'Caml already have compiler > magic for making float arrays fast and efficient? Yup. > Why not just do the same thing for char arrays? Compiler complexity? I'll let an implementor answer, if they're not already bored to tears by this thread. I understand what you want, and if it were no problem to just pack everything, that would be great, but I think it's a bit more complex than that. > You indicated towards the end of your email that you feel that strings and > arrays are different enough to warrant different representations, Actually, no. I indicated that they are different enough to warrant different interfaces, though I suppose from there you could infer from that that different representations may be warranted as well. In fact, as I stated earlier (I hope?), I don't think one, single string representation will satisfy everyone. It certainly won't satisfy me, and I'm only one person. Given that, and given that I do understand the OP's desire to share notation, I think some amount of overloading would be a good way to address this problem, as well as many others. Aren't hash tables kind of like arrays too? Can't we use the same notation to access them as for arrays and strings? Ditto for association lists. The tool for addressing this problem is overloading (of the access function), not shoehorning all of these things into one representation. > What's the good reason for separating these two ideas > that are clearly very similar in interface, and probably not too different > in implementation? I don't think they're all that similar in interface. I do agree with you that the representations could be pretty close though, at least for the simplest kind of string. But ropes (for example) have a very different representation than simple strings, yet an almost identical interface. What to do? -- 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