Re: 1.5.6: (bound? ) missing from optargs.scm

[Marius Vollmer]

Steve Tell <address@hidden> writes:

> On Thu, 28 Mar 2002, Thien-Thi Nguyen wrote:
> 
> > using some other out-of-band object is possible.  (we can bring `bound?'
> > back.  we just need to finish this iso-API change in the right way, or
> > justify in NEWS the new API.)
> 
> So, might it be back for 1.6?   

Hmm, yes.

I removed 'bound?' and related code in 'let-o-k-template' since we can
not reveal the SCM_UNDEFINED value to Scheme code.  This was a bug and
needed to be solved.  The 'bound?' functionality itself is not
problematic (although not really critical as one can emulate it easily
with default-values, as you point out) and we can bring it back.
Thien-Thi is right that the removing was done without much planning or
work on the real fix, i.e. a 'bound?' that doesn't use the magic
SCM_UNDEFINED value.

'bound?' would switch from being a macro to being a function.  Would
that cause any problems?

I have recorded this issue as bug 'optargs-bound-gone'.  (Please also
see the upcoming announcement of the newish bug data base.)

> > wrt other woes, when i took guile-snarf off of noinst_ i did not take
> > advantage of the dist-hook to modify already-distributed guile-snarf to
> > emit warnings when run, even though i thought about it.  my bad.
> 
> I'm glad you didn't - that would be rather antisocial (cf. discussion on 
> peaceful coexistance of multiple versions)

You can't have two versions of Guile on your system
_for_compiling_programs_with_ anyway.  You can run programs that are
linked to different versions of libguile (with the same installation
prefix), but you can't install two sets of header files (with the same
installation prefix).

Leaving a guile-snarf around that does not correspond to the installed
header files will only cover up bugs.  I think you figured this out
yourself, right?

> [...] Now that its official that every application has to implement
> its own snarfing system 

guile-snarf will be back for 1.6.

> (or go back to manual construction of the init functions), there's
> plenty of room for experimentation with alternate mechanisms.

This room is still there, unless I'm missing something.  You are not
forced to use guile-snarf.  If you find it inadequate, feel free to
experiment with something else.

> I get the sense that one only gets to break binary compatibility every few
> years, so there's a strong need to make it count when it does become
> necessary.

In my happy ignorance of real world issues, I don't see why binary
compatibility is a big deal.  It's an annoying artifact of the usual
implementations of the C programming language, but Unix systems seem
to deal pretty well with it, anyway, wither by using static linking or
versioned shared libraries.  It has to catch up a bit when linking
dynamically (i.e. via dlopen), but it is manageable.  Source
compatibility is much more important.

Is there more to it?  (Likely.)

> I hope I'm helping make 1.6 more likely to be what gets widespread
> distribution for two years after that by porting to and testing the
> 1.5.x ones and asking all these questions.

Thanks, that's really appreciated!