[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shared-text substrings

This page is part of the web mail archives of SRFI 13 from before July 7th, 2015. The new archives for SRFI 13 contain all messages, not just those from before July 7th, 2015.



>>>>> "Olin" == Olin Shivers <shivers@xxxxxxxxxxxxxxxxxx> 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