Practically put: We need Andy Wingo to nitpick the tutorial about things
which will cause overheads the compiler cannot fix easily — including
expensive use of macros.
I definitely oppose. If Chez has something solved better, why not use
It’s not "why not use Chez", but rather "what should I teach new
They are already learning a new language. When I now go and point them
towards many different implementations which differ in details of stuff
I teach them, I’m throwing more complexity at them. More things to
understand before even starting to write working code.
I totally agree. Programmers shouldn't be concerned whether they're
using Chez or Guile or Gambit or Stalin or whatever else. Ideally, they
should do well without even knowing that such things exist.
There are Schemes, such as Kawa or Biwa or IronScheme, that are tied
to their environment, but most of them just run on the PC
I think this is a point which cannot be reached, because the design of
the Scheme system itself must make certain tradeoffs — especially for
the default environment (what to present a new user). If that is too
large, then users cannot start quickly. If it is too small, then users
cannot solve problems easily. But different problem spaces require
different base tools.
Another points are the basic datastructures: If they are too complex,
then the system cannot be used easily on tiny computers.
Essentially you have to find reasons for decisions like this:
Maybe it would already help to mark the code which will work the same in
all (r7rs) Schemes. Is there stuff which is well optimized in all
Schemes? Who knows that? The r7rs benchmarks look like this is very much
not the case: http://ecraven.github.io/r7rs-benchmarks/benchmark.html
(Or rather, the benchmarks would ask: "why should I *not* use Chez or
stalin for everything I do?" Because those are the fastest for most
But that might mean to write less elegant or efficient code to keep it
cross-implementation. Should I rather teach new people to solve a
problem as well as possible, or teach them to solve a problem in a
I think that in principle, the programmer should only focus on writing
most elegant code
I think there are several different kinds of elegance. There’s technical
elegance (combining existing things to build something unexpectedly
powerful with minimal effort), readability (being easy to understand for
newcomers), minimal code (solving a problem with the minimal amount of
code — often close to mathematics), uniformity (using the same basic
structure everywhere), efficiency (solving a problem with minimal
I’m sure we’ll find more.
Sadly these elegances contradict each other in some points.
In my case, I decided to use Guile by checking Scheme
implementations. There were three with roughly equal activity and
features. I chose Guile, because it’s a GNU project and it has a long
history of surviving changing maintainers, so my skills are most likely
to stay useful.
That's interesting. I chose it by trying to add a scripting language
to my game engine written in C++. But I guess that if I was starting
now, I'd write the whole engine in Chez (which wasn't opensource until
Chez becoming free software is an interesting development.
The ultimate goal is not to optimize programs, but programmers.
I’m not sure that I want to optimize them, I want to teach them tools to
be more efficient and enjoy their work more (and teach myself the same).
Yeah, maybe I used a harsh word, but I meant exactly optimizing
programmers' efficiency (or if it sounds too bad, "giving them tools
to be more efficient")
Sounds good :)
I think one important point for Scheme would be to gather some consensus
points. The Zen of Python is part of what made that one community
strong. There is no reason why there should not be a Zen of Scheme,
along with implementation-specific Koans which extend it.
Do you have ideas for principles which could be shared by most Schemers?
It depends on the most Schemers, not me :)
That’s why its a social problem :)
Finding a set of basic koans which most Schemers agree with requires
talking to and knowing a lot of Schemers.
However, you can have a look at the (grand scheme) glossary that I've been
maintaining for some time:
This looks interesting.
of course, the intent is to make the glossary usable for someone else than
and I can boast that I have at least one user distinct from the maintainer.
You can have a look and let me know what you think. (for now it only works
with Guile). In particular, are there any factors that could convince you to
adapt it as a base for your library, or what would you want changed
(I assume you won't stop at the README file).
I’d mainly need practical examples. Tell me how I’d solve a problem
with (grand scheme) and how it would be solved without it — showing me
why using it is better.
That means: Documentation.
Also I’d need to know whether some of these methods have performance
problems: Will this scale as well as the method without (grand scheme)?
- functions should be pure
- language constructs that cause side-effects should be encapsulated
with macros that limit the extent of those side-effects
- if possible, use the quasiquote macro, rather than cons, append or list
- prefer the use of match <http://synthcode.com/scheme/match.scm> to cond,
if the patterns are simple
- never use abbreviations
- use commented prepositions to separate arguments
As guidelines for easy-to-use libraries, that sounds good.
Also, I recently added infix syntax to Scheme, but (unlike in Racket
or David Wheeler's solutions) in the way it is still a prefix
syntax. So for example, instead of writing (< a b), one ought to write
(is a < b). The rationale is that prefix notation is terrible for
non-symmetrical binary predicates, because it obscures the roles of
respective arguments (in addition, (is a < b <= c) expands to (and (<
a b) (<= b c))). I'm still not sure whether it is a good idea, but I
have no reasons to think that it is bad either :] [Curiously enough, I
think that prefix notation in arithmetic is just fine: (+ a b c) reads
as "sum of a, b and c"]
This is an old idea, but using (is) as prefix looks
interesting. Typically the prefix was something like (nfx), which
doesn’t say anything semantic (other than that what follows uses infix
syntax). It’s like an expanded equal?
(if (is a = 5)
((is q = p)
((is p > 5)
This seems pretty close to natural language. Can I also use (is A 5)
instead of (equal? A 5)?
Though (is? a = 5) might be closer to canonical Scheme.
I like it that you and Amirouche look a lot at the sociocultural
perspective of programming
I’m glad to hear that :)
Yes, to me the ease of understanding is also crucial. (I'd even go
further and say that undestranding is the very point of programming)
I would not go that far: We’re programming both for the future
maintainers of the code and for the computer. This restricts us in
expressing things, because we always have to keep two targets audiences
in mind (many different systems *and* many different people).