Do we need descriptions of relationship in the metadata , let us say for SRFI 13 and SRFI 135?

[APIPLM]

One question as well, do we have like descriptions of relationship in the metadata like SRFI 13 and SRFI 135. I just saw like see-also in the file data/srfi-data. For search ability, for one SRFI it is much better for user to review the related SRFIs, and how can it be displayed, that is the other story.

[jpellegrini]

Yes. We already show when a SRFI is withdrawn and when it's superseded. "related" would be nice too.

There is a lot more that could be displayed, but we need to be careful how to do that, so as to not put so much data that it becomes confusing.
One thing that I think would be important is to include data about conflicting SRFIs, or SRFIs conflicting with standards (example: SRFI 43 conflicts with R7RS small)

[lassik]

Good ideas all!

If there's too much info, maybe put some info into a pop-up that is shown when the mouse goes over a SRFI number?

[APIPLM]

I more like the relationship of their related SRFIs. conflicting of SRFIs probably are needed to more attentions for the implementator of those conflicting SRFIs. And also it is much effective for implementators to work on one particular SRFI before he know and learn related to SRFIs. Like email and talk with the people , who used to work on these related SRFIs. After all parallel work model are better than the traditional waterfall work model.

[lassik]

Maybe we should have another view where the screen is split into a left and right half.

• The left half of the screen shows a table or list of SRFIs, with number and title. Click to select a SRFI.
• The right half of the screen shows detailed info about the selected SRFI.

[APIPLM]

Yeah. That is a popular one for most metadata project. The left half is the object node , for our case is the SRFIs, and the right side has the different view of the selected object node. But most of them has a framework to work with. For our case, not like complex enough to do that.

[lassik]

Maybe the right side can be a <div> and the left side uses a little JavaScript to change which SRFI is shown on the right side?

[APIPLM]

Not sure. But if need to show more information for one SRFIs, that right side sound like need a form.

[APIPLM]

Personally, I prefer that matrix way to view it, even it does not looks like good as the number of SRFIs increase. But it still is in the build phase. One more thing is I would have one matrix, row is the SRFI , column is the SRFI as well. So that we can the relationship between two SRFIs. And also have more keywords to find the related SRFIs by setting up in the filter in the homepage. The most important is that how those keywords can be built out, and the search result of these related SRFIs are more valuable from SRFI designer and implementor view.

[lassik]

@APIPLM Those are good ideas. Do you know HTML/JavaScript, and would you like to experiment with how the pages would look?

[APIPLM]

@lassik. I can try to do that, and find the kind of same project, and show how it look like. I mean that the homepage is fine. and it just need a little bit of refine or polish for related SRFIs search. Of course I have not know how much program structure of the current homepage.

[APIPLM]

One more thing, I just came to the webpage https://srfi.schemers.org/. The search panel does not show up in my Android phone. In the laptop, it shows up, and can work out. In the webpage, there is not any place to open issues. That is why I mentioned here. If you find the right site to open this issue, feel freely to forward there.

[lassik]

Good catch! Please email Arthur at srfi-editors at srfi dot schemers dot org about the srfi.schemers.org website. He is friendly and likes to hear suggestions and bug reports for the site.

[APIPLM]

Done. I have sent email to him. And let us to see how much we can do with this issue.

[APIPLM]

I got the notification email, which is that I am not in the email list and the email is hold, need to be approved. So if you have your way to reach him, could you mention there is an email about the issue, which is the search panel does not show up in the homepage in the Android phone.

[lassik]

srfi-editors@ should not be a mailing list. Did you accidentally send to srfi-discuss@ instead?

[lassik]

srfi at speechcode.com is another address to try.

[APIPLM]

A message that you sent to [email protected] with the subject
The search panel does not show up in my Android phone.
is being held for approval because your email address is not
permitted to send to the list.

The list owner has been notified and may approve your message.

I forwarded the email to srfi at speechcode.com. Maybe it is about my email account issue.

[lassik]

Ah, that's weird. Maybe srfi-editors is set up like a mailing list. Hopefully speechcode works.

[APIPLM]

Sound like Arthur have fixed the issue, as I checked it back again. Now it works in my phone. it is so quickly.

Technically the page already have the capability to filter by the second option. which is that related to SRFIs. But I have a few comments in the current homepage.

1. The status of SRFIs in the table already show up by the color of item SRFI. No need to put this filter in the first option. In the last option is okay?
2. Sort button could be put later. It like we search and filter, and then sort the result of the search. The default sort in search result page would be the date of the status final SRFIs.
3. The default value of "Search for" in the form, more meaningful like number or description.

Then I will explore more how the relationship name will show up in the filter.

[arthurgleckler]

@APIPLM I haven't made any changes, so something else fixed your phone's access. Perhaps your phone had trouble reaching one of the necessary URLs.

Also, I approved your message to srfi-editors. Any subscriber to an SRFI list can send to it without approval, but messages from unknown senders are held for my review. That is how I keep spammers away. It makes a huge difference.

About related SRFIs, those are shown in the See-also links. I don't collect metadata specifying what relationship each See-also link represents, but it's usually a quick matter to determine that once you click on the link.

[APIPLM]

@arthurgleckler Thank for your reply. When I firstly came to the homepage on my phone, the search panel did not show up. Then after three hours, I thought that it might have an issue in my site.Then charged the battery for my second phone, and checked it. it works. Then came back the first phone to check, it works as well. Sound like there was a network traffic in my site to reach one of the necessary URIs inside the homepage.

Yes. you are right. the See-also links show up the related to the linker of SRFIs in the search result table. The current metadata file srfi-data.scm does not have the specific relationship for related SRFIs. But as we discussed in this issue, and we thought that we have a try to find out a way to add the relationship name or description in the metadata file srfi-data.scm, as well setup in the second option (Relationship name or description ) in the filter for search. That is what we mean to be. That is why I came to you ,and have a look for this issue.

[arthurgleckler]

If you'd like to collect the information necessary in the srfi-data.scm file, I'd be happy to accept a pull request and then look into ways of presenting the information.

[APIPLM]

Yes. Appreciate how you see this issue. Collecting the relationship description of these related SRFIs to the file srfi-data.scm should be done firstly. The below is the initial table look like for the feature pattern-matching.

For instance, SRFI-2 is composed into SRFIs-202 in the feature pattern-matching, that is how can build up the relationship.
The table will be sent to the authors of the related SRFIs to review and approve as well. The main benefit is that the authors of these related SRFIs like in the one page to view their own SRFIs. Basically the idea make the collaboration happen in the certain level. Also have the visualization in search result table in the homepage. What do you think? @lassik . That is my initial thought.
Of course we need to more way to look up the relationship name and descriptions as well. Not only feature point view to see the relationship of these related SRFIs. Like in Scheme different forms built view to see the relationship.

[APIPLM]

@arthurgleckler About related SRFIs, those are shown in the See-also links. and that is fine. As I studied the srfi-158 and srfi-121, and the srfi-121 is superseded by the srfi-158, there is no description about the reason. And also I checked them is in the one of the implementation chicken. Both of them are available as well. If the implementation have not completely understood the reason of the superseded SRFI. it is not easy for them replace the old one SRFI for their implementation. The author of the srfi for superseded SRFI should clearly declare the reason. Let us say, someone will port this feature to his implementation. Which one should be? The old one or new one. How can they make the decision? So it is much better for them know how the srfi they chose is evolved. That is also the reason I request the relationship between two related SRFIs.

[arthurgleckler]

On Sat, Jul 3, 2021 at 3:08 AM APIPLM ***@***.***> wrote: @arthurgleckler <https://github.com/arthurgleckler> About related SRFIs, those are shown in the See-also links. and that is fine. As I studied the srfi-158 and srfi-121, and the srfi-121 is superseded by the srfi-158, there is no description about the reason. And also I checked them is in the one of the implementation chicken. Both of them are available as well. If the implementation have not completely understood the reason of the superseded SRFI. it is not easy for them replace the old one SRFI for their implementation. The author of the srfi for superseded SRFI should clearly declare the reason. Let us say, someone will port this feature to his implementation. Which one should be? The old one or new one. How can they make the decision? So it is much better for them know how the srfi they chose is evolved. That is also the reason I request the relationship between two related SRFIs.

The Rationale section of SRFI 158 explains: This SRFI differs from SRFI 121 by restoring the generator constructor circular-generator and the generator operations gflatten, ggroup, gmerge, gmap, gstate-filter, and generator-map->list from gauche.generator. It also adds the definition of accumulators and some accumulator constructors.

[APIPLM]

Thanks.That is my fault. When I came back again to see both of them (SRFI-158 and SRFI-121). All of content are kind of the same except what they mentioned in the rationale section restoring the generator constructor circular-generator and the generator operations gflatten, ggroup, gmerge,gmap, gstate-filter, and generator-map->list from gauche.generator. It also adds the definition of accumulators and some accumulator constructors

One of the reason for them to have separate the SRFI-158 is that they mentioned in the message. This seems also better for the R7RS-large process because it allows more easily individual votes on replacing the generators of SRFI 121 by SRFI 158 and on including accumulators into the large language

My point is that the content of both of them (SRFI-121 SRFI-158) in term of generators functionality are almost same, only add one more generators constructor circular-generator . Of cause, we can not restrict the author of the SRFI to say that you can not have the content of generators functionality in the SRFI-121 document as the same one in the SRFI-158 Generators and Accumulators document because you already have them in the SRFI-121 document. Maybe the authors are the same person. It is the way they like to work out. But what we can do is that have metadata of these documents(SRFI-121 SRFI-158) for this kind of information. Then we can easy to identify what is the purpose for them having two documents (SRFI-121 SRFI-158) for the people porting to them to their scheme implementation.After all duplicated information confuse the reader.

[lassik]

Then we can easy to identify what is the purpose for them having two documents (SRFI-121 SRFI-158) for the people porting to them to their scheme implementation.After all duplicated information confuse the reader.

I think this is a good idea. Comparing related SRFIs.