[gambit-list] Thoughts on Scheme

Mikael mikael.rcv at gmail.com
Sat Jan 5 05:37:53 EST 2013


Hi Jason,

What you wrote reflects that you thought this through with care.

You wanted an opinion so here you go:

 * Identifiers made case-sensitive.
> *Rationale:* This makes integration with other langauges easier. Since
> the usual way to write Scheme is all lowercase, this should not be an
> issue. Many implementations already deviate from the standard in this
> regard.
>

At least all the Scheme implementations I checked have case-sensitive
identifiers?


>  * Replacement of the macro system
> This entails the removal of define-syntax, syntax-rules, let-syntax,
> letrec-syntax. They are replaced with define-macro and let-macro.
> *Rationale:* R5RS's syntax-rules defines a sub-language used for hygenic<http://en.wikipedia.org/wiki/Hygienic_macro> and
> [referentially transparent] macro transformation.
> The replacement removes the sub-language and replaces it with macro
> expanders which are written in plain Scheme code. While this puts the
> hygenic and referentially transparent properties on the programmer, it
> reduces the amount of knowledge the programmer needs and gives her more
> power and flexibility.
> The system will provide expand-macro in order to allow inspection of the
> macro-expansion results.
>

While at its core Scheme is the making of a programming language out of
lambda calculus, the macro facilities are more like a 'feature' there to
provide a needed practical function, than because they'd be so
scientifically or otherwise perfect they just needed to be in the language
for that reason.

Define-macro and let-macro come with this enormous hygiene issue:

; [Your macro library:]
(define-macro (give-me-the-first-element-please var) `(car ,var))

; [User's code:]
(define car +) ; User's custom language!
(give-me-the-first-element-please '(1 2 3))


=> error.

Thus you can see the limited purpose of define-macro and let-macro. Of
course it can work perfectly in a code base that's like a closed system,
such as in Gambit's sources, and, in any code base where programming is
done with this possibility in consideration.

A define-macro/let-macro system with hygiene through |alias| is
fundementally described at http://www.p-cos.net/documents/hygiene.pdf and
in detail as regards Gambit in this post by Per the 20:th of March 2012,
see here
https://mercure.iro.umontreal.ca/pipermail/gambit-list/2012-March/005815.html.


The syntactic-closures based macro systems (syntax-rules/syntax case
including define-syntax, syntax-rules, let-syntax, letrec-syntax) bring
incredible complexity and with that low debuggability through a very
complex identifier concept based a kind of duality of the identifier symbol
in itself and the syntactic environment in which it is used in a particular
instance, and brings a complex API for handling macros with this, that by
nature is not Schemy and not suited for debugging.

Per came with the suggestions above based on having spent approx 6 months
fulltime on developing the Black Hole module system, which does hybrid
define-macro and syntactic closures expansion.

There might be some caveat I didn't get, but, I'd guess you could actually
make a macro expander that supports both an alias macro system as per above
and a syntactic-closures for compatibility with code that uses it, possibly
by splitting expansion into two expansion phases, thus isolating all the
identifier-related complexity.

Removal of do
> *Rationale:* Use of do rather than let for looping is not typical in
> Scheme, and the form is hard to read.
>

Never used it, the presence of the ~50 lines or so it probably occupies in
the evaluator and compiler never bothered me.


> car and cdr replaced with pattern matching and iterators
> The names car and cdr are vestigates of the PDP-11. They and their
> variations (such as caddr) are difficult to read and reason through.
> Pattern matching can be used to extract values from data structures easily
> and concisely, and so the language will instead offer pattern matching
> along the lines of this <http://wiki.call-cc.org/man/3/Pattern%20matching>
> .
> [..]

 &

> The standard procedures made generic
> [..]
>

The point with Scheme is to provide a language in which you can do anything
[at-least-somewhat-in-the-direction-of-highlevelish]. The language is not
intended to be complete. It's *your* role to make it complete for your
purposes.

Partially, it is put this way, because there's always some variation or
improvement you could do to a pattern matching, iterator or generics
system, while with the limited scope the Scheme language works with it's
easy enough to get to a minimum language around which consensus can grow
quite spontaneously and widely and in a way that is lasting.

Very much secondarily, there might be some performance characteristic in
how generics would combine with the type system, that make them unsuitable
for being a feature included by default.


I admit pattern matching, iterators and generics would be really nice to
have. It is not so difficult to implement it in a given environment such as
Black Hole, at all.

I didn't need it so much as for it to be worth it to implement it at all
though.

You can be the one to implement it!

I'm sure many would be happy to use it, if it's experienced as really neat.


values, let-values, let*-values and call-with-values removed.


values is the tool for bringing symmetry between procedure invocation and
return, and thus it is a bringer of important symmetry. Since the language
is fundamentally about symmetry, I cannot see any reason for removal. Of
course an implementation can implement values any way it wants to,
including just as an alias for lists.




Any language or system will always contain like a design
balance/equilibrium that could be described as involving an aspect of
compromise. This brings a limit in suitability for some interval of
purposes.

Scheme provides extensive code abstraction features, but for instance, is
not exactly as heavily optimized for contemporary CPU caching as C and C++
is through their much more extensive use of structures [of structures etc.]
that are focused in completely sequential RAM address intervals. Partially
therefore, you might be better off implementing video codecs in C.

So the task is always yours to choose appropriate tools for a given task,
in consideration of their unique characteristics.


Please feel free to share any thoughts or reflections.

Regards,
Mikael

2013/1/5 Jason Felice <jason.m.felice at gmail.com>

> Hi!
>
> This might not be the right place for this, but I've failed to solicit
> useful (or any) opinions elsewhere and I imagine some people here would be
> interested in it.
>
>  I drafted a post called "A Critique on the Language Scheme".  The draft
> is here:
>
> https://gist.github.com/4430394
>
> I hope this provokes thought.
>
> Thanks,
> -Jason
>
> _______________________________________________
> Gambit-list mailing list
> Gambit-list at iro.umontreal.ca
> https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.iro.umontreal.ca/pipermail/gambit-list/attachments/20130105/9a679887/attachment.htm>


More information about the Gambit-list mailing list