I would like to make three comments:

1. While I don't subscribe to the statements about the many "obvious"
problems of the SRFI process, I welcome the creation of a place where
a community can be gathered to discuss libraries and other
Scheme-related issues outside of the SRFI process.  This can even
benefit the SRFI process because it can also play the role of an
incubator for new proposals.

2. The SRFI process is essential for increasing portability.  The SRFI
process is probably the best way to make a yet unportable feature
portable by encouraging Scheme implementations to adopt it.
(Therefore, the portability of a sample implementation is less
important than that it must show that the feature is implementable.)
But even SRFIs that consist basically of a portable library together
with a description of its API help portability in the sense that it is
much easier to read code written by others and contribute to it if the
code is written using "standardized" idioms or procedures.

3. While the SRFI process itself has high standards, it is the
individual authors that are finally responsible for what's in each
SRFI.  In particular, the whole set of SRFIs does not define a
coherent language, nor will every SRFI maintain the same high-quality
standard by whatever quality measure one applies.

Marc

PS I would prefer if we could agree on a civilized language here.

Am So., 4. Dez. 2022 um 08:28 Uhr schrieb Vladimir Nikishkin
<xxxxxx@gmail.com>:
>
> > The execptions are as follows:
>
> These "three tiny exceptions" are 90% of the code which is actually
> useful, not some "category theory monadic involution combinators"
> mumbo-jumbo. So, yes, I stand by my point. Scheme code is largely
> unportable.
>
> >Are there any other areas, besides the three points above, that others have tried to port and run into problems between implementations?
>
> GUI
>
> >I would recommend that people actually test the 'common knowledge' before talking about it so much.
>
> I would recommend you be less of an arrogant patronizing asshole with
> zero experience than you are trying to present yourself.
>
> >I have ported significant amounts of code between implementations
>
> No you have not, you have nothing to show. Prove me wrong.
>
> On Sun, 4 Dec 2022 at 15:13, elf <xxxxxx@ephemeral.net> wrote:
> >
> > Sorry - how many of the people who think Scheme is largely unportable between implementations have actually tried porting code between implementations?
> >
> > I have ported significant amounts of code between implementations. Each implementation has its strengths and weaknesses and I use whichever implementation is best suited for the project at hand to quickly prototype projects for my employer(s), which means that certain types of 'base libraries', so to speak, must be kept working in several implementations.
> >
> > Scheme code is largely _portable_ with minimal effort, SRFIs particularly so. The execptions are as follows:
> >
> > 1) Macro systems are generally much less portable or suffer massively in doing so. This is not to say that macros themselves are unportable - R5RS and R7RS systems (at least - I don't work with R6 systems), implementing the basic hygenic macros, do not have this problem - it is when one tries to add a new system augmenting this.
> >
> > 2) FFI code is unportable. Whilst working out standards for representation may be useful,
> > A) an implementation written in and targeting C (for example) is not going to have a meaningful FFI compatiblity to a native Java (for example) implementation,
> > B) the individuality/uniqueness of each implementation may suffer if this becomes too uniform (which would make the entire scheme ecosystem poorer, imho)
> >
> > 3) Network coding is drastically different between implementations, in that the primitives differ greatly in scope and level. This is a weakness - but very few SRFIs are affected by this at the moment.
> >
> > I would recommend that people actually test the 'common knowledge' before talking about it so much.
> >
> > Are there any other areas, besides the three points above, that others have tried to port and run into problems between implementations?
> >
> > -elf
> >
> >
> >
> > On 4 December 2022 08:27:03 GMT+02:00, Vladimir Nikishkin <xxxxxx@gmail.com> wrote:
> > >
> > >3. Most SRFIs are either unportable or portable with significant effort.
> > >
> > >
> > >
>
>
>
> --
> Yours sincerely, Vladimir Nikishkin
> (Sent from GMail web interface.)