Greets, I have had sufficient wine to respond.
On Tue 04 Dec 2007 07:50, "Marco Maggi" <[EMAIL PROTECTED]> 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/ _______________________________________________ Guile-user mailing list [email protected] http://lists.gnu.org/mailman/listinfo/guile-user
