Re: the future of Guile

[Marco Maggi]

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