From: Ari Krupnik
Subject: multiple namespaces
Date: 
Message-ID: <86ac80l57s.fsf@deb.lib.aero>
Common Lisp has separate namespaces for functions and values. What are
the tradeoffs? There are two cases I've seen where one is easier to
use than the other, but I'm sure there must be others.

One case is where I find it convenient to have a variable share a
name with a function:

(defun process (list)
  (do-something-to list))

The other case is where I find it inconvenient to have to use funcall
or apply:

(defun tautology (func arg)
  (funcall #'func arg))               ;; (func arg) seems clearer

What else does having separate namespaces buy?


Ari.

-- 
Elections only count as free and trials as fair if you can lose money
betting on the outcome.

From: Pascal Bourguignon
Subject: Re: multiple namespaces
Date: 
Message-ID: <87fyhs5mry.fsf@thalassa.informatimago.com>
Ari Krupnik <···@lib.aero> writes:

> Common Lisp has separate namespaces for functions and values. What are
> the tradeoffs? There are two cases I've seen where one is easier to
> use than the other, but I'm sure there must be others.
>
> One case is where I find it convenient to have a variable share a
> name with a function:
>
> (defun process (list)
>   (do-something-to list))
>
> The other case is where I find it inconvenient to have to use funcall
> or apply:
>
> (defun tautology (func arg)
>   (funcall #'func arg))               ;; (func arg) seems clearer
>
> What else does having separate namespaces buy?

Nothing. 
You should be programming instead of pondering uselessly these questions.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

"You cannot really appreciate Dilbert unless you read it in the
original Klingon"
From: Ari Krupnik
Subject: Re: multiple namespaces
Date: 
Message-ID: <863bdsl245.fsf@deb.lib.aero>
Pascal Bourguignon <···@informatimago.com> writes:

> Ari Krupnik <···@lib.aero> writes:
>
>> What else does having separate namespaces buy?
>
> Nothing. 
> You should be programming instead of pondering uselessly these questions.

I appreciate your pragmatic attitude. The question I'm pondering is
what language I should be programming a particular project in. Some
consequences of the differences between these languages are clear to
me, and others I'm hoping to learn about. I've often found that what
appears to me as a limitation is in fact a layer of possibilities I
hadn't noticed.

Ari.

-- 
Elections only count as free and trials as fair if you can lose money
betting on the outcome.
From: Pascal Bourguignon
Subject: Re: multiple namespaces
Date: 
Message-ID: <87bqsg5kyt.fsf@thalassa.informatimago.com>
Ari Krupnik <···@lib.aero> writes:

> Pascal Bourguignon <···@informatimago.com> writes:
>
>> Ari Krupnik <···@lib.aero> writes:
>>
>>> What else does having separate namespaces buy?
>>
>> Nothing. 
>> You should be programming instead of pondering uselessly these questions.
>
> I appreciate your pragmatic attitude. The question I'm pondering is
> what language I should be programming a particular project in. Some
> consequences of the differences between these languages are clear to
> me, and others I'm hoping to learn about. I've often found that what
> appears to me as a limitation is in fact a layer of possibilities I
> hadn't noticed.

Yes, but this is really an unimportant detail, which is discussed much
too often (check the archives at http://groups.google.com/) and if you
ever need to write some  lisp-1 style code in Common Lisp, there are
various macros that allow you to do so (check the above mentionned
archives).

Really, if you must choose between scheme and Common Lisp, try other criteria.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

PLEASE NOTE: Some quantum physics theories suggest that when the
consumer is not directly observing this product, it may cease to
exist or will exist only in a vague and undetermined state.
From: Pascal Costanza
Subject: Re: multiple namespaces
Date: 
Message-ID: <4galabF1lsgdqU1@individual.net>
Ari Krupnik wrote:
> Pascal Bourguignon <···@informatimago.com> writes:
> 
>> Ari Krupnik <···@lib.aero> writes:
>>
>>> What else does having separate namespaces buy?
>> Nothing. 
>> You should be programming instead of pondering uselessly these questions.
> 
> I appreciate your pragmatic attitude. The question I'm pondering is
> what language I should be programming a particular project in. Some
> consequences of the differences between these languages are clear to
> me, and others I'm hoping to learn about. I've often found that what
> appears to me as a limitation is in fact a layer of possibilities I
> hadn't noticed.

I agree with Pascal B. that other questions are probably more important, 
but the executive summary is this: If have a common namespace for 
functions and values, certain functional programming idioms became more 
straightforward (because you don't to use function and funcall all over 
the place). If you have separate namespaces for functions and values, 
it's easier to use the same name in different contexts, and it makes 
implementing macros safer without requiring a hygienic macro system.

For more details, google for "Lisp-1" and "Lisp-2" in google groups.


Pascal

-- 
3rd European Lisp Workshop
July 3 - Nantes, France - co-located with ECOOP 2006
http://lisp-ecoop06.bknr.net/
From: Wolfram Fenske
Subject: Re: multiple namespaces
Date: 
Message-ID: <1151357167.460915.230840@r2g2000cwb.googlegroups.com>
Ari Krupnik <···@lib.aero> writes:

> Common Lisp has separate namespaces for functions and values. What are
> the tradeoffs? There are two cases I've seen where one is easier to
> use than the other, but I'm sure there must be others.
>
> One case is where I find it convenient to have a variable share a
> name with a function:
>
> (defun process (list)
>   (do-something-to list))
>
> The other case is where I find it inconvenient to have to use funcall
> or apply:
>
> (defun tautology (func arg)
>   (funcall #'func arg))               ;; (func arg) seems clearer
>
> What else does having separate namespaces buy?

I read in "Lisp in Small Pieces" [1] that this makes it easier for the
compiler to generate efficient code if in addition the function-value
of a symbol can't be changed at runtime, because then it's much easier
to figure out which function is referenced by the CAR of an
expression.  Of course CL has FLET and LABELS, but they only create
lexical bindings, so it's still pretty easy for the compiler to
determine which functions will be called at runtime.


Wolfram

Footnotes: 
[1]  <http://www-spi.lip6.fr/~queinnec/WWW/LiSP.html>