Re: request for comments: namespace mechanism

Hi Ralf,

> 
> I am working on a mechanism for simulating namespaces. The
> implementation is inspired by the package macro. Here is my
> idea so far: Writing
> 

Perhaps you should just extend the package mechanism. The package mechanism
defines a namespace already, that is basically what it looks like you are attempting
anyway.

> The namespace form creates a mapping from unqualified names
> ('func1' ...) to qualified names ('abc-func1') and binds it
> to the name 'abc' using defparameter. Thus, there is an
> object 'abc' that represents the namespace and that you may
> pass around to other code.

The current Lush package implementation has this.

> 3. It may globally bind selected things to the unqualified
>     names using 'import'
> 
> (import (func1 sym1) from abc)
> (print (func1 815))
> (print (abc-func2 816))
> ...

The 'from' is superfluous if you follow the CL package declaration of import:

import 'symbols' &optional 'package' (see pp268 Common Lisp, The Language,
2nd Ed.)


> 
> Namespace forms may be nested. For example evaluating
> 
> (namespace abc
>    (defun func1 (...) ...)
>    (namespace def
>      (defun func2 (...) ...)
>    )
> )

Something similar to nesting can occur in the CL package facility, without embedding
in blocks. That's another way to implement it.

> 
> I'm half-way done with this, please let me know if you
> have any suggestions. For instance, what should happen when
> an import form occurs in a namespace form?
> 
> (namespace abc
>    (import (f1 f2) from xyz)
>    (defun func1 (..)
>      (+ (f1 ..) (f2 ...)) )
> )

The imports should only have local scope within the enclosing package (namespace).
The package will thus have some resemblance to a 'let' with its local environment.


> 
> This could either (in line with my earlier definition of
> import) establish the global bindings 'f1' -> 'xyz-f1'
> and 'f2' -> 'xyz-f2' and add nothing to the namespace
> 'abc'. Alternatively, import could add the names 'f1'
> and 'f2' to the namespace 'abc' instead (hence, import
> would establish the global bindings 'abc-f1' -> 'xyz-f1',
> 'abc-f2' -> 'xyz-f2').
> 
> 

You are importing into a package for the the package's use. Otherwise, you
would just import that functionality in some other place instead of accessing
via this particular package. To access via this package use accessor functions
that can be either public or private. Adds a little overhead, but keeps access
rules sorted out better. 

That is, those things which are clearly defined in the package have first class 
access rules (public or private capability). Things which are brought in from 
elsewhere (imported) are second class (private only) and have their own first 
class access in their defining packages (from which they are publicly accessible).

Cheers.

Raymond

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642