From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.user,gmane.lisp.guile.devel Subject: Re: Request for feedback on SRFI-126 Date: Mon, 28 Sep 2015 01:20:04 +0200 Message-ID: References: <87zj08t5w1.fsf@T420.taylan> <87vbavtyfz.fsf@T420.taylan> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01227ec42411c60520c2d281 X-Trace: ger.gmane.org 1443396036 8236 80.91.229.3 (27 Sep 2015 23:20:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Sep 2015 23:20:36 +0000 (UTC) Cc: "guile-user@gnu.org" , guile-devel To: =?UTF-8?B?VGF5bGFuIFVscmljaCBCYXnEsXJsxLEvS2FtbWVy?= Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Sep 28 01:20:31 2015 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZgLF7-0000On-4O for guile-user@m.gmane.org; Mon, 28 Sep 2015 01:20:29 +0200 Original-Received: from localhost ([::1]:59357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgLF6-00064G-OU for guile-user@m.gmane.org; Sun, 27 Sep 2015 19:20:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32826) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgLEn-0005w3-NZ for guile-user@gnu.org; Sun, 27 Sep 2015 19:20:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZgLEk-0001Th-48 for guile-user@gnu.org; Sun, 27 Sep 2015 19:20:09 -0400 Original-Received: from mail-wi0-x22f.google.com ([2a00:1450:400c:c05::22f]:37885) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZgLEj-0001OO-NN; Sun, 27 Sep 2015 19:20:06 -0400 Original-Received: by wicfx3 with SMTP id fx3so78916450wic.0; Sun, 27 Sep 2015 16:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kd3QCBxIYh1grcBy85PhQ9MPARIAx1HisPqDDlPB4G8=; b=WOTyphMb6Mm0EkGn+BZx6Ej+32ZaRWdzi9R91dJWdAuAz6BHACDPWh5fiPpmVy4HwS vX7UmyPcNTPnyVnBg4PY0V+GYTsQ9jTLfApD/io3iaLnwcbM1XIwAIcx1zTPlARUKMzC fAVYYnF/BrarYT47rw/rm5U0u981IbEn7eVXvyqIwn/OlQvbNi1OD5wTdV1J2cu2uvqh lcLCenYXXp1EWv4MbsQBvFupJb61DRXpnurRl+LDaBDrQuewTyXM9r5AJBAypL6FrgB4 xG6srMMzFZP9/kWZTp6szquH8yikxENKixP/RTbCW92QUNe1/HcgTUmRHv868GYsnVAW np5A== X-Received: by 10.194.121.232 with SMTP id ln8mr21950196wjb.76.1443396004874; Sun, 27 Sep 2015 16:20:04 -0700 (PDT) Original-Received: by 10.194.34.35 with HTTP; Sun, 27 Sep 2015 16:20:04 -0700 (PDT) In-Reply-To: <87vbavtyfz.fsf@T420.taylan> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22f X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12044 gmane.lisp.guile.devel:17865 Archived-At: --089e01227ec42411c60520c2d281 Content-Type: text/plain; charset=UTF-8 > > > > 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. > Maybe you should explain why there are so many implementations of Scheme in the first place? (That isn't the case for Python, Java or Perl) 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: > > Had I such a "Grand Dream", I'd go with Python, because they already have that. Scheme has very different traits, and very different purpose. The position of Python stems from its particular notion of elegance, which -- although isn't as extreme as Scheme's -- is easier to grasp to the masses. This especially regards syntax. Python has a very intuitive syntax for its basic notions (including dictionaries). Lisp has "all those hairy parentheses", which apparently very few people can appreciate, although they help to work with the code greatly, allowing to see beyond language's limitations. 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. :-) > > Not sure what you mean by "taking over the world". That there will be many people using it? There won't. That there will be important systems based on it? Don't think so. Scheme's power to change the world doesn't stem from standardized APIs, but (hopefully) from SICP and the way it affects thinking about computer systems. 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. > Somehow I can't get amazed with that vision. The best thing that Scheme does for programming is that it promotes writing software that can be read, and not only executed. What you claim to be essential here seems to be a rather minor detail from that point of view. 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. > Quite the contrary, I am grateful. > 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. > > The advantage of which rarely manifests in everyday practice, especially if you're not used to working with s-expressions (most programmers I know haven't got a clue what those are). I recommend that you read this: http://norvig.com/python-lisp.html > 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. > > I sometimes use Racket to teach people to program in Scheme. That's because it's cross-platform and comes with a GUI that anyone can comprehend quickly. It is terribly inconvinient compared to emacs, but most people are unable to get through the basics of emacs. And here's where the revolution stops. 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. > I shouldn't think so. I was once porting a fairly advanced Guile application to Chicken and Gambit, and although there were some issues with macros, the overall process wasn't particularly painful. (OTOH I admit that the app didn't use many guile-specific features, which made that much easier) > > 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. > Or provide guarantees for certain kinds of optimizations. > 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. > Sure. The only difference is the cognitive overhead. If you could use plain "cons" for constructing hash tables and vectors, that would be a big win, because you would remove another weakness and restriction that makes this additional feature of yours necessary. > > 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. > > Hash tables, weak references and threading are just implementation details that a programmer usually shouldn't care about. Delimited continuations are an academic curiosity, and sockets and regexps are just a specific domain (I'm sure you could easily find plenty of others; anyway, they are by no means fundamental) > Those are fundamental language features. Either you have them, or you > don't; they can't be implemented in terms of more primitive features. > You can surely implement threads using call/cc, or even delimited continuations. You can implement hash tables and weak references (and anything you please) using vectors. You can implement regular expressions using... uhm, recursive functions. Sure, this isn't what you meant, because you meant native support on a target system, and not just a lousy emulation layer. But it only means that those are not "language features", but "systems features". Not every system provides sockets (my pen&pencil certainly doesn't, and although it can easily use multiple threads to evaluate s-expressions, it surely doesn't need threads as first-class objects) 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. > > Then create them with extended Scheme's feature set of your liking. Or is there anything that stops you from doing that? Like the fact that the name of the language that you use isn't Scheme, but Racket, Bigloo or Guile? Or the fact that there is no pdf out there on the web whose naming scheme is R*RS, that would describe the language that you use? > 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. > Somehow to me it has never been a problem. What has been the actual problem is the multiplicity of ways that things can be expressed in any Scheme implementation (like the fact that Scheme provides both lists and vectors as collections, and that some implementations also provide multi-dimensional arrays) --089e01227ec42411c60520c2d281 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>=C2=A0 =C2=A0 =C2=A0I've made pretty fine experiences with R7RS-sma= ll so far[0][1][2]
>=C2=A0 =C2=A0 =C2=A0[3], and after seeing people's disdain towards = R7RS-large's
>=C2=A0 =C2=A0 =C2=A0direction and agreeing with them (although I wouldn= 't trust my own
>=C2=A0 =C2=A0 =C2=A0judgment alone), I've decided to try pushing R7= RS-large in a
>=C2=A0 =C2=A0 =C2=A0somewhat 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<= br> would like us to reach a state where one can think "I need to write application X?=C2=A0 Let's do it in Scheme since it's such a neat l= anguage,"
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<= br> 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.
<= br>
Maybe you should explain why there are so many implementation= s of Scheme in the first place? (That isn't the case for Python, Java o= r Perl)

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:


Had I such a "Grand Dream", = I'd go with Python, because they already have that.
Scheme ha= s very different traits, and very different purpose. The position of Python= stems from its particular notion of elegance, which -- although isn't = as extreme as Scheme's -- is easier to grasp to the masses. This especi= ally regards syntax. Python has a very intuitive syntax for its basic notio= ns (including dictionaries). Lisp has "all those hairy parentheses&quo= t;, which apparently very few people can appreciate, although they help to = work with the code greatly, allowing to see beyond language's limitatio= ns.

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.=C2=A0 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!=C2=A0 Scheme could have been taking over the world by now. :-)<= br>

Not sure what you mean by "taking= over the world". That there will be many people using it? There won&#= 39;t. That there will be important systems based on it? Don't think so.=
Scheme's power to change the world doesn't stem from sta= ndardized APIs, but (hopefully) from SICP and the way it affects thinking a= bout computer systems.

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.
<= /blockquote>

Somehow I can't get amazed with that vi= sion.
The best thing that Scheme does for programming is that it = promotes writing software that can be read, and not only executed. What you= claim to be essential here seems to be a rather minor detail from that poi= nt of view.

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

Quite the contrary, I am grateful.

> Maybe I'm reading your point wrong, but I don't think that com= peting
> 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.


The advantage = of which rarely manifests in everyday practice, especially if you're no= t used to working with s-expressions (most programmers I know haven't g= ot a clue what those are).
I recommend that you read this:
<= div>http://norvig.com/python= -lisp.html

>=C2=A0 =C2=A0 =C2=A0Perhaps a better summary: better Scheme standards -= > more
>=C2=A0 =C2=A0 =C2=A0libraries that work on any implementation -> mor= e total Scheme
>=C2=A0 =C2=A0 =C2=A0users & more free-flow of users between impleme= ntations -> more
>=C2=A0 =C2=A0 =C2=A0potential for growth of the Guile community.
>
> I don't think that the flow of users between the implementations i= s
> 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&qu= ot; means.
> "Better" by which standards?

By the above explained standards.=C2=A0 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.


I sometimes us= e Racket to teach people to program in Scheme. That's because it's = cross-platform and comes with a GUI that anyone can comprehend quickly. It = is terribly inconvinient compared to emacs, but most people are unable to g= et through the basics of emacs. And here's where the revolution stops.<= /div>

A good standard can be in line with lo= ts of different values I think.
And the (lack of) standardization currently works as a "wall" tha= t 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.=C2=A0 It abolishes a fundamental limitation.=

I shouldn'= t think so. I was once porting a fairly advanced Guile application to Chick= en and Gambit, and although there were some issues with macros, the overall= process wasn't particularly painful. (OTOH I admit that the app didn&#= 39;t use many guile-specific features, which made that much easier)
=C2=A0
>=C2=A0 =C2=A0 =C2=A0The envisioned direction for R7RS-large? I'll t= ry writing specs
>=C2=A0 =C2=A0 =C2=A0which could have been part of the clean R7RS-small,= or could be
>=C2=A0 =C2=A0 =C2=A0part of an R8RS that would be more in the vein of R= 6RS (without
>=C2=A0 =C2=A0 =C2=A0some key bad parts), that is: not being overly mini= malist, not
>=C2=A0 =C2=A0 =C2=A0catering to obscure implementations that are barely= maintained and
>=C2=A0 =C2=A0 =C2=A0used, being more daring in requesting modern and ad= vanced features
>=C2=A0 =C2=A0 =C2=A0from 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?=C2=A0 I= f my
application needs that, ouch, back to lesser language X.

Or provide guarantees for certain kinds of optimizations.=

> What I believe would go along the spirit of Scheme is that in certain<= br> > 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 useles= s.=C2=A0 If it's
reliable, then you specified something effectively equivalent to a hash
table API.

Sure. The only difference is= the cognitive overhead. If you could use plain "cons" for constr= ucting hash tables and vectors, that would be a big win, because you would = remove another weakness and restriction that makes this additional feature = of yours necessary.
=C2=A0
>=C2=A0 =C2=A0 =C2=A0Not like R7RS-large's apparent current directio= n[4][5][6][7][8],
>=C2=A0 =C2=A0 =C2=A0i.e.: specifying a ton of questionable libraries th= at seem to fill
>=C2=A0 =C2=A0 =C2=A0imaginary gaps, invite design bugs through the incl= usion of
>=C2=A0 =C2=A0 =C2=A0spurious utility forms, and overall seem more suita= ble to live as
>=C2=A0 =C2=A0 =C2=A0third-party libraries, because they can be implemen= ted as such
>=C2=A0 =C2=A0 =C2=A0without needing support for additional fundamental = features from
>=C2=A0 =C2=A0 =C2=A0Scheme implementations. All the while said fundamen= tal features
>=C2=A0 =C2=A0 =C2=A0are neglected from standardization because X and Y = minimalist
>=C2=A0 =C2=A0 =C2=A0implementation of Scheme won't be able to suppo= rt them.
>
> Which "said fundamental features" do you mean?

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


Hash tables, weak references and threa= ding are just implementation details that a programmer usually shouldn'= t care about. Delimited continuations are an academic curiosity, and socket= s and regexps are just a specific domain (I'm sure you could easily fin= d plenty of others; anyway, they are by no means fundamental)
=C2= =A0
Those are fundamental language features.=C2=A0 Either you have them, or you=
don't; they can't be implemented in terms of more primitive feature= s.

You can surely implement threads usi= ng call/cc, or even delimited continuations. You can implement hash tables = and weak references (and anything you please) using vectors. You can implem= ent regular expressions using... uhm, recursive functions.
Sure, = this isn't what you meant, because you meant native support on a target= system, and not just a lousy emulation layer. But it only means that those= are not "language features", but "systems features".
Not every system provides sockets (my pen&pencil certainly doe= sn't, and although it can easily use multiple threads to evaluate s-exp= ressions, it surely doesn't need threads as first-class objects)
<= div>
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.=C2=A0 (A bit like where R7RS-large seems headed maybe?)

>=C2=A0 =C2=A0 =C2=A0Does that make sense? Feel free to add to this high= -level
>=C2=A0 =C2=A0 =C2=A0description of the desired direction, even if it se= ems vague. I'm
>=C2=A0 =C2=A0 =C2=A0trying to sum up the sentiment of others, so don= 9;t see the above
>=C2=A0 =C2=A0 =C2=A0as 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= 9;s
> particular traits), rather than constantly improving the language
> which is already good enough.

Lacking hash tables, sockets, threading, regular expressions, and re= cord
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.


Then create th= em with extended Scheme's feature set of your liking. Or is there anyth= ing that stops you from doing that? Like the fact that the name of the lang= uage that you use isn't Scheme, but Racket, Bigloo or Guile? Or the fac= t that there is no pdf out there on the web whose naming scheme is R*RS, th= at would describe the language that you use?

> 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.=C2=A0 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.

Somehow= to me it has never been a problem.
What has been the actual prob= lem is the multiplicity of ways that things can be expressed in any Scheme = implementation (like the fact that Scheme provides both lists and vectors a= s collections, and that some implementations also provide multi-dimensional= arrays)

--089e01227ec42411c60520c2d281--