Email list hosting service & mailing list manager

Re: shared-text substrings Olin Shivers (24 Mar 2000 00:27 UTC)
Re: shared-text substrings sperber@xxxxxx (24 Mar 2000 15:53 UTC)

Re: shared-text substrings sperber@xxxxxx 24 Mar 2000 15:53 UTC

>>>>> "Olin" == Olin Shivers <xxxxxx@mongkok.ai.mit.edu> writes:

Olin> Languages should be small. Libraries should be large.

Yeah, well, we know this is your opinion.  It's not fact.  I'm not
asking you to abandon functionality.  I'm asking you to divide
functionality into smaller parts.  You keep refusing to address this
issue.  I really like what's in SRFI 13.  But it's too much for a
single library.

Olin> It is not hard to handle this library --

This is just plain wrong.  It *is* (would be ...) hard to handle this
library, because, in realistic application code, I'll want to use it
alongside two dozen other libraries.  Moreover, I'll realistically
only use 10% of the strings library, yet---in finding out about what
the library does and reading the docs---there's conceptual overhead.
If anything, *implementation* size is totally irrelevant.  The *docs*
are 1000 lines.

I'll be much more likely to use a string library with a much smaller,
but better-defined focus, and if nobody else does, I'll eventually
submit a SRFI to that end.  I'm not mainly a designer, I'm a potential
user.  Look at the discussion archive---I'm not the only one who feels
that way.

Olin> Subtle algorithms requiring careful reasoning. Which makes them
Olin> prime candidates for being packaged up once & for all.

And the complexity of the discussion should convince you that SRFI 13
is not succeeding at the "once & for all" part.

--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla