[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 0/3] Add CommonMark reader
|
From: |
Ludovic Courtès |
|
Subject: |
Re: [PATCH 0/3] Add CommonMark reader |
|
Date: |
Sat, 24 Feb 2024 12:35:11 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hello,
Arun Isaac <arunisaac@systemreboot.net> skribis:
>>> Why the explicit listing of inputs? It seems less redundant to inherit
>>> from the upstream Guix package
>>
>> I thought the two might diverge, as in this case: we need Autotools and
>> guile-commonmark, so I find it somewhat clearer to be explicit about
>> what we expect.
>
> I think any divergence would be temporary. The divergence would be
> resolved after the next release and the Guix upstream skribilo package
> is updated. Addition of autotools would remain, and that's ok. If we
> listed inputs explicitly, we would have to maintain the same list in two
> different places (in Guix upstream and in the skribilo repo).
Yeah, it’s a tradeoff between correctness and maintenance burden I
guess; no strong opinion.
>> Looks like there’s material for a new release, with the two new
>> readers.
>
> Two? Do you mean the gemtext reader? We already released that as part of
> 0.10.0.
Oh right!
>> BTW, I figured the fact that readers emit code as sexps is pretty bad:
>> it’s an additional layer that makes things more brittle and less
>> efficient, because we need to pass that sexp through ‘eval’, and there
>> could well be undefined variables and the likes. It would be more
>> natural for readers to return a <document> object.
>
> I definitely agree. One of many dated decisions in skribilo for
> sure. Could you describe what this <document> object should be
> like?—what fields it should have, etc. Might come in handy if I or
> someone else works on it later.
I mean that <document> object as already defined in (skribilo ast).
Concretely, instead of returning '(document …), readers would use
(skribilo packages base) & co. and directly call the ‘document’
procedure and its friends.
That will require changing the section about the outline reader that
shows the outline-to-sexp translation. tests/readers/* will also have
to be adjusted to deal with ASTs instead of sexps; perhaps a
‘document->sexp’ procedure (ironically) can make that easier.
Ludo’.