Hi Thien-Thi, On Fri 15 Jul 2011 18:25, Thien-Thi Nguyen <t...@gnuvola.org> writes:
> "semantics changed while name unchanged" is basically a big fat ‘set!’ > to the libguile API. Very true. It seems that maintaining a library is an exercise in managing mutation -- mutation of your software from state A to B, and the corresponding mutation of your library's users. There is an analog to the functional / imperative thing here regarding our community: we can add names until the cows come home, but that increases our heap size---both real, on machines, and virtual in terms of size of API and mental load---until GC runs, in which case users of old definitions have to migrate anyway. But we don't always have to avoid mutation; we can use it where it is sensible. For example, strictly following "semantics changes -> name changes" means introducing new names whenever you fix a bug, because hey, someone might have been relying on it. This obviously increases GC costs. I think we probably agree that bugs can be fixed without names changing, so there is some middle point that is a good compromise between heap size and GC rate. Heap compaction is possible at major GC's, when new major versions are released. One cost of name allocation is that it turns part of our community into garbage, because they use the old names that will be collected at some point. They will then have to change their code to point to live names. If they do it sooner, we have a more unified, dynamic community, ready to face changes. If they do it later, we have a more brittle, fragmented community. That's not to say that we should treat our users like garbage, of course! ;-) Anyway, I continue to disagree regarding this particular point, but I do appreciate the general concerns. We're building something here -- specifically, GNU -- and it's irritating to have to take off your roof because the walls aren't right. But sometimes it is necessary, so we need to manage this mutation, of ourselves & of our code. Regards, Andy -- http://wingolog.org/