Skyler Ferris via "Developers list for Guile, the GNU extensibility library" <guile-devel@gnu.org> writes:
> I have 2 concerns that I want to address. The first concern is the bad > user experience created by calling a procedure which is advertised in > the manual only to be told that it does not exist. I consider this to > be an urgent problem and would like to find a path to fix this > quickly. Based on the above I still believe that removing > program-arity (and updating the manual accordingly) makes sense. Given that the program-arity / program-arities is documented, the more pressing problem is that programs using it would be broken right now. People may be holding off from updating Guile because they don’t have the time to investigate breakage in programs that are working perfectly fine in the old version. Which is the typical case for useful tools. The worst user experience is seeing a working program break when updating a dependency: if the docs are wrong, you’re still in the context of your tool, but if it breaks on update, all that context has been flushed out already — often years ago. Is it viable to wrap the procedure and exactly preserve the API, so existing programs keep working? If it’s a bit slower, that should not cause pain (because hardware and Guile got faster in the meantime) but it should not break. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de
signature.asc
Description: PGP signature
