Partial support for SRFIs

[jpellegrini]

What happens when a Scheme implementation has only partial support for a SRFI?

An example: Chicken is listed in the table as supporting SRFI-207 (and actually the only supporting implementation currently). But it only has the procedures implemented; for complete support the reader would have to be changed to allow for things like this:

#u8"a b c"  => #u8(97 32 98 32 99)

and it does not (as noted in the Chicken egg documentation).

Do you consider this important enough so as to include this kind of information in the table? (I am sure there would be some more similar cases -- I vaguely remember some other partial-support implementation).

Also, there are two different situations:

1. the SRFI requires A, B and C, but the Scheme implementation only has A and B (it's not conforming)
2. the SRFI requires A, B, but leaves C as "optional". The Scheme implementation only has A and B (so it is conforming)

[lassik]

You've written an excellent summary of the problems of optional features in SRFIs, and how those problems ultimately cannot be solved in an unambiguous way. IMHO SRFIs should not have optional features because it invariably leads to the problems you state.

IMHO the best policy for this project is to push the blame downstream upstream:

• We don't make a distinction in srfi-metadata whether a SRFI is partially supported. We say that it's either supported or not supported - no middle ground.
• Each Scheme implementation/package supplies a list of the SRFIs it supports.
• Each Scheme implementation/package can make a decision on whether to say that it supports a partially-implemented SRFI or not. We reflect that decision in srfi-metadata without passing judgment on the decision.
• If Scheme programmers think a particular supported/not-supported entry in srfi-metadata is misleading, we tell them to talk to the authors of the Scheme implementation/package and fix the problem at their end.

This is probably the only easily sustainable policy long-term. Otherwise there will be so many different shades and variations of partial support, and everyone will just be confused.

For new future SRFIs that need optional features, it's better to split into two SRFIs. This should have been done with SRFI 207 as well, and originally was.

[jpellegrini]

This is probably the only easily sustainable policy long-term.

Ok -- would it make sense to include this information (as a disclaimer) somewhere? Like "The responsibility for stating that a SRFI is supported is on the Scheme implementation developers"

[lassik]

Alternatively, for each partially supported SRFI, srfi-metadata could link to a verbal description of which features are missing. But that would mean implementors are punished for honesty and thoroughness, because people who shipped partial support without mentioning anything verbally about the missing features would be marked as "full support" even though in reality they also have partial support. In practice, the line between full and partial support is not that clear-cut. Basic differences in things like continuations and number type implementations (are bignums available? how are complex numbers implemented?) already mean that two implementations of the same SRFI don't support precisely the same functionality.

If we differentiated between full and partial support, srfi-metadata would also be tasked with tracking changes to that status. What if something is partial now, but full later? Etc.

[jpellegrini]

link to a verbal description of which features are missing

Which would have to be maintained... Is it feasible?

[lassik]

Ok -- would it make sense to include this information (as a disclaimer) somewhere? Like "The responsibility for stating that a SRFI is supported is on the Scheme implementation developers"

We could say that. Would it work to have it at the bottom of the web page with the table? A kind of "small print" like in legal documents :)

[jpellegrini]

continuations and number type implementations

This is important too -- as much as SRFI support... But probably not on that same table, I guess.

[jpellegrini]

Would it work to have it at the bottom of the web page with the table? A kind of "small print" like in legal documents :)

I suppose so!

[lassik]

link to a verbal description of which features are missing

Which would have to be maintained... Is it feasible?

I'd estimate that it's probably not feasible, unless someone can think of a clever way to do it. In general, it's not useful to add more data unless we have a plausible way to ensure the data stays correct over time.

[jpellegrini]

clever way to do it

Since that information may be buried down in implementors' deocumentation in several ways, I would guess either some deep learning system that would itself be hard to maintain, or no other clever way exists... :) :)

[lassik]

Since that information may be buried down in implementors' deocumentation in several ways, I would guess either some deep learning system that would itself be hard to maintain, or no other clever way exists... :) :)

Exactly :) Correctness is mainly about human responsibility: If a well-defined person can do some well-defined thing at well-defined times to keep the information correct, that usually works well. If it's not clear who should do what when, the information will usually start to get inaccurate over time. (Unless it's static information about things that will never change, e.g. old implementation/package releases that have already been published.)

[jpellegrini]

So - what about just the disclaimer on the top (or bottom)?

[lassik]

So - what about just the disclaimer on the top (or bottom)?

Works for me. Do you want to make a PR?

[jpellegrini]

Works for me. Do you want to make a PR?

I can do that later -- not able right now

[jpellegrini]

Just did, actually.

[lassik]

Thanks! Merged.

[jpellegrini]

Can we close this?

[lassik]

Fine with me. @erkin @diamond-lizard Please re-open this issue if you'd like to make changes or suggest an alternative.

[APIPLM]

My opinion is that SRFIs is not unchanged for ever. I think that Scheme implementation more focus on the the problem solving. There is probably a case, where partially implement those SRFIs, let us randomly say SRFI 76 to solve their problems. Then they can request to the related SRFIs, and complement the corresponding SRFIs if it is a common need.

[lassik]

Indeed, even Guile has at least one partially implemented SRFI (SRFI 13 is missing a few procedures).

Do we agree that we should leave full vs partial implementation to the implementors, and the table should just say supported / not supported?

[APIPLM]

@lassik I have not correctly answer for it yet. The better way to do is that leave them (implementors and the author of the SRFI ) to discuss how it should be stated, and there is one more person to check it as well.

[diamond-lizard]

Do we agree that we should leave full vs partial implementation to the implementors, and the table should just say supported / not supported?

I agree. It's not scalable to expect this project to dig in to which SRFI is or is not fully implemented on every Scheme. For now, if a Scheme reports as supporting a SRFI, it should be reported as supported it, with no distinction made between fully and partially implemented SRFIs.

In the future, if there's ever a standard way of reporting SRFI metadata, a distinction between fully and partially implemented SRFIs could be reported by Scheme implementations and/or their package managers. Only at that point would it make sense for this project to report whether a SRFI is fully or partially implemented, but until that data is available it doesn't..

[lassik]

@diamond-lizard Agreed completely!