Re: the future of Guile

[Ludovic Courtès]

Hello,

"Marco Maggi" <address@hidden> 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.