This kind of relates to the huge namespaces thread but it's a
different thing I think.
The Lisp1 / Lisp2 debate seems to result in a lot of people obsessing
about functions and variables, but this is really only a tiny fraction
of the problem it seems to me. For instance consider a lisp system
with an extensible type or class system, like CL, especially if types
or classes are first-class, as classes are in CL. These things need
names too (well, of course they don't *need* names any more than
functions do, but it's useful the same way it's useful for functions).
Should these names cohabit with variable names? They don't in CL;
Scheme avoids the issue by not having an extensible type system (or
first-class types/classes I think); if I remember correctly they *did*
in oaklisp -- I forget how it solved the obvious problems (what was
the name of the type of conses?), but I do remember it being a
significant pain to use, though I never wrote more than small programs
in it.
In general large systems develop a whole bunch of things-with-names --
CL, being historically quite large, already has quite a few, certainly
a lot more than two (I've heard the number seven quoted), and apart
from the language, programs written in the language often develop many
more.
I guess the question would then be: is the Lisp1 approach is to say
that all these things get loaded into the single space of names, or is
this only done for some specific types of thing, or what? Scheme
seems to have solved this in practice by not having very many types of
thing, and providing a single namespace for those it does have. What
do/did other unified function/variable lisps which have/had an
extensible type/class system do? Is my memory of oaklisp correct?
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> I guess the question would then be: is the Lisp1 approach is to say
> that all these things get loaded into the single space of names, or is
> this only done for some specific types of thing, or what? Scheme
> seems to have solved this in practice by not having very many types of
> thing, and providing a single namespace for those it does have. What
> do/did other unified function/variable lisps which have/had an
> extensible type/class system do?
Well, I'll be the token Dylan chump again.
Dylan has a single namespace for functions andan extensible class/type
system and variables, and it also puts both classes and types[1] in the
same namespace. There is a lexical *convention* often used to
distinguish types, which is to form the name like <integer> with angle
brackets around it, just as global variables are conventionally named as
*my-global*.
Dylan also provides namespace management tools, such as allowing you to
selectively import only the items you want from a library, and allowing
you to rename them as you import them. If you really don't like the
standard names and conventions in the "Dylan" library then you can even
make a "myDylan" library in which you import all the standard stuff,
rename it to your liking, and re-export it. Then you can have your
programs import the myDylan library instead of the Dylan library.
-- Bruce
[1] not the same thing -- a class is a type, but there are types which
are not classes e.g. unions of classes, singletons, limited integers and
limited collections
"Bruce Hoult" <·····@hoult.org> wrote in message
································@news.nzl.ihugultra.co.nz...
> Well, I'll be the token Dylan chump again.
>
> Dylan has a single namespace for functions andan extensible class/type
> system and variables, and it also puts both classes and types[1] in the
> same namespace.
Yeah, but it's dead. And besides, it's not a Lisp. It has a screwed up
syntax and macro system. I could just as well say that C++ has multiple
namespaces and be as relevant. In short, your comment has no bearing on
anything remotely Lisp-like. Go play on comp.lang.dylan.
faa
In article <·····················@news.uswest.net>, "Frank A. Adrian"
<·······@uswest.net> wrote:
> "Bruce Hoult" <·····@hoult.org> wrote in message
> ································@news.nzl.ihugultra.co.nz...
> > Well, I'll be the token Dylan chump again.
> >
> > Dylan has a single namespace for functions andan extensible class/type
> > system and variables, and it also puts both classes and types[1] in the
> > same namespace.
>
> Yeah, but it's dead.
Funny sort of dead. There are two implementations under active
development. I can name off the top of my head two universities who
have started to use it for teaching in the past year.
> And besides, it's not a Lisp.
I don't really give a damn whether you want to call it a Lisp of not.
If you plot a bunch of programming languages in any multi-dimensional
space then Dylan is going to end up in a tiny little cluster somewhere
between Common Lisp and Scheme and with virtually nothing else nearby
(but Perl and Python are both headed that way).
So Dylan isn't written using S-expressions. Get over it.
> It has a screwed up syntax and macro system.
Guess you haven't seen C++, Perl, Visual Basic, or ML.
> I could just as well say that C++ has multiple namespaces and
> be as relevant.
Regardless of relevancy you'd be totally wrong, in the sense being used
here anyway.
> In short, your comment has no bearing on
> anything remotely Lisp-like. Go play on comp.lang.dylan.
I love you too, darling.
-- Bruce
"Frank A. Adrian" <·······@uswest.net> writes:
> "Bruce Hoult" <·····@hoult.org> wrote in message
> ································@news.nzl.ihugultra.co.nz...
> > Well, I'll be the token Dylan chump again.
> >
> > Dylan has a single namespace for functions andan extensible class/type
> > system and variables, and it also puts both classes and types[1] in the
> > same namespace.
>
> Yeah, but it's dead. And besides, it's not a Lisp. It has a screwed up
> syntax and macro system. I could just as well say that C++ has multiple
> namespaces and be as relevant. In short, your comment has no bearing on
> anything remotely Lisp-like. Go play on comp.lang.dylan.
I find this response to be annoying, and utterly rude, given that
someone has offered useful information. Anyone in his right mind can
look at Dylan and know that it was strongly affected by (Common) Lisp,
and so his post is relevant, and does have bearing on the topic.
jeez. some of us have really lost it over this.
dave
"David Bakhash" <·····@alum.mit.edu> wrote in message
···················@alum.mit.edu...
> I find this response to be annoying, and utterly rude, given that
> someone has offered useful information.
1+1=2
1+2=3
2+1=3
...
I could go on, but I hope you have a clue by now. This is useful
information, but is is relevant?
>Anyone in his right mind can
> look at Dylan and know that it was strongly affected by (Common) Lisp,
Actually, the first implementations were in Scheme. But the language lost
any relevance to the debate on single namespaces in Lisp-like languages when
the developers of Dylan decided that C-like syntax would move them closer to
market acceptance. Given that this is the quality of decision that they
make (confirmed by the OBVIOUS market success of Dylan) I see no reason to
see why their input on this debate would be valuable. If they want to
debate single vs. multiple namespaces, let them go into comp.lang.c++, since
this is the pit of perdition into which they have cast themselves...
> and so his post is relevant, and does have bearing on the topic.
Only in your dreams...
> jeez. some of us have really lost it over this.
Obviously...
faa
"Frank A. Adrian" <·······@uswest.net> writes:
> > and so his post is relevant, and does have bearing on the topic.
> Only in your dreams...
> > jeez. some of us have really lost it over this.
> Obviously...
Maybe you missed the original posters question to which Bruce was
responding. It read:
> I guess the question would then be: is the Lisp1 approach is to say
> that all these things get loaded into the single space of names, or is
> this only done for some specific types of thing, or what? Scheme
> seems to have solved this in practice by not having very many types of
> thing, and providing a single namespace for those it does have. WHAT
> DO/DID OTHER UNIFIED FUNCTION/VARIABLE LISPS WHICH HAVE/HAD AN
> EXTENSIBLE TYPE/CLASS SYSTEM DO?
[I upcased the relevant part to which Bruce responded]
The *only* argument I can possibly see here is that the question was
about other Lisps, and you don't consider Dylan to be related in the
context of this discussion.
This is such a fine line, considering that the information Bruce gave
on Dylan was purely technical and factual, I simply don't see how you
could respond the way you did. If you didn't welcome the information
here as a followup to the poster asking, well, then I'll openly state
that I for one *do* welcome it. More important is probably the
opinion of the poster who asked. Maybe he can separate the facts in
the answer from his hatred.
If you go back recently, you'll see a post about how Lisps and Scheme
are cousins, but when it comes to classification, they do not share
attributes that are taxonomically meaningful. If Dylan and Common
Lisp are such cousins (and, to me, Dylan is closer to CL than Scheme),
then the choices made by the Dylan community (and why) can be learned
from, and I am confounded about why you resist this knowledge. And if
you already [think you] know it, then why would you want to make it
harder for others, like me, to find out?
There are so many posts that offer less information no utility, and
almost no relevance to what they're following up, and the one to which
you so wrongly replied probably deserves a second thought. We don't
need to rehash with "Is Dylan a Lisp" to see this, either.
dave
"David Bakhash" <·····@alum.mit.edu> wrote in message
···················@alum.mit.edu...
> "Frank A. Adrian" <·······@uswest.net> writes:
> Maybe you missed the original posters question to which Bruce was
> responding. It read:
[Irrelevant BoC snipped]...
And perhaps you missed the post that started this whole mudball spiralling
downhill in the first place. Somebody posted a question about design flaws
in CL and some pathetic, scheme-loving LOSER posted that multiple namespaces
was a design flaw. In most cases, CL people don't go into comp.lang.scheme
and piss and moan about Scheme's design flaw of NOT having a single name
space. As far as I am concerned, a bunch of Scheme (or Dylan) weenies
coming into comp.lang.lisp attempting to bash CL with this NON-ISSUE deserve
what they get. Especially people from the Dylan camp who made it clear long
ago that they wished to sever ties with the Lisp community. So as to his
(or your) opinion... Who cares?
faa
* Frank A Adrian wrote:
> And perhaps you missed the post that started this whole mudball spiralling
> downhill in the first place. Somebody posted a question about design flaws
> in CL and some pathetic, scheme-loving LOSER posted that multiple namespaces
> was a design flaw. In most cases, CL people don't go into comp.lang.scheme
> and piss and moan about Scheme's design flaw of NOT having a single name
> space. As far as I am concerned, a bunch of Scheme (or Dylan) weenies
> coming into comp.lang.lisp attempting to bash CL with this NON-ISSUE deserve
> what they get. Especially people from the Dylan camp who made it clear long
> ago that they wished to sever ties with the Lisp community. So as to his
> (or your) opinion... Who cares?
Just to make things clear. I posted the original article in this
thread (the thread to which the article you are reading now belongs,
not any other thread: I quite deliberately started a new thread), and
I think the response about Dylan was useful and interesting. Quite
unlike any of your contributions to this thread, which I found too
offensive and stupid to reply to until now.
--tim
"Frank A. Adrian" <·······@uswest.net> writes:
> "David Bakhash" <·····@alum.mit.edu> wrote in message
> ···················@alum.mit.edu...
> > "Frank A. Adrian" <·······@uswest.net> writes:
> > Maybe you missed the original posters question to which Bruce was
> > responding. It read:
> [Irrelevant BoC snipped]...
> And perhaps you missed the post that started this whole mudball
> spiralling downhill in the first place. Somebody posted a question
> about design flaws in CL and some pathetic, scheme-loving LOSER
> posted that multiple namespaces was a design flaw. In most cases,
> CL people don't go into comp.lang.scheme and piss and moan about
> Scheme's design flaw of NOT having a single name space. As far as I
> am concerned, a bunch of Scheme (or Dylan) weenies coming into
> comp.lang.lisp attempting to bash CL with this NON-ISSUE deserve
> what they get. Especially people from the Dylan camp who made it
> clear long ago that they wished to sever ties with the Lisp
> community. So as to his (or your) opinion... Who cares?
Ah, so you're seeking to win the "biggest jerk of the week"
competition.
If you want to complain at the Scheme or Dylan "LOSERS," then you
really should post your messages to the appropriate newsgroups.
_Particularly_ if you feel that they aren't instances of Lisp.
It seems pathetic that you'd bother cluttering up comp.lang.lisp with
_your_ blathering.
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www.ntlug.org/~cbbrowne/finances.html
What hair color do they put on the driver's licenses of bald men?
"Frank A. Adrian" <·······@uswest.net> writes:
> And perhaps you missed the post that started this whole mudball
> spiralling downhill in the first place.
No. been following it closely.
> Somebody posted a question about design flaws in CL and some
> pathetic, scheme-loving LOSER posted that multiple namespaces was a
> design flaw.
That "pathetic Scheme-loving loser" appears to also be a CL
programmer. And even if he's not, he's interested, and he's
contributed as much as he's queried here. If his strength is in other
languages that share certain important goals with Common Lisp, then
why is this bad? Do you want comp.lang.lisp to be inbred?
If he'd come on and just said "CL sucks, Lisp2's suck,..." then you'd
have a point. The guy you so vehemently followed up to _did_ provide
reasoning for his arguments, and seemed to make an effort to
substantiate his views on the matter.
> In most cases, CL people don't go into comp.lang.scheme and piss and
> moan about Scheme's design flaw of NOT having a single name space.
No. The one you reacted to wasn't pissing and moaning. He might have
been playing devil's advocate, but that's not a bad thing.
> Especially people from the Dylan camp who made it clear long ago
> that they wished to sever ties with the Lisp community.
Let them sever sever whatever they want. Doesn't mean we should do
the same, and therefore cease to learn from them, shutting our eyes
and ears.
> So as to his (or your) opinion... Who cares?
Agreed. I voiced my opinions, and wish to scratch that. I do it more
often than appropriate (it leaks out sometimes). I don't think, and
hope, that people don't care about my opinion, nor do I care about
theirs. I do care about the facts, and the pros and cons to different
programming languages, styles, and paradigms, and I think that was the
focus of the thread, even more than Lisp vs. Scheme.
dave
Bruce Hoult <·····@hoult.org> writes:
> Dylan has a single namespace for functions andan extensible class/type
> system and variables, and it also puts both classes and types[1] in the
> same namespace. There is a lexical *convention* often used to
> distinguish types, which is to form the name like <integer> with angle
> brackets around it, just as global variables are conventionally named as
> *my-global*.
So Dylan does have more than one namespace, it's just that it failed
to include it in the language, so that people now have to kludge
around it, just like CL failed to provide a different namespace for
dynamic variables, and we have to kludge around it. Seems to me that
this kind of invalidates your earlier comments about "single"
namespace users not having a burning need for different namespaces:
If they hadn't, they wouldn't have come up with said conventions
(they'd just name things differently on each occassion).
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
"Pierre R. Mai" <····@acm.org> writes:
> Bruce Hoult <·····@hoult.org> writes:
>
> > Dylan has [...] a lexical *convention* often used to distinguish
> > types, which is to form the name like <integer> with angle
> > brackets around it, just as global variables are conventionally
> > named as *my-global*.
In the case of Dylan, I have no firsthand knowledge to share, but I
seem to recall a Dylan designer telling me the choice of single
namespace-ness was cast in stone because of the pragmatics of native
function linkers on operating systems, which (I was told; I don't
gnerally deal directly with linkers) typically insist there be only
one symbol with any given name; that is, they don't embrace namespacing.
> So Dylan does have more than one namespace, it's just that it failed
> to include it in the language, so that people now have to kludge
> around it, just like CL failed to provide a different namespace for
> dynamic variables, and we have to kludge around it. Seems to me that
> this kind of invalidates your earlier comments about "single"
> namespace users not having a burning need for different namespaces:
> If they hadn't, they wouldn't have come up with said conventions
> (they'd just name things differently on each occassion).
The same observation could be made about Java, where one might think
that casification gave one access to more names, but where in fact that
access is, in practice, taken back because Foo, FOO, and foo are
pragmatically reserved by lexical convention for things that namespaces
ought to have separated... exactly because people find it useful to pun
in their brains, but the langauge doesn't allow them syntax enough to pass
the pun through to the langauge.
Erik Naggum <····@naggum.net> writes:
> * Kent M Pitman <······@world.std.com>
> > In the case of Dylan, I have no firsthand knowledge to share, but I
> > seem to recall a Dylan designer telling me the choice of single
> > namespace-ness was cast in stone because of the pragmatics of native
> > function linkers on operating systems, which (I was told; I don't
> > gnerally deal directly with linkers) typically insist there be only
> > one symbol with any given name; that is, they don't embrace namespacing.
>
> You were bullshitted by this guy. From times immemorial, deficient
> linkers have been tricked by adding all sorts of junk to symbols. C
> makes sure that you don't conflict with other symbols by prefixing an
> underscore to its symbols. C has the redeeming quality that it was
> probably smart at the time. C++ requires name mangling to deal with
> deficient linkers. C++ does not have any redeming qualities.
Well, effectively their naming conventions implement this, but under
user-controlled mangling... The only oddity of it is that I assume
symbols with funny characters like "<" and ">" and "*" in them must
be problematic for at least someone in some other language. Arguably
the Java conventions were "better" in this regard.
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> "Pierre R. Mai" <····@acm.org> writes:
>
> > Bruce Hoult <·····@hoult.org> writes:
> >
> > > Dylan has [...] a lexical *convention* often used to distinguish
> > > types, which is to form the name like <integer> with angle
> > > brackets around it, just as global variables are conventionally
> > > named as *my-global*.
>
> In the case of Dylan, I have no firsthand knowledge to share, but I
> seem to recall a Dylan designer telling me the choice of single
> namespace-ness was cast in stone because of the pragmatics of native
> function linkers on operating systems, which (I was told; I don't
> gnerally deal directly with linkers) typically insist there be only
> one symbol with any given name; that is, they don't embrace namespacing.
That's pretty clearly bogus because you can use the same trick that C++
uses to get multiple functions with the same name past the linker --
name mangling.
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> In article <···············@world.std.com>, Kent M Pitman
> <······@world.std.com> wrote:
>
> > "Pierre R. Mai" <····@acm.org> writes:
> >
> > > Bruce Hoult <·····@hoult.org> writes:
> > >
> > > > Dylan has [...] a lexical *convention* often used to distinguish
> > > > types, which is to form the name like <integer> with angle
> > > > brackets around it, just as global variables are conventionally
> > > > named as *my-global*.
> >
> > In the case of Dylan, I have no firsthand knowledge to share, but I
> > seem to recall a Dylan designer telling me the choice of single
> > namespace-ness was cast in stone because of the pragmatics of native
> > function linkers on operating systems, which (I was told; I don't
> > gnerally deal directly with linkers) typically insist there be only
> > one symbol with any given name; that is, they don't embrace namespacing.
>
> That's pretty clearly bogus because you can use the same trick that C++
> uses to get multiple functions with the same name past the linker --
> name mangling.
FWIW, and I don't know what that is, I recall asking this very same question
at the time. My recollection is that the response was that they wanted
transparent pass-through of the name chosen by the user; that is, that
they did not want the unpredictability of mechanically introduced name
mangling. (I recall suggesting specifically that the namespace could be
partitioned by adding "f_" to the start of functions and "v_" to the start
of variables, or some such, but my recollection is that their reply was that
this wasn't suitable because then the programmer had no, or perhaps it was
"inadequate", control over what symbol he was delivering to a remote package.)
I'm very sorry I can only say sentences beginning with "recall" here,
but the problem is that I (then and now) have no specific detailed
knowledge of how linkers work. I would have presumed that the only thing
you had to do was project the twospace onto a single namespace in a way that
no names collided, but for some reason the person I was talking with seemed
to reject this as unacceptable. At that point, as now, I was out of my
conversational depth and merely "recorded" the textual details for future
pondering because it puzzled me that it didn't match what model I had.
I can't remember who I was talking to but had no reason to doubt their
competence, nor time to ask them to explain in more detail.
Oh well.
On Mon, 12 Mar 2001, Kent M Pitman wrote:
> Bruce Hoult <·····@hoult.org> writes:
[ Dylan has single namespace for compatibility with braindead linkers]
> > That's pretty clearly bogus because you can use the same trick that C++
> > uses to get multiple functions with the same name past the linker --
> > name mangling.
>
> FWIW, and I don't know what that is, I recall asking this very same question
> at the time. My recollection is that the response was that they wanted
> transparent pass-through of the name chosen by the user; that is, that
> they did not want the unpredictability of mechanically introduced name
> mangling. (I recall suggesting specifically that the namespace could be
> partitioned by adding "f_" to the start of functions and "v_" to the start
> of variables, or some such, but my recollection is that their reply was that
> this wasn't suitable because then the programmer had no, or perhaps it was
> "inadequate", control over what symbol he was delivering to a remote package.)
Seems to me the compelling issue is not getting Dylan to work with
existing single namespace linkers -- name mangling can get you past this
-- but in accessing Dylan functions and objects from traditional single
namespace *languages*. If the language implementation uses name mangling,
then it also needs special syntax to make things available to languages
that don't understand the mangling, like C++'s extern "C" syntax, or some
other automatic cruft. Or, you need extra syntax and support in the other
language to support the foreign names; there's lots of precedent for that
on Mac and Windows platforms, but politically it was probably thought
impossible to ram that through in the case of Dylan. So, the choice of a
single namespace does simplify the problems of interacting with existing
language environments even though there are other choices.
Tim
On Mon, 12 Mar 2001 09:14:32 GMT, Kent M Pitman <······@world.std.com>
wrote:
>they did not want the unpredictability of mechanically introduced name
>mangling. (I recall suggesting specifically that the namespace could be
>partitioned by adding "f_" to the start of functions and "v_" to the start
>of variables, or some such, but my recollection is that their reply was that
>this wasn't suitable because then the programmer had no, or perhaps it was
>"inadequate", control over what symbol he was delivering to a remote package.)
You normally have to use mangling to support function overloading, but
the mangled name is deterministic: it is usually generated from arity
and parameter types [sometimes return type as well]. Could/does Dylan
do enough type inferencing to generate a determinstic name for
functions with untyped parameters?
It sounds to me as if they were concerned about delivering library
modules callable from other languages. Linkage formats [apart from
the "image" runtime languages] are almost invariably single namespace
and the link editors are inanely stupid and offer poor user control of
the process as a bonus.
George
In article <··················@helice>, ·······@dyn.com wrote:
> You normally have to use mangling to support function overloading, but
> the mangled name is deterministic: it is usually generated from arity
> and parameter types [sometimes return type as well]. Could/does Dylan
> do enough type inferencing to generate a determinstic name for
> functions with untyped parameters?
"Untyped" parameters (and return types) just means that the type is
<object>, so that's not a problem. In Dylan you also have to allow for
whether or not the function accepts #rest arguments and keyword
arguments, and the arity of the return values.
The "d2c" compiler (www.gwydiondylan.org) compiles Dylan into C and so
has to have names acceptable to C (and the linker) for overloaded
functions. However, unlike C++, separate compilation works by having
the compiler create a summary file for each library and when the library
is used elsewhere the compiler reads the summary file rather than a
source code include file. This means that the mapping from a Dylan
function to a C function name can be arbitrary, as long as that mapping
is stored in the summary file.
Unfortunately d2c doesn't currently do that :-( and the compiler
generates C names that can change when you add or remove other functions
in the same library, or with different versions of the compiler. As a
result you need to recompile things a bit more often than you should. I
consider this a bug.
-- Bruce
In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
<····@acm.org> wrote:
> Bruce Hoult <·····@hoult.org> writes:
>
> > Dylan has a single namespace for functions andan extensible class/type
> > system and variables, and it also puts both classes and types[1] in the
> > same namespace. There is a lexical *convention* often used to
> > distinguish types, which is to form the name like <integer> with angle
> > brackets around it, just as global variables are conventionally named
> > as
> > *my-global*.
>
> So Dylan does have more than one namespace, it's just that it failed
> to include it in the language, so that people now have to kludge
> around it, just like CL failed to provide a different namespace for
> dynamic variables, and we have to kludge around it. Seems to me that
> this kind of invalidates your earlier comments about "single"
> namespace users not having a burning need for different namespaces:
> If they hadn't, they wouldn't have come up with said conventions
> (they'd just name things differently on each occassion).
You could look at it that way if you wanted to, but as I just wrote in
another post, I think that being able to distinguish certain kinds of
things such as global (or special in CL) variables or types by
inspection is a useful thing to do.
-- Bruce
* Bruce Hoult wrote:
> Dylan has a single namespace for functions andan extensible class/type
> system and variables, and it also puts both classes and types[1] in the
> same namespace. There is a lexical *convention* often used to
> distinguish types, which is to form the name like <integer> with angle
> brackets around it, just as global variables are conventionally named as
> *my-global*.
How would this differ in practice from a separate namespace with an
accessor construct which looked like <...>? It looks suspiciously
like the same thing, except you'd avoid occasional lossage when
someone defined a class with the `wrong' naming convention.
CL has the same issues with special variables. It has a naming
convention, but occasionally you come across programs written people
who didn't know it, and discover that special variables have curious
names. I kind of think, on balance that it would be better to have a
different namespace for specials, though it's not something I lose
sleep over.
Come to think of it, don't scheme systems which have specials tend to
support then by something like (fluid-let ...) and (fluid ...). No,
surely no scheme person could tolerate this, I must be misremembering
(or perhaps it's OK because specials are impure anyway so it's OK to
have impure constructs to access them?).
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>* Bruce Hoult wrote:
>
>> Dylan has a single namespace for functions andan extensible class/type
>> system and variables, and it also puts both classes and types[1] in the
>> same namespace. There is a lexical *convention* often used to
>> distinguish types, which is to form the name like <integer> with angle
>> brackets around it, just as global variables are conventionally named as
>> *my-global*.
>
>How would this differ in practice from a separate namespace with an
>accessor construct which looked like <...>? It looks suspiciously
>like the same thing, except you'd avoid occasional lossage when
>someone defined a class with the `wrong' naming convention.
>
>CL has the same issues with special variables. It has a naming
>convention, but occasionally you come across programs written people
>who didn't know it, and discover that special variables have curious
>names. I kind of think, on balance that it would be better to have a
>different namespace for specials, though it's not something I lose
>sleep over.
>
>Come to think of it, don't scheme systems which have specials tend to
>support then by something like (fluid-let ...) and (fluid ...). No,
>surely no scheme person could tolerate this, I must be misremembering
>(or perhaps it's OK because specials are impure anyway so it's OK to
>have impure constructs to access them?).
You aren't misremembering, if you'll allow a minor
nitpick from me that the "let" form was actually called
"let-fluid" rather than "fluid-let", in deliberate
contrast. The idea is that fluid-let works by
side-effecting lexical variables, whereas let-fluid
manipulates a global stack of "fluid"
pseudo-variables. (There was a set-fluid! form
also in the let-fluid approach. fluid-let variables
don't need anything more than set!.)
Both approaches are implemented as syntactic
extensions in a blandly single-namespace Lisp1, so they
don't create the purity dilemma you evoke. In the
let-fluid approach, (fluid x) is actually a macro for
"look up the symbol x in the alist or hashtable stored
in the global lexical variable *fluids*".
But this is logically a different namespace, one could
counter. Exactly so. Scheme usage is very pro
logically multiple namespaces, created by using lexical
conventions to partition a physically single namespace.
Predicates (predicate?), side-effecting procedures
(side-effect!) and datatype converters
(datatype1->datatype2) each have their own "namespace".
(Though I wish the -> were a <- for compositional
legibility.)
Of course this is all possible merely because of our
great good luck in inhabiting a world where a set of
cardinality aleph-null is so easily splittable
into many (aleph-null?) different subsets, all of
cardinality aleph-null.
--d
"God didn't create *all* the natural numbers. Just
lots. Plenty."
--Edsger Dijkstra spoofing Leopold Kronecker
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * Bruce Hoult wrote:
>
>
> > Dylan has a single namespace for functions andan extensible class/type
> > system and variables, and it also puts both classes and types[1] in the
> > same namespace. There is a lexical *convention* often used to
> > distinguish types, which is to form the name like <integer> with angle
> > brackets around it, just as global variables are conventionally named
> > as
> > *my-global*.
>
> How would this differ in practice from a separate namespace with an
> accessor construct which looked like <...>? It looks suspiciously
> like the same thing, except you'd avoid occasional lossage when
> someone defined a class with the `wrong' naming convention.
>
> CL has the same issues with special variables. It has a naming
> convention, but occasionally you come across programs written people
> who didn't know it, and discover that special variables have curious
> names. I kind of think, on balance that it would be better to have a
> different namespace for specials, though it's not something I lose
> sleep over.
I don't think something like Dylan putting <> around types, or ** around
special variables in Common Lisp (paralled by putting ** around globals
in Dylan) is a matter of trying to emulate multiple namespaces within a
single namespace. The value in those conventions is that they signal to
a person reading the code that those variables have particular
properties.
In other languages, such as C++, it is common to use conventions such as
calling types foo_t, globals gFoo, members of a class or struct mFoo
etc. The purpose is not to be able to overload the same name with
different things. It's also not a form of (ick) Hungarian notation to
indicate the concrete type of the variable. What it *is* is mostly a
way to signal the *scope* and/or lifetime of the variable.
At the same time, yes, it provides a kind of poor man's multiple
namespaces, but without the extra syntax to support that. And it is
even used that way on occasion, with declarations such as "string ::
<string>".
-- Bruce
Bruce Hoult <·····@hoult.org> writes:
> At the same time, yes, it provides a kind of poor man's multiple
> namespaces, but without the extra syntax to support that. And it is
> even used that way on occasion, with declarations such as "string ::
> <string>".
Just to be clear: naming conventions are not an indication of "separate"
namespaces within a single namespace. More accurately, they are a
*partitioning* of a single namespace (a way of organizing it, if you will).
The difference is important: with separate namespaces one can have the same
identifier in each, and there is no conflict. With a partitioning you can't
because, of course, it is still a single namespace.
The obvious result is that things from different partitions still *look*
different, which is the point.
For the reasoning impaired: whether one prefers that or not is irrelevant to
this post.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
Ray Blaak <·····@infomatch.com> writes:
>
> The obvious result is that things from different partitions still *look*
> different, which is the point.
>
I'm not trying to argue with this (I agree with the elided bit that
it's very much a matter of taste). However, imagine that CL had a
separate namespace for special variables. So perhaps (SPECIAL x)
would be the formal way of getting at these things. One obvious thing
to do would be to define a read-syntax for this such that *x* ->
(special x). Similarly for classes one could define <x> ->
(find-class 'x) or something. (Neither of these would actually be a
good idea, but you see what I mean).
So it's kind of fuzzy, or at least it's fuzzy in a language with
flexible sntax.
--tim
In article <··············@blight.transcend.org>, Ray Blaak
<·····@infomatch.com> wrote:
> Bruce Hoult <·····@hoult.org> writes:
> > At the same time, yes, it provides a kind of poor man's multiple
> > namespaces, but without the extra syntax to support that. And it is
> > even used that way on occasion, with declarations such as "string ::
> > <string>".
>
> Just to be clear: naming conventions are not an indication of "separate"
> namespaces within a single namespace. More accurately, they are a
> *partitioning* of a single namespace (a way of organizing it, if you
> will).
Right.
> The difference is important: with separate namespaces one can have
> the same identifier in each, and there is no conflict. With a
> partitioning you can't because, of course, it is still a single
> namespace.
Right, but I think some people are making the argument that single-
namespace languages with naming conventions are trying to *pretend* to
have multiple namespaces, with the clear implications that someone who
wrote in, say, Dylan ...
method (list :: <list>) second(list) end
... would have *preferred* to write ...
method (list :: list) second(list) end
... if only the language permitted it. With which contention I disagree
:-)
> The obvious result is that things from different partitions still *look*
> different, which is the point.
Yes they do. I think that's a good thing. Other appear to think that
programming in such a single-namespace language would require them to
squint sufficiently that identifiers differing only in being in
different partitions looked the same, and that existing practitioners in
those languages are doing exactly that.
-- Bruce