Hello, "Marco Maggi" <[EMAIL PROTECTED]> 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
