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