Re: [oliver: Re: [Caml-list] Strings as arrays or lists...]

[brogoff@speakeasy.net]

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