This was precisely what I meant. :)

Whilst standardising some things about FFI may be productive - boxing/unboxing between native and Scheme code, certain primitives - on the whole, I find the lack of standardisation to be a strength.

(An additional caveat - even if these are standardised, this doesn't necessarily mean they'll be compatible. The internal representations and structure are different, and standardisation could open up a huge Pandora's box of problems, as, for example, an integer representation of { 32 bit tag, 64 bit int } will not yield the same precision as a single 64bit int with a certain number of tag bits at the top - though this will not be obvious to end users.)

If I can expand on the experiment aspect, integrating with SWIG some years, and its pitfalls and abandonment, would probably have never been attempted if FFIs were semi-standardised. I like that we can play with things and try to target different possibilities.

-elf

On 4 December 2022 11:56:53 GMT+02:00, "Marc Nieper-Wißkirchen" <xxxxxx@gmail.com> wrote:
>Am So., 4. Dez. 2022 um 08:13 Uhr schrieb elf <xxxxxx@ephemeral.net>:
>
>> 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)
>
>The latter point is a very important one and can even be expanded.
>
>The "unportability" of Scheme (outside of the R5RS, R6RS, or R7RS
>core) should be interpreted as a good sign.  It means that the Scheme
>language is live and that people (users and implementers) are still
>experimenting, trying to push the boundaries.  We don't need 30+
>implementations if they all basically can do the same.  But we welcome
>30+ running experiments.
>
>What can be criticized in my opinion is that Scheme implementations
>make it too easy to write non-portable code, some even invite to do
>so.