Am Di., 13. Okt. 2020 um 21:00 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

> On Tue, Oct 13, 2020 at 1:45 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote:
>
>> > That is, it is possible for implementers to do so, but it is not possible for users to do so in general, because they typically have no control over the implementation of vectors in the Scheme they are using. [...]
>>
>> This is an argument against anything that cannot be portably
>> implemented, isn't it?
>
>
> It is an argument that favors designs that can be implemented portably whenever other costs are not too high.  In particular, a design that can be implemented portably is better than one that must be implemented in different ways on different Schemes, which in turn is better than one which has to be implemented from scratch on all but a few Schemes.  The discussion of sample implementations in the SRFI process document <https://srfi.schemers.org/srfi-process.html>, section "Structure", bullet points 7a-7e, reflects this same set of priorities.

I agree now that I see that you want to take other cost factors into
account as well. Initially, the argument sounded (to me) a bit
absolute.

>> If an exception is raised whenever the vector has to reallocate
>> itself, this will probably detrimental to its performance (as going
>> through exception handlers may not be the fastest thing in the world)
>>
>> when all what the programmer wants is that the vector does the
>> reallocation.
>
>
> As I said, I don't think this idea is particularly meritorious.

And I don't think that, in this special case, it is a good idea to
force implementations to give up their native vector model in favor of
a resizable one because of the extra indirection required.

>> > It's not so small when you figure the total cost of persuading implementers to do it.  As SRFI 214 stands, implementers don't have to do anything at all, as a portable implementation is practical.
>>
>> This is an argument often repeated. For the vast majority of the
>> currently existing R7RS-large SRFIs, implementers don't have to do
>> anything at all. And yet, they would have to do anyway if they want to
>> provide a competitive solution.
>
>
> One of the strengths of the Scheme (and Lisp in general) community is that there is no consensus on what counts as a "competitive solution".  CL provides some compiler directives that tell the implementation what the compiler should optimize for: speed, space, safety, compilation speed, and ease of debugging.  Like all CL declarations except "notinline", these may have any effect or none.  In any case, it serves as a useful taxonomy of programmer concerns.
>
> Rather than having such directives in Scheme, we have multiple implementations.  Chibi will never beat Chez on speed, but Chibi is engineered for embeddability (a sixth concern).

That's true. And yet Chibi has a native C hash table implementation.
Without it, it would be hardly better in any regard. As I wrote
previously, this is currently the issue with SRFI 166 on Chibi. It's
there and it's elegant, but it's two magnitudes too slow to be useable
for any larger (program) texts to be formatted.

> Speaking of C, it too has multiple implementations too, but they all optimize for the same thing: execution speed is far and away the most important concern, followed at a distance by compilation speed, with all the other concerns absolutely nowhere.  The consensus of C programmers, or at least of C implementers, is that these are what matter.

To *some* extent this is the raison d'être for C, isn't it? That said,
implementations are improving on error reporting and debuggability.
Sometimes, at least for me, it is impossible to find an error in my C
code without using Valgrind; sometimes it is much easier to find an
error in my C code than in my, say, Chibi code thanks static types,
compiler warnings and much better source line information.

PS You can embed Chez in your C programs depending on what you want.
It's probably not possible on an embedded device with only 256k of
memory, though.

I once managed to run Chibi on a Lego Mindstorms but the execution
speed was just enough for the experiment, not for anything serious.