> There is something we can take inspiration from called ECMA Script > compatibility table: > > https://kangax.github.io/compat-table/es6/#test-proper_tail_calls_(tail_call_optimisation) > > Talking about JavaScript, there is also https://caniuse.com/ > > I find the user experience of latter very great. Both those sites are impressive! I had never heard of them before. Tables like that are indeed very useful. caniuse.com also has very pleasing design IMHO. This is the kind of thing I had in mind when I sent those weird emails about originality. That site works very intuitively, but it looks unique (at least based on the sites I've seen). I immediately understood how to use the compatibility chart even though it's complicated and I've never used anything like it before. It would be awesome if we could offer a similar experience for Scheme - a site that looks and feels unique but is still intuitive. It's a challenge, but fun, and those are the sites that people remember. To start with, we quite a unique opportunity to do some novel things with hyperlinking, because Scheme is heavily based around different implementations and SRFIs instead of a central core. I'm confident that we can create a uniquely compelling site that will make quite Scheme easy to understand by linking and combining information in creative ways, and using design (colors, typography, layout) to call attention to the right things. This would also be real a challenge to anyone interested in graphic design or information design. I have this intuition that Scheme is a compact yet versatile language, even with all the different implementations (whereas e.g. Common Lisp is not compact - its advantages are in other things). We need to find a presentational metaphor to convey the feeling that we have of Scheme's nature. It can be done by organizing and presenting information the right way - those are very powerful tools, and the web is a powerful enough medium. If we succeed, I think many people will "get" Scheme faster. > I made a list of some "metadata" I would like to use attached to this email. I missed this mail earlier, but I like detail of that metadata a lot :) That's exactly the kind of data I've been wanting to gather too. I enjoy how we have thorough, diligent people in this community. I'm used to people hacking together something that works, but in Scheme people gather a lot of data, do big surveys, write detailed specs, etc. - putting in effort not only to do things, but to do them right. It's very rewarding because that's where longevity comes from. We talked about establishing a standard round-trip compatible JSON <-> S-expression mapping with Arthur and John. This will make it easy to programmatically translate any JSON data to S-expressions or vice versa, whenever needed, without losing information. John says there is already some kind of de facto standard emerging among the existing Scheme JSON libraries; we just need to write a spec based on it. Once that spec is done (should be soon because there don't seem to be any controversial or difficult decisions) I can translate the .scm files in our implementation-metadata repo so they are compatible with that spec (but still keep them as S-expression files in our repo, not JSON). The current "schema" is not all that well thought out so it should be re-designed anyway. Anyway, feel free to add new metadata to the .scm files already if you want to :) I parse those files, but the parser won't break from adding new things. Once we have designed a better schema, then we can coordinate to change the .scm files and our parsers to use it.
