[ERR5RS] FFI concern from a lowly user

[Leonardo Valeri Manera]

Take this with a bit of salt, considering i'm no wizard and only in
1st year of a computer science undergrad course but... also, please
excuse my english, not my first language :)

It seems, to my moderately unenlightened point of view, that the
currect tentative spec for ERR5RS solves most of the issues i always
thought prevented R5RS (and obviously R6RS) scheme from being truly
portable, bar one... and it is one I believe to be quite important, if
not fundamental, to provide the ability to write portable scheme
programs that do real-world tasks.

I mean, don't get me wrong, I adore scheme, but I often find myself
having to use other laguages or bind myself to a particular
implementation not because of implementation-specific syntax
extensions or the like, but because of the lack of a portable FFI
structure.

I've found myself thinking that the ERR5RS will come to nothing, at
least for my uses, unless this is addressed... and from the amount of
text this gets in the wiki, it doesn't seem to be a particular
concern... i might be wrong there though?

At the same time, I believe its beyond the scope of the ERR5RS to
define the FFI itself with all its syntax - rather, it should define
the underpinnings that would allow third parties to make ffi
libraries. After all, a FFI must be able to evolve as new languages
and paradygms come into the fore, and this kind of evolution is not
pertinent to the specification of a multiple-implementation language
like scheme.

That is to say, provide standardized low-level "stuff" that would
_allow_ implementers to port say, chicken's c++ ffi, or CL's UFFI, to
the ERR5RS, and leave the high-level to third-party libraries.

IMO, when you have that, everything else is doable (asdf-alikes
etc)... without it, you've solved the ickyness of R6RS, but we'll
still be in the same place the R5RS is.

Well... I guess that's it, please don't go down too hard on my
noobishness, wise masters :D

Cheers,
Leo