This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Part of the API


Keisuke Nishida <kxn30@po.cwru.edu> writes:

> > But I'm not saying that an application writer *shouldn't* use the
> > snarf macros.  We should regard it as a convenient optional extension.
> 
> I see.  I just thought it is good if snarf macros are regarded as a part
> of the API.  It's the application author's decision not to use it.

Well, I guess it depends on what we mean by "part of the API" and
"extension to the API".

The real thing I'm pushing for is that we should know that we can't
assume that the application author has access to the snarf macros.  If
they were considered "part of the API", you could say "look, another
part of the API supports this, so we don't need this function".

It seems to me that the Guile API proper is what you get when you
compile with Guile headers and link with libguile minus those
"internal" things used for communication between compilation units
within Guile.

What do you mean by "part of the API"?

Why do you think it is bad if the snarf macros are not considered part
of it?

(These are not rhetorical questions.  I'm not sure I really know
 myself how we should define the API.)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]