From: Ray Blaak
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <m33dc8zwmp.fsf@blight.transcend.org>
Erik Naggum <····@naggum.net> writes:
> * Bruce Hoult <·····@hoult.org>
>> As someone coming to the discussion from a background of using C++ and
>> Java and other similar languages I'm just trying to find out what the
>> big advantage of having two namespaces is.
>
> Do you use an environment where you can give commands to a shell?
[...all about . and $PATH...]
> you have been using a system with just this separation of functions from
> variables all along, and the reason it is like that is that it scales better
> than any other approach, and it gives you freedom from worry that you nuke
> commands by naming your files what you think is best.
> If I had to deal with a computer that did not allow me call a file "cat"
> because there was a command by that name, I'd consider it broken as
> designed, and that's exactly what I feel about Scheme and Dylan and other
> retarded languages that conflate the function namespace with the variable
> namespace.
[Hmmm. Missed this one earlier. One of Xah's posts was actually useful!]
What you are completely missing is the difference between dynamically scoped
and lexically scoped systems.
In a dynamically scoped system, function/variable separation is a requirement,
not a matter of preference, for precisely the reasons you point out with the
shell example: things break very quickly if there is no such separation,
because what you execute depends completely on the dynamic context at run time.
(Shells are inherently dynamically scoped, for anything else is not really
sensical -- what is the lexical scope of a command line?)
With lexically scoped systems, however, this security is not necessary since
all the names one refers to are resolved before execution, and so there are no
hidden surprises. (Of course, if the system has no static namespaces, then
there are still major inconveniences -- with static namespaces shadowed names
can always be referred to by suitably qualifying the reference with the
namespace prefix.)
Things then become a matter of preference, efficiency, etc. Which approach one
prefers is a matter of trading off various goals (ease of use, minimizing
ambiguity, clarity, etc.).
In such a situation, disliking (time time) is not inherently stupid, since that
can reasonably be considered as confusing (note: such situations are *also*
often confusing in natural languages, in spite of humans' ability to deal with
it). Liking it is *also* not inherently stupid, since it can be reasonably
considered as useful.
> Sometimes, I think you one-namespace guys are just plain idiots, but it's
> probably a cultural thing -- you don't know any better because you never saw
> any better. That would be OK, but when you're as stupid as to _refuse_ to
> _listen_ to people who know a better way, it's no longer a cultural thing,
> it's stupidity by choice.
To assume that people who still prefer a single namespace are just stupid or
ignorant is profoundly foolish and arrogant. It really does depend on the
situation.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: Tim Bradshaw
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <nkj8zm07lfg.fsf@tfeb.org>
Ray Blaak <·····@infomatch.com> writes:
>
> (Shells are inherently dynamically scoped, for anything else is not really
> sensical -- what is the lexical scope of a command line?)
>
rc - the plan 9 shell - or in fact one of its descendants I think - is
lexically scoped. It has closures.
--tim
From: Harald Hanche-Olsen
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <pco1yrsdv2b.fsf@thoth.home>
+ Tim Bradshaw <···@tfeb.org>:
| rc - the plan 9 shell - or in fact one of its descendants I think -
| is lexically scoped. It has closures.
You're thinking of es, I think. Though it actually has dynamically
scoped variables too: Any binding created with local (name=value) is
dynamically scoped (and the name=value is exported to the environment,
which does not happen with the lexically scoped variables bound by let
or lambda).
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
From: Pierre R. Mai
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <8766h4pnx5.fsf@orion.bln.pmsf.de>
Ray Blaak <·····@infomatch.com> writes:
> With lexically scoped systems, however, this security is not necessary
> since all the names one refers to are resolved before execution, and
> so there are no hidden surprises. (Of course, if the system has no
While they are not as devilishly hidden as in dynamically scoped
systems, they are none the less not always as "directly" visible, as
your strawman example '(time time)' tries to suggest. A more
reasonable example might be:
(defun loop-for-across (var val data-type)
(loop-make-iteration-variable var nil data-type)
(let ((vector-var (loop-gentemp 'loop-across-vector-))
(index-var (loop-gentemp 'loop-across-index-)))
(multiple-value-bind (vector-form constantp vector-value)
(loop-constant-fold-if-possible val 'vector)
(loop-make-variable
vector-var vector-form
(if (and (consp vector-form) (eq (car vector-form) 'the))
(cadr vector-form)
'vector))
(loop-make-variable index-var 0 'fixnum)
(let* ((length 0)
(length-form (cond ((not constantp)
(let ((v (loop-gentemp 'loop-across-limit-)))
(push `(setq ,v (length ,vector-var)) *loop-prologue*)
(loop-make-variable v 0 'fixnum)))
(t (setq length (length vector-value)))))
(first-test `(>= ,index-var ,length-form))
(other-test first-test)
(step `(,var (aref ,vector-var ,index-var)))
(pstep `(,index-var (1+ ,index-var))))
(declare (fixnum length))
(when constantp
(setq first-test (= length 0))
(when (<= length 1)
(setq other-test t)))
`(,other-test ,step () ,pstep
,@(and (not (eq first-test other-test)) `(,first-test ,step () ,pstep)))))))
Is that clash obviously apparent to everyone? I don't think so.
> In such a situation, disliking (time time) is not inherently
> stupid, since that can reasonably be considered as confusing
> (note: such situations are *also* often confusing in natural
> languages, in spite of humans' ability to deal with it). Liking
> it is *also* not inherently stupid, since it can be reasonably
> considered as useful.
Well, noone said that disliking '(time time)' is inherently stupid.
But there is a difference between disliking a strawman, disliking real
examples, and much more importantly there is a huge difference
from disliking it to effectively forbidding it:
In a multiple-namespace language noone is forced to use identical
names, but everyone is enabled not to worry about clashes. In a
single-namespace language, everyone is forced to worry about clashes,
so that those that dislike "punning" don't have to understand it in
the innards of _foreign_ code (they can avoid it in their own code
just as well in a multiple-namespace language, and because of lexical
scoping, the punning never escapes the local lexical scope).
So the single-namespace approach is restricting freedom of expression,
in order to increase readability for a segment of the user community
(possibly even decreasing readability for another segment).
In and of itself I don't think that is a good trade-off (if I wanted
B&D, I'd go elsewhere). So in order to convice me of the validity of
the single-namespace approach, there would have to be some additional
advantage to offset the net disadvantage I perceive. Beside the
theoretical argument that "only 0, 1 and infinity are valid numbers in
CS", I haven't seen any such argument. In my eyes it is not
multiple-namespaces that have to defend their existence (as if they
were abberations that better have a good raîson d'être, lest they be
flushed). And that is the whole problem with this discussion:
Instead of considering both approaches to be equally in need of
validation, it somehow always is single-namespaces that are considered
the norm, and only multiple-namespaces have to be defended.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Kent M Pitman
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <sfwu24ocvf6.fsf@world.std.com>
"Pierre R. Mai" <····@acm.org> writes:
> In a multiple-namespace language noone is forced to use identical
> names, but everyone is enabled not to worry about clashes. In a
> single-namespace language, everyone is forced to worry about clashes,
> so that those that dislike "punning" don't have to understand it in
> the innards of _foreign_ code (they can avoid it in their own code
> just as well in a multiple-namespace language, and because of lexical
> scoping, the punning never escapes the local lexical scope).
Further, as I've alluded to, punning goes on in Lisp1's, too. It just
takes a different form. For example, in T (Yale Scheme), we used an
implementation trick in the bookkeeping which was user-visible and kind
of cool, but which wouldn't be available in a Lisp2, but which was based
on "cleverness" and "punning", not on some sound foundation of non-ambiguity.
We wanted to have "messages" (in the sense of Lisp Machine "send") that
were dispatched off of and functions that sent the messages. We opted to
use the function itself as the message, so that
(defmessage foo)
or some such thing [can't remember the name or syntax] would essentially
do
(define foo (letrec ((msg (lambda (arg1 . more-args)
(apply (message-handler arg1) msg more-args))))
msg))
so that foo was bound not only to the message but also to the function which
sent the message. In effect, the desire to pun was transferred from the
namespace to the dataspace. The result was that a message handler in a
different environment could "rename" this message (i.e., put it in a
different function name) and its message handlers which dispatched on the
name would also magically work with the new name because instead of case
dispatch like
(cond ((eq? msg 'clear-screen) ...))
we were doing
(cond ((eq? msg clear-screen) ...))
[As an aside, this was a weird exercise because we started out with symbolic
names as the messages, and one day realized we could use the function
objects themselves, so we reimplemented the thing and then went through and
removed a billion quotes from the system and the system still ran... It was
scary but fun.]
It is often recommended to people that they not be "clever" in their programs
becuase it will lead to trouble. But sometimes the urge to do something
clever is irresistable and one just does it anyway. But I wanted to observe
that just because it was the Scheme domain, it wasn't free of punning. THere
is a quite definite pun going on here--use of a piece of data that would
ordinarily be thought to be useful for its "functional sense" as also useful
for its "identity sense", diminishing at that moment the ability to ever in
the future for that dialect say (as Scheme designers HAVE, sometimes,
suggested) "let's make functions like integers be something that has no
identity and cannot be compared for identity since (a) we might want to
move them around and lose their identity, as happens for numbers, and
(b) we don't want to get involved in whether things like
(eq? (lambda (x) x) (lambda (x) x)) could ever happen." Being clever has
consequences, and our decision did. But it had benefits, too. And we
liked those.
Moral? Scheme programmers are capable of bieng just as human and unclean
as CL programmers--giving them different tools does not fix this.
> So the single-namespace approach is restricting freedom of expression,
> in order to increase readability for a segment of the user community
> (possibly even decreasing readability for another segment).
I think this was an interesting observation that I wanted to pick out of
Pierre's long message and make more visible. (Then I wrote a bunch of
text above it and buried it again. C'est la vie.)
> In and of itself I don't think that is a good trade-off (if I wanted
> B&D, I'd go elsewhere). So in order to convice me of the validity of
> the single-namespace approach, there would have to be some additional
> advantage to offset the net disadvantage I perceive. Beside the
> theoretical argument that "only 0, 1 and infinity are valid numbers in
> CS", I haven't seen any such argument. In my eyes it is not
> multiple-namespaces that have to defend their existence (as if they
> were abberations that better have a good ra=EEson d'=EAtre, lest they be
> flushed). And that is the whole problem with this discussion:
> Instead of considering both approaches to be equally in need of
> validation, it somehow always is single-namespaces that are considered
> the norm, and only multiple-namespaces have to be defended.
Btw, I have often suggested the right "fix" is to allow what I call a
Lisp-Omega in which there are an infinite number of namespaces. (I've actually
somewhere in deep background started to work out a great deal of the
syntax and semantics of such a dialect, but I haven't had time to work on
it in the last couple of years due to other intrusions. Perhaps at some
point I'll get back to it. It's cool because both Lisp1 and Lisp2 are
proper subsets of it and code for each can be "macroexpanded" into the
Lisp-Omega dialect for interchange/interoperability. Or so I imagine.
Not having completed it, I am not 100% sure it will work. But that's the
fun of trying. To see if I can make that work. If I get it done, I'll
write a paper.)
Anyway, when this suggestion (to fix the perceived "Lisp2 problem", which
I don't agree is a problem but some Lisp1ers do) by turning Lisp2 into a
Lisp-Omega instead, it's interesting to see what happens to the gripes of
the Lisp1ers. In my experience, many of them still bolt, even tho an
isomorphism has been created to the holy grail of 0-1-infinity-ness. Hence,
I disregard the 0-1-infinity claim because it seems to me to be constructed
more as an administrative obstacle than a principled checklist items of
"things that would need to be repaired to reduce my unhappiness with it".
Then again, perhaps it's just because they lack the imagination to believe
it could really work, and perhaps if they actually saw a worked dialect
they would feel better about it.
But the hair required to make a formal semantics for a Lisp2 is often
cited, and though I don't do formal semantics myself, I've been assured
that if the problem were changed from a Lisp2 to Lisp-Omega, the amount of
work required to adjust Scheme's formal semantics to accomodate an infinite
number of namespaces instead of just 1 is very tiny. (As I recall, the people
I've asked for advice on this claim it would probably be only a line or two
here and there to make the change.)
From: Ray Blaak
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <m3snk7h7li.fsf@blight.transcend.org>
"Pierre R. Mai" <····@acm.org> writes:
> While they are not as devilishly hidden as in dynamically scoped
> systems, they are none the less not always as "directly" visible, as
> your strawman example '(time time)' tries to suggest. A more
> reasonable example might be:
Fair enough.
> Well, noone said that disliking '(time time)' is inherently stupid.
> But there is a difference between disliking a strawman, disliking real
> examples, and much more importantly there is a huge difference
> from disliking it to effectively forbidding it:
Right. But my point is not about the advantages of Lisp1 vs Lisp2 per se, but
that reasonable people can have reasonable reasons for choosing one way or the
other.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: Xah Lee
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <B6DDE497.69F2%xah@xahlee.org>
Dear Pierre R. Mai and readers,
You too, can nourish from my harangue.
The English language, and just as well any natural human language, are
so-called fucked up languages because of their irregularity and complexity
and all. In front of so many of you knowledgeable man here, i don't think i
need to explain that. What needs explanation is how stupid you guys are, not
seeing what improvement and progress is about. Allow me to elaborate.
You know, that learning is moving forward and not backward right? I mean, in
general, knowledge accumulates. When you were a teen, you surely jump
higher, run faster, and can bully more kids when you were a kindergartener.
But when you were in mid age, you surely know more about sciences, more
about politics, and more about how to get laid, do you not? And, when you
are an older adult, you know more about people and the way things are than
20 years ago. (this is why sages are portrayed as old man) Likewise, except
the Dark Ages of fucking God believing religions, each generation of human
beings certainly understand more about ourselves and the world. Unless some
massive burning of books or erasing of memories took place, knowledge in
general grows and accumulates. "Your kids are 'smarter' than you", goes the
saying. A bright math student of today knows far more about Calculus than
Newton or Lebniz, for example. A short course of group theory or logic of
today covers the crystalized gist of centuries of geniuses' work. A physics
major moron in today's school can _rightfully_ tell Aristotle or other
classic sages to shove their theories of Fire, Air, Water and Earth up their
asses.
For nature of progress or the advancement of ideas and concepts, it is
important to realize what are known _were_ not known. That _is_ the gist of
intellectual progress. For example, Kurt Godel's works are what logicians
before him could not possibly imagine. The modern idea of space-time by
Albert Einstein is what earlier physicists could not dream of. The digital
computers of today Charles Babbage could not foresee.
I'll come back to this in a moment.
> Well, noone said that disliking '(time time)' is inherently stupid.
> But there is a difference between disliking a strawman, disliking real
> examples, and much more importantly there is a huge difference
> from disliking it to effectively forbidding it:
> In a multiple-namespace language noone is forced to use identical
> names, but everyone is enabled not to worry about clashes. In a
> single-namespace language, everyone is forced to worry about clashes,
> so that those that dislike "punning" don't have to understand it in
> the innards of _foreign_ code (they can avoid it in their own code
> just as well in a multiple-namespace language, and because of lexical
> scoping, the punning never escapes the local lexical scope).
I haven't read this whole thread, but i dare say so far everyone is
thoughtlessly abliss that nobody have explicitly made the critical
pronouncement that the term "namespace" is unfit and misleading as the
caption for the topic of the argument in the thread.
In this thread, you guys are discussing the merit of allowing one single
variable name in a computer language to have multiple meanings in a single
program, e.g. as a variable and as a function's name.
This is not about _namespace_. Namespace in programing languages has more
standard meanings, namely a system to allow names in different modules or
libraries to coexist in a single program without clashing. We say that each
module, package, library, or other such has their own namespace. We say that
we import names from one package to our program's namespace.
Languages that don't have modules or library systems are thus
single-namespace by definition. Scheme is thus an example. Early languages
are also single-namespace.
The concept you guys are debating about may be more appropriately called
semantic-space, type-space, or meaning-space. The gist is that one name is
mapped to single or multiple grammatical meanings with respect to the
language compiler. Thus, for brevity we may say Common Lisp's name is
multi-meaning-space, whereas Scheme's single-meaning-space.
This is not nitpicking on names, because bad terminology begets
misunderstanding and confusion. Erik Naggum's stupid analogy of
multi-meaning-space to Unix's shell's program/file multi-namespace is lead
by this confusion. (this is another example of the subtleties, difficulties,
and the stupidities of English and those blind English language lovers.)
> So the single-namespace approach
> is restricting freedom of expression,
^^^^^^^^^^^^^^^^^^^^^
That's really a bad expression.
Expression for a computer language _should_ mean the ability to express with
respect to algorithms, not syntax variability or obfuscatibility. (e.g.
syntax sugars, formatting styles. Such are Perl enthusiast's definition of
expressiveness; not by choice either, but because they are too stupid to
understand any other way.)).
In comparison, in human languages it is more valuable to consider
expressiveness as the ability to express ideas, not how many ways one idea
can be expressed. English do poorly with respect to the former, but richly
with respect to the latter.
One may ask: "given that general computer languages are Turing Complete,
that they can express any thing computable, then what does 'expressiveness'
mean?". Answer: "Given that any cars run, does that mean all cars are
equal?". Efficiency, precision, flexibility, will be good measures to begin
with. The measures of metrics is another topic.
> in order to increase readability for a segment of the user community
> (possibly even decreasing readability for another segment).
Because of the screwiness of English, which made Pierre to not have a _clear
and explicit_ understanding of the word _expressibility_, thus he is mislead
here to think in a stupid direction.
_Readibility_ of a program, as most of you well-read man here knew, depends
foremost on algorithm, design, and coding discipline of the programer, and
much less on trivial things like syntax sugar, formatting, or whether the
language's single-meaning-space.
If we want to encourage readability, then we should emphasize beginning with
proper education, proper understanding of the problem, proper understanding
of the language, proper algorithm selection. Zero attention should be paid
to other things.
> In and of itself I don't think that is a good trade-off (if I wanted
> B&D, I'd go elsewhere). So in order to convice me of the validity of
> the single-namespace approach, there would have to be some additional
> advantage to offset the net disadvantage I perceive. Beside the
> theoretical argument that "only 0, 1 and infinity are valid numbers in
> CS", I haven't seen any such argument. In my eyes it is not
> multiple-namespaces that have to defend their existence (as if they
> were abberations that better have a good ra�son d'�tre, lest they be
> flushed). And that is the whole problem with this discussion:
> Instead of considering both approaches to be equally in need of
> validation, it somehow always is single-namespaces that are considered
> the norm, and only multiple-namespaces have to be defended.
I dare say many of you are AI experts (at least familiar with) or linguists
(not very bright, though). You guys know that because of all the computer
proliferation, AI research, and the need for translation software in the
past hundred years, we have made significant strides in understanding
languages. In the beginning of the message, I reminded and gave you examples
that the discovery of unforeseen ideas is the gist of progress. We can take
a moment to self-analyze. What's that hidden idea? What is holding us up?
What will be our greatest next discovery? I cannot be an unerring prophet,
but hints are around us. Because of our advanced understanding of languages,
we were able to invent a language that is based on sound mathematics. This
language, is called loglan/lojban. This language is superficially and
artificially flaw-free, but we do not know how it spats with natural
languages like English in practice. Not until, we embrace the possibilities.
Let's just imagine that in a crystal ball of some prophet somewhere, that
human beings of some years away speaks not natural language no more, and
their children speaks _poetry_ more teeming with concepts, more poignant
with nuances, more _expressive_ than Shakespeare can possibly dream in
English.
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
From: Wade Humeniuk
Subject: Re: Separate namespaces [was: Re: please tell me the designfaults]
Date:
Message-ID: <99blqu$gr3$1@news3.cadvision.com>
"Xah Lee" <···@xahlee.org> wrote in message
······················@xahlee.org...
> Dear Pierre R. Mai and readers,
>
> You too, can nourish from my harangue.
> <snip>
> but hints are around us. Because of our advanced understanding of
languages,
> we were able to invent a language that is based on sound mathematics. This
> language, is called loglan/lojban. This language is superficially and
> artificially flaw-free, but we do not know how it spats with natural
> languages like English in practice. Not until, we embrace the
possibilities.
> Let's just imagine that in a crystal ball of some prophet somewhere, that
> human beings of some years away speaks not natural language no more, and
> their children speaks _poetry_ more teeming with concepts, more poignant
> with nuances, more _expressive_ than Shakespeare can possibly dream in
> English.
It sounds that one cannot construct a pun (not that any AI program would
understand anyways) in Lojban, kind of dry and boring. Lojban if accepted
would be quickly modified as a language by groups in society to
differentiate themselves from other groups.
Why are you a proponent of Lojban (culturally neutral) instead of a language
that builds on the past like Esparanto?
Flaw-free???????? What is that? You don't like chaos?
Wade
From: Xah Lee
Subject: Re: Separate namespaces [was: Re: please tell me the designfaults]
Date:
Message-ID: <B6DEFD3F.6A1D%xah@xahlee.org>
"Wade Humeniuk" <········@cadvision.com> wrote:
> It sounds that one cannot construct a pun (not that any AI program would
> understand anyways) in Lojban, kind of dry and boring. Lojban if accepted
> would be quickly modified as a language by groups in society to
> differentiate themselves from other groups.
>
> Why are you a proponent of Lojban (culturally neutral) instead of a language
> that builds on the past like Esparanto?
>
> Flaw-free???????? What is that? You don't like chaos?
>
> Wade
For an uninformed twit like you, the best way to ask a question is to be
sincere and earnest.
Spent some months reading about constructed languages, then you can try me
again.
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
> From: "Wade Humeniuk" <········@cadvision.com>
> Organization: CADVision/PSINet
> Newsgroups: comp.lang.lisp
> Date: Wed, 21 Mar 2001 17:52:01 -0700
> Subject: Re: Separate namespaces [was: Re: please tell me the designfaults]
From: Lieven Marchand
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <m3lmpzoya1.fsf@localhost.localdomain>
Xah Lee <···@xahlee.org> writes:
> I dare say many of you are AI experts (at least familiar with) or linguists
> (not very bright, though). You guys know that because of all the computer
> proliferation, AI research, and the need for translation software in the
> past hundred years, we have made significant strides in understanding
> languages. In the beginning of the message, I reminded and gave you examples
> that the discovery of unforeseen ideas is the gist of progress. We can take
> a moment to self-analyze. What's that hidden idea? What is holding us up?
> What will be our greatest next discovery? I cannot be an unerring prophet,
> but hints are around us. Because of our advanced understanding of languages,
> we were able to invent a language that is based on sound mathematics. This
> language, is called loglan/lojban. This language is superficially and
> artificially flaw-free, but we do not know how it spats with natural
> languages like English in practice. Not until, we embrace the possibilities.
> Let's just imagine that in a crystal ball of some prophet somewhere, that
> human beings of some years away speaks not natural language no more, and
> their children speaks _poetry_ more teeming with concepts, more poignant
> with nuances, more _expressive_ than Shakespeare can possibly dream in
> English.
I know (of) lojban. Perhaps all of the people I've talked with about
it are very stupid, but none of them (myself included) has ever gone
far in mastering it, probably because it just doesn't mesh well with
our inate language parser. Do you know anyone who can write or speak
lojban with a reasonable speed?
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
From: Marco Antoniotti
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <y6cd7bawz6b.fsf@octagon.mrl.nyu.edu>
Lieven Marchand <···@wyrd.be> writes:
> Xah Lee <···@xahlee.org> writes:
>
...
> > we were able to invent a language that is based on sound mathematics. This
> > language, is called loglan/lojban. This language is superficially and
> > artificially flaw-free, but we do not know how it spats with natural
> > languages like English in practice. Not until, we embrace the
> > possibilities.
...
> I know (of) lojban. Perhaps all of the people I've talked with about
> it are very stupid, but none of them (myself included) has ever gone
> far in mastering it, probably because it just doesn't mesh well with
> our inate language parser. Do you know anyone who can write or speak
> lojban with a reasonable speed?
Somehow reading this message, made me think of Crick and of his
"comma-free" code for DNA. It was an ingenious creation, but it
turned out to be wrong. Nature can be more devious than what we would
like it to be. Sometimes by being less sophisticated than what we
expect.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Xah Lee
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <B6DEF8DA.6A18%xah@xahlee.org>
Lieven Marchand wrote:
> I know (of) lojban. Perhaps all of the people I've talked with about
> it are very stupid, but none of them (myself included) has ever gone
> far in mastering it, probably because it just doesn't mesh well with
> our inate language parser.
How many people you know knew Chinese, Mongolian, Hawaiian, Tamil, Latvian,
Estonian, Persian, Greek, or Norwegian Sign Language fluently? Perhaps "the
people you've talked to are stupid"??? Probably these natural languages
"just doesn't mesh well with our inate language parser"??? <-- Kent Pitman
style moronitude.
> Do you know anyone who can write or speak
> lojban with a reasonable speed?
The answers can be found rather effortlessly on the web.
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
> From: Lieven Marchand <···@wyrd.be>
> Newsgroups: comp.lang.lisp
> Date: 21 Mar 2001 17:57:26 +0100
> Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
From: Ray Blaak
Subject: Re: Separate namespaces [was: Re: please tell me the design faults]
Date:
Message-ID: <m3vgp3h8fn.fsf@blight.transcend.org>
Erik Naggum <····@naggum.net> writes:
> * Ray Blaak
> > To assume that people who still prefer a single namespace are just stupid
> > or ignorant is profoundly foolish and arrogant. It really does depend on
> > the situation.
> What really bugs me about stupidity is that those suffering from it seem
> unable to figure out _why_ they are (called) stupid, but have to deflect
> the accusation, so they object to it based on some obviously non-stupid
> thing, and _ignore_ the property that _is_ stupid. This self-defense
> mechanism that prevents them from getting any point beyond the obvious is
> probably how they ended up how they are, too. Retaliation is of course the
> only option, not the smartest they can think of, but the only option
"Retaliation"? Just because that is your usual mode of operation does not mean
that it is mine, or even most people's. "Explaining how it is not stupid" is a
more accurate way to put it.
Do you really expect something different? You call people stupid they will
defend/explain themselves. I just called you foolish and arrogant, so naturally
you are defending yourself/crushing me too.
At any rate, I didn't originally post because I thought you were calling *me*
stupid, although you certainly are now.
> Does it make anyone _less_ stupid if he can claim that the one who calls
> him that is foolish and arrogant?
No, what makes "anyone" less stupid is if they can show that some of the
reasons for which they are called stupid do not apply.
Being foolish and arrogant results, naturally, by assuming that a whole class
of people who like a certain technical approach are inherently stupid. Until
you know all of the reasons people choose such an approach, you cannot assume
that their reasons are invalid by definition. You can certainly disagree with
the reasons you know about, and even discover stupid ones and stupid people,
but whether an arbitrary person is choosing an approach for a stupid reason can
only be discovered by dealing with that person. Until then, you do not *know*
if the person is stupid.
I mean, even the use of Visual Basic, an abominable language if I have ever
seen one, is not inherently stupid given the appropriate goals.
> Lexical vs dynamic scope is _completely_ irrelevant
No, it is _very_ relevant, and obviously so, since it directly affects how much
a Lisp2 (well Namespace-2, in the case of shells) is needed to avoid
problems. Consider this excerpt from another subthread:
(defun some-list ()
(list 'a 'b 'c))
(let ((list '(1 2 3)))
(let ((another-list (some-list)))
(cons list another-list)))
Notice how in a dynamically-scoped Lisp1 system such code will fall flat on its
ass. Notice how in a dynamically-scoped Lisp2 system the problem is neatly
avoided. Notice how in a lexically-scoped Lisp1 system the problem cannot even
occur. And for completeness, a lexically-scoped Lisp2 system passes with flying
colors as well.
> So, _are_ shells really dynamically scoped? Of course not!
You're right! I should have been more precise. I grovel appropriately.
The important point, however, is that shell command execution is dynamically
determined, as you were so strenuously pointing out to Bruce. It is precisely
in these situations that function/variable namespace separation is such a help.
When you no longer have such dynamic resolution of names, such as in a
lexically scoped system, this particular strong reason for using Lisp2, that of
avoiding insanely obscure bugs that the programmer has no absolute control
over, is no longer necessary.
Now, there are other reasons to use Lisp2, of course, but that general debate
is not the one I am dealing with.
> Is it really true that function/variable separation is a _requirement_ of
> dynamically scoped systems? No, not at all.
Am I in the weird position of arguing with you *for* function/variable
separation? Or are you just being anally pedantic about the word "requirement"?
No, it is not a _requirement_ if one is willing to live with insanely obscure
bugs. No, it is not a _requirement_ if one is willing to use naming conventions
for functions, which no one actually is, especially you. No, it is not a
_requirement_, just a really really fucking good idea.
I was actually *agreeing* with you in the shell example!
> I don't have time to debunk Ray Blaak's incredibly stupid response, but
> it does _not_ refute my impression that single-namespace guys are idiots.
Well, you are certainly acting true to form. c.l.l just wouldn't be the same
without your lovable, prickly presence.
--
Hugs and Kisses, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.