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