Re: :export vs. define-public

Re: :export vs. define-public

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> writes:

> Those two approaches (:export vs. define-public) to public v. private
> module contours are isomorphic, so what's the big deal?

There is no big deal.  What makes you think there is?  Only
define-public is documented.  :export is not, nor is the more local
(export ...) form that Marius recently mentioned.

> Historically, I suspect that some module system changes made after the
> Cygnus releases were motivated in part because they made the Guile
> module system look more like S48 or some other famous schemes.  And as
> we all know, those other systems reek of the scent of perfection (or
> at least, a perfection-style cologne).  But that's just speculation,
> on my part.  I'm aware that module system changes were originally
> argued (vaguely) for in terms of support for compilation.

I like perfection.  I have access to many many "just do it, screw
perfection" systems.  I'm tired of them.  



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

:export vs. define-public

[Tom Lord]

Those two approaches (:export vs. define-public) to public v. private
module contours are isomorphic, so what's the big deal?

`define-public' supports "locality of editting": everything you need
to know about a definition is collected right there under your editor
cursor.  There's no need to remember to change some other part of the
file.

Extension languages should optimize for interactive use.  Thus,
locality of editting is an important consideration.

Historically, I suspect that some module system changes made after the
Cygnus releases were motivated in part because they made the Guile
module system look more like S48 or some other famous schemes.  And as
we all know, those other systems reek of the scent of perfection (or
at least, a perfection-style cologne).  But that's just speculation,
on my part.  I'm aware that module system changes were originally
argued (vaguely) for in terms of support for compilation.

mentioning-part-of-the-list-of-things-i-don't-like-about-guile-other
than-#f/()-but-that-might-be-usefully-rethought, 

-t




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

Re: :export vs. define-public

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> writes:

> 	>> Those two approaches (:export vs. define-public) to public v. private
> 	>> module contours are isomorphic, so what's the big deal?
> 
> 	> There is no big deal.  What makes you think there is?  
> 
> Well, somebody felt strongly enough about the issue to make the change
> from define-public to :export.   In 1.5.6, at least, code in `ice-9'
> uses :export.

define-public is still there too.



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

cvs access broken?

[Tom Lord]

Following the instructions posted on savanah:

	  % cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/guile login
	  CVS password: anoncvs
	  cvs [login aborted]: authorization failed: server subversions.gnu.org rejected access


so....what's up?

-t


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

Re: :export vs. define-public

[Tom Lord]

	>> Those two approaches (:export vs. define-public) to public v. private
	>> module contours are isomorphic, so what's the big deal?

	> There is no big deal.  What makes you think there is?  

Well, somebody felt strongly enough about the issue to make the change
from define-public to :export.   In 1.5.6, at least, code in `ice-9'
uses :export.

-t



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

Re: :export vs. define-public

[Tom Lord]

       > define-public is still there too.


Having both seems like an invitation to subtle errors.

-t


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

Re: :export vs. define-public

[Thomas Bushnell, BSG]

Tom Lord <lord@regexps.com> writes:

>        > define-public is still there too.
> 
> 
> Having both seems like an invitation to subtle errors.

Ah!  So after your plea that it's really irrelevant, it turns out that
you think only one should exist.  Seems like a mistake to me.  As you
rightly point out, they represent different styles of module design,
and there's no particular reason we should support only one.

The solution to subtle errors is bugfixing.  The semantics, at least,
are quite clear.


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

Re: :export vs. define-public

[Tom Lord]

Oooo -- what a zinger.



-t


   Cc: guile-devel@gnu.org
   X-Reply-Permission: Posted or emailed replies to this message constitute
		    permission for an emailed response.
   X-PGP-Fingerprint: 1F0A1E51  63 28 EB DA E6 44 E5 5E  EC F3 04 26 4E BF 1A 92
   X-Zippy-Says: They don't hire PERSONAL PINHEADS, Mr. Toad!
   From: tb@becket.net (Thomas Bushnell, BSG)
   Date: 04 Sep 2002 18:12:32 -0700
   User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
   Content-Type: text/plain; charset=us-ascii
   X-UIDL: "fW!!D:O"!2?;"!RLC!!

   Tom Lord <lord@regexps.com> writes:

   >        > define-public is still there too.
   > 
   > 
   > Having both seems like an invitation to subtle errors.

   Ah!  So after your plea that it's really irrelevant, it turns out that
   you think only one should exist.  Seems like a mistake to me.  As you
   rightly point out, they represent different styles of module design,
   and there's no particular reason we should support only one.

   The solution to subtle errors is bugfixing.  The semantics, at least,
   are quite clear.




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

Re: :export vs. define-public

[Eric E Moore]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

Tom Lord <lord@regexps.com> writes:

> Those two approaches (:export vs. define-public) to public v. private
> module contours are isomorphic, so what's the big deal?

: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)

-- 
Eric E. Moore

[-- Attachment #2: Type: application/pgp-signature, Size: 184 bytes --]

Re: :export vs. define-public

[Rob Browning]

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

Re: :export vs. define-public

[Eric E Moore]

[-- Attachment #1: Type: text/plain, Size: 556 bytes --]

Rob Browning <rlb@defaultvalue.org> writes:

> Eric E Moore <e.e.moore@sheffield.ac.uk> writes:
> 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.  

I like (export foo) better too.  Just the original thread was
:export vs define-public.  Since :export and (export) serve similar
purposes, I'd be happy to see one of the two go, but would like to see
at least one kept.

-- 
Eric E. Moore

[-- Attachment #2: Type: application/pgp-signature, Size: 184 bytes --]

Re: cvs access broken?

[Marius Vollmer]

Tom Lord <lord@regexps.com> writes:

> Following the instructions posted on savanah:
> 
> 	  % cvs -d:pserver:anoncvs@subversions.gnu.org:/cvsroot/guile login
> 	  CVS password: anoncvs
> 	  cvs [login aborted]: authorization failed: server subversions.gnu.org rejected access
> 
> 
> so....what's up?

You need to supply the empty password.

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


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