Guile warts (was: [GOOPS] Specializing <generic> to allow lazy method addition)

* Guile warts (was: [GOOPS] Specializing <generic> to allow lazy method addition)
       [not found]       ` <xy74quhpgjj.fsf@chunk.mit.edu>
@ 2004-02-01 19:41         ` Andy Wingo
  2004-02-05 19:03           ` Guile warts Mikael Djurfeldt
  2004-02-18 22:22           ` Marius Vollmer
  0 siblings, 2 replies; 3+ messages in thread
From: Andy Wingo @ 2004-02-01 19:41 UTC (permalink / raw)
  Cc: guile-devel

[cc'ing to devel for the bug list -- please reply to -devel]

On Tue, 2004-01-27 at 17:17, Mikael Djurfeldt wrote:
> While the MOP for <class> works, the MOP for <generic> isn't yet
> implemented.

I might poke around with this, we'll see. But I reply for a different
reason: <class>, in (guile-user), is not the same as <class> in (oop
goops).

guile> (use-modules (oop goops))
guile> <class>
$2 = #<struct 805c4d0:805c4d0>
guile> (module-ref (resolve-module '(oop goops)) '<class>)
$3 = #<<class> <class> 80863b0>
guile> (is-a? <class> <class>)
$4 = #f

There are some warts that I see with guile 1.6, that I don't think are
fixed yet. I'm making this list to see if there are any objections to
it. Some of these I might get to patching and perhaps others are
inspired to fix some.

* The <class> issue

Can be solved by exporting <class> from (oop goops) ?

* The default namespace is a mess

The problem lies mostly in the fact that bindings used by internal
routines from boot-9.scm are exported, by default, to (guile-user). The
solution is difficult to see. As evidence to the problem, do you really
think that routines like `make-root-module' should be exported to the
normal namespace? Really though. Press TAB at the guile command prompt,
it's ridiculous.

** There are undocumented reserved words, like `app' and `repl'

These really really need to go, somehow. But again, the byzantine nature
of the module system makes it difficult to see the answer. At the very
least, these words (and perhaps others, and if we don't actually do
anything all of boot-9.scm) must be documented. Why can't I have a
module called (gnome gtk repl)?

** Some things in the default namespace should really be in modules of
their own

POSIX, for instance, should be in (os posix) or something. inet-*. All
the environment functions.  module-*.

...

I speak as a hacker on guile-gnome, which can output a holy shitload of
bindings. Every existing binding is important. When I load up gstreamer
and gtk+, I get the following conflicts:

.append  .delete  .hash    .load    .merge   .seek    .write
.close   .error   .id      .map     .raise   .select  .yield

Some of them need to keep their vanilla meanings, like map, write,
delete, load, and append. Maybe yield. But the others should come from
(os posix). And the irritating thing is that (define-method ...) just
overshadows the bindings on these ones, doesn't create the
primitive-generic.

I don't want to sound negative. I'm so much happier programming in guile
scheme than in any other language I've tried. But I do want feedback
from the devs: are these complaints valid, and is there anyone who is
working on them? The boot-9 problems are prolly the worst and most
difficult.

Thanks for reading :-)
-- 
Andy Wingo <wingo@pobox.com>

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

^ permalink raw reply	[flat|nested] 3+ messages in thread