Re: Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Panicz Maciej Godek <address@hidden> writes:

> Hi,
> while I have nothing to say regarding the details of your SRFI, I find
> some of your motivations questionable, and therefore I decided to
> write this reply. Forgive the somewhat "negative" tone of this e-mail,
> despite my intentions being positive.

Hi, no problem at all, just speak your mind.

>     I've made pretty fine experiences with R7RS-small so far[0][1][2]
>     [3], and after seeing people's disdain towards R7RS-large's
>     direction and agreeing with them (although I wouldn't trust my own
>     judgment alone), I've decided to try pushing R7RS-large in a
>     somewhat better direction.
>
> It is unclear to me what do you mean by "better direction", and in
> particular, how do you judge which direction is better or worse

Even more broadly than the summaries I already gave, I could say: I
would like us to reach a state where one can think "I need to write
application X?  Let's do it in Scheme since it's such a neat language,"
and then proceed to install standard Scheme libraries A, B, and C into
my system either with the distro's package manager or a Scheme package
manager (written in standard Scheme, working with my favorite
implementation), proceed to write my application in standard Scheme
using those libraries, and have this application X using libraries A, B,
and C work across Guile, Racket, Chicken, Gauche, Kawa, and what have
you, without having to change a single line of code.

Application X could be anything from a network service to a video game.
Whatever I can do in Perl, Python, shell, Java, etc., and even most
things I could do in C/C++, I should be able to do in standard Scheme.

That's the Grand Dream, but I don't even think it's *that* far away:

Many mature Scheme implementations can do those things in one or another
non-portable way, although they lack a big pool of utility libraries to
help.

In our example we might find ourselves missing libraries A and C, *even*
if we specifically choose Guile instead of standard Scheme.  That's a
big losing point against something like Python or Java.

Now if it were possible to write said pool of utility libraries in a
portable way, thanks to the standards unifying all *fundamental*
features needed to do so under unified APIs (i.e. things you can't
implement as a library in terms of more primitive features, like
sockets, multithreading, filesystem commands, etc.), then it would be
plausible to have the larger Scheme community start producing such a
pool of utility libraries, and then we're done really.

I find it daunting that it took us 106 whopping SRFIs to reach a *basic*
socket API!  Scheme could have been taking over the world by now. :-)

And as amazing as it would be if that huge pool of libraries existed
specifically as Guile modules, I'm not sure if it's realistic.

Now to bring that back to R7RS, what we have is *still* lacking a basic
hash table API that all implementations can agree on, and certain people
go and work on things like SRFI-114 (needless), SRFI-113 (can be utility
library), SRFI-116 (really?), SRFI-117 (can be utility library),
SRFI-124 (just support weak hash tables instead), and so on.  (By the
way, I like John Cowan as a person very much; whenever I write him a
critique, he responds by genuinely encouraging me to work on
counter-proposals and such so that in the end the community can decide
what they want.  All the mentioned SRFIs won't become part of R7RS-large
if the votes decide they shouldn't.)

That was a huge chunk of text, so I'll try to keep the rest of the mail
very terse.  Don't be irritated by the terseness of the sentences.

>     The benefit for Guile? I shortly summed up my thoughts on that in
>     the FOSDEM thread on the Guix ML; here the mail from the archives:
>     http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00759.html
>
> You wrote there, among others, that "with a little more work, standard
> Scheme might actually become a language essentially as usable as
> Python and the like".
>
> If you're looking for a language that is "as usable as Python", then
> I'd recommend trying out Python, which is very good at what it does.
>
> Maybe I'm reading your point wrong, but I don't think that competing
> with Python or chasing Python or trying to mimic Python would be
> anything but a waste of time

Python lacks many of Scheme's greatest features.

>     Perhaps a better summary: better Scheme standards -> more
>     libraries that work on any implementation -> more total Scheme
>     users & more free-flow of users between implementations -> more
>     potential for growth of the Guile community.
>
> I don't think that the flow of users between the implementations is
> the major concern of the Scheme community, and I also haven't got a
> clue how one can tell what the phrase "better Scheme standards" means.
> "Better" by which standards?

By the above explained standards.  Maybe the pool of libraries is more
important than flow of users, but still, if a Racket user can install
Guile and immediately feel somewhat at home because all standard Scheme
parts are still there, that could gain us a lot.

> Actually, I think that if you really wanted to unite communities
> around various Scheme implementations, you'd need to do that through
> dialogue rather than standardizations -- because apparently the
> diversity between various implementations exists for a reason, as
> probably those communities worship different values

A good standard can be in line with lots of different values I think.
And the (lack of) standardization currently works as a "wall" that makes
the flow of users simply nigh impossible (have to rewrite most of one's
code for to work on another implementation), so a good standard would
mean abolishing that wall, even if people won't immediately want to
cross the now open boundaries.  It abolishes a fundamental limitation.

>     The envisioned direction for R7RS-large? I'll try writing specs
>     which could have been part of the clean R7RS-small, or could be
>     part of an R8RS that would be more in the vein of R6RS (without
>     some key bad parts), that is: not being overly minimalist, not
>     catering to obscure implementations that are barely maintained and
>     used, being more daring in requesting modern and advanced features
>     from implementations that want to be compliant.
>
> To me, minimalism is at the very heart of Scheme, and any departure
> from it will sooner or later turn out to be harmful. I think that
> putting hash tables into the language is a particularly good example
> of something that goes against the spirit of Scheme.

What should I do when I want constant-time key-value lookup?  If my
application needs that, ouch, back to lesser language X.

> What I believe would go along the spirit of Scheme is that in certain
> circumstances, an assoc list could be optimized to a hash table,
> because a hash table is essentially an optimized implementation of
> key-value lookup

If I can't *rely* on the constant-time factor, that's useless.  If it's
reliable, then you specified something effectively equivalent to a hash
table API.

>     Not like R7RS-large's apparent current direction[4][5][6][7][8],
>     i.e.: specifying a ton of questionable libraries that seem to fill
>     imaginary gaps, invite design bugs through the inclusion of
>     spurious utility forms, and overall seem more suitable to live as
>     third-party libraries, because they can be implemented as such
>     without needing support for additional fundamental features from
>     Scheme implementations. All the while said fundamental features
>     are neglected from standardization because X and Y minimalist
>     implementation of Scheme won't be able to support them.
>
> Which "said fundamental features" do you mean?

Hash tables, weak references, sockets, threading, regular expressions,
record type subtyping, procedural macros, delimited continuations, etc.

Those are fundamental language features.  Either you have them, or you
don't; they can't be implemented in terms of more primitive features.
The *lack* of these lead to "the weaknesses and restrictions that make
additional features appear necessary" in Clinger's words, as I see it.
For each and every one of them, if the language lacks the feature, then
either you're excluded from implementing a whole group of utility
libraries that would have been possible in terms of that feature, or you
specify each and every one of those utility libraries as a separate
built-in API, piling utility library on top of utility library in the
standard.  (A bit like where R7RS-large seems headed maybe?)

>     Does that make sense? Feel free to add to this high-level
>     description of the desired direction, even if it seems vague. I'm
>     trying to sum up the sentiment of others, so don't see the above
>     as my personal opinion.
>
> I think it would be much more worthwhile to create stunning
> applications (especially the ones that would make use of the Scheme's
> particular traits), rather than constantly improving the language
> which is already good enough.

Lacking hash tables, sockets, threading, regular expressions, and record
type subtyping, is *not* good enough. :-) It's, I dunno, 1970 maybe?
It's literally impossible to create most applications with standard
Scheme's feature-set, let alone particularly stunning ones.

> The issue of library interoperability between implementations should
> be solved only if it really turns out to be an actual problem.

It's an actual problem if a Guile user can't use any Scheme library that
wasn't written with Guile in mind.  At the *very* very least, the user
will need to add define-module boilerplate; in practice she or he will
probably need to do a lot more.

Taylan