Re: A new Scheme tutorial

[David Kastrup]

Jean Abou Samra <jean@abou-samra.fr> writes:

> Le 25 juil. 2022 à 14:51, David Kastrup <dak@gnu.org> a écrit :
>> 
>> syntax-rules/syntax-case introduce a completely new and arbitrary syntax
>> intended to be human-readable.  That's sort of a counterthesis to the
>> LISP philosophy of representing programs by the data representation of
>> their parse tree, skipping a human-readable abstraction for the sake of
>> making it easy to programmatically generate and analyze programs.
>> 
>> Macros, in contrast, are just a flag on functions telling the evaluator
>> "evaluate the function result instead of its arguments".  That is an
>> almost trivial tweak.
>
> Modulo the fact that IIRC, Guile 1 would only run the macro the first
> time the form was evaluated, but I see what you mean.

I was not really talking about Guile.  Guile is a comparatively faithful
Scheme implementation.  It was more about the LISP/Scheme difference in
philosophy.

LISP is at its heart, conception and inception an interpreted language.
Compilation is an afterthought, just like demand-paging is an
afterthought for UNIX, with the original concept having just one process
in memory and the difference between swapping and forking essentially
being that swapping pulled in a process image before continuing
execution and forking just continued running, as "child", the process
image it just wrote to disk.

The original simplicity that allowed running stuff in 64k of memory or
less has not been retained either way.

In Guile 1, I've successfully used call/cc for implementing a fairly
trivial local-eval that was able to deal with closures.

<https://guile-devel.gnu.narkive.com/m42DJSjd/summary-lilypond-lambda-and-local-eval#post4>

That doesn't work with the compilation complexity of Guile 2 since this
trick obviously falls apart really hard with anything operating in
multiple passes.

>> More complex, indeed, is the quasiquote mechanism that operates to a
>> good degree in the LISP reader and makes it comparatively easy to
>> handle the creation of material suitable as macro body.
>> 
>> In contrast to syntax-rules/syntax-case this reflects more a
>> philosophy rather than a religion since it isn't arbitrary.  Using it
>> is more a matter of understanding rather than learning it.
>
>
> There are two mostly unrelated parts in the Scheme macro system that
> differentiate it from the traditional Lisp system: the pattern
> matching language, and hygiene.

Effective hygiene can be achieved with make-symbol.  But of course once
you stop having an interpreter, the conceptual simplicity is not
continued into the implementation, particularly if you want
compiled-language efficiency.  And Scheme also has thrown the conceptual
simplicity overboard along with the simple implementation.

> The first part is definitely not all lilies and roses. It’s weird to
> have a separate namespace for the pattern variables bound by
> syntax-case. It’s weird that the primitive way to analyze syntax
> objects is not a set of simple procedures like syntax-pair?,
> syntax-car, but only syntax-case pattern matching, against the
> traditional Scheme principle that complex tools (like syntax-case) are
> built at will on top of very simple tools. It’s weird that syntax
> pairs aren’t normal pairs, so you can’t use list functions on them
> directly. It’s weird that #'(pat …) doesn’t return a syntax list but
> just a plain list (at least in Guile, didn’t check the standard).
>
> Still, this macro system gives you a form of lexical scoping and
> hygiene, and allows things like renaming syntax keywords when
> importing them, which is really nifty and the main reason why I prefer
> writing syntax-rules/case macros. I like the principle of annotated
> symbols containing scope information. It’s not that I’m fond of the
> tools provided to manipulate them.

I feel similar with regard to C++'s implementation of the template
system: the goals are worthwhile and they are accomplished, but the
syntax appears foreign to the base language and has been dragged in from
elsewhere (in C++'s case, basically from Ada with subsequent cancerous
proliferation), at considerable cost that seems like too much of an
uncalled-for expense.

-- 
David Kastrup