From: Rob Browning <rlb@defaultvalue.org>
Cc: guile-devel@gnu.org
Subject: Re: :export vs. define-public
Date: Thu, 05 Sep 2002 12:38:03 -0500 [thread overview]
Message-ID: <87r8g8wd50.fsf@raven.i.defaultvalue.org> (raw)
In-Reply-To: <87sn0o1jzo.fsf@dyn006239.shef.ac.uk> (Eric E Moore's message of "Thu, 05 Sep 2002 17:25:47 +0100")
Eric E Moore <e.e.moore@sheffield.ac.uk> writes:
> :export makes it considerably easier to port scheme code across
> multiple implememntations, since the code to deal with the module
> systems, which are regrettably non-standard, can be kept separate from
> the R5RS code. If scheme had an official module system, it might not
> need :export. 'till guile has a good compiler, I'd like to see it
> possible to port code easily. (I suppose one could write a
> define-public macro for schemes that lack one, but it's still nice to
> have :export)
Actually, I tend to like (export foo) better, but either way I agree,
:export and (export foo) make it possible to have a common source file
that you share between different scheme implementations. The module
system specific bits can go in a stub file that loads the shared file,
or the sys-specific and shared files can be stuck together via cat at
build time. While this isn't particularly important for me at the
moment, it has been handy in the past.
Another argument in favor of :export, and (export foo), depending on
how you use them, is that they can be used to centralize the
information about a given module's public exports. That's something
I've found helpful in the past, but I'm sure which type of locality
you prefer depends on the person.
Personally, I have no problem with the availability of three different
export methods: (export foo), :export, and define-public, though I
actually prefer both (export foo) and :export over define-public since
they keep the module system bits independent of function definition,
and since I also prefer module "signature locality" to "locality of
editing" in this case.
FWIW I tend to use a set of (export foo) declarations at the top of
the file most of the time these days. I believe (export foo) also
made code generation in g-wrap a little easier since I didn't have to
worry about placement as much, but that's not a big deal either.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2002-09-05 17:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-05 0:41 :export vs. define-public Tom Lord
2002-09-05 0:33 ` Thomas Bushnell, BSG
2002-09-05 0:59 ` cvs access broken? Tom Lord
2002-09-05 18:01 ` Marius Vollmer
2002-09-05 1:02 ` :export vs. define-public Tom Lord
2002-09-05 0:55 ` Thomas Bushnell, BSG
2002-09-05 1:09 ` Tom Lord
2002-09-05 1:12 ` Thomas Bushnell, BSG
2002-09-05 2:05 ` Tom Lord
2002-09-05 16:25 ` Eric E Moore
2002-09-05 17:38 ` Rob Browning [this message]
2002-09-05 17:54 ` Eric E Moore
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=87r8g8wd50.fsf@raven.i.defaultvalue.org \
--to=rlb@defaultvalue.org \
--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).