Re: define-namespace patch

[Per Bothner <per at bothner dot com>]

Chris Dean wrote:

> I use define-namespace extensively and have a few patches to extend its
> functionality.  This first one adds two features:
>
> 1.  Extend the syntax to allow class names to be of the form
>     <some.class.Name> in addition to the traditional "class:..."
>
> 2. Add a procedure define-private-namespace that creates a namespace but
>    doesn't export the name out of the current module.

I have mixed feelings about both of these, but especially the second.

I guess it's reasonable to allow <cname> as a convenient shorthard for
"class:cname".  However, the implementation isn't right.  You're doing
the re-mapping at reader-time, but it should be done later at name
resolution time.  For example:
  (define-alias <foo> <bar>)
  (define-namespace ns <foo>)
This should be shorthand for:
  (define-name ns "class:bar")
not
  (define-namespace ns "class:foo")

In Kawa <foo> is an identifier that *by convention* and by default
evaluates to (the ClassType for) the class foo, but it is not a class
literal.  I.e. the meaning of <foo> is whatever is lexially in scope
for <foo>; it is just if there is no definition in scope, then Kawa
falls back to using the class foo.

Adding procedure define-private-namespace (it's syntax, not a
procedure, of course) is the problem that it's not needed:  You can
always use module-export to list the exported names, and that may
be a better style to recommend.

Adding define-private-namespace raises the question:  why don't we have 
private versions of all the other define forms:  define-private-syntax,
define-private-alias, etc.

Yes, I suspect most uses of define-namespace should be private, but
there is the issue of controlling language bloat.

Comments?
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/