Re: the future of Guile

[Andy Wingo]

Greets,

I have had sufficient wine to respond.

On Tue 04 Dec 2007 07:50, "Marco Maggi" <address@hidden> writes:

> I think that  it is time for a chat on  the future of Guile.

Sure, why not. (Stop justifying your emails, it looks stupid in
fixed-width fonts.)

> [Guile] does not have to [compete] because, like it or not, Guile is a
> language for extensions.

Totally. This is what defines guile. (Making it a good standalone scheme
is another goal.)

> 3b. Death to  structs!  IMO they were "an  attempt", but the
>     resulting code is awful (sorry, but can you disagree?). 

No, I cannot :) But solving this would go to solving a lot of your other
points. Record types are the hip disjoint type in Schemeland, and you
certainly need a way to deal with them from Guile. Structs might not be
it, but you will need something smarter than SMOBs... Suggestions?

> 4. If  a garbage  collector allows  to remove  the  need for
>    "scm_remember_upto_here"  it must be  adopted even  if it
>    makes Guile slower  and it raises memory usage  a bit (or
>    more than a bit). 

Who cares? I have written thousands and thousands of lines of guile
extensions in C. I have not yet had to use this. Perhaps it's just dumb
luck or something.

> 5. Guile  must be loadable/unloadable  as a  shared library.
>    Use case: once I have read a configuration file or a sexp
>    data file, I do not need it anymore.

If you aren't running your app with Guile extensions / code, you don't
need a whole scheme interpreter to read s-expressions...

> 6. More modularity. 

Sure, but any breaking of Guile into modules without thinking about
syncase is half-baked. This is one bit that r6rs definitely got right
IMO.

> 7a.  It makes no sense to discuss if Guile should go R6RS or
>     not.   The  only meaningful  discussion  is about  which
>     hooks are needed in  Guile's code to make those features
>     available   as   loadable   modules.   (Yes,   this   is
>     difficult).

Oh, I don't know. Standards are definitely relevant, whether it's ERR5RS
or R6RS or whatever. The guile hacker community is a small part of the
scheme hacker community, we should cooperate if at all possible.

In summary, may I unfairly caricature your attitude: "Guile does not
follow a number of 'modern' norms, and therefore we should update it."
Unfortunately for you Guile is widely deployed and coded to; those users
also define "what guile is". Radical changes to the C interface are not
going to be forthcoming.

Just another Guile hacker,

Andy
-- 
http://wingolog.org/