On 2021-05-01 20:31, John Cowan wrote: > On Sat, May 1, 2021 at 12:44 PM Amirouche Boubekki > <xxxxxx@gmail.com> wrote: > >>> then individual implementations >>> can try different approaches to things like threads, and if a >> consensus >>> emerges among them, then that consensus can be written up in RnRS. > > SRFI 18 actually does that. It is over-complex and I would like to > have a SRFI providing a smaller subset, supplemented by a gochan or > CML built on top. I have something that looks like CML on an API similar to SRFI-18. It mixed with network io, I guess you do not want that network io? > >> RDF is an ivory tower of highly >> educated PhDs [0]. > > Well, and me. I have no degrees, and call myself an ontological > engineer rather than an ontologist. What is the difference between ontological engineer and ontologist? Also I did not know you were involved with RDF. >> Regarding "initial education", except maybe scratch visual >> programming >> language, without picking a particular Scheme, R7RS is in a better >> position than any other programming language that I know. > > Remember that MIT ditched Scheme in favor of Python precisely because > professional programming today is mostly gluing things together. A > friend of mine once said that programming in Scheme is like building a > ship in a bottle: you have to do everything from scratch except making > the tiny little parts. Next time the WG title should less subtle along the line: a language ready to ship CRUD webapps >> Speaking of R5RS, I was going to suggest R7RS-micro without the >> library system. > > Well, it is conformant to provide only (scheme base), which makes all > the library support unnecessary. Someone should write a demo version > of R7RS-small like that. I need something like that, except since my target is JavaScript, so far string will be immutable, also I will only document primitives (things that can not be computed otherwise), and other stuff. >> If R8RS gives up on portability, what will be the point of R8RS >> then? > > See Clinger's paper "R7RS Considered Unifier of Previous Standards". > His view (which I did not foresee but with which I agree) is that R6RS > focused on portability, R7RS-small on interoperability. Ok, I think I know, but maybe I do not know the difference. Interoperability is re-using libraries, not necessarily running the same program on another Scheme? > >> It seems to me there is no agreement on >> whether threads are cooperative, or can be pre-empted, and whether >> they run truly in parallel (different CPU cores) or not, and how to >> communicate with the threads. Even if I was / am die-hard Chez user, >> I >> do not know whether threads are necessary in the standard. > > If they are used for concurrency rather than parallelism, I think none > of these things matter. Parallelism needs a separate API; I have a > pre-SRFI based on "eager promises" that execute right away but may be > suspended by the implementation whenever anything "too hard" is > attempted. This is based on Racket. > >> Again side note unrelated to the core of the topic: There is >> existing >> work. It is possible to create DSL to interop with the host, and >> fine >> tune the details, until it is good to be standardized. I am not >> suggesting I will do the work, just that there is a way to make >> progress on the subject. > > The problem is in how you do the glue: in weird-looking Scheme that > provides what C expects, or in weird-looking C that provides what the > Scheme implementation expects. That's a distinction I see no way to > bridge. We also need a standard groveler like the one for CL's CFFI. Maybe I will need to look into that. -- Amirouche ~ https://hyper.dev
