Re: Request for feedback on SRFI-126

[Panicz Maciej Godek]

2015-09-28 10:13 GMT+02:00 Taylan Ulrich Bayırlı/Kammer <address@hidden>:

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