Hi Julian!
Julian Graham <jool...@gmail.com> writes:
>> How about this instead:
>>
>> �...@code{div} is an alias for Guile’s @code{quotient} and @code{mod} is
>> an alias for @code{modulo} (@pxref{Integer Operations}).
>
> Well, I don't know. Those exports currently /are/ aliases for those
> procedures, but that's a bug that I introduced because I had some
> hesitation over how to implement the real procedures efficiently. I
> suppose I should revisit that problem... :)
Aah, OK.
>> This use of @pxref is incorrect and leads to broken rendering with all
>> back-ends (info "(texinfo) pxref"). The same problem appears in other
>> places. Could you look into it?
>
> Fixed as many of these as I could find. Let me know if you notice other ones.
Cool, thanks.
>> Perhaps add an xref to SRFI-35, in pure TIMTOWTDI spirit. ;-)
>
> Done. Off-topic: While poking around, I noticed that SRFI-35 is
> implemented purely in terms of Guile structs; would it make sense
> later to re-implement using a subset of the features of `(rnrs
> conditions)'? (Ditto for SRFI-9 and `(rnrs records)'.)
Well, I’m sentimentally attached to the SRFI modules and I remain
R6-skeptical. ;-)
So, I’d rather have the R6RS modules implemented in terms of the SRFI
modules rather than the other way round.
Now, I agree that SRFI-35 could be implemented in terms of SRFI-9,
especially since SRFI-9 accessors are inlined (initially SRFI-35 was
implemented for Guile 1.8, where it made a difference to use raw
structs.)
I don’t consider it important though since the SRFIs have no connection
to one another anyway.
>> The ‘---’ should not be surrounded by spaces. Though according to
>> https://secure.wikimedia.org/wikipedia/en/wiki/Dash#Em_dash you could
>> argue that you’re following the /The New York Times Manual of Style and
>> Usage/. ;-)
>
> I make no such claim! Fixed. :)
Cool! :-)
Thanks!
Ludo’.
