[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the future of Guile
From: |
Marco Maggi |
Subject: |
Re: the future of Guile |
Date: |
Wed, 5 Dec 2007 10:01:18 +0100 |
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"
- Re: the future of Guile, (continued)
- Re: the future of Guile, Neil Jerram, 2007/12/04
- Re: the future of Guile, Andy Wingo, 2007/12/05
- Re: the future of Guile, Mikael Djurfeldt, 2007/12/06
- Re: the future of guile, Daniel Llorens del Río, 2007/12/04
- Re: the future of Guile, Kjetil S. Matheussen, 2007/12/04
- Re: the future of guile, Daniel Llorens del Río, 2007/12/04
- Re: the future of Guile,
Marco Maggi <=
- Re: the future of Guile, Mike Gran, 2007/12/05
- Re: the future of Guile, Marco Maggi, 2007/12/05
- Re: the future of Guile, Marco Maggi, 2007/12/05
- Re: the future of Guile, Kjetil S. Matheussen, 2007/12/06