Re: [PATCH] Per-port read options, reader directives, SRFI-105

[Ludovic Courtès]

Hi Mark!

Mark H Weaver <address@hidden> skribis:

> Thanks for your review and consent!  I have incorporated your
> suggestions and pushed the improved patch set to stable-2.0.

Excellent, thanks!

> address@hidden (Ludovic Courtès) writes:
>> Regarding SRFI-105, I’m skeptical about a couple of things.
>>
>> First, $bracket-apply$, $nfx$, and $bracket-list$ need to be
>> user-defined, but implementations are allowed to provide a pre-defined
>> version of these.  This sounds like an opportunity for incompatibilities
>> (which the document describes as a shortcoming of Guile’s infix module.)
>
> First of all, I should clarify that $bracket-list$ is not part of
> SRFI-105; it is part of GNU Kawa.  However, since SRFI-105 adopted
> Kawa's convention for $bracket-apply$ within curly braces, I chose to
> also adopt Kawa's $bracket-list$ convention when curly-infix is enabled
> and when no other meaning has been given to square brackets.
>
> SRFI-105 says that $nfx$ and $bracket-apply$ "SHOULD NOT" be bound by
> default (except to something that produces an error), and that they
> "MUST NOT" be bound to anything that cannot be overridden.

Right, I had forgotten that part.  That addresses the risk of
incompatibilities I was thinking of.

[...]

>> It’s also unhygienic, in the sense that programs that need it would
>> typically have to start with a definition of $nfx$ & co., although these
>> identifiers never appear literally in the neoteric code.
>
> I agree that this is not ideal, but I see no way around it without
> losing the benefits that these (optional) features are meant to provide.
>
> Apart from the fact that $nfx$ et are meant to be defined by the user,
> it is exactly the same situation as for 'quote', 'quasiquote',
> 'unquote', 'unquote-splicing', 'quasisyntax', etc.  The whole point of
> these shorthand notations is to avoid having to type the associated
> identifier, and yet this means that an identifier is being referenced
> without appearing literally in the code.

Yes, right.  It’s probably just that I hadn’t thought of these good ol’
identifiers in this way.  ;-)

[...]

>>> +Guile also implements the following non-standard extension to SRFI-105:
>>> +if @code{curly-infix} is enabled but the @code{square-brackets} read
>>> +option is turned off, then lists within square brackets are read as
>>> +normal lists but with the special symbol @code{$bracket-list$} added to
>>> +the front.  To enable this combination of read options within a file,
>>> +use the reader directive @code{#!curly-infix-and-bracket-lists}.  For
>>> +example:
>>
>> Do you think it would be possible, or even desirable, to be able to turn
>> off this extension?
>
> I definitely think it's desirable to be able to assign some other
> meaning to square brackets, and indeed SRFI-105 allows us to do whatever
> we want with them (though they must be delimiters), and by default Guile
> treats square brackets an equivalent alternative to parentheses.
>
> My intent was that this extension would apply only when square brackets
> have no other meaning, and I changed the documentation to make this more
> clear.  This gives us license to add additional read options to do other
> things with square brackets in the future.

OK, makes sense.

> [... skipped several of your suggestions which I incorporated ...]
>
>>> +  ;;(pass-if (equal? '#1=f(#1#)               '#1=(f #1#)))
>>
>> Not implemented yet?
>>
>>> +  ;;(pass-if (equal? '#1={a + . #1#}          '($nfx$ . #1=(a + . #1#))))
>>
>> Same?
>
> The '#1=' and '#1#' notation is part of SRFI-38 and R7RS (draft 6),
> which is not yet implemented in Guile.  SRFI-105 does not require that
> we support this notation, but gives those examples of how the two
> notations should interact if they are both supported.

OK.

> Thanks again for your careful review.  The final result certainly
> benefitted greatly from your input :)

And from your patience and thoroughness!  ;-)

Thanks!

Ludo’.