Re: the future of Guile

Re: the future of Guile

[Mike Gran]

> On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote:

> > Pre-answer to all: the most important thing is to make clear
> > what are  the priorities.  With a  "language for extensions"
> > (LFE)   there  are  certain   priorities,  with   a  "Scheme
> > implementation"  (SI) there are  others. I  fear that  if no
> > choice is made Guile will be wiped out by other Schemes.

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: Roland Orre <roland.orre@neurologic.se>

> Today, however, I find that there are nearly no extension
> libraries available for guile. As a shell scripting language
> I prefer python because it has a very simple and clean
> shell interface. To extend my applications beyond real number
> crunching with e.g. graphical interphases (currently working
> with xlib...) I feel a limitation and have more and more often
> looked upon python where a lot of libraries are available for
> GUI, database and you name it.

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.  Unit test, documentation, 
cgi, http, sql, md5, utf8, xml, and perhaps pickle.

Much has been done (GEE, Guile-lib, guile-gtk, all of TTN), 
but, each has its own packaging scheme, documentation
scheme.  None of them are released in a coordinated manner 
with the Guile releases themselves. 

This goes back to the packaging problem.  After I've written a program, 
I'd like to give it away for others to use.  Giving code away in a scripting 
language should be easy.  It isn't easy here. 

First, dependencies on the many libraries are
difficult to coordinate.

Second, most non-trivial scripts require the whole of the configure, 
make, make install, LD_LIBRARY_PATH, %load-path overhead.

Where is the analog of a Java jar file?

Apologies if my rant has drifted off topic.

Thanks,

Mike Gran






_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Julian Graham]

I've been frustrated with the situation, too.  Might I direct your
attention to the Snow project?  (http://snow.iro.umontreal.ca/)

One of the difficulties with these things is that they kind of require
a certain critical mass to establish themselves, and, so far,
nothing's really done that.  (SLIB, maybe?)  One thing that seems
apparent to me, though, is that any good packaging / library solution
is going to be cross-interpreter, so we should pay attention to what's
going on with PLT, Chicken, etc.


On Dec 5, 2007 10:40 AM, Mike Gran <spk121@yahoo.com> wrote:
>
>
> > On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote:
>
> > > Pre-answer to all: the most important thing is to make clear
> > > what are  the priorities.  With a  "language for extensions"
> > > (LFE)   there  are  certain   priorities,  with   a  "Scheme
> > > implementation"  (SI) there are  others. I  fear that  if no
> > > choice is made Guile will be wiped out by other Schemes.
>
> 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: Roland Orre <roland.orre@neurologic.se>
>
> > Today, however, I find that there are nearly no extension
> > libraries available for guile. As a shell scripting language
> > I prefer python because it has a very simple and clean
> > shell interface. To extend my applications beyond real number
> > crunching with e.g. graphical interphases (currently working
> > with xlib...) I feel a limitation and have more and more often
> > looked upon python where a lot of libraries are available for
> > GUI, database and you name it.
>
> 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.  Unit test, documentation,
> cgi, http, sql, md5, utf8, xml, and perhaps pickle.
>
> Much has been done (GEE, Guile-lib, guile-gtk, all of TTN),
> but, each has its own packaging scheme, documentation
> scheme.  None of them are released in a coordinated manner
> with the Guile releases themselves.
>
> This goes back to the packaging problem.  After I've written a program,
> I'd like to give it away for others to use.  Giving code away in a scripting
> language should be easy.  It isn't easy here.
>
> First, dependencies on the many libraries are
> difficult to coordinate.
>
> Second, most non-trivial scripts require the whole of the configure,
> make, make install, LD_LIBRARY_PATH, %load-path overhead.
>
> Where is the analog of a Java jar file?
>
> Apologies if my rant has drifted off topic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Daniel Ridge]

On mike's question about the natural analog of the jar file, I find  
that one of the big binary distribution hurdles for guile code has  
been static paths baked everywhere. Static, absolute paths get baked  
into libtool .la files when the underlying platform does not  
necessarily require it.

Guile itself contributes to this relocatability problem with the way  
guile-config uses %guile-build-info,%library-dir,%package-data-dir,% 
site-dir.

I use guile as an extension language in all of my codes. In almost  
every case I need to build guile alongside my application. Guile's  
relocatability problems become my own. I hack boot-9.scm to prefer a  
prefix from the environment to the one baked into % guile-build-info.  
My programs are typically wrapped with a shell script that figures out  
where they live and updates LD_LIBRARY_PATH and the prefix for guile  
and execs the prog.

When I use guile to load shared objects, I'm not demonstrating a  
preference for Scheme hacking vs extension hacking, as some would  
claim. Instead, I'm using it as as as 'extension linker' that grabs  
code needed by my underlying application. Guile often just marshalls  
args from C through Scheme back to C. Along the way, many calls become  
transparent RPCs. Guile is absolutely excellent at this. In many  
cases, I use guile to marshall args to RPCs evaluated in other Scheme  
runtimes that play less well with C.

With the elimination of just a couple of  these problems, guile and  
guile extended apps run quite nicely from live CDs, loopback mounted  
disk images, and even Apple's relocatable application bundles.

On Dec 5, 2007, at 10:40, Mike Gran <spk121@yahoo.com> wrote:

>
>
>> On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote:
>
>>> Pre-answer to all: the most important thing is to make clear
>>> what are  the priorities.  With a  "language for extensions"
>>> (LFE)   there  are  certain   priorities,  with   a  "Scheme
>>> implementation"  (SI) there are  others. I  fear that  if no
>>> choice is made Guile will be wiped out by other Schemes.
>
> 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: Roland Orre <roland.orre@neurologic.se>
>
>> Today, however, I find that there are nearly no extension
>> libraries available for guile. As a shell scripting language
>> I prefer python because it has a very simple and clean
>> shell interface. To extend my applications beyond real number
>> crunching with e.g. graphical interphases (currently working
>> with xlib...) I feel a limitation and have more and more often
>> looked upon python where a lot of libraries are available for
>> GUI, database and you name it.
>
> 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.  Unit test, documentation,
> cgi, http, sql, md5, utf8, xml, and perhaps pickle.
>
> Much has been done (GEE, Guile-lib, guile-gtk, all of TTN),
> but, each has its own packaging scheme, documentation
> scheme.  None of them are released in a coordinated manner
> with the Guile releases themselves.
>
> This goes back to the packaging problem.  After I've written a  
> program,
> I'd like to give it away for others to use.  Giving code away in a  
> scripting
> language should be easy.  It isn't easy here.
>
> First, dependencies on the many libraries are
> difficult to coordinate.
>
> Second, most non-trivial scripts require the whole of the configure,
> make, make install, LD_LIBRARY_PATH, %load-path overhead.
>
> Where is the analog of a Java jar file?
>
> Apologies if my rant has drifted off topic.
>
> Thanks,
>
> Mike Gran
>
>
>
>
>
>
> _______________________________________________
> Guile-user mailing list
> Guile-user@gnu.org
> http://lists.gnu.org/mailman/listinfo/guile-user


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

Hi,

Mike Gran <spk121@yahoo.com> writes:

> Much has been done (GEE, Guile-lib, guile-gtk, all of TTN), 
> but, each has its own packaging scheme, documentation
> scheme.  None of them are released in a coordinated manner 
> with the Guile releases themselves. 

They don't have to be coordinated.  We may want, from time to time, to
move commonly used code e.g., from Guile-Lib, into Guile core, but we're
not going to have all possible Guile bindings into Guile core.

> Second, most non-trivial scripts require the whole of the configure, 
> make, make install, LD_LIBRARY_PATH, %load-path overhead.

For pure Scheme applications or modules, there's little overhead.  You
can use Autoconf + Automake (I use it because I find it helpful and
consistent with other free software packages), but you don't have to.
You can as well just distribute and bunch of suitably laid out Scheme
files along with a `README' explaining how to use them.  :-)

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Kjetil S. Matheussen]

"Marco Maggi":
>>> 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?
>

When I developed this:
http://www.notam02.no/arkiv/doc/snd-rt/ , my biggest problem
was all crashes related to garbage collection.

I think I got rid of the last garbage collector-bug in september 2006, 
which was related to the ladspa plugin[1] SMOB in the function
rt-compiler.scm/make-ladspa. In that function, the variable "handle"
could be garbage collected during the execution
of the function. The diff for the fix is here:

http://snd.cvs.sourceforge.net/snd/cvs-snd/rt-compiler.scm?r1=1.45&r2=1.46

I think the exampe above shows how insanely complicated things
can get when you manually have to tell guile's garbage collector
what to scan and what not,  and I also think it was
a miracle that I eventually spotted the bug. :-)

So in my experience, the current system is very inconvenient, and should 
be replaced by a general garbage collector which works also works
for C objects, where this and other related problems wouldn't be an 
issue.


[1] ladspa is the linux audio plugin format


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

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"




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Kjetil S. Matheussen]

"Marco Maggi":
>> 3b. Death to  structs!  IMO they were "an  attempt", but the
>>     resulting code is awful (sorry, but can you disagree?).
>>
>> Err..  but aren't  structs the  main  part of  how GOOPS  is
>> implemented?
>
> IMO Guile's  structs do nothing  that cannot be  done better
> with a good old C struct  wrapped by a SMOB.


I've mentioned this before, but In Snd there is a function to
automatically create C structs. You have to free
the underlying c object manually though, but adding a SMOB
wrapper around shouldn't be that hard.

Oh, and thats yet another "should" for HBGC:
You don't need to mess with SMOBs to garbage collect C
objects when using the HBGC.


(load "eval-c.scm")

(define-ec-struct <struct_name>
   <int> one
   <float-*> twos
   <char-*> three
   <SCM> scm)

(define test (<struct_name> :one 1
 			    :twos '(2)
 			    :three "three"))

(-> test one)
=> 1

(-> test one 90)
(-> test one)
=> 90

(-> test twos)
=> (2.0)

(-> test twos '(4 5 6))
(-> test twos)
=> (4.0 5.0 6.0)

(-> test three)
=> "three"

(-> test three "four")
(-> test three)
=> "four"

(-> test scm)
=> #f

(-> test scm (lambda (x) x)) ;; stored elsewhere too, so it won't be gc-ed.
(-> test scm)
=> #<procedure #f ((x) x)>

(-> test get-size)
=> 16

(-> test get-c-object)
=> ("A_POINTER" 147502592)


(-> test destructor) ;;free it



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

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"




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

Hi Marco,

"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:

> Woah! I had not noticed  that the binding is created in (oop
> goops).

He he.  ;-)

> 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);
> }

Hmm, right (except if ARG was passed on the stack, which must not be the
case with most ABIs).

OTOH, when `my_func ()' is a subr called by the evaluator, there
definitely are live references to ARG in the heap (argument list) and
probably on the stack too (local variables in `CEVAL ()'), which is why
it rarely hurts in practice...

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

Well, maybe my statement was too strong.  At least I do use records a
lot.  Any programming language needs vector-like data structures, and
records provide a convenient interface to them in many scenarios.

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Marco Maggi]

"Roland Orre" wrote:
>How about setting up a voting/wishing site to collect
wishes for
>our visions and desires about guile, and in what way we can
>contribute to this?

If there is interest in having such a thing, it is a matter of
5 minutes with Jottit <http://jottit.com/>, they have a
screencast
with a tutorial from the about page.

I am not sure that voting on topics can work though. This is
the Net not a polite society...

One thing that would be useful is to have a page with a roadmap
like this one <http://wiki.tcl.tk/12753> for Tcl.

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

Re: the future of Guile

[Marco Maggi]

Pre-answer to all: the most important thing is to make clear
what are  the priorities.  With a  "language for extensions"
(LFE)   there  are  certain   priorities,  with   a  "Scheme
implementation"  (SI) there are  others. I  fear that  if no
choice is made Guile will be wiped out by other Schemes.

Call me stupid if you want, but I picked Guile because the G
stands for GNU  and the E stands for  Extensions.  I look at
the E as a promise: There will always be special interest in
making it easy to interface with C.  Now I am not sure if it
was a good choice.

I  tried to  attract users  interested in  math  software by
coding extensions to special numbers  and the GSL.  I did it
for my own  interest, not "for Guile". But  I failed. I will
never know why (maybe it was  just a bad idea), but maybe it
is because Guile  is too slow and the fact  that Scheme is a
beautiful and  featureful language (compared  to Octave, for
example) is not enough.

It is all FUD, yes, but in  the last 7 years a lot of people
said that "TCL is dead".  Lately on comp.lang.tcl they had a
discussion on  a unified interface for  database access; and
they are going  to do it. This is not  being dead. For Guile
we cannot even  talk about such a thing; correct  me if I am
wrong, but on the Net there are mostly orphaned projects for
Guile...

Ludovic,  you are doing  an incredible  amount of  work. But
everybody's life moves on.  How many active Guile developers
are there? Or at least developers that are "still here"? How
many active ones understand the evaluator?

So, how much work is needed to make Guile a good choice "for
something"? As  a LFE I think  that the work  needed is less
than what is required for a SI.

As a SI my opinion is  that some sort of compiler is a must,
but  it is  a lot  of work  (I took  a look  at Lightning...
there are  soooo many  opcodes...).  You can  try to  do any
algorithmic stunt  to make Guile faster  without a compiler,
but will it be enough for someone?

@Stephen Compall:
>> 3. For Guile 2.0 backwards  compatibility at the C level can
>>    be broken. Freely. No shame. No blame.
>
>This message references another message that I can't find:
>
>http://lists.gnu.org/archive/html/guile-devel/2003-04/msg00076.html
[stuff about inclusion of deprecated code]

@Neil Jerram:
>Disagree, in general.  Why should we be arbitrarily awkward?
>If there are specific  motivations, we should consider those
>case by case.

How much does it cost never  to discard a thing?  With a LFE
a huge shared library is not "lightweight". Can something be
discarded at least in the 1.x -> 2.x transition?

With "everything is a SMOB" and "death to structs" something
in the  interface changes.  I am not  talking about changing
"scm_to_int" and  the like, but, for example,  if a function
to bind  a <smob-name> symbol  to the class  of a SMOB  in a
selected module  is added:  the SMOB definition  protocol is
changed  a  bit.  The  same  with  a  function that  selects
superclasses.

More on this later about the limit on SMOB number.

@Ludovic Courts
>> 2. GOOPS always there.
>
>GOOPS is  nice at times,  but it's also very  "unschemey" in
>spirit, [...]

I am not  sure what you mean here. The ugly  thing for me is
that the  DEFINE-* must be at  top level; I  dunno why. This
prevented me  from trying  some automation (I  cannot recall
which ones now).

Generic functions  must be mutable  and they must  be "entry
points"  in a big  graph-like data  structure.  That  is the
only way to  do it.  I think that there  is consensus on the
idea  that  generic  functions  are  one of  the  points  of
strength of Lisps.

The thing  I know  is that coding  a math  extension without
them would be  a nightmare (there is a reason  if I have not
written my stuff for TCL).


@Ludovic Courts
>> 2a.   It  is  fine  to  have  both  procedures  and  generic
>>     functions,   but  the  default   for  Guile's   C  coded
>>     procedures  must  be  primitive generic.
>
>What would  it buy you  if `read' were a  primitive generic?
>`write' is  certainly useful as  a generic, but I  don't see
>the benefit of `read' as a generic.

READ is a nice short  symbol and everybody knows its meaning
in real life. It should  be available for everyone to use as
function name.  I do not  care if MAKE-PROCEDURE-WITH-SETTER
is not a generic function because it is unlikely that I need
such a name for a method, but READ...


@Ludovic Courts
>> 3a. The limit on SMOB type number must be destroyed.
>
>It's  gonna be  hard since  we  have only  8 bits  available
>currently[...]

A possible solution is to use the first level SMOBs only for
Guile-defined  ones, and  change the  implementation  of the
public API  for SMOB  definition to use  an evolution  of my
subordinate SMOB thing.


@Neil Jerram
> 3b. Death to  structs!  IMO they were "an  attempt", but the
>     resulting code is awful (sorry, but can you disagree?).
>
>Err..  but aren't  structs the  main  part of  how GOOPS  is
>implemented?

IMO Guile's  structs do nothing  that cannot be  done better
with a good old C struct  wrapped by a SMOB.  The thing I am
sure of is that structs are preventing me from understanding
what  goes on  in  "goops.c":  too much  work  is needed  to
understand the data structures layout.


@Ludovic Courts
>> 3c. Every  SMOB must  have a class  and an optional  list of
>>     superclasses, to allow  for methods dispatching.
>
>As  you  noted  in  a  recent  post,  SMOBs  types  have  an
>associated class when GOOPS is  loaded.  So what else do you
>want?

An optional  list of superclasses  and an interface  to bind
the class to a symbol in a module. At present I have to do:

  if (scm_smob_class)
    scm_c_define("<" SMOB_DESCRIPTION ">",
      scm_smob_class[SCM_TC2SMOBNUM(gvector_smob_driver)]);

but I think  that at the public API level  I am not required
to    know    what    "scm_smob_class"   is,    let    alone
"SCM_TC2SMOBNUM".

Anyway, that  feature is undocumented;  so now I have  to go
back to change all my  GOOPS interfaces that wrap SMOBs. But
first I have to understand  how to register a method that is
directly implemented with  a compiled procedure: ADD-METHOD!
wants Scheme level procedures...  If only I could understand
where methods are stored...


@Stephen Compall
>> 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).
>
>I am  not a GC  expert, but it  is my understanding  that as
>long as  SMOBs can own  non-GC-controlled mallocations freed
>by the SMOB free function, you need those macros/functions[...]

@Ludovic Courts
>Well, `scm_remember_upto_here ()' is rarely need anyway.

This  is Guideline #2  for a  LFE.  I  wrote this  because I
recall  to have read  a discussion  about an  alternative GC
that does not require it.  I think that it is the one Kjetil
is referring  to, but I am  not able to find  the message in
which someone stated that.

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.


@Ludovic Courts
>> 6. More modularity.
>
>I think we  could almost have one module  per C source file,
>e.g., `socket', `posix', `filesys', etc.

Fine.

>(however, we  definitely don't  want one shared  library per
>module, because of the overhead).

Ugh! The only reason I see to split up is to reduce the size
of the core shared library.


@Stephen Compall
>> 6c. GMP  support should  go into a  loadable module  (do not
>>     nuke my mailbox, please).
>
>Er, what would happen if you overflow fixnums?

The  same very  bad things  that happen  with all  the other
languages  that do  not support  bignums. A  LFE  should not
depend upon another big thing  like GMP (and should not come
with  bignums embedded),  but there  are no  problems  for a
SI. What  is the probability  of overflowing a  fixnum while
reading a config file like the one of Serveez?


@Ludovic Courts
>> 6d. Floating point math procedures should go into a loadable
>>     module.
>
>Likewise.

I am  talking about  the SIN, COS,  TAN, ...  functions, the
ones  in the  Scientific Info  node.  It  is another  way of
reducing a bit the size of the core shared library.

@Ludovic Courts
>> 6e. Records should go into a loadable module.
>
>SRFI-9 records? They are already in a "loadable" module. :-)

If  structs  are  moved  into an  external  shared  library,
records can go there, too.


@Neil Jerram
>> 8. Hackability of the core. If nobody understands it...
>
>Is it really that difficult?

How many can say: I  understand the evaluator? And GOOPS, as
it  is now,  is beyond  what an  occasional  contributor can
understand in a few hours.


@Neil Jerram
>> 8c. This is for my own ego: yeah, yeah, yeah! Define:
>>
>> 	typedef SCM scm_t;
>>
>
>Surely there's an elisp  incantation that would make it kiss
>SCM for you?

Of course! :-)


"Marco Maggi" wrote:
> 1. TCL  has nice  programs that  allow to  distribute single
>    file  auto-extracting-and-running  archives  holding  the
>    core executable,  shared libraries, pure  TCL modules and
>    some data files (search for "tclkit").

@Neil Jerram
>I don't  think that a  programming language should  have its
>own packaging  system.

I am  not talking about  a packaging system like  .deb, .rpm,
etc.  Tclkit is  a  solution to  the application  deployment
problem. It seems that among Tclers it had a lot of success.


@Neil Jerram
>> 3. Resurrect SCWM (Scheme Constraints Window Manager).
>
>I've settled happily on ion2 now.  I suspect a WM may be one
>of those things that  doesn't really need much scripting, so
>I'm not sure what SCWM would be aiming at.

IMHO Serveez and a WM for X are perfect usage examples for a
LFE. I use  Fvwm, and its configuration file  is yet another
pseudo-language  that I  have to  remember. A  design choice
that makes sense for them, makes sense for Guile as a LFE.

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

Re: the future of Guile

[Roland Orre]

On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote:
> Pre-answer to all: the most important thing is to make clear
> what are  the priorities.  With a  "language for extensions"
> (LFE)   there  are  certain   priorities,  with   a  "Scheme
> implementation"  (SI) there are  others. I  fear that  if no
> choice is made Guile will be wiped out by other Schemes.

I agree with Marco, that the reason for choosing a particular
language is essential. My choice of guile is based upon my
earlier choice of scm (Aubrey Jaffer) as extension language as
scm was the basis for guile.

At that time (early 90ies) I wanted a small and efficient scheme
with a simple C interface. The choices were basically between ELK
and scm as I remember, but as I remember scm had much better
performance and some other benefits.

My strategy is to write the high level scripts in scheme and
heavy number crunching (data mining) stuff in C. For this purpose
scm and later guile has served very well.

Today, however, I find that there are nearly no extension
libraries available for guile. As a shell scripting language
I prefer python because it has a very simple and clean
shell interface. To extend my applications beyond real number
crunching with e.g. graphical interphases (currently working
with xlib...) I feel a limitation and have more and more often
looked upon python where a lot of libraries are available for
GUI, database and you name it.

However, I like scheme and I think I ideally would like an
environment where I could use scheme,C and python arbitrarily.
I consider that scheme is a much cleaner language than e.g. python,
and have several advantages.

How about setting up a voting/wishing site to collect wishes for
our visions and desires about guile, and in what way we can
contribute to this? For my own I haven't done much, I added the
sorting routines a few years ago and the first apropos function
but if there was a way to make a "language independent" nucleus
where applications could easily be written in e.g. scheme,
python or possible other popular langauges like ruby I could
possibly contribute to this.

Could e.g. the goops package be used for implementation of a
common object structure as python?

OK, it is not for granted that a multi language platform
may be optimal, other ideas?

/Roland





_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

Hello,

"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:

> Pre-answer to all: the most important thing is to make clear
> what are  the priorities.  With a  "language for extensions"
> (LFE)   there  are  certain   priorities,  with   a  "Scheme
> implementation"  (SI) there are  others. I  fear that  if no
> choice is made Guile will be wiped out by other Schemes.

It took me some time, but I now think there's no such sharp distinction
between "LFE" and "SI".  With the LFE paradigm in mind, one thinks about
a C application occasionally calling Scheme code.  But as you want more
extensibility, you rather end up having a Scheme application
occasionally calling C code.

This is what SIs are about: being able to do the best with Scheme code,
while still allowing interfaces with C code.

> For Guile we cannot even talk about such a thing; correct me if I am
> wrong, but on the Net there are mostly orphaned projects for Guile...

I'm not sure about the "mostly", but there's surely a huge amount of
orphaned projects, including VMs, compilers and the likes.

> How many active Guile developers are there? Or at least developers
> that are "still here"? How many active ones understand the evaluator?

Neil and Kevin (at least) have been here for a long time, and I'm sure
they understands large parts of the project.  Now, it's true that few of
us are spending a lot of time to actually create new stuff and set a
direction.  I encourage others to contribute too, but we need this kind
of discussion to get an idea of what we're heading to.

> As a SI my opinion is  that some sort of compiler is a must,
> but  it is  a lot  of work  (I took  a look  at Lightning...
> there are  soooo many  opcodes...).  You can  try to  do any
> algorithmic stunt  to make Guile faster  without a compiler,
> but will it be enough for someone?

An interpreter *can* be much faster than what we have now, and SICP
(among others) is here to guide us.

> @Ludovic Courts
>>> 2. GOOPS always there. 
>>
>>GOOPS is  nice at times,  but it's also very  "unschemey" in
>>spirit, [...]
>
> I am not  sure what you mean here.

Then I failed to convey my feeling.  ;-)

It's really a matter of taste: I've become more and more interested in
the functional aspect of Scheme (and other languages), and have come to
dislike the imperative programming style.

> READ is a nice short  symbol and everybody knows its meaning
> in real life. It should  be available for everyone to use as
> function name.  I do not  care if MAKE-PROCEDURE-WITH-SETTER
> is not a generic function because it is unlikely that I need
> such a name for a method, but READ...

Then generic functions are not the right tool.  What you want is
"(define core-read read)" or something like that.  Then you can use the
name `read' in your modules for whatever pleases you---and in practice,
you may not always need core `read' anyway.

> A possible solution is to use the first level SMOBs only for
> Guile-defined  ones, and  change the  implementation  of the
> public API  for SMOB  definition to use  an evolution  of my
> subordinate SMOB thing.

Maybe, I don't have a clear picture of the possible solutions.

> @Ludovic Courts
>>> 3c. Every  SMOB must  have a class  and an optional  list of
>>>     superclasses, to allow  for methods dispatching.
>>
>>As  you  noted  in  a  recent  post,  SMOBs  types  have  an
>>associated class when GOOPS is  loaded.  So what else do you
>>want?
>
> An optional  list of superclasses  and an interface  to bind
> the class to a symbol in a module.

OK, got it.  The latter is easily addressed, by defining said class in
your module to `(@ (oop goops) <SMOB-NAME>)', though it's admittedly not
very elegant.

As for the former, well, I dunno.  It may have unforeseen implications.

> @Ludovic Courts
>>Well, `scm_remember_upto_here ()' is rarely need anyway.
>
> This  is Guideline #2  for a  LFE.  I  wrote this  because I
> recall  to have read  a discussion  about an  alternative GC
> that does not require it.

Right, Boehm's GC is looks for object pointers in registers.

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

>>(however, we  definitely don't  want one shared  library per
>>module, because of the overhead).
>
> Ugh! The only reason I see to split up is to reduce the size
> of the core shared library.

Shared libraries add memory overhead as they need to be aligned on page
boundaries, symbol lookup overhead, among others.  Ulrich Drepper wrote
a nice article about the pitfalls of writing DSOs (shared libs) but I
can't find it.

> The  same very  bad things  that happen  with all  the other
> languages  that do  not support  bignums.

... which is the raison d'être of Scheme's numeric tower.  :-)

> I am  talking about  the SIN, COS,  TAN, ...  functions, the
> ones  in the  Scientific Info  node.  It  is another  way of
> reducing a bit the size of the core shared library.

These are very common procedures, part of R5RS, and you wouldn't gain
much by removing them.

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

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of guile

[Daniel Llorens del Río]

On 4 Dec, 2007, at 18:01, guile-user-request@gnu.org wrote:

>> 1a. Why functions like  SIN have a Scheme implementation for
>>     complex numbers when standard C has "csin"?
>
> In Scheme, any real is also complex. That's not the case in C. I hope
> you're not proposing to separate the numeric types in Scheme.

Ok, I misunderstood. Now I see what you mean. Sorry :)



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Kjetil S. Matheussen]

"Marco Maggi":
>
> 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).

If we replace "should" with "must", I agree.

Regarding the HBGC, a few nonscientific tests earlier this year
showed that HBGC had _much_ lower latency than Guile's garbage
collector.

I am planning to measure the difference in latency properly
quite soon, and if what I suspect is correct, that the HBGC
has significant lower latency, this is another "should"
for replacing the old one, even if the new one is a little
bit slower and use a little bit more memory.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Kjetil S. Matheussen]

On Tue, 4 Dec 2007, Kjetil S. Matheussen wrote:

> 
> "Marco Maggi":
> >
> > 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).
> 
> If we replace "should" with "must", I agree.
> 
> Regarding the HBGC, a few nonscientific tests earlier this year
> showed that HBGC had _much_ lower latency than Guile's garbage
> collector.
> 
> I am planning to measure the difference in latency properly
> quite soon, and if what I suspect is correct, that the HBGC
> has significant lower latency, this is another "should"
> for replacing the old one, even if the new one is a little
> bit slower and use a little bit more memory.
> 

Oh, and another thing. My tests (available in the guile-devel archives)
also showed that the HBGC version usually use a bit less memory
than Guile's old garbage collector. (Yet another "should"
for replacing. :-) )



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Roland Orre]

On Tue, 2007-12-04 at 19:34 +0100, Kjetil S. Matheussen wrote:
...
> Oh, and another thing. My tests (available in the guile-devel archives)
> also showed that the HBGC version usually use a bit less memory
> than Guile's old garbage collector. (Yet another "should"
> for replacing. :-) )

I don't have much experience with different GC algorithms, but
as I understand the HBGC is not intended for background GC.

If the GC should be replaced I would consider it wise to
replace it with an algorithm than can be run in a thread.
This I consider strongly motivated by the fact that most new
machines today are multi core. An efficient way to decrease the
latency of the GC is to simply run it in background.

Regarding GC I also think it is could be useful to have a GC that
can compact the memory and of course give allocated memory back to
the OS when no longer needed. OK, a compacting GC may make it
hard to write applications, so don't take this point too
seriously...

/Roland



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

Hi,

Roland Orre <roland.orre@neurologic.se> writes:

> If the GC should be replaced I would consider it wise to
> replace it with an algorithm than can be run in a thread.

HBGC can be configured with `--enable-parallel-mark'.  The `GC_MARKERS'
environment variable then sets the number of marker threads.

> Regarding GC I also think it is could be useful to have a GC that
> can compact the memory and of course give allocated memory back to
> the OS when no longer needed.

HBGC doesn't compact memory and does not either give unused memory back
to the OS (current GC doesn't either).

Thanks,
Ludovic.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Kjetil S. Matheussen]

On Tue, 4 Dec 2007, Roland Orre wrote:

> On Tue, 2007-12-04 at 19:34 +0100, Kjetil S. Matheussen wrote:
> ...
>> Oh, and another thing. My tests (available in the guile-devel archives)
>> also showed that the HBGC version usually use a bit less memory
>> than Guile's old garbage collector. (Yet another "should"
>> for replacing. :-) )
>
> I don't have much experience with different GC algorithms, but
> as I understand the HBGC is not intended for background GC.
>

Actually, it does:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html



> If the GC should be replaced I would consider it wise to
> replace it with an algorithm than can be run in a thread.
> This I consider strongly motivated by the fact that most new
> machines today are multi core. An efficient way to decrease the
> latency of the GC is to simply run it in background.
>

Sure, that would be great. But I don't think you know how hard
it is to actually do that... But as a matter of fact, the HBGC do
at least support parallell marking though, and I also think the
HBGC patch for guile supports that feature.



> Regarding GC I also think it is could be useful to have a GC that
> can compact the memory

I think the HB gc does a pretty good job of not fragmenting the memory
at least.



> and of course give allocated memory back to
> the OS when no longer needed.

Well, Don't think you need that feature very often when using an OS 
supporting virtual memory.


Anyway, there is no third option here. The two choices are Guile's 
own garbage collector and Hans Boehms general garbage collector.
The last one is used in a bunch of other programming languages with great 
success, and except for being a bit slower on uniprocessor machines
when running a garbage collector benchmark, the HBGC seems
to generally work better for Guile than Guile's own GC.

Personally I hope the Guile developers choose to switch to HBGC when 
starting the next development cycle of Guile.



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of guile

[Daniel Llorens del Río]

On 4 Dec, 2007, at 15:50, guile-user-request@gnu.org wrote:

> 1a. Why functions like  SIN have a Scheme implementation for
>     complex numbers when standard C has "csin"?

In Scheme, any real is also complex. That's not the case in C. I hope  
you're not proposing to separate the numeric types in Scheme.




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

the future of Guile

[Marco Maggi]

Ciao,

I think that  it is time for a chat on  the future of Guile.
It is  a difficult topic,  but: the sooner, the  better. The
plan I  outline below requires  a lot of  work and a  lot of
discussion, and I can volunteer only for some of it.  But of
what use is the silence?

It seems clear  to me that Guile cannot  compete in terms of
speed with  projects like  PLT Scheme, Ikarus  and YouNameIt
Scheme with a native/JIT/VM/TheNext compiler.

But it does not have to  because, like it or not, Guile is a
language for extensions. With this in mind...


Guidelines
----------

1. Guile as a lightweight choice.

2. Simplicity of the C interface.

3. For Guile 2.0 backwards  compatibility at the C level can
   be broken. Freely. No shame. No blame.


Concrete goals
--------------

1. ISO C99, can we look forward?

1a. Why functions like  SIN have a Scheme implementation for
    complex numbers when standard C has "csin"?

2. GOOPS always there.

2a.   It  is  fine  to  have  both  procedures  and  generic
    functions,   but  the  default   for  Guile's   C  coded
    procedures  must  be  primitive generic.   Non-primitive
    generics  are allowed  as  exceptions (case:  READ is  a
    primitive procedure, dunno why).

3. Everything  must  be  a  SMOB:  ports,  values,  classes,
   instances. We can fight over procedures.

3a. The limit on SMOB type number must be destroyed.

3b. Death to  structs!  IMO they were "an  attempt", but the
    resulting code is awful (sorry, but can you disagree?).

3c. Every  SMOB must  have a class  and an optional  list of
    superclasses, to allow  for methods dispatching. This is
    not meant to  be an attempt to "corrupt"  the concept of
    class, but a mean to extend methods dispatching.

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).

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.

5a. A lighter  feature would be useful, too:  to collect all
    the  allocated SMOBs  (running GC  twice,  guardians can
    release async resources). It would be optional, so it is
    all right to have situations in which this is forbidden.

6. More modularity.

6a.   All the  non-string ports  should go  into  a loadable
    module.

6b. The networking stuff should go into a loadable module.

6c. GMP  support should  go into a  loadable module  (do not
    nuke my mailbox, please).

6d. Floating point math procedures should go into a loadable
    module. Once they are there, more functions can be added
    (from  the  standard C  library  and  not)  and a  "long
    double" SMOB can be put in, too.

6e. Records should go into a loadable module.

7. Every feature can be added as a loadable module.

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).

8. Hackability of the core. If nobody understands it...

8a. Ludovic, do  you still have that patch  that reduces the
    size of  the evaluator? I  do not want to  hurt anyone's
    feelings, but I do not understand why it was rejected.

8b. There  are struct  types in the  core whose name  is not
    prefixed with "scm_t_" (example: scm_metaclass_standard)
    this  should be  fixed. (Yes,  I  am a  nazi with  other
    people's code and I allow mine to become wastesource.)

8c. This is for my own ego: yeah, yeah, yeah! Define:

	typedef SCM scm_t;

    Emacs font locking kisses "scm_t" automatically.


Tough ones
----------

1. TCL  has nice  programs that  allow to  distribute single
   file  auto-extracting-and-running  archives  holding  the
   core executable,  shared libraries, pure  TCL modules and
   some data files (search for "tclkit").

2. Resurrect Serveez.

3. Resurrect SCWM (Scheme Constraints Window Manager).

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

Re: the future of Guile

[Stephen Compall]

[-- Attachment #1.1: Type: text/plain, Size: 1919 bytes --]

On Tue, 2007-12-04 at 07:50 +0100, Marco Maggi wrote:
> 3. For Guile 2.0 backwards  compatibility at the C level can
>    be broken. Freely. No shame. No blame.

This message references another message that I can't find:

http://lists.gnu.org/archive/html/guile-devel/2003-04/msg00076.html

> 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). 

I am not a GC expert, but it is my understanding that as long as SMOBs
can own non-GC-controlled mallocations freed by the SMOB free function,
you need those macros/functions, GCPRO structures, or refcounting to
work with C code that can poke at their contents.  I guess you could
disable GC while executing subrs not marked safe-for-GC....

> 6c. GMP  support should  go into a  loadable module  (do not
>     nuke my mailbox, please).

Er, what would happen if you overflow fixnums?

> 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).

7a1. Inter-module hygiene/implicit exports.

> 1. TCL  has nice  programs that  allow to  distribute single
>    file  auto-extracting-and-running  archives  holding  the
>    core executable,  shared libraries, pure  TCL modules and
>    some data files (search for "tclkit").

I know of SBCL, CLISP, and PLT also doing this, but much more
sophisticated for the former 2.

-- 
Our last-ditch plan is to change the forums into a podcast, then send
RSS feeds into the blogosphere so our users can further debate the
legality of mashups amongst this month's 20 'sexiest' gadgets.
        --Richard "Lowtax" Kyanka

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

Hi,

"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:

> But it does not have to  because, like it or not, Guile is a
> language for extensions. With this in mind...

Right, although I question the "language for extensions" paradigm: why
would you choose language Y for "extensions" and language X for the
rest, given that (i) X sucks, (ii) Y rocks, and (iii) nothing inherently
makes programs in language Y "slower".  :-)

(Of course, language X allows you to re-use lots of libraries and tools,
so you definitely don't want to throw it away, but at least you want to
reduce the amount of code written in X.)

> 3. For Guile 2.0 backwards  compatibility at the C level can
>    be broken. Freely. No shame. No blame.

As Stephen suggested, we have to be cautious here.

> 2. GOOPS always there. 

GOOPS is nice at times, but it's also very "unschemey" in spirit,
relying on hard-to-follow side-effects for a lot of core operations (see
the `define-method' mess in G-Wrap), and biased towards an imperative
programming style.  I used to be a big fan, but I've become more and
more suspicious.

> 2a.   It  is  fine  to  have  both  procedures  and  generic
>     functions,   but  the  default   for  Guile's   C  coded
>     procedures  must  be  primitive generic.   Non-primitive
>     generics  are allowed  as  exceptions (case:  READ is  a
>     primitive procedure, dunno why). 

What would it buy you if `read' were a primitive generic?  `write' is
certainly useful as a generic, but I don't see the benefit of `read' as
a generic.

Besides, if turning primitives into primitive-generics doesn't slow down
Guile startup, then we can go for it.

> 3a. The limit on SMOB type number must be destroyed.

It's gonna be hard since we have only 8 bits available currently (BTW, I
saw your patch that adds support for sub-SMOBs but it looks complex to
me---more on that later).

> 3b. Death to  structs!  IMO they were "an  attempt", but the
>     resulting code is awful (sorry, but can you disagree?). 

We may have to keep it, at least for the sake of backward compatibility.

> 3c. Every  SMOB must  have a class  and an optional  list of
>     superclasses, to allow  for methods dispatching. This is
>     not meant to  be an attempt to "corrupt"  the concept of
>     class, but a mean to extend methods dispatching.

As you noted in a recent post, SMOBs types have an associated class when
GOOPS is loaded.  So what else do you want?

> 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). 

Well, `scm_remember_upto_here ()' is rarely need anyway.

> 6. More modularity. 

I think we could almost have one module per C source file, e.g.,
`socket', `posix', `filesys', etc. (however, we definitely don't want
one shared library per module, because of the overhead).  We could them
set up a backward-compatible namespace that pulls all of them, while
still leaving the opportunity to execute code in a minimal environment
where only core primitives are available.

> 6c. GMP  support should  go into a  loadable module  (do not
>     nuke my mailbox, please).

No way (see Stephen's reply).  :-)

> 6d. Floating point math procedures should go into a loadable
>     module. Once they are there, more functions can be added
>     (from  the  standard C  library  and  not)  and a  "long
>     double" SMOB can be put in, too.

Likewise.

> 6e. Records should go into a loadable module.

SRFI-9 records?  They are already in a "loadable" module.  :-)

> 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).

Agreed.

> 8a. Ludovic, do  you still have that patch  that reduces the
>     size of  the evaluator? I  do not want to  hurt anyone's
>     feelings, but I do not understand why it was rejected.

It did not really make it smaller, it just splitted it into several
parts.  The main arguments against it were that it splitted things badly
and that moving code around precludes auditing through diffs:

  http://lists.gnu.org/archive/html/guile-devel/2007-02/msg00040.html

> 8b. There  are struct  types in the  core whose name  is not
>     prefixed with "scm_t_" (example: scm_metaclass_standard)
>     this  should be  fixed.

Right.

> 8c. This is for my own ego: yeah, yeah, yeah! Define:
>
> 	typedef SCM scm_t;
>
>     Emacs font locking kisses "scm_t" automatically.

I'm afraid it's a bit too late, and we don't want two names for one
thing.

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Bill Schottstaedt]

> Right, although I question the "language for extensions" paradigm: why 
> would you choose language Y for "extensions" and language X for the 
> rest, given that (i) X sucks, (ii) Y rocks, and (iii) nothing inherently 
> makes programs in language Y "slower".  :-) 

There are several reasons to have different base and extension
languages.  The worst is that Guile/Scheme is 10 to 30 times
slower than the equivalent C code, and in DSP work, that matters.
For stuff involving vectors, C is much easier to read than Scheme.
Another is that everyone has his favorite language, and
by separating the basic stuff out, you can provide any number
of extension language choices at reasonably small cost (Snd
can be built with Guile, Gauche, Forth, Ruby, or no extension
language).  I've seen this "There is one Language and its
name is XXX" about 40 times -- at least once for every language
except maybe Pascal.  Of course, it was true in SAIL's case...




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

Hi,

"Bill Schottstaedt" <bil@ccrma.Stanford.EDU> writes:

> There are several reasons to have different base and extension
> languages.  The worst is that Guile/Scheme is 10 to 30 times
> slower than the equivalent C code, and in DSP work, that matters.

Of course it matters, but another solution would be to have a faster
Scheme implementation.

> Another is that everyone has his favorite language, and
> by separating the basic stuff out, you can provide any number
> of extension language choices at reasonably small cost (Snd
> can be built with Guile, Gauche, Forth, Ruby, or no extension
> language).

Right, but few applications really do this, probably because it's hard
to provide good integration and good maintenance of all these.

Actually, I'm not arguing against "embeddability", rather stating
that it should not serve as an excuse for not going beyond the mere
"language for extension" approach.  Among Schemers, many care about
writing applications in Scheme, rather than in C.  That people develop
Guile bindings for existing C libraries is an illustration.

Thanks,
Ludovic.


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Neil Jerram]

"Marco Maggi" <marco.maggi-ipsu@poste.it> writes:

> 3. For Guile 2.0 backwards  compatibility at the C level can
>    be broken. Freely. No shame. No blame.

Disagree, in general.  Why should we be arbitrarily awkward?  If there
are specific motivations, we should consider those case by case.

> 2. GOOPS always there. 

I think I agree.  I haven't developed Ludovic's suspicions yet.

> 3b. Death to  structs!  IMO they were "an  attempt", but the
>     resulting code is awful (sorry, but can you disagree?). 

Err.. but aren't structs the main part of how GOOPS is implemented?

> 6. More modularity. 

Yes, definitely, in general.  Like others I don't agree with trying to
split up the numerical tower though.

> 8. Hackability of the core. If nobody understands it...

Is it really that difficult?

(Actually the array code is pretty nasty, that could do with cleanup
if we can do that without breaking it!)

> 8c. This is for my own ego: yeah, yeah, yeah! Define:
>
> 	typedef SCM scm_t;
>
>     Emacs font locking kisses "scm_t" automatically.

Surely there's an elisp incantation that would make it kiss SCM for
you?

> 1. TCL  has nice  programs that  allow to  distribute single
>    file  auto-extracting-and-running  archives  holding  the
>    core executable,  shared libraries, pure  TCL modules and
>    some data files (search for "tclkit").

I don't think that a programming language should have its own
packaging system.  Instead, we should provide tools to make it trivial
to package up Guile code into the common kinds of distribution
package.

> 3. Resurrect SCWM (Scheme Constraints Window Manager).

I've settled happily on ion2 now.  I suspect a WM may be one of those
things that doesn't really need much scripting, so I'm not sure what
SCWM would be aiming at.

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Andy Wingo]

Greets,

I have had sufficient wine to respond.

On Tue 04 Dec 2007 07:50, "Marco Maggi" <marco.maggi-ipsu@poste.it> 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
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Mikael Djurfeldt]

2007/12/4, Marco Maggi <marco.maggi-ipsu@poste.it>:
> I think that  it is time for a chat on  the future of Guile.

Some pieces of input to the discussion:

* There is (or should be) a module called "workbook" in the
repository.  It contains policy documents setting out the direction
for Guile development.  It is important to be consistent regarding the
direction, over long time, otherwise Guile doesn't come very far.  The
Guile policy documents should be material for discussion if the future
of Guile is on the table.

* In my personal opinion, Guile needs a bytecode interpreter.  Keisuke
long ago wrote guile-vm which succeeded well concerning speed.  One
option is to dust it off and do the last part of development.

* Personal wish for Guile-2: Some primitive procedures, like display,
+ and equal? are, in principle, generics.  I think the evaluator
(eval.c), which currently is a frightening monster, could be both
cleaner and more efficient if all procedures were generic functions.
This could lead to the elimination of all special cases in eval.c and
elimination of argument checking in all primitives throughout the
Guile code base.

* It would be great if someone could complete the GOOPS meta object protocol.

* What about writing a python-module adapter so that Guile can
dynamically load python extension modules, using GOOPS for wrapping?
8-)


_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user