[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the future of Guile
From: |
Marco Maggi |
Subject: |
Re: the future of Guile |
Date: |
Fri, 7 Dec 2007 07:28:41 +0100 |
"Andy Wingo" wrote:
>> 3b. Death to structs!
>
>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?
I dunno what you mean by "smarter", anyway my original plan
was to put records in a module and structs could go with
them. My understanding of records is that: the only thing
that structs do that a vector cannot do (without special
handling), is to have a print closure used by WRITE and
DISPLAY.
There is a comment in "boot-9.scm" that lets us understand
about a plan to make GOOPS wrap records (maybe)
automatically, but if it was implemented it is
undocumented. It goes along with other undocumented things
that maybe are there but nobody (still here) knows if they
were finished and working. And Guile maintainers keep them
in for future releases (if they exist), because they are not
going to break backwards compatibility...
>> 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.
While coding GEE I had crashes that I fixed by remembering.
I am probably using it also in places where it is not
required. But I am not able to recognise those places, can
you guess why?
>> 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...
This depends upon the type and number of transformations
that I want to apply before converting data into the
application's internal representation.
>> 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.
Sorry, I am not competent enough to understand and comment
on this, can you elaborate?
>> 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.
Well, I am not going to do work for R6RS compliance, and I
am not going to ask Ludovic and Neil to do it. In truth, I
hope that they will not dive into this because in 2009 it
might turn out to have been a full waste of their time. But
I am noone, and their motivations are their business only,
so they will do what they want.
Will Guile gain active users if it goes R6RS? Will Guile
loose active users if it does not go R6RS?
>Unfortunately for you Guile is widely deployed and coded to;
I do not see where is my misfortune in this.
>those users also define "what guile is".
They define what Guile 1.8 has been.
>Radical changes to the C interface are not going to be
>forthcoming.
This is probably true if Neil and Ludovic stop hacking it.
--
Marco Maggi
"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"
- Re: the future of Guile, (continued)
- Re: the future of Guile, Mike Gran, 2007/12/05
- Re: the future of Guile, Marco Maggi, 2007/12/05
- Re: the future of Guile, Marco Maggi, 2007/12/05
- Re: the future of Guile, Kjetil S. Matheussen, 2007/12/06
- Re: the future of Guile,
Marco Maggi <=
- Re: the future of Guile, Kjetil S. Matheussen, 2007/12/07