Request for feedback on SRFI-126

Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Hello Guile folks,

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.

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

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.  Not to mention simply more libraries Guile users can
use, from the pool of standard-Scheme libraries, without needing a Guile
porter and maintainer for every possible Scheme library.

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.

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.

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'm doing my best to bring together good ideas from mature Scheme
implementations like Racket, MIT/GNU Scheme, Gauche, and it goes without
saying Guile.  I shamelessly bother people like Taylor Campbell and Mark
for their input, feeling they have a good sense for API design, get
input from Shiro Kawai (Gauche author) and others on the SRFI MLs (John
Cowan also has pretty good ideas sometimes), bother 'samth' and
'stamourv' on #racket, Jorgen Schäfer ('forcer') on #emacs, and so on,
overall trying to work as an aggregator of good ideas.

I hope that clarifies why/how someone inexperienced like me could be
working on SRFIs/R7RS-large.

***

Now on to SRFI-126.

http://srfi.schemers.org/srfi-126/

First, why?

Short history: there is SRFI-69, and it sadly has a design bug that
makes it unsuitable for Schemes with a moving garbage collector (the "by
pointer identity" hash function is exposed).

Then there is the R6RS hashtables API, which is a good base and indeed
SRFI-126 builds on that, fully backwards compatibly.  Indeed I would
have said "just standardize R6RS hashtables for R7RS" if it weren't for
SRFI-125 popping up and gaining traction.  It was a third incompatible
API, not compatible with either SRFI-69 nor R6RS.  Terrible!

I needed to steal the attention from SRFI-125, so to say, with something
that offers similarly neat features missing in SRFI-69 and R6RS, but
without being terribly incompatible with them.

Since then SRFI-125 received big changes and became SRFI-69 compatible
itself, somehow managing to amend SRFI-69's design bug.  If it also
drops the SRFI-114 dependency and gets a little more polish, we might
actually merge SRFI-125 and SRFI-126, but that hasn't happened yet.

So I would now love to get feedback on the SRFI from the whole Guile
community.  Do you think it's RnRS worthy, specifically could it have
been section "6.10 Hashtables" in R7RS-small?  Would you enjoy being
able to use the library in your Guile programs?

I would especially love hearing the thoughts of the other main Guile
developers, since I only queried Mark so far.  Of course, I know you're
all very busy, and I think I understand the frustrations over the RnRS,
so no problem if you have no time or just don't feel like it.

***

After that?

I will probably work on a delimited continuations SRFI, heavily inspired
by Guile's call-with-prompt, since I find it *immensely* more easy to
grok than shift/reset and prompt/control because those mingle together
the "stack slice" and the "handler" code whereas call-with-prompt
clearly separates them.

I will probably push for syntax-case re-standardization because it's
very powerful and IMO most correctly captures/reifies the notion of
Scheme "identifiers" as separate entities from contextless symbols.

I will probably push for SRFI-99 standardization because it's backwards
compatible with our beloved SRFI-9 and removes other flaws of R6RS
records, while adding the important fundamental feature of subtyping.
Like R6RS it also allows non-hygienic creation of getter/setter
procedures, which seem often desired.  (I wish it also supported R6RS's
"protocol" feature...  While seeming obscure, it has no clean
implementation without being supported as a fundamental feature.)

Let's see where this goes...

I hope I didn't waste your time and am only wasting my own at worst!

Taylan


[0] https://github.com/taylanub/scheme-srfis
[1] https://github.com/taylanub/scheme-bytestructures
[2] https://github.com/larcenists/larceny/tree/master/tools/R6RS
[3] https://github.com/TaylanUB/srfi-123 (code in srfi/ dir)

[4] http://srfi.schemers.org/srfi-114/ "Comparators"
[5] http://srfi.schemers.org/srfi-113/ Sets and bags using "comparators"
[6] http://srfi.schemers.org/srfi-116/ Separate "immutable pair" type
[7] http://srfi.schemers.org/srfi-117/ Queues based on lists
[8] http://srfi.schemers.org/srfi-125/ Hash-tables using "comparators"

Re: Request for feedback on SRFI-126

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 4310 bytes --]

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.


> 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

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


> 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?

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


> 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 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

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?

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.

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

Best regards,
M.

[-- Attachment #2: Type: text/html, Size: 6219 bytes --]

Re: Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Panicz Maciej Godek <godek.maciek@gmail.com> 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

Re: Request for feedback on SRFI-126

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 12400 bytes --]

>
>
> >     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)

[-- Attachment #2: Type: text/html, Size: 17018 bytes --]

Re: Request for feedback on SRFI-126

[Marko Rauhamaa]

Panicz Maciej Godek <godek.maciek@gmail.com>:

> The best thing that Scheme does for programming is that it promotes
> writing software that can be read, and not only executed.

Really? I think the best thing Scheme does for programming is it brings
you closer to God. Seriously, Lisp in general and Scheme in particular
is an intellectual eye-opener — but I wouldn't call it inherently
readable.

Personally, it seems that too many people get too excited with defining
new syntax. It is understandable because it's just so cool, but in
practice, macros should be defined sparingly and locally. Weird macros
can make Scheme code very difficult to read. Instead, one should get
comfortable with the lambda and go wild with it.

> 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)

Assoc lists are not abstract enough to serve as a generic map. Note that
Python and Java pretend to provide abstract maps but require you to
specify hash functions anyway.

Nothing wrong with hash tables. Throw in balanced trees as well.

> 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)

All Linux system calls should be available to Scheme on Linux. Don't
fall in the Java trap. Perl and Python give access to system facilities.
So does Guile (for the most part).

> 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?

True, I develop exclusively with Guile. So far, I've generally been very
happy with their choices.


Marko

Re: Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Panicz Maciej Godek <godek.maciek@gmail.com> writes:

>     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)

Because it's too easy to make a standards-compliant implementation
because the standards ask for too little from compliant implementations.
And/or other reasons; don't really know your intent with the question.

>     [...]
>
>     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.

Python still lacks many of Scheme's greatest features. :-)

> 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.

S-expression syntax, allowing things like Paredit, is one of Scheme's
many virtues over other languages.  So I would like to use Scheme, not
Python.  Currently I can't.  (I can use Guile, but it still misses some
"batteries.")

>     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.

Why not?

> 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.

Why even bother with something like Guile if the only worth of Scheme
were pedagogical?

>     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.

Libraries *are* software.  Currently people *don't* write any of that
"software that can be read" except in small groups.

>     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

I'm wondering more and more why you use Scheme if you think it has no
advantages over Python.

>     > "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.

I was talking about programmers using Racket to write software, not
students using Racket to learn computer science.

>     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)

How many hours did it take, for how many LOC, per implementation?
There's a massive difference between having to spend an amount of time
growing linearly with project size and number of implementations ported
to, and having to spend absolutely no time at all.  Linear time
complexity vs. constant time complexity with a factor of 0. ;-)

>     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.

How can one implement such a miracle cons that constructs a list,
vector, or hash table depending on the programmer's wishes?

Maybe you're thinking of something like PHP's arrays, which are somehow
vectors and hash tables at the same time.  It's pretty terrible...

Scheme does no such muddying of what should be distinct abstract data
types, thankfully.

>     > 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)

"Hash tables" are understood to be a data type providing amortized
constant-time key-value lookup.  Time complexity is part of program
semantics, not implementation.  Weak references change program
semantics.  Threading changes program semantics.  Sockets are
fundamental because you can't implement them as a library.  Regexps
might actually be possible to implement as a portable library, though it
will probably be pretty slow.

These things could not possibly be any more fundamental.

> You can surely implement threads using call/cc, or even delimited
> continuations.

No, you can't.  Your program will run on one core.

> You can implement hash tables and weak references (and
> anything you please) using vectors.

No, you can't.  Hashing requires implementation support.  Weak
references too.

> You can implement regular expressions using... uhm, recursive
> functions.

A regexp implementation in portable Scheme might be better than nothing,
but users of other languages will still be laughing at us though.

>     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.
> [...]

So we are back to square one: anyone who wants to use Scheme for
something real needs to pick a specific implementation, and will not be
able to use any Scheme libraries if they were not written for that
particular implementation.

>     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)

I suspect that the things you use programming languages for differ
greatly from what most programmers use them for.

I don't feel very motivated to continue this discussion since we seem to
see things way too differently.

Taylan

Re: Request for feedback on SRFI-126

[Marko Rauhamaa]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer"):

> So we are back to square one: anyone who wants to use Scheme for
> something real needs to pick a specific implementation,

Which is true for other programming languages as well: C, C++, Python,
..

For me, in practice, C/C++ is gcc, Python is CPython, sh is bash, Scheme
is Guile, and the OS is Linux.


Marko

Re: Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Marko Rauhamaa <marko@pacujo.net> writes:

> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer"):
>
>> So we are back to square one: anyone who wants to use Scheme for
>> something real needs to pick a specific implementation,
>
> Which is true for other programming languages as well: C, C++, Python,
> ..
>
> For me, in practice, C/C++ is gcc, Python is CPython, sh is bash, Scheme
> is Guile, and the OS is Linux.

Unfortunately, Scheme is also Racket, Chicken, Kawa, Gambit, Gauche,
Chibi, and so on.  Racket individually has considerable power so they
would benefit the least from this, but a bridge between the user-bases
of the others would probably have significant benefits to all of them.
(And I suppose Racket would eventually support such an RnRS too; why not
if they support even ALGOL.)

Knowing that one doesn't have to choose and stick to an implementation
would also make Scheme as a whole more attractive.  Many people first
hear of just "Scheme" and not immediately "Guile," then they see that
one can't do anything serious with "Scheme" (standard), and the image
stains every Scheme implementation.

Guile could make a bold move like Racket and say that it's not Scheme
anymore, not caring about further RnRS at all, but I'm not sure if it
would be a good move with Guile's current stand-alone popularity.

(I hope that doesn't sound negative.  Of course I'd *love* Guile to
become for Scheme what GCC is for C, but I don't see that becoming the
case any time soon.  Racket is nearer to that, though they don't even
call themselves Scheme.)

Taylan

Re: Request for feedback on SRFI-126

[Christopher Allan Webber]

Taylan Ulrich Bayırlı/Kammer writes:

> I will probably work on a delimited continuations SRFI, heavily inspired
> by Guile's call-with-prompt, since I find it *immensely* more easy to
> grok than shift/reset and prompt/control because those mingle together
> the "stack slice" and the "handler" code whereas call-with-prompt
> clearly separates them.

This could be interesting!  I wonder how hard it will be to do?  IIRC
from reading wingolog, delimited continuations need to be planned in at
a pretty low level, and I wonder how hard it will be for many
implementations to bring them in who don't have them at present?  Will
be interesting to see!

Anyway, interesting to hear, good luck!
 - Chris

Re: Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Christopher Allan Webber <cwebber@dustycloud.org> writes:

> Taylan Ulrich Bayırlı/Kammer writes:
>
>> I will probably work on a delimited continuations SRFI, heavily inspired
>> by Guile's call-with-prompt, since I find it *immensely* more easy to
>> grok than shift/reset and prompt/control because those mingle together
>> the "stack slice" and the "handler" code whereas call-with-prompt
>> clearly separates them.
>
> This could be interesting!  I wonder how hard it will be to do?  IIRC
> from reading wingolog, delimited continuations need to be planned in at
> a pretty low level, and I wonder how hard it will be for many
> implementations to bring them in who don't have them at present?  Will
> be interesting to see!
>
> Anyway, interesting to hear, good luck!

Thanks for the encouragement!

Yeah, AFAIUI delimited continuations are a very fundamental feature.
They can't really be implemented in call/cc for instance, as some people
used to claim I think.

(And that's why they need to be part of the language, as I see it; if
the language itself doesn't have them, there's no way to have them, and
no way to implement all the things they make possible on a higher
level.)

Of course it might be useful not to entirely turn one's back against
implementations that have a difficulty with that feature (it's pretty
new compared to some other Scheme features AFAIK, and going fairly deep
into the implementation), so it could be left optional, but sanctioned
as the official API for implementations to support, if they support it
in any way at all.  Like SRFI-106 does for sockets.

Taylan

Re: Request for feedback on SRFI-126

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 9385 bytes --]

2015-09-28 10:13 GMT+02:00 Taylan Ulrich Bayırlı/Kammer <
taylanbayirli@gmail.com>:

> Panicz Maciej Godek <godek.maciek@gmail.com> writes:
> >
> > 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)
>
> Because it's too easy to make a standards-compliant implementation
> because the standards ask for too little from compliant implementations.
> And/or other reasons; don't really know your intent with the question.
>

Because Scheme is constructed by removing unnecesary features, rather than
by adding them.

>     [...]
> >
> >     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.
>
> Python still lacks many of Scheme's greatest features. :-)
>

The MIT course 6.01 that replaces SICP introduces a language Spy, which is
a mixture of Python and Scheme. Might be worth checking out, although I
don't really think so. Anyway, if anyone's interested, it can be found here:
http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-01sc-introduction-to-electrical-engineering-and-computer-science-i-spring-2011/Syllabus/MIT6_01SCS11_notes.pdf
(page 89)


>
> > 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.
>
> S-expression syntax, allowing things like Paredit, is one of Scheme's
> many virtues over other languages.  So I would like to use Scheme, not
> Python.  Currently I can't.  (I can use Guile, but it still misses some
> "batteries.")
>
> >     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.
>
> Why not?
>

Because no one does them.

> 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.
>
> Why even bother with something like Guile if the only worth of Scheme
> were pedagogical?
>

No. I never said it's the only worth.
I find Guile very practical and convinient tool, despite its flaws.


> >     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.
>
> Libraries *are* software.  Currently people *don't* write any of that
> "software that can be read" except in small groups.
>

Small groups are a good start, I guess.

>     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
>
> I'm wondering more and more why you use Scheme if you think it has no
> advantages over Python.
>

I don't think so, and I never said that. Python has some inherent
limitations that Scheme manages to avoid, because it isn't over-specified.
I gave that link because it comes from one of the greatest Lisp advocates
-- and yet he claims that "Some just couldn't get used to Lisp syntax in
the limited amount of class time they had to devote to it", and also
"Although some people have initial resistance to the [Python's indentation
as block structure]/(Lisp parentheses), most come to [like]/(deeply
appreciate) them."

Even within the Scheme community there appear voices complaining on the
Lisp syntax, like SRFI-105, SRFI-110 or SRFI-119.

>     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.
>
> How can one implement such a miracle cons that constructs a list,
> vector, or hash table depending on the programmer's wishes?
>
>
This is a very good question, if taken seriously. (And I really wish I knew
the answer)


> Maybe you're thinking of something like PHP's arrays, which are somehow
> vectors and hash tables at the same time.  It's pretty terrible...
>

It is troublesome, especially combined with PHP's dynamic typing.
However, if the optimization could happen through static analysis, that
would be a different story.


> Scheme does no such muddying of what should be distinct abstract data
> types, thankfully.
>

Well, I don't think that there should be such thing as data types. I'd
rather say that there are concepts that programmers wish express (and those
rarely are data structures). Hash tables are just an optimization technique
for the concept of key-value association that is most accurately expressed
using assoc lists. (The problem with assoc lists, however, is their access
time)


> >     > 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)
>
> "Hash tables" are understood to be a data type providing amortized
> constant-time key-value lookup.


They are nothing more than a mere optimization technique.


> Time complexity is part of program semantics, not implementation.


There are two papers that seem particularly worthwhile in the context of
this discussion. The first one presents the Darlington-Burstall
transformation system:
http://www.diku.dk/OLD/undervisning/2003e/235/Burstall-1977-TransSystem.pdf

The second is the Kent Dybvig's PHD dissertation, in particular chapter 5:
http://www.cs.indiana.edu/~dyb/papers/3imp.pdf


> Sockets are fundamental because you can't implement them as a library.


Sockets are just procedures with side-effects, from the point of view of
the semantics of the language.


> Regexps
> might actually be possible to implement as a portable library, though it
> will probably be pretty slow.
>

On slow implementations of Scheme, perhaps. But on fast implementations
they could be, well, pretty fast.

These things could not possibly be any more fundamental.
>
> > You can surely implement threads using call/cc, or even delimited
> > continuations.
>
> No, you can't.  Your program will run on one core.
>
>
How can you tell?


> > You can implement hash tables and weak references (and
> > anything you please) using vectors.
>
> No, you can't.  Hashing requires implementation support.


I'm not sure what you mean. Hash table is essentially a vector plus a
function that converts data to an integer. Or am I getting something wrong?

>     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)
>
> I suspect that the things you use programming languages for differ
> greatly from what most programmers use them for.
>
>
Maybe you're right, but that doesn't concern me very much.


> I don't feel very motivated to continue this discussion since we seem to
> see things way too differently.


As you like it. I shall allow myself to drop discussion only if the topics
of my interest get depleted, though.

[-- Attachment #2: Type: text/html, Size: 14841 bytes --]

Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1026 bytes --]

Am Montag, 28. September 2015, 22:02:42 schrieb Panicz Maciej Godek:
> Even within the Scheme community there appear voices complaining on the
> Lisp syntax, like SRFI-105, SRFI-110 or SRFI-119.

I wrote SRFI-119, not because I want Scheme to become more like
Python, but because I want it to *look* more like Python while
retaining its strengths.

It isn’t necessary to sacrifice the strengths of Scheme to become as
easy for new programmers as Python. However it does require accepting
that a large part of the utility of any language lies in its
libraries: The best language for any job is the one which provides the
solution off-the-shelf. SRFIs could give Scheme such solutions, and
the flexibility of Scheme would allow making these solutions much more
elegant than what can be created with Python.

But someone has to actually do that: Creating libraries with
consistent style which provide to the application developer what
Scheme already provides to the language developer.

Best wishes,
Arne

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 299 bytes --]

Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

Am Sonntag, 27. September 2015, 21:00:46 schrieb Panicz Maciej Godek:
> 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

Saying that it should be “as usable as Python” isn’t the same as
saying that it should chase Python or mimic Python. You can make
furniture from wood or steel, but if you only have off-the-shelf
chairs and tables of wood, no one is going to open a restaurant with a
kitchen made of steel. Or built a skyscraper, for that matter.

Making Scheme as usable as Python requires finding an elegance which
fits Scheme and allows creating applications at least as easily as
with Python — but not necessarily in the same style.

Best wishes,
Arne

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 299 bytes --]

Re: Request for feedback on SRFI-126

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

2015-09-29 22:05 GMT+02:00 Arne Babenhauserheide <arne_bab@web.de>:

> Am Montag, 28. September 2015, 22:02:42 schrieb Panicz Maciej Godek:
> > Even within the Scheme community there appear voices complaining on the
> > Lisp syntax, like SRFI-105, SRFI-110 or SRFI-119.
>
> I wrote SRFI-119, not because I want Scheme to become more like
> Python, but because I want it to *look* more like Python while
> retaining its strengths.
>

If you asked me, I'd say that if people started using that SRFI (or the two
others), then it would be most harmful to the Scheme community, because
that would increase code enthropy and force programmer to make an
irrelevant choice.
It also sacrifices some of the strengths of Scheme, actually, because it
makes the code structure obscure.

The same goal could better be achieved (non-intrusively) by making an easy
to use editor that would allow to display your Scheme code in the way you
prefer, be it Python-style indentation or some fancy LaTeX formatting.

It isn’t necessary to sacrifice the strengths of Scheme to become as
> easy for new programmers as Python. However it does require accepting
> that a large part of the utility of any language lies in its
> libraries: The best language for any job is the one which provides the
> solution off-the-shelf.


Fine. But I don't find it disturbing that this "useful language with tons
of great libraries" is called Racket or Guile, rather than Scheme.

SRFIs could give Scheme such solutions, and
> the flexibility of Scheme would allow making these solutions much more
> elegant than what can be created with Python.
>

I will agree with you if you show me one example of successful deployment
of Guile or Racket. Like, Python has some impressive tools like Django or
Enaml.

But someone has to actually do that: Creating libraries with
> consistent style which provide to the application developer what
> Scheme already provides to the language developer.
>

I agree. But from my experience, in order to make a useful library, it is
best to work on some real applications.

I think it is actually reasonable to think that the power of a programming
language manifests itself in the applications that are written in that
language.

[-- Attachment #2: Type: text/html, Size: 3154 bytes --]

Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 4114 bytes --]

Am Mittwoch, 30. September 2015, 01:02:50 schrieb Panicz Maciej Godek:
> 2015-09-29 22:05 GMT+02:00 Arne Babenhauserheide <arne_bab@web.de>:
> > I wrote SRFI-119, not because I want Scheme to become more like
> > Python, but because I want it to *look* more like Python while
> > retaining its strengths.

> If you asked me, I'd say that if people started using that SRFI (or the two
> others), then it would be most harmful to the Scheme community, because
> that would increase code enthropy and force programmer to make an
> irrelevant choice.

It’s no more irrelevant than the choice between Guile and Racket. And
different from that choice, it’s trivial to change:

    for i in *.w; do guile wisp.scm $i > $(basename $i .w).scm; done

> It also sacrifices some of the strengths of Scheme, actually, because it
> makes the code structure obscure.

I disagree on that. The structure is still just as easy to recognize
as with parens: Even with parens the strongest indicator of the
structure is the indentation. It keeps the effects of inline-colons
limited to one line to avoid the need to do any complex mental
parsing: If there’s a colon in a line, the paren it opens gets closed
at the end of the line.

> The same goal could better be achieved (non-intrusively) by making an easy
> to use editor that would allow to display your Scheme code in the way you
> prefer, be it Python-style indentation or some fancy LaTeX formatting.

I consider it as problematic when programming languages need strong
tool support to be easy to read. With the right tools, even Java is
nice to use.

Changing indentation sensitive code needs some tool support to be
elegant, but that is available in most editors, but reading does
not. And I’ve been stuck in too many github diffs to consider that as
a solved problem :)

> > It isn’t necessary to sacrifice the strengths of Scheme to become as
> > easy for new programmers as Python. However it does require accepting
> > that a large part of the utility of any language lies in its
> > libraries: The best language for any job is the one which provides the
> > solution off-the-shelf.
> 
> Fine. But I don't find it disturbing that this "useful language with tons
> of great libraries" is called Racket or Guile, rather than Scheme.

This week a Freenet user wrote a client to Freenet in Racket. I wanted
to use it for Guile, but since I didn’t really know the capacities of
Racket, I didn’t know how to replicate them in Guile. I asked the user
whether he/she could port to Guile and after a few days he/she
published a Guile version but stated that it did not work yet. One
hour of fixing later I had it running.

Why I write that: For large projects it might be relatively easy to do
the conversion, because the compatibility layers are only a small part
of the total code base. The saved time by reusing existing code is
much larger than the time spent doing the compatibility stuff. For
small projects, it can be a blocker. You can’t spend a few days
waiting and 1 hour porting for programs which just take 4 hours to
write. Or rather: You can’t do that if you need to combine many small
projects into a bigger whole.

> I will agree with you if you show me one example of successful deployment
> of Guile or Racket. Like, Python has some impressive tools like Django or
> Enaml.

Can you give me clear criteria for when you would consider a
deployment as successful?

> > But someone has to actually do that: Creating libraries with
> > consistent style which provide to the application developer what
> > Scheme already provides to the language developer.
> >
> 
> I agree. But from my experience, in order to make a useful library, it is
> best to work on some real applications.

I agree.

> I think it is actually reasonable to think that the power of a programming
> language manifests itself in the applications that are written in that
> language.

I agree, too.

So our viewpoints don’t seem to be that far away from each other :)

Best wishes,
Arne

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 299 bytes --]

Re: Request for feedback on SRFI-126

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 5737 bytes --]

2015-09-30 1:44 GMT+02:00 Arne Babenhauserheide <arne_bab@web.de>:

> Am Mittwoch, 30. September 2015, 01:02:50 schrieb Panicz Maciej Godek:
> > 2015-09-29 22:05 GMT+02:00 Arne Babenhauserheide <arne_bab@web.de>:
> > > I wrote SRFI-119, not because I want Scheme to become more like
> > > Python, but because I want it to *look* more like Python while
> > > retaining its strengths.
>
> > If you asked me, I'd say that if people started using that SRFI (or the
> two
> > others), then it would be most harmful to the Scheme community, because
> > that would increase code enthropy and force programmer to make an
> > irrelevant choice.
>
> It’s no more irrelevant than the choice between Guile and Racket.


No. Guile and Racket are both experiments. I think it was a good move on
Racket's side that they proclaimed that they are a separate programming
language, because that way they manage to avoid bad community pressures
like this.


> And different from that choice, it’s trivial to change:
>
>     for i in *.w; do guile wisp.scm $i > $(basename $i .w).scm; done
>
>
Converting strange syntax to Lisp is essentially what parsing does.
Yet you loose a lot of support from your tools if you miss the assumptions
that they were made upon.


> > It also sacrifices some of the strengths of Scheme, actually, because it
> > makes the code structure obscure.
>
> I disagree on that. The structure is still just as easy to recognize
> as with parens:


It is easy for you, because you're inveted it. For everyone else it's just
another thing they'd need to learn in order to read the code. They'd need
to remember all the assumptions you've made.


> > The same goal could better be achieved (non-intrusively) by making an
> easy
> > to use editor that would allow to display your Scheme code in the way you
> > prefer, be it Python-style indentation or some fancy LaTeX formatting.
>
> I consider it as problematic when programming languages need strong
> tool support to be easy to read. With the right tools, even Java is
> nice to use.
>
>
Raise your hands all those who don't use emacs to write their Lisp code.
Raise your hands all those who don't use geiser to interact with Guile.

I honestly think that, however clever Lisp is, it would be rather painful
to edit it without proper tools. Even the aforementioned 'wisp.scm' is a
tool.

Regarding Java, I think its tools have the same problem the language has,
i.e. everything is fine as long as you stick to the path that their
developers chose for you.

Changing indentation sensitive code needs some tool support to be
> elegant, but that is available in most editors, but reading does
> not. And I’ve been stuck in too many github diffs to consider that as
> a solved problem :)
>

This is the reason why emacs indents lisp code. This is the part of
Norvig's comparison that I particularly like:

"One of Python's controversial features, using indentation level rather
than begin/end or braces, was driven by this philosophy: since there are no
braces, there are no style wars over where to put the braces.
Interestingly, Lisp has exactly the same philosphy on this point: everyone
uses emacs to indent their code, so they don't argue over the indentation.
Take a Lisp program, indent it properly, and delete the opening parens at
the start of lines and their matching close parens, and you end up with
something that looks rather like a Python program."


> > Fine. But I don't find it disturbing that this "useful language with tons
> > of great libraries" is called Racket or Guile, rather than Scheme.
>
> This week a Freenet user wrote a client to Freenet in Racket. I wanted
> to use it for Guile, but since I didn’t really know the capacities of
> Racket, I didn’t know how to replicate them in Guile. I asked the user
> whether he/she could port to Guile and after a few days he/she
> published a Guile version but stated that it did not work yet. One
> hour of fixing later I had it running.
>
> Why I write that: For large projects it might be relatively easy to do
> the conversion, because the compatibility layers are only a small part
> of the total code base. The saved time by reusing existing code is
> much larger than the time spent doing the compatibility stuff. For
> small projects, it can be a blocker. You can’t spend a few days
> waiting and 1 hour porting for programs which just take 4 hours to
> write. Or rather: You can’t do that if you need to combine many small
> projects into a bigger whole.
>
>
The same is true if you try to port e.g. PHP code to Guile, but then it
only gets more difficult


> > I will agree with you if you show me one example of successful deployment
> > of Guile or Racket. Like, Python has some impressive tools like Django or
> > Enaml.
>
> Can you give me clear criteria for when you would consider a
> deployment as successful?
>

Well, that would be a little vague, but my first shot would be that it runs
an app that makes money to anyone.


> > > But someone has to actually do that: Creating libraries with
> > > consistent style which provide to the application developer what
> > > Scheme already provides to the language developer.
> > >
> >
> > I agree. But from my experience, in order to make a useful library, it is
> > best to work on some real applications.
>
> I agree.
>
> > I think it is actually reasonable to think that the power of a
> programming
> > language manifests itself in the applications that are written in that
> > language.
>
> I agree, too.
>
> So our viewpoints don’t seem to be that far away from each other :)
>
>
Cool :)

[-- Attachment #2: Type: text/html, Size: 8215 bytes --]

Re: Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Arne Babenhauserheide <arne_bab@web.de> writes:

> [...] The best language for any job is the one which provides the
> solution off-the-shelf. SRFIs could give Scheme such solutions, and
> the flexibility of Scheme would allow making these solutions much more
> elegant than what can be created with Python.
>
> But someone has to actually do that: Creating libraries with
> consistent style which provide to the application developer what
> Scheme already provides to the language developer.

Exactly, I agree.  It should be noted though that some things can be
implemented purely as portable libraries, so there needn't be a Request
For Implementations to do it, whereas some other things, which I call
"fundamental" features, need to be supported by implementations, so they
need to be in the language specification or an authoritative SRFI.

For instance the "sets and bags" library in SRFI-113 could have been
just a library hosted on snow-fort.org or elsewhere because it can be
implemented as a library on top of hash tables, but the hash table
library/API needs to be in the language because it can't be implemented
as portable library code (not very well anyway; see SRFI-69 ref. impl.).
I like to think of SRFI-126 as "R7RS-small section 6.10 Hashtables" if
that isn't too shameless.  (I don't know yet if it's really worthy of
that, hence critique welcome.)

***

I think there are only few fundamental APIs left now that need to be
standardized, for standard Scheme to become fairly seriously usable and
possible to write as plenty libraries in as e.g. Python.  One could
already do a ton given R7RS-small, SRFI-99, SRFI-106, SRFI-115,
SRFI-126, though the mentioned SRFIs aren't well-supported yet.  After
that, we probably want a fuller POSIX API (not just sockets), an FFI,
delimited continuations, and a few other things.  Care needs to be taken
not to fall for API design mistakes in the conception of these SRFIs,
but I could say I see the writing of them as more drudgery than anything
else at this point.

But sadly, there seems to be little interest anymore among the biggest
Scheme implementations to help get that work done.

In any case I'll go on to write a delimited continuations SRFI inspired
by Guile's API, an FFI SRFI based on libffi's feature-set, will preach
for broader syntax-case adoption (don't know about phasing yet), and see
if I can write some POSIX API SRFIs as well.

If that effort will be in vain, so be it I guess.

Taylan

Re: Request for feedback on SRFI-126

[Mark H Weaver]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> 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.
>
> 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
>
> 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.  Not to mention simply more libraries Guile users can
> use, from the pool of standard-Scheme libraries, without needing a Guile
> porter and maintainer for every possible Scheme library.

I agree that standardization would be helpful, but we already have a
fine standard in R6RS.  It's not perfect, but IMO it's a more promising
platform than R7RS, which is so gratuitously incompatible with R6RS that
it's not possible to write even the simplest library or program that
works with both (wtf?).

One might well argue that having two competing and incompatible
standards is *worse* for standardization than having just one, hence my
reluctance to support R7RS.

In response to the argument that R6RS is a failure because so many
Scheme implementations rejected it: R6RS already has more high-quality
implementations than C++, Python, or Ruby.  Having 10+ implementations
of the same language doesn't seem to be a requirement for a language to
be successful.

In response to the argument that we should engage more in the R7RS-large
process to help move it in a better direction: I wasted a ridiculous
amount of time trying to get some R6RS numerics fixes into R7RS-small,
and was stonewalled the whole way.  I have neither the time nor the
interest in repeating that experience.

More to the point, I have no confidence that the decision making
processes in R7RS-large will result in a well-designed standard.
I agree with Andy Wingo's comments here:

  http://article.gmane.org/gmane.lisp.scheme.reports/4005
  http://article.gmane.org/gmane.lisp.scheme.reports/4019

Anyway, having said all this, I very much appreciate your sincere
efforts to help the Scheme and Guile communities, Taylan.

    Regards,
      Mark

Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 5990 bytes --]

Am Mittwoch, 30. September 2015, 08:39:44 schrieb Panicz Maciej Godek:
> > > others), then it would be most harmful to the Scheme community, because
> > > that would increase code enthropy and force programmer to make an
> > > irrelevant choice.
> >
> > It’s no more irrelevant than the choice between Guile and Racket.
> 
> No. Guile and Racket are both experiments. I think it was a good move on
> Racket's side that they proclaimed that they are a separate programming
> language, because that way they manage to avoid bad community pressures
> like this.

Do you see wisp as community pressure on Scheme implementations?

> > And different from that choice, it’s trivial to change:
> >
> >     for i in *.w; do guile wisp.scm $i > $(basename $i .w).scm; done

> Converting strange syntax to Lisp is essentially what parsing does.

I’ll cheat a bit here and pull your later answer:

> This is the reason why emacs indents lisp code. This is the part of
> Norvig's comparison that I particularly like:
> 
> "One of Python's controversial features, using indentation level rather
> than begin/end or braces, was driven by this philosophy: since there are no
> braces, there are no style wars over where to put the braces.
> Interestingly, Lisp has exactly the same philosphy on this point: everyone
> uses emacs to indent their code, so they don't argue over the indentation.
> Take a Lisp program, indent it properly, and delete the opening parens at
> the start of lines and their matching close parens, and you end up with
> something that looks rather like a Python program."

If you do that, you essentially have wisp. Being as close as possible
to Scheme with just leaving out the parens you can infer from
indentation is the core design principle of wisp.

> Yet you loose a lot of support from your tools if you miss the assumptions
> that they were made upon.

That’s completely, totally true.

Guile itself provides almost its full support when you’re using wisp,
but the tool support is much weaker. The Emacs mode for wisp is much,
much weaker than Geiser and there are no syntax highlighters in any
code hosting service, and that doesn’t even start with external code
analysis tools.

But you can already do stuff like this:
http://draketo.de/english/wisp/shakespeare

> > > It also sacrifices some of the strengths of Scheme, actually, because it
> > > makes the code structure obscure.
> >
> > I disagree on that. The structure is still just as easy to recognize
> > as with parens:
> 
> It is easy for you, because you're inveted it. For everyone else it's just
> another thing they'd need to learn in order to read the code. They'd need
> to remember all the assumptions you've made.

Let’s do that by example:


define : hello world
  format #t "Hello ~A!\n" world

hello "World"


Recognizing the structure isn’t the problem. Tool support is a
problem. And integration. And documentation. And so on. It is unlikely
to be the best system for all kinds of hacking. But it might be a
pretty good system for some tasks. And when you program in wisp, going
to standard Scheme is really easy. You already know all the
functionality, the structures, the libraries and so on.

> > > The same goal could better be achieved (non-intrusively) by making an
> > easy
> > > to use editor that would allow to display your Scheme code in the way you
> > > prefer, be it Python-style indentation or some fancy LaTeX formatting.
> >
> > I consider it as problematic when programming languages need strong
> > tool support to be easy to read. With the right tools, even Java is
> > nice to use.
> 
> Raise your hands all those who don't use emacs to write their Lisp code.
> Raise your hands all those who don't use geiser to interact with Guile.
> 
> I honestly think that, however clever Lisp is, it would be rather painful
> to edit it without proper tools. Even the aforementioned 'wisp.scm' is a
> tool.

You’re talking about editing right now. I explicitly talked about
reading, not about editing.

> Regarding Java, I think its tools have the same problem the language has,
> i.e. everything is fine as long as you stick to the path that their
> developers chose for you.

Replace Java with Python, and that still fits. Python even has flake8
for Emacs which checks for you whether you are following the canonical
path. And people do that intentionally. I know I do.

But there’s a reason why I started into Scheme.

> > > Fine. But I don't find it disturbing that this "useful language with tons
> > > of great libraries" is called Racket or Guile, rather than Scheme.
> > …
> > small projects, it can be a blocker. You can’t spend a few days
> > waiting and 1 hour porting for programs which just take 4 hours to
> > write. Or rather: You can’t do that if you need to combine many small
> > projects into a bigger whole.
> 
> The same is true if you try to port e.g. PHP code to Guile, but then it
> only gets more difficult

Sure, but that’s not what I would compare it to. I’d rather compare it
to the situation with C and Fortran. Porting a big codebase from one
compiler to the other takes some time, but once you did it, the code
works on both compilers. And you can quite easily write code which
works for both compilers. There will be minor glitches, but most
things will just work.

> > > I will agree with you if you show me one example of successful deployment
> > > of Guile or Racket. Like, Python has some impressive tools like Django or
> > > Enaml.
> > Can you give me clear criteria for when you would consider a
> > deployment as successful?
> Well, that would be a little vague, but my first shot would be that it runs
> an app that makes money to anyone.

I can work with that ☺

Best wishes,
Arne
--
singing a part of the history of free software: 

- http://infinite-hands.draketo.de


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 299 bytes --]

Re: Request for feedback on SRFI-126

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

Am Mittwoch, 30. September 2015, 09:58:32 schrieb Taylan Ulrich Bayırlı /Kammer:
> Exactly, I agree.  It should be noted though that some things can be
> implemented purely as portable libraries, so there needn't be a Request
> For Implementations to do it, whereas some other things, which I call
> "fundamental" features, need to be supported by implementations, so they
> need to be in the language specification or an authoritative SRFI.

What is an authoritative SRFI? One which is available in most
implementations?

Best wishes,
Arne
-- 
1w6 sie zu achten,
sie alle zu finden,
in Spiele zu leiten
und sacht zu verbinden.
→ http://1w6.org


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 299 bytes --]

Re: Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Mark H Weaver <mhw@netris.org> writes:

> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
>
>> 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.
>>
>> 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
>>
>> 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.  Not to mention simply more libraries Guile users can
>> use, from the pool of standard-Scheme libraries, without needing a Guile
>> porter and maintainer for every possible Scheme library.
>
> I agree that standardization would be helpful, but we already have a
> fine standard in R6RS.  It's not perfect, but IMO it's a more promising
> platform than R7RS, which is so gratuitously incompatible with R6RS that
> it's not possible to write even the simplest library or program that
> works with both (wtf?).

While that might have been a dumb decision on the side of R7RS, at least
converting an R6RS library to an R7RS library is usually trivial; one
only needs to change the library boilerplate.  (As long as an R6RS +
R7RS implementation allows importing (rnrs *) libraries with the R7RS
import directive.)

But I suppose one desires a library that works with both unchanged, so
as to keep working with R6RS-only implementations.  If R6RS had
'include', one could have an R6RS and an R7RS library using the same
body of code, so that goal would be fulfilled.  Sadly R6RS doesn't have
'include'.  (And it can't really be implemented with syntax-case as
advertised, since there's insufficient control over the filesystem.)

I'm not sure how important that is though, since most implementations
seem to be taking the R7RS path.  From what I know, Guile and Racket are
the only remaining popular Scheme implementations that support R6RS
libraries but not R7RS.  Racketeers apparently discourage using R6RS
anyway, preferring the racket language, and if there were demand they
could probably implement R7RS quickly.

I also see other shortcomings in R6RS in addition to the lack of
'include'.  There is no 'cond-expand', which further makes it hard to
write portable code.  It also came to my attention that Guile's R6RS
records API does not recognize SRFI-9 records.  (I don't know if that
can easily be fixed.)  All in all R6RS feels like a "dead end", as
William Clinger also suggests(*), whereas R7RS generally integrates very
well with the underlying implementation and seems to address the goal of
writing portable programs more pragmatically.  In my bytestructures
library I ultimately dropped R6RS support, because it just wouldn't play
along.

(*) http://andykeep.com/SchemeWorkshop2015/papers/sfpw1-2015-clinger.pdf

For these reasons, I think it would be best if we could support R7RS
too, and programmers gradually converted their R6RS libraries and
programs to R7RS (which is fairly trivial as long as an R6RS + R7RS
implementation allows importing R6RS libraries from R7RS).

(By the way, regardless of the issues above, I like many aspects of the
R6RS and will do my best to get them into R7RS.  I would claim that my
negative experiences with R6RS were not influenced by bias; I genuinely
tried to make the R6RS wrapper for bytestructures work, and failed.)

On another note, there is also the Larceny project of implementing R6RS
libraries in R7RS, making some R6RS programs easy to port even to
R7RS-only systems that lack native (rnrs *) libraries:

https://github.com/larcenists/larceny/tree/master/tools/R6RS

> One might well argue that having two competing and incompatible
> standards is *worse* for standardization than having just one, hence my
> reluctance to support R7RS.
>
> In response to the argument that R6RS is a failure because so many
> Scheme implementations rejected it: R6RS already has more high-quality
> implementations than C++, Python, or Ruby.  Having 10+ implementations
> of the same language doesn't seem to be a requirement for a language to
> be successful.

Well, I don't see any coordination between R6RS implementations to
define more useful libraries (like sockets, delimited continuations, or
an FFI), and don't see any future updates to R6RS itself happening.  All
in all, I'm not sure if I will ever be able to write something arguably
basic like e.g. a small HTTP server in R6RS.

I wouldn't call it a "failure" because I see it as a good resource for
some purposes, but I could say I see it as a "dead" language.  I can't
do many useful things with it.

> In response to the argument that we should engage more in the R7RS-large
> process to help move it in a better direction: I wasted a ridiculous
> amount of time trying to get some R6RS numerics fixes into R7RS-small,
> and was stonewalled the whole way.  I have neither the time nor the
> interest in repeating that experience.
>
> More to the point, I have no confidence that the decision making
> processes in R7RS-large will result in a well-designed standard.
> I agree with Andy Wingo's comments here:
>
>   http://article.gmane.org/gmane.lisp.scheme.reports/4005
>   http://article.gmane.org/gmane.lisp.scheme.reports/4019

Indeed, I understand your frustration, and wouldn't expect you and Andy
to spend any more time and nerves on the R7RS discussion lists.  I would
still appreciate some quick reviews of SRFIs I will be writing, but I
also understand if you see that too as a waste of time so no hard
feelings if you say no.

> Anyway, having said all this, I very much appreciate your sincere
> efforts to help the Scheme and Guile communities, Taylan.

Thanks for the kind words. :-)

I'm not sure if anything I said affected your opinion, I hope it wasn't
just a waste of time.

>     Regards,
>       Mark

Taylan

Re: Request for feedback on SRFI-126

[Panicz Maciej Godek]

[-- Attachment #1: Type: text/plain, Size: 6478 bytes --]

2015-10-01 0:16 GMT+02:00 Arne Babenhauserheide <arne_bab@web.de>:

> Am Mittwoch, 30. September 2015, 08:39:44 schrieb Panicz Maciej Godek:
> > > > others), then it would be most harmful to the Scheme community,
> because
> > > > that would increase code enthropy and force programmer to make an
> > > > irrelevant choice.
> > >
> > > It’s no more irrelevant than the choice between Guile and Racket.
> >
> > No. Guile and Racket are both experiments. I think it was a good move on
> > Racket's side that they proclaimed that they are a separate programming
> > language, because that way they manage to avoid bad community pressures
> > like this.
>
> Do you see wisp as community pressure on Scheme implementations?
>

I meant this discussion in general. I think that there we either need to
treat SRFIs as a sort of a pressure on the community, or the status of a
document being SRFI becomes irrelevant.

> > And different from that choice, it’s trivial to change:
> > >
> > >     for i in *.w; do guile wisp.scm $i > $(basename $i .w).scm; done
>
> > Converting strange syntax to Lisp is essentially what parsing does.
>
> I’ll cheat a bit here and pull your later answer:
>
> > This is the reason why emacs indents lisp code. This is the part of
> > Norvig's comparison that I particularly like:
> >
> > "One of Python's controversial features, using indentation level rather
> > than begin/end or braces, was driven by this philosophy: since there are
> no
> > braces, there are no style wars over where to put the braces.
> > Interestingly, Lisp has exactly the same philosphy on this point:
> everyone
> > uses emacs to indent their code, so they don't argue over the
> indentation.
> > Take a Lisp program, indent it properly, and delete the opening parens at
> > the start of lines and their matching close parens, and you end up with
> > something that looks rather like a Python program."
>
> If you do that, you essentially have wisp. Being as close as possible
> to Scheme with just leaving out the parens you can infer from
> indentation is the core design principle of wisp.
>

I think it is a slippery slope. You may wish to have lisp, infix curly
braces and "sweet-expressions" and suddenly everything gets complicated and
no one knows how the code should be written, because there are so many
options.


>
> > Yet you loose a lot of support from your tools if you miss the
> assumptions
> > that they were made upon.
>
> That’s completely, totally true.
>
> Guile itself provides almost its full support when you’re using wisp,
> but the tool support is much weaker. The Emacs mode for wisp is much,
> much weaker than Geiser and there are no syntax highlighters in any
> code hosting service, and that doesn’t even start with external code
> analysis tools.
>
> But you can already do stuff like this:
> http://draketo.de/english/wisp/shakespeare
>
>
:)
This surely does look nice :D

> > > It also sacrifices some of the strengths of Scheme, actually, because
> it
> > > > makes the code structure obscure.
> > >
> > > I disagree on that. The structure is still just as easy to recognize
> > > as with parens:
> >
> > It is easy for you, because you're inveted it. For everyone else it's
> just
> > another thing they'd need to learn in order to read the code. They'd need
> > to remember all the assumptions you've made.
>
> Let’s do that by example:
>
> define : hello world
>   format #t "Hello ~A!\n" world
>
> hello "World"
>

Simple examples are simple.
Now tell me how this code would look like in wisp and how would the lack of
parenthesis be helpful in its analysis. This is a real-life example
copied&pasted from my repository:

(define* (setup-pose! #;of rig #;to pose #:key (keeping #f))
  (assert (and (pose? pose)
      (if keeping (body? keeping))))
  (with-context-for-joint/body-relation
   (let ((('pose . parameters) pose))
     (for (joint-name . angle) in parameters
       (when angle
(let* ((joint (joint-named joint-name #;from rig))
(mobile-bodies immobile-bodies direction
      (let ((left right (split-bodies-at joint)))
(cond ((and keeping (in? keeping left))
(values right left -1))
      ((or (not keeping) (in? keeping right))
(values left right +1))
      (else
(error)))))
(angle* (- angle (joint-property joint 'angle)))
(mobile-joints (unique (fold union '()
    (map joints-attached-to
 mobile-bodies))))
(axis pivot (values (* direction (joint-property joint 'axis))
   (joint-property joint 'anchor))))
  (assert (eq? (joint-type joint) 'hinge))
  (for body in mobile-bodies
    (rotate-body! body #;by angle* #;around axis #;at pivot))))))))


Recognizing the structure isn’t the problem. Tool support is a
> problem. And integration. And documentation. And so on. It is unlikely
> to be the best system for all kinds of hacking. But it might be a
> pretty good system for some tasks. And when you program in wisp, going
> to standard Scheme is really easy. You already know all the
> functionality, the structures, the libraries and so on.
>

I can't see the gain from using that system. Actually, if we had an editor
that could typeset the Scheme code in various ways, everyone could be
aesthetically pleased, and that wouldn't need to break the existing code
base.

> > > The same goal could better be achieved (non-intrusively) by making an
> > > easy
> > > > to use editor that would allow to display your Scheme code in the
> way you
> > > > prefer, be it Python-style indentation or some fancy LaTeX
> formatting.
> > >
> > > I consider it as problematic when programming languages need strong
> > > tool support to be easy to read. With the right tools, even Java is
> > > nice to use.
> >
> > Raise your hands all those who don't use emacs to write their Lisp code.
> > Raise your hands all those who don't use geiser to interact with Guile.
> >
> > I honestly think that, however clever Lisp is, it would be rather painful
> > to edit it without proper tools. Even the aforementioned 'wisp.scm' is a
> > tool.
>
> You’re talking about editing right now. I explicitly talked about
> reading, not about editing.
>

Emacs indenting your code is an editing tool support that faciliates
reading. Also, I find rainbow parens and hide-show mode helpful when
reading the code.

I end here, because I need to get going
all best

[-- Attachment #2: Type: text/html, Size: 9981 bytes --]

Re: Request for feedback on SRFI-126

[Marko Rauhamaa]

Arne Babenhauserheide <arne_bab@web.de>:

> Making Scheme as usable as Python requires finding an elegance which
> fits Scheme and allows creating applications at least as easily as
> with Python — but not necessarily in the same style.

The main thing is to keep the S expressions' data/code duality. Python
doesn't have it. Here's a Python program:

    for i in range(10):
         print(i)

Here's the abstract syntax tree of the same program (generated by
ast.dump):

    Module(
        body=[
            For(target=Name(
                    id='i',
                    ctx=Store()),
                iter=Call(
                    func=Name(
                        id='range',
                        ctx=Load()),
                    args=[Num(n=10)],
                    keywords=[],
                    starargs=None,
                    kwargs=None),
                body=[Expr(value=Call(
                    func=Name(
                        id='print',
                        ctx=Load()),
                    args=[
                        Name(id='i',
                             ctx=Load())],
                    keywords=[],
                    starargs=None,
                    kwargs=None))],
                orelse=[])])

In Scheme, code is its own abstract syntax tree.


Marko

Re: Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Arne Babenhauserheide <arne_bab@web.de> writes:

> Am Mittwoch, 30. September 2015, 09:58:32 schrieb Taylan Ulrich Bayırlı /Kammer:
>> Exactly, I agree.  It should be noted though that some things can be
>> implemented purely as portable libraries, so there needn't be a Request
>> For Implementations to do it, whereas some other things, which I call
>> "fundamental" features, need to be supported by implementations, so they
>> need to be in the language specification or an authoritative SRFI.
>
> What is an authoritative SRFI? One which is available in most
> implementations?

Yeah, broadly speaking an SRFI that has wide acceptance, or is set out
to gain wide acceptance by means of being as uncontroversial as possible
and such.

> Best wishes,
> Arne

Taylan