Consider providing srfi-1

[0-8-15]

ln_core/lists.scm contains a few list operations analogous to SRFI-1.

The list is small and a bit arbitrary chosen. The implementation is rather bad at handling invalid calls and often O(horror^2).

Instead of fixing that file, I'd recommend to include srfi-1 and phase this one out.

[0-8-15]

The non-standard implementation furthermore risk to break seemingly at random on known-to-be-good third party code.

[mgorges]

Don't have the bandwidth to consider this at the moment as it will introduce changes that are not backwards compatible and we would have namespace collisions if we added it as a module as ln_core is used everywhere; this includes obvious ones regarding lists, e.g. make-list and non-obvious ones like zip. There is a reference implementation at https://srfi.schemers.org/srfi-1/srfi-1-reference.scm (with a very permissive license) and two versions on the Gambit-C Dumping Grounds. Both come with what I would interpret to be a warning that they might not be optimal?

[mgorges]

If I do a (probably not safe or comprehensive) approach for looking at conflicting function names, limited to those listed as being exported, I get hits for these:

modules/array/array.scm:(define (every pred lst . rest)
modules/generic-arrays/generic-arrays-impl.scm:  (define (drop x i)
modules/generic-arrays/generic-arrays-impl.scm:  (define (take x i)
modules/generic-arrays/test-arrays.scm:(define (filter p l)
modules/irregex/irregex.scm:(define (any pred ls)
modules/irregex/irregex.scm:(define (every pred ls)
modules/irregex/irregex.scm:(define (filter pred ls)
modules/irregex/irregex.scm:(define (find pred ls)
modules/irregex/irregex.scm:(define (find-tail pred ls)
modules/irregex/irregex.scm:(define (fold kons knil ls)
modules/irregex/irregex.scm:(define (last ls)
modules/irregex/irregex.scm:(define (remove pred ls)
modules/ln_core/list.scm:(define (make-list n #!optional (elem 0))
modules/redcap/redcap-unittest.scm:(define (drop lst n)
modules/redcap/redcap-unittest.scm:(define (take lst n)
modules/scran/scran.scm:(define (delete! entity)
modules/sets/sets.scm:(define (delete e s)
modules/sets/sets.scm:(define (remove e s)
modules/ssax/SSAX-code.scm:(define (fold kons knil lis1)
modules/ssax/SSAX-code.scm:(define (fold-right kons knil lis1)
modules/ssax/common.scm:(define (filter pred lis)	

[0-8-15]

Correct: the question is how to deal with code, which depends on the semantics in the list.scm.

Replace? Deprecated? ...

For those external modules, we'll only need to check what they export and why.
A quick assessment, partial from memory: array, generic-arrays, irregex, sets, ssax and redcap-unittest.scm would work with srfi-1 definitions. (These define either what srfi-1 implements or a compatible subset.)

scran defines a different delete! -- needs consideration.

[0-8-15]

Don't have the bandwidth to consider this at the moment as it will introduce changes that are not backwards compatible and we would have namespace collisions if we added it as a module as ln_core is used everywhere; this includes obvious ones regarding lists, e.g. make-list and non-obvious ones like zip. There is a reference implementation at https://srfi.schemers.org/srfi-1/srfi-1-reference.scm (with a very permissive license) and two versions on the Gambit-C Dumping Grounds. Both come with what I would interpret to be a warning that they might not be optimal?

Not optimal is IMHO not a valid argument but not a show stopper. Better than maintaining an environment incompatible with srfi compliant Scheme code.

Right now I'm looking into the issue that the inclusion of generalized-arrays overrides a srfi-compatible version of take with a even less optimal version (according to my recently gained understandings of gambit wrt do vs. let loop's).

No matter how sub-optimal: It breaks unrelated code! -- That's bad.

So where should I change? The recently added module, which brings it's own version of take to be nurtured or the ln_core/list.scm which so far at least does has no conflict in this particular case? (Don't bother, I'll change lists.scm remove it from generalized arrays and submit a PR.)

The issue is still annoying. Could we get rid - with reasonable effort - of uses of generic top level bindings defined by some srfi?

I know that this will always be an issue as new srfis might be published. In so far I'd recommend to follow a policy of "have your own prefix/namespace" as Gambit itself does. It helps to keep code working in a backward compatible way without turning into a road block after another sunrise. Sure: it's additional typing. Don't take this a a "prefix everthing"!

[0-8-15]

Right now I'm looking into the issue that the inclusion of generalized-arrays overrides a srfi-compatible version of take with a even less optimal version (according to my recently gained understandings of gambit wrt do vs. let loop's).

Sorry: blamed the wrong cause here. It's actually gambit, which takes the "liberty" to not follow srfi-1 in edge cases.