On Thu, 11 Sep 2014 15:44:34 +0200 Peter Bex <[email protected]> wrote:
> On Thu, Sep 11, 2014 at 03:25:24PM +0200, Felix Winkelmann wrote: >> Ah, well done, Mario! >> >> But, some remarks: >> >> * Perhaps we should "svn cp" the release/4 branch and add new eggs >> afterwards, otherwise the "5" directory will be in the way. By >> copying the tree, the new eggs for the functionality extracted in >> the recent CR will be available, too. > > 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'm not sure I understand either. I thought we would populate release/5 as eggs get ready to work with CHICKEN 5. As a side-effect, it would be a good opportunity to left some crufty eggs behind. >> * Wouldn't it be preferrable if we collect re-implementations of some >> srfi-13 routines in a common library unit, for internal use only? > > 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. I don't have a strong opinion on this point. I'm slightly concerned about too much name duplication of often-used procedures. I think it can be confusing. Like "is this `string-prefix?' from core or from srfi-13?" (of course, we can make it clear at import time). OTOH, I'd love to have a procedure like `string-prefix?' (without all the optional argument madness) in the core. :-) >> * Does this require a change-request? We haven't "officially" decided >> yet on extracting the srfi's, even though it seems to be the >> consensus. > > Nah, CHICKEN 5 will break backwards compat across the board anyway, so > change-requests aren't really necessary. If someone disagrees, they > can object here on the list. Sorry, I haven't even thought about CRs. I just assumed we won't bother much about breaking compatibility in CHICKEN 5 (it doesn't mean we should gratuitously break stuff). But you have a point -- we may not have a consensus on some decisions. How about creating CRs when such issues arise? For example, like Peter suggests, when someones disagrees on the list. Best wishes. Mario -- http://parenteses.org/mario _______________________________________________ Chicken-hackers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-hackers
