~dmbaturin/soupault

3 2

[INPUT NEEDED] "Monadic" approach to HTML module functions

Details
Message ID
<600a2d18-b2cd-6b5e-b551-368e67b21af5@baturin.org>
DKIM signature
pass
Download raw message
Hi everyone,

Right now, HTML module functions don't accept a nil for an argument. If
Lua was typed, they would be "html → 'a".

This can be mildly annoying when working with pages that naturally may
not have an element you are looking for, since you are forced to check
for nil at every step.

An alternative would be to make then "html option → 'a" and have them
return a nil if the argument is nil.

I think this shouldn't break any existing code, and you still can check
for nil explicitly, but you can also just chain those calls and get a
nil at the end, if any of them stumbles upon a nil.

Implementation in Lua-ML is trivial since it offers an option
combinator, so the question is whether we want to do it or not.

What do you think?
Thomas Letan
Details
Message ID
<20200305160742.mexcqnhk5suyl5ad@ideepad.localdomain>
In-Reply-To
<600a2d18-b2cd-6b5e-b551-368e67b21af5@baturin.org> (view parent)
DKIM signature
pass
Download raw message
> An alternative would be to make then "html option → 'a" and have them
> return a nil if the argument is nil.

As long as this is correctly documented, it looks like a sound design
choice.

> I think this shouldn't break any existing code

This makes me think: should soupault try to version its plugin interface,
and allows for using old interfaces? A bit like what dune is achieving.

By default, plugins would use the most up-to-date plugin api version,
but it would be possible to ask explicitely for another one in
soupault.conf.

It would probably lead to code duplication, but on the other hand, it
could be a nice feature to have.

> What do you think?

I would give it at least a try. I don’t see any reason not too!
Details
Message ID
<39eff202-c313-3a0f-b94c-ec25a43a15a2@baturin.org>
In-Reply-To
<20200305160742.mexcqnhk5suyl5ad@ideepad.localdomain> (view parent)
DKIM signature
pass
Download raw message
My reasoning is that all code that handles nils correctly already checks
for it (it has to).
Code that doesn't check it will be failing in a different way after that
change, but the invariant "code that never fails still doesn't and code
that fails in known cases still fails in the same cases" holds.
I don't think "code that never worked correctly now fails in a different
way" should be considered a breaking change.

>should soupault try to version its plugin interface, and allows for
using old interfaces?

Lua-ML doesn't allow dynamic mapping of Lua functions to OCaml
functions, but there may be a possible workaround (e.g. recording the
required version somewhere and doing the dispatch internally).
I still think we should rather try to avoid breaking changes for as long
as we can. If we stumble upon something that cannot be radically
improved without a breaking change, that's definitely something to consider.

On 3/5/20 11:07 PM, Thomas Letan wrote:
>> An alternative would be to make then "html option → 'a" and have them
>> return a nil if the argument is nil.
> As long as this is correctly documented, it looks like a sound design
> choice.
>
>> I think this shouldn't break any existing code
> This makes me think: should soupault try to version its plugin interface,
> and allows for using old interfaces? A bit like what dune is achieving.
>
> By default, plugins would use the most up-to-date plugin api version,
> but it would be possible to ask explicitely for another one in
> soupault.conf.
>
> It would probably lead to code duplication, but on the other hand, it
> could be a nice feature to have.
>
>> What do you think?
> I would give it at least a try. I don’t see any reason not too!
Details
Message ID
<c783179c-a710-cc6f-69f7-e53a8d823393@baturin.org>
In-Reply-To
<20200305160742.mexcqnhk5suyl5ad@ideepad.localdomain> (view parent)
DKIM signature
pass
Download raw message
I've done the deed. None of my plugins broke in obvious ways, so I
assume the hypothesis about backwards compatibility was correct.

Please check if your websites still build fine.
Export thread (mbox)