module systems: why no namespaces?

I was going to post an overview of my scheme implementation's module
system (which is based on Perl's) here. But before I do that I'd like
to ask why most Scheme module systems don't utilize namespaces.


Namespace separation is common in non-lisp 3GLs; Perl, Python, Java,
C++ all have namespace based module systems.

I can't see any reason why LISPs should not have namespace separation
embedded in their module systems.

Is there a reason why?

--
Nic Ferrier
http://www.tapsellferrier.co.uk

Nic Ferrier wrote:
> I was going to post an overview of my scheme implementation's module
> system (which is based on Perl's) here. But before I do that I'd like
> to ask why most Scheme module systems don't utilize namespaces.
>
> Namespace separation is common in non-lisp 3GLs
[...]

It's common in Common Lisp. ;)


Pascal

--
Tyler: "How's that working out for you?"
Jack: "Great."
Tyler: "Keep it up, then."

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> I was going to post an overview of my scheme implementation's module
> system (which is based on Perl's) here. But before I do that I'd like
> to ask why most Scheme module systems don't utilize namespaces.

Do you actually understand the design constraints behind modules?  In
particular, that the word "module" means about 4-5 different things?

Or, as Bear (I believe) will say is a reflex action around here, I
have to ask: have you read Flatt's ICFP 2002 paper?

Shriram

Shriram Krishnamurthi wrote:
>
> Or, as Bear (I believe) will say is a reflex action around here, I
> have to ask: have you read Flatt's ICFP 2002 paper?

For those of us 'not in the know' about which particular paper this is, or
what it contains, could you provide a URL?

--
Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

20% of the world is real.
80% is gobbledygook we make up inside our own heads.

Brandon J. Van Every wrote:

> Shriram Krishnamurthi wrote:
>=20 
>=20
>=20
> For those of us 'not in the know' about which particular paper this is,=
or
> what it contains, could you provide a URL?
>=20
<http://library.readscheme.org/page5.html>

--=20
Jens Axel S=F8gaard

Shriram Krishnamurthi <sk@cs.brown.edu> writes:

> Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:
> 
>
> Do you actually understand the design constraints behind modules?  In
> particular, that the word "module" means about 4-5 different things?

You're probably right.

Like some people say about Art: I don't know much about it but I do
know what I like.

And I am pretty stupid.


> Or, as Bear (I believe) will say is a reflex action around here, I
> have to ask: have you read Flatt's ICFP 2002 paper?

Well, as I say, I'm stupid. But the 2002 paper is about macro
languages. I think the relevant paper is the 1998 one co-authored with
Matthias Felleisen:

http://www.ccs.neu.edu/scheme/pubs/pldi98-ff.ps.gz

I have to say, it looks jolly clever but I only got to page 3 before I
had forgotten my own name.



One of the main things I like about module systems in languages like
Perl and Python is the namespacing. If I declare a procedure:

get_address_book

in a module called:

person

then I can use it thusly:

import person
person.get_address_book

or:

import person
person::get_address_book

or:

import person
person->get_address_book

Scheme implementations don't seem to offer this simplicity. I know
many Scheme module systems can make the imported procedure appear to
be in a separate namespace but it's not just done.

I'd just like to know why this is. Why are there such complex systems
as Guile's:

(use-modules ((ice-9 popen)
:select ((open-pipe . pipe-open) close-pipe)
:renamer (symbol-prefix-proc 'unixy:)))

(unixy:pipe-open ...)

Instead of simple ones like Python's:

import os

os.popen(...)



I *think* that the Scheme community, by realizing that modules can be
complicated, is making an error in implementing totally comprehensive
solutions.



--
Nic Ferrier
http://www.tapsellferrier.co.uk

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> I'd just like to know why this is. Why are there such complex systems
> as Guile's:
>
>      (use-modules ((ice-9 popen)
>                    :select ((open-pipe . pipe-open) close-pipe)
>                    :renamer (symbol-prefix-proc 'unixy:)))
>
>      (unixy:pipe-open ...)
>
> Instead of simple ones like Python's:
>
>      import os
>
>      os.popen(...)
>
Well, If you always want to do a namespace-like import in Guile, try
this:

(define-macro (import namespace module)
`(use-modules (,module #:renamer (symbol-prefix-proc
(string->symbol
(string-append
(symbol->string ',namespace)
":"))))))

Then you can do:

(import os (ice-9 popen))

(os:pipe-open ...)

That's not that much more complicated than Python, is it?

>
> I *think* that the Scheme community, by realizing that modules can be
> complicated, is making an error in implementing totally comprehensive
> solutions.
>
Well, you can easily layer a "simplified" module system over the
comprehensive solutions, but you can't do the other way round.

Rotty
--
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.a
t
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B6
2

Software Patents: Where do you want to stifle inovation today?

Jens Axel Søgaard wrote:
> Brandon J. Van Every wrote:
> 
> http://library.readscheme.org/page5.html

Thanks for the compendium of papers.  May be useful to me.
I believe the particular paper is "Composable and Compilable Macros: You
Want it When?"
http://www.cs.utah.edu/plt/publications/macromod.pdf

--
Cheers,                         www.indiegamedesign.com
Brandon Van Every               Seattle, WA

"We live in a world of very bright people building
crappy software with total shit for tools and process."
- Ed McKenzie

Andreas Rottmann <a.rottmann@gmx.at> writes:

> Well, If you always want to do a namespace-like import in Guile, try
> this:
>
> (define-macro (import namespace module)
>   `(use-modules (,module #:renamer (symbol-prefix-proc
>                                     (string->symbol
>                                      (string-append
>                                       (symbol->string ',namespace)
>                                       ":"))))))

Yes. And where do I put this code?

Of course I understand that you can do anything with macros. But the
macro then becomes part of the code and makes things difficult to move
around.


> Well, you can easily layer a "simplified" module system over the
> comprehensive solutions, but you can't do the other way round.

But are these ultra-complicated systems really bringing us anything?

Why does a module system, by default, import into the current
namespace?


--
Nic Ferrier
http://www.tapsellferrier.co.uk

Nic Ferrier <nferrier@tapsellferrier.co.uk> writes:

> You're probably right.
>
> Like some people say about Art: I don't know much about it but I do
> know what I like.
>
> And I am pretty stupid.

1. I'm not trying to say you're stupid.  I'm just making sure you
understand that there is some prior context that you should consider
acquainting yourself with.

2. Stupid can be good.  "Stupid" questions like "Why can't your
modules be as simple as Python's?" are valuable, because they force
people to rethink what they've always believed.

> Well, as I say, I'm stupid. But the 2002 paper is about macro
> languages. I think the relevant paper is the 1998 one co-authored with
> Matthias Felleisen:
>
>   http://www.ccs.neu.edu/scheme/pubs/pldi98-ff.ps.gz
>
> I have to say, it looks jolly clever but I only got to page 3 before I
> had forgotten my own name.

This paper is silent on the question of macros.  And the problem is
that in Scheme, unlike in Python or Perl, you do have to take macros
into account explicitly (even if you only disallow them).  That's why
the 2002 paper is relevant: because it explores the question of
modularity in the context of macros.

> I *think* that the Scheme community, by realizing that modules can be
> complicated, is making an error in implementing totally comprehensive
> solutions.

I'm all for simple solutions, too.  I think the PLT system is (in its
essence) pretty simple, while also providing support for macros.  A
solution so simple that it ignores macros is, I'm afraid, not a
*solution*.

Shriram