Re: guile: going the way of DEATH

[Telford Tendys <telford@triangle.triode.net.au>]

> 	* As far as I could see, but again, this is a newbie view, the gh API
> seems strange, uncomplete and inconsistent. Some examples:
> 
> 	- Why using so many functions with just a `return' line, instead of a
>         set of standardized macros ? Something like BOOLEAN_P instead of
>         gh_boolean_p.

NO! use functions. Thanks to the magic of gcc you have static inline
functions and function attributes like ((unused, const)). These allow
functions to optimise as well as macros (in theory at least, gcc still
misses the odd optimisation, I'll leave that argument for the `eggs heads').
Using functions allows you to produce predictable versions for debugging
and then still produce optimised versions are as fast as macros.

Even a dose of `-finline-functions' will probably clean up a lot of
the gh_ functions without changing the source one jot.

Also, functions check argument types, macros don't.

> 	- What's the point in having gh_number_p but not gh_integer_p and the
>         like, if people will need to mix the APIs anyway ?

Arg! there IS a gh_number_p() -- but you have to look at the source code
to find it, this time I looked at the info files.

> 	Again, my view is the one of somebody discovering the package, but I
> think guile developpers currently lack feelings from people like me. I hope
> this can help identify the caveats in the project. I've found out about Elk
> after a recent mail on this list, and I immediately switched to it. In one
> day reading/coding I could do much more things with it than in a week
> investigating guile sources. That's the point.

Keep us informed on Elk then, especially the behaviour of the garbage
collector. How do they do things like type conversion, type checking,
wrapper functions? How do they handle smobs (or do they?) The more research
you can predigest for me, the less I'll have to puzzle over it myself
(same probably goes for a lot of list readers).

	- Tel