Re: define-namespace patch

[Chris Dean <ctdean at sokitomi dot com>]

Per Bothner <per@bothner.com> wrote:
> I guess it's reasonable to allow <cname> as a convenient shorthard for
> "class:cname".  However, the implementation isn't right.  

That's no surprise!  I can't see all the subtleties of the system.  Or
at least not yet :-).

> 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.

Aha - that makes sense.  Can you point me at the right place to make the
change?

> 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.

The analogy is with the define-private form.  Sure you can use
module-export, but as you say most uses of define-namespace (for me at
least) should be private.  The normal case is I have a couple dozen
procedures and one or two define-namespaces that are being used just for
implementation of the procedures.   

My goal is very pragmatic - how can we use Kawa to write real programs
easily, powerfully, consistently, and elegantly.  I hear what you are
saying about define-private-namespace and how it doesn't seem consistent
with the rest of Kawa.  I agree.  The lazy side of me likes
define-private-namespace because it is less work for me.

One solution (which seems ugly to me) would be to not issue a duplicate
definition warning when two namespace with the same value where
encountered.

Or maybe the right long term goal is to have a different way of calling
Java code.

Regards,
Chris Dean