Hi Mark!
Mark H Weaver <m...@netris.org> skribis:
> Thanks for your review and consent! I have incorporated your
> suggestions and pushed the improved patch set to stable-2.0.
Excellent, thanks!
> l...@gnu.org (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’.
