more extensible reader directive, was: Wisp as shipped language in Guile?

[Arne Babenhauserheide <arne_bab@web.de>]

[-- Attachment #1: Type: text/plain, Size: 2474 bytes --]


Arne Babenhauserheide <arne_bab@web.de> writes:

>> For example, I've pondered the idea of making the "reader directive"
>> mechanism (e.g. things like #!curly-infix) easily extensible.  For
>> example, we could perhaps arrange for 'read', when encountering "#!FOO"
>> in the input stream, to look for a module named something like (system
>> reader-directives FOO) which would extend the reader as needed.
>>
>> What do you think?
>
> That sounds useful on its own

After pondering this a bit, I’m worried that this might push people
towards using reader directives as a replacement for
syntax-definitions. One problem with that is that reader directives
aren’t necessarily composable: While srfi-105 and srfi-119 compose well,
the indentation parsing in srfi-119 and srfi-110 is mutually exclusive.


For Racket I have the impression that this has the effect that the
easiest way to experiment is to define a new language. The main reason
why I think that is #lang typed/racket: Instead of creating a
(define-typed ...) syntax, which would have been available in all
languages, they added the (: ...)  special form.
(https://docs.racket-lang.org/ts-guide/quick.html)

When you define something in a module, it can be used in other languages
— including ecmascript and elisp. More exactly: You know that it can be
(at least I think that — I used Guile features from ecmascript: Is there
a limit to that which I did not hit?). With reader adjustments that’s
different.

However in Racket which started as a teaching language, this easier
experimentation likely outweights the cost of fragmentation into
different structures which cannot easily be used together. If you have
lots of students going into lots of different directions, and you don’t
actually want to recombine their work in specific applications, then you
can easily afford the price of limited composability.


But I’m biased in this: To avoid such fragmentation while providing
indentation-based syntax (which cannot be done at all without adjusting
the reader), I tried to keep the reader adaption in Wisp as minimal as
possible — to defer to regular Scheme as quickly as possible. This
should minimize friction from different approaches for tackling
problems, making it easy for people who start with Wisp to understand
any Scheme code (and vice versa).


Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]