[Top][All Lists]

[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/

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

> > 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]