Re: the future of Guile

[Marco Maggi]

@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"