This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: typedef void *
- To: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Subject: Re: typedef void *
- From: "Greg J. Badros" <gjb at cs dot washington dot edu>
- Date: 08 Mar 2000 09:09:08 -0800
- Cc: guile at sourceware dot cygnus dot com, djurfeldt at nada dot kth dot se
- References: <m12SW2s-001mHjC@docupress.com> <xy7put5ljei.fsf@mdj.nada.kth.se>
Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:
> Radey Shouman <Radey_Shouman@splashtech.com> writes:
>
> > Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:
> > > ramap.c is entirely incomprehensible to me. The function raeql is
> > > schizophrenic: it can return SCM_BOOLs, 0 as well as what comes out
> > > ramapc().
> >
> > My original intent was that raeql should return a C boolean, which was
> > why it was declared to return an int, rather than a SCM. Anything in
> > raeql returning a SCM value is wrong.
> >
> > Similarly, ramapc was intended to return a C boolean, and was declared
> > to return an int.
>
> It's probably only fair to supply a piece of Guile history here.
>
> Guile has been moulded by a succession of people with different design
> philosophies. Tom Lord had the approach to quickly hack away all over
> Guile, and straighten things out later. This had the advantage that,
> during his time, things were happening. But one disadvantage was that
> when he left, no-one really knew what parts of Guile was in a "stable"
> condition, and what was simply unfinished.
>
> I say this because I know that the array support was changed during
> this time, so we should probably not blame Radey for the present
> condition of the code.
Well, coding should never be about blame, anyway. We just need to fix
it, that's all.
I'll be applying Han-Wen's void * patch on Friday unless we decide
otherwise and hopefully committing that same day.
Greg