[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH][for chicken-5] Remove srfi-13
From: |
Peter Bex |
Subject: |
Re: [Chicken-hackers] [PATCH][for chicken-5] Remove srfi-13 |
Date: |
Thu, 11 Sep 2014 17:27:46 +0200 |
User-agent: |
Mutt/1.4.2.3i |
On Thu, Sep 11, 2014 at 05:13:48PM +0200, Felix Winkelmann wrote:
> [replying to Peter]
>
> > I don't grok what you are saying here. Do you want to copy the entire
> > CHICKEN 4 egg list to CHICKEN 5? It may be better to copy individual
> > eggs later, when we've finished all our module refactorings. That way,
> > the eggs won't all break at once, and only the eggs people are really
> > interested in will survive the transition.
>
> I think as many eggs as possible should make the transition, at least
> those that are in svn.
They'll still have to be ported one-by-one, as probably every egg will
break.
> > Maybe not just for internal use. Perhaps a chicken.string module could
> > contain these things plus the CHICKEN-specific ones from data-structures,
> > like string-intersperse and such? these functions are useful to user
> > code, too. Especially if we optimise them by removing all the silly
> > polymorphisms from the SRFI-13 implementation.
>
> By restricting them to internal use, we can use faster variants, and
> it will make user-code less confusing if it uses the "official"
> eggified definitions.
As you know, one of the problems with SRFI-13 is that it's extremely
inefficient. It would make sense if user code can also rely on faster
alternatives. One of the rules of CHICKEN optimization has long been
to avoid SRFI-13 if you can.
> Otherwise people will start mixing official and
> internal SRFI procedures. Isn't one of the goals of CHICKEN-5 to make
> the API cleaner?
I don't see how providing faster alternatives to SRFI-13 procedures is
mutually exclusive with making a cleaner API, unless you're planning on
making completely unsafe versions.
Cheers,
Peter
--
http://www.more-magic.net