guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: api differences between 1.4 and 1.6


From: Thien-Thi Nguyen
Subject: Re: api differences between 1.4 and 1.6
Date: Fri, 22 Feb 2002 10:27:49 -0800

   From: Neil Jerram <address@hidden>
   Date: 22 Feb 2002 15:32:04 +0000

   What do you mean by an xref script?

sorry i was unclear...

   It seemed to me that the necessary next steps were to group
   everything from your C/Scheme new/old lists into functional groups,
   and then for each group try to explain the change/removal/addition.
   I also think that we should classify a lot of stuff as
   internal/experimental - i.e. "use at your own risk", and not such a
   high priority for us to document right now.  (For example, anything
   scm_gc_* would be internal, and environments and anything in C to do
   with GOOPS would be experimental.)

yes, this is exactly what needs to be done.  to me, this is all
"xref"-ish in nature: given a symbol (j.r.hacker asks "i want to use
QUX, what are the ramifications of this function?"), the database can
respond: QUX, a proc, is present in libguile x.y.z and libguile q.r.s,
part of the group "internal procs that begin with Q, experimental, so
don't use it", documentation available in info node "subversive hacks",
referenced as deprecated in NEWS, referenced as deprecated in info node
"internal procs deprecation", reference material in info node "internal
procs"...

or perhaps: QUX, no info available, be very scared.

similar attributes could be mined for scheme symbols.

i guess my intention is to not do the actual grouping (manually) so much
as to codify some mechanism for specifying/reporting groupings.  maybe
the best way to do this is to annotate the original alists (which is why
they are alists and not simply lists), with grouping info.  what do you
think?

thi



reply via email to

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