From: Andy Wingo <wingo@pobox.com>
Cc: guile-devel@gnu.org
Subject: Guile warts (was: [GOOPS] Specializing <generic> to allow lazy method addition)
Date: Sun, 01 Feb 2004 21:41:39 +0200 [thread overview]
Message-ID: <1075664499.3688.125.camel@localhost> (raw)
In-Reply-To: <xy74quhpgjj.fsf@chunk.mit.edu>
[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
next prev parent reply other threads:[~2004-02-01 19:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <87smkc5b22.fsf@alice.rotty.yi.org>
[not found] ` <874qwhsa2u.fsf@zip.com.au>
2003-12-04 9:02 ` New g-wrap supported in guile-gtk--rotty-0.1! Andreas Rottmann
2003-12-04 14:14 ` Mikael Djurfeldt
2003-12-04 17:21 ` Andreas Rottmann
2003-12-04 22:33 ` Andreas Rottmann
2003-12-06 16:18 ` Andreas Rottmann
[not found] ` <1074535797.1517.64.camel@localhost>
2004-01-23 11:38 ` [GOOPS] Specializing <generic> to allow lazy method addition Andreas Rottmann
2004-01-27 15:17 ` Mikael Djurfeldt
2004-01-27 23:27 ` Stephen Compall
2004-01-28 2:14 ` Mikael Djurfeldt
2004-02-01 19:41 ` Andy Wingo [this message]
2004-02-05 19:03 ` Guile warts Mikael Djurfeldt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1075664499.3688.125.camel@localhost \
--to=wingo@pobox.com \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).