From: ········@wat.hookup.net
Subject: Re: Namespaces in Scheme vs. Namespaces in CL.
Date: 
Message-ID: <5eko2v$kl1$1@nic.wat.hookup.net>
In <·············@no.spam.please>, Fnu Lnu <······@no.spam.please> writes:
>Some time ago, I was part of a "discussion" here about the 
>value of namespaces.  CL proponents were claiming I could 
>never get anything major done in Scheme, because it had a 
>single namespace that tended to get polluted -- I was simply
>saying, "well, it's never been a problem..."  
>
>I think I understand why.  
>
>In CL, definitions are allowed only at the top lexical level, 

not true

>so when you have a function gloop that uses functions foo, 
>bar, and baz, you wind up going, 
>
>(defun foo ....)
>(defun bar ....)
>(defun baz ....)
>
>(defun gloop .....) 
>
>
>Using 4 names.  
>
>To do the same thing in Scheme, you go,
>
>(define gloop (lambda (params)
>	(define foo ....)
>	(define bar ....)
>	(define baz ....)
>	..... ;body of gloop
>))
>
>using, at the top level, one name -- the other three 
>are only defined locally, when you're inside the function.
>
>I've been thinking about that, too...  That is a way to 
>guarantee that foo, bar, and baz can be called only from 
>within the body of gloop.  That's a promise that a good 
>compiler could use to make optimizations: abbreviating 
>the stack frame, register use, eliminating typechecks, 
>inlining if appropriate -- that you just couldn't guarantee 
>the ability to make if they were defined with those names 
>having global scope.

The problem is when you want to make more than one name accesible to the
world outside gloop

>On the other hand, CL compilation benefits from the separate 
>namespaces; with rare exceptions, the type of something can 
>be determined statically, and that allows eliminating 
>typechecks as well.  
>
>Is this a fair comparison of the two languages?  

At least one scheme implementation (MzScheme) has multiple name spaces.  In
general, most modern languages (Dylan, ML) use a module system for the
purpose Lisp's package system is meant to handle

>				Bear

Hartmann Schaffer

From: William D Clinger
Subject: Re: Namespaces in Scheme vs. Namespaces in CL.
Date: 
Message-ID: <330DE177.2CF3@ccs.neu.edu>
Hartmann Schaffer (·······@wat.hookup.net) wrote:
> The problem is when you want to make more than one name accesible to the
> world outside gloop

Yes, this is a problem with Scheme, as it is with Common Lisp, but
the following idiom works fine in most cases:

                                                ; In Common Lisp:
(define bar (lambda () #t)) ; assigned below    ; (defun bar () 't)
(define baz (lambda () #t)) ; assigned below    ; (defun baz () 't)

(define gloop
  (lambda (params)
    (define foo (lambda (...) ...))
    (set! bar (lambda (...) ...))   ; (setf (symbol-function 'bar) #'...)
    (set! baz (lambda (...) ...))   ; (setf (symbol-function 'baz) #'...)
    ..... ;body of gloop
  ))

Fnu Lnu (······@no.spam.please), evidently aka Bear, wrote:
> On the other hand, CL compilation benefits from the separate
> namespaces; with rare exceptions, the type of something can
> be determined statically, and that allows eliminating
> typechecks as well.

This is mostly untrue.  In particular, the CL compiler seldom
knows the type of a global procedure.  The one thing that it does
know is that (SYMBOL-FUNCTION 'X) is some kind of procedure.  This
allows the CL compiler to eliminate the procedure-ness check that
would otherwise be required for safe calls to global procedures.
The arity check and most other type checks must still be performed
dynamically.

In Scheme there is an implementation tradeoff that determines
whether the Scheme compiler can eliminate the implicit PROCEDURE?
check for safe calls to global procedures.  An implementation of
Scheme is free to use a separate procedure cell for global variables,
as in Common Lisp, but there is a disadvantage to doing this in Scheme
that does not exist in Common Lisp:  Assignments to global variables
become more expensive, because the assignment must update both the
value cell and the procedure cell.  It costs no more to fetch both
cells together than to fetch one, and the cost of the write barrier
is only slightly greater for a double assignment than for a single
assignment, so assignments to global variables might be about 20%
more expensive than in a more naive implementation.

This is a worthwhile tradeoff, because calls to global procedures
are much more common than assignments to global variables.

Will
From: Rainer Joswig
Subject: Re: Namespaces in Scheme vs. Namespaces in CL.
Date: 
Message-ID: <joswig-ya023180002202971140540001@news.lavielle.com>
In article <············@nic.wat.hookup.net>,
··················@wat.hookup.net wrote:

> not true

exactly


> >To do the same thing in Scheme, you go,
> >
> >(define gloop (lambda (params)
> >       (define foo ....)
> >       (define bar ....)
> >       (define baz ....)
> >       ..... ;body of gloop
> >))

How about FLET and LABELS in Common Lisp???


> general, most modern languages (Dylan, ML) use a module system for the
> purpose Lisp's package system is meant to handle

Don't forget EuLisp.

-- 
http://www.lavielle.com/~joswig/
From: Kellom{ki Pertti
Subject: Re: Namespaces in Scheme vs. Namespaces in CL.
Date: 
Message-ID: <xfzn2su8yjr.fsf@vihertikka.cs.tut.fi>
In article <·············@ccs.neu.edu> William D Clinger <····@ccs.neu.edu> writes:
   Hartmann Schaffer (·······@wat.hookup.net) wrote:
   > The problem is when you want to make more than one name accesible to the
   > world outside gloop

   Yes, this is a problem with Scheme, as it is with Common Lisp, but
   the following idiom works fine in most cases:

						   ; In Common Lisp:
   (define bar (lambda () #t)) ; assigned below    ; (defun bar () 't)
   (define baz (lambda () #t)) ; assigned below    ; (defun baz () 't)

   (define gloop
     (lambda (params)
       (define foo (lambda (...) ...))
       (set! bar (lambda (...) ...))   ; (setf (symbol-function 'bar) #'...)
       (set! baz (lambda (...) ...))   ; (setf (symbol-function 'baz) #'...)
       ..... ;body of gloop
     ))

The problem with this if you are writing a larger system is that it
prevents the use of bar and baz in the rest of the program. I usually
circumvent this by using gloop:bar and gloop:baz instead, but I am not
very happy about it.

-- 
Pertti Kellom\"aki (TeX format)  #       These opinions are mine, 
  Tampere Univ. of Technology    #              ALL MINE !
      Software Systems Lab       #  (but go ahead and use them, if you like)