Re: Request for feedback on SRFI-126

[Taylan Ulrich Bayırlı/Kammer]

Panicz Maciej Godek <address@hidden> 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