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