On 2021-05-01 20:31, John Cowan wrote:
On Sat, May 1, 2021 at 12:44 PM Amirouche Boubekki
<[email protected]> 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
