@Julian Graham
>I've been frustrated with the situation, too. Might I
>direct your attention to the Snow project?
>(http://snow.iro.umontreal.ca/)
Rules, rules and rules! I don't know... It is not for me
because I am using C and GOOPS everywhere.
@Mike Gran
>As far as being an LFE, 1.8.x has been a big improvement
>over 1.6. The API is much cleaner when wrapping stuff by
>hand.
>From what I have seen of 1.6, I agree.
>One problem here is that there does need to be a richer
>library that is official and downloadable right from
>www.gnu.org/software/guile.
This is impossible. Too much coordination work. TCL has
something like this, but only because ActiveState is backing
it (and they make money with consultancy).
It would be an enormous success if every Guile related
package maintainer opens a project at the same site, like
GNA!, so that all the source code can be found with a search
for the string Guile at that site.
>Much has been done (GEE, Guile-lib, guile-gtk, all of TTN),
>but, each has its own packaging scheme, documentation
>scheme.
I feel guilty here because I do not digest GNU Automake, and
I have built my own (shock! horror!) GNU Make automation
using its functions. And I am the only one that can
understand it... :-/
>None of them are released in a coordinated manner with the
>Guile releases themselves.
This is true for different reasons. I, for example, am still
moving stuff around in GEE. If a roadmap comes with
milestones for Guile 1.9, I can try to make alpha releases
that build with them.
>First, dependencies on the many libraries are difficult to
>coordinate.
Ugh! And I am making it worse with GEE 0.4 ...
This is linked with the application deployment problem. With
a self executing archive we could distribute a single
executable with everything in it. It is not a tool that we
can build in an afternoon, though.
@Ludovic Courts
>It took me some time, but I now think there's no such sharp
>distinction between "LFE" and "SI".
Yep. Probably I am giving too much importance on the size of
the core library.
>> As a SI my opinion is that some sort of compiler is a must,
>
>An interpreter *can* be much faster than what we have now
Really? Fine!
>>an interface to bind the class to a symbol in a module.
>
>[...] is easily addressed, by defining said class in your
>module to `(@ (oop goops) <SMOB-NAME>)'
Woah! I had not noticed that the binding is created in (oop
goops).
>> Anyway, remembering "scm_remember_upto_here" is really
>> annoying. And it is needed almost every time I access the
>> client data of a custom SMOB.
>
>This is strange. I rarely had to use it, and I can't think
>of a common programming pattern where it's useful.
SCM
my_func (SCM arg)
{
client_data_t data = (client_data_t)SCM_SMOB_DATA(arg);
/* Do something with "data" but do not access "arg"
anymore. With compiler optimisations the reference
to the SMOB can disappear.
If here I call scm_* functions, GC collects the
SMOB removing the carpet from under my feet and
if I access "data": crash.
So:
*/
scm_remember_upto_here_1(arg);
}
>> If structs are moved into an external shared library,
>> records can go there, too.
>
>Records are too common to be removed from the core: almost
>everyone would end up loading that module.
This surprises me. I thought that they were a rarely used
feature because they are unschemey :-) and because of the
existence of GOOPS.
--
Marco Maggi
"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
