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"