[Top][All Lists]

[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)


Arun Isaac <> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]