search

schemedoc / srfi-metadata

Import SRFI metadata into the Scheme API
https://docs.scheme.org/srfi/support/
MIT License
10 stars 2 forks source link

Show unsupported and withdrawn SRFIs in the color of withdrawn SRFIs #15

Open diamond-lizard opened 3 years ago

diamond-lizard commented 3 years ago

It would be nice if a SRFI that a particular Scheme implementation did not support happened to be withdrawn, the cell at that location in the SRFI Table was shown in the color of withdrawn SRFIs (currently orange).

This way one would not have to look all the way to the left-most column to see if the SRFI that was unsupported for a particular Scheme implementation was withdrawn or not. One would be able to see it right there in the cell that cross-references the Scheme implementation and the SRFI.

lassik commented 3 years ago

A minor point of note is that a few withdrawn SRFIs can still be quite important: For example, Chicken's condition system is based on the withdrawn SRFI 12. So "withdrawn" does not always mean "ignore and do not use". However, this is quite unusual.

lassik commented 3 years ago

The above minor cases would belong in the "withdrawn" and "supported" categories simultaneously. Currently they are painted in the "supported" color, which seems like exactly right thing to do.

diamond-lizard commented 3 years ago

I'm not suggesting the (withdrawn and supported) SRFI cells change color, just the (withdrawn and unsupported) ones.

Also, I don't intend the colors to imply value judgments or say anything about whether the SRFI in question should or shouldn't be used. Ideally all the colors would be as neutral as possible.

My main goal is consistency, accuracy, and usefulness of the information provided.

lassik commented 3 years ago

There probably isn't a problem with painting withdrawn and unsupported SRFIs in a less prominent color. SRFIs are withdrawn by their authors, which means the authors themselves are saying that their SRFIs are less prominent now. So it's not offensive to them.

The withdrawn and supported ones are still important, but they're already handled well.

lassik commented 3 years ago

It might also make sense to paint the most widely implemented SRFIs in a prominent color. It's pretty uncontroversial which ones are really popular, and should be inoffensive to other authors as far as I can tell.

diamond-lizard commented 3 years ago

It might also make sense to paint the most widely implemented SRFIs in a prominent color. It's pretty uncontroversial which ones are really popular, and should be inoffensive to other authors as far as I can tell.

The problem is, how widely supported is "widely supported"?

If 100% of the Scheme implementations support a SRFI, that's pretty clear that it's widely supported, but what about if 51% do? Or 75%? Where do you draw the line?

Also, it's pretty easy to see just by looking at the table that a bunch of Scheme implementations support a particular SRFI, because you'll see a lot of check marks.

lassik commented 3 years ago

The problem is, how widely supported is "widely supported"?

There is no absolute line - we'd have to do a manual version of the "clustering" done in machine learning in our heads and come up with something reasonable :)

Also, it's pretty easy to see just by looking at the table that a bunch of Scheme implementations support a particular SRFI, because you'll see a lot of check marks.

You're right - it's clear enough already. I was overcomplicating things.

jpellegrini commented 3 years ago

There is no absolute line

The Scheme X-reference at https://practical-scheme.net/wiliki/schemexref.cgi?SRFI uses color brightness for that... But I see it would not work for the table.

But what about including one more column with the number of supporting implementations?

SRFI | support |  Bigloo | Chez |... |
  0  | 19      |  v      | v    |... |
jpellegrini commented 3 years ago

For completeness, a first line, right below the implementations, could tell the number of SRFIs each one supports.

Question is: do we count the unreleased ones?

jpellegrini commented 3 years ago

But what about including one more column with the number of supporting implementations?

And (I know, maybe a little too much) let the user choose to sort by SRFI number or by number of implementations...

lassik commented 3 years ago

But what about including one more column with the number of supporting implementations?

For completeness, a first line, right below the implementations, could tell the number of SRFIs each one supports.

These are good ideas in principle, but would the UI get cluttered if it has several different kinds of numbers, since each SRFI document already has a number which is shown? Would it be enough to have the numbers in tooltips?

do we count the unreleased ones?

IMHO the best policy is to primarily present the situation as it applies to the latest release versions, and any pre-release information is a nice bonus. For production projects, people typically like to use release versions of software since those are guaranteed not to change.

And (I know, maybe a little too much) let the user choose to sort by SRFI number or by number of implementations...

Not too much IMHO. We can find some good default settings for the sorting and filtering so people don't need to change any of them if they don't want to. The srfi.schemers.org front page has sorting filtering, and it's quite unobtrusive.