Re: First look at Guile Std Library available

[Richard Todd]

Andreas Rottmann wrote:
> Hmm, I always kind of disliked that approach. 

<snip>

> 2) Presumed the need for API-breaking changes are needed, in turn not
>    to hinder development of the library itself, in intervals quite
>    smaller than 5 years, it would be more of a annoyance to developers
>    regularly adapting to the API changes (which indeed should only be
>    "major" in the sense that they require a lot of adaption to
>    existing code accross major version changes) to require changing
>    all their code to use stdY instead of stdX.

You could be right.  I was thinking along these lines:

There is a lot that can be done to preserve compatibility over a period 
of time, that essentially builds up cruft in the library.  Things like 
leaving the old function name _and_ the new function name in.  Things 
like moving the module _and_ leaving a module in the original location 
to load it, too.  Things like adding the second XML processing module 
but leaving the original one there too.

Then, (I was hoping only once every few years), you have to say 
"Enough!" and break with the past.

It could be that it's best to do something in-between, and let small 
incompatibilities in over time, and reserve std2 for a massive 
reorganization.  Some people do a "deprecate-for-1-major-release" 
strategy, after which deprecated things disappear.  That might be an 
option also.

> 1)
>
> ,----
> | (define (register-logger! str lgr)
> |   (if (not (string? str))
> |       (throw 'bad-type "Expected a string for the log registration"))      
> |   (hash-set! all-loggers str lgr))
> `----
>
> Why not make GOOPS care for type-checking (given GOOPS is used)?

Good question!  I'll do this.

> 2) Have you considered the need for a "log domain" as in GLib? This
>    can be useful e.g. for an application to dump most logs including
>    all those generated by libraries into a file and present all logs
>    messages from its own domain and above a certain level in a special
>    way (e.g. message dialog).
Not familiar with GLib, but if you mean that different parts of the 
program talk to different named 'domains', then that you should be able 
to get something similar with the register-logger! mechanism, right? 
You could log to as many named loggers as you want.  You can even assign 
the same handlers to different named loggers.  So, your "gtk" logger 
could be sending its logs to the same files as your "app" logger, for 
instance.  I may not fully understand the domain concept, yet, though.

thanks,
Richard