Dylan isn't called Lisp, not by much of anybody.  While there are
similarities in some of the semantics, and Lisp folk were involved in
its design, it's still pretty clearly not "Lisp":
 -> It doesn't normally offer a REPL;
 -> Programs aren't expressed in the form of lists.

Is it potentially of interest to people interested in Lisp?  Surely.
But it's still not "Lisp."  

If it's arguable that Scheme isn't "a Lisp," then Dylan certainly
isn't.

I agree that people should say "CL" when the context doesn't make it
manifestly clear that that's what's meant.

If someone is asking about how to "use MOP in Lisp," that's a
conversation that is pretty clearly likely to be about Common Lisp.

But in more 'generic' discussions, such as this one, where Emacs Lisp
and ISLisp and such are _certainly_ legitimate instances of languages
under discussion, and where Scheme might even be near enough to fit,
it certainly does _not_ suffice to just say "Lisp."

I'd think that there is room for discussions about the similarities
and differences between Dylan and Lisp.  Just as someone might want to
discuss the differences between C# and Java.  And comp.lang.lisp is
probably a reasonable forum for such a discussion (you know which
one!).

But to consider that Dylan should be considered an instance of a "Lisp
language" seems to be going ab it too far.

Mentioning Dylan in such a context doesn't seem reasonable.

(cons 'a 'b) is something that works perfectly well in a whole raft of
Lisp-related languages, including CL, REP, and even Scheme.  It is
amusing that you have found an implementation that rejects it.

The serious point of the litmus test is that (cons 'a 'b) does
something reasonably appropriate in all of (list 'CL 'Scheme 'REP).

Dylan is sufficiently "not like Lisp" that (cons 'a 'b) doesn't work
there.

The fact that it's _not_ reasonable to include them as being "Lisps"
suggests that maybe evaluating things based on dynamically-typed
subsets of languages isn't a meaningful way to divide things up.

You can choose not to agree with that test; the wider point is that
for things not to fall into a pointless dispute, there needs to be
_some_ sort of test to agree on.

The really _simple_ one, mentioned up top, would involve the
predicate:

(defun lisp-p (language)
  (search "lisp" (string-downcase language)))

(loop
  for lang in '("common lisp" "elisp" "Scheme" "Dylan" "ISO Lisp")
  do (format t "Language ~A ~A a Lisp~%"
             lang
             (if (lisp-p lang)
                 "is" "is not")))

Language common lisp is a Lisp
Language elisp is a Lisp
Language Scheme is not a Lisp
Language Dylan is not a Lisp
Language ISO Lisp is a Lisp

I said these are four surviving flavors. ISLisp survives in the form
of an up to date ISO standard. EuLisp is, presumably, being actively
developed, and Emacs lisp in in wide use.

Of course there are historic dialects. The language to which McCarthy pointed,
and uttered ``Lisp'' was Lisp at the time. But today, that word no longer
refers to his language, except in well-established a historic context.

So when we say that McCarthy invented Lisp, we don't mean Common Lisp;
the mention of the inventor's name establishes the historic context
which causes Lisp to refer to the first dialect which he invented.

I will change, but only after the newsgroup is renamed to
comp.lang.common-lisp, right after Corman Lisp becomes Corman Common Lisp,
Xanalys LispWorks becomes CommonLispWorks, and the domain registered by the
Association of Lisp Users becomes www.common-lisp.org along with a new logo
which somehow blends in the word Common.

The definitions of programming language names change. For example Fortran
refers to Fortran 90. If you mean Fortran 77, then you have to say that,
unless it is made obvious by context, like ``in 1983, I worked on a Fortran
program'' which cannot possibly mean Fortran 90.  C now refers to C99, with
complex numbers, variable length arrays, designated initializers and other
things.  Ada refers to Ada 95, which is the most recent standard as far as I
know, not, in any case, to Ada 83.

  Goldilocks's "just right" position between these extremes will
  strike nearly all cooperatively minded intellectuals, committed to
  the operationality and advance of their disciplines, as eminently
  sensible: shared content, not only historical continuity, must
  define the /structure/ of a scientific theory; but this shared
  content should be expressed as a /minimal list/ of the /few defining
  attributes/ of the theory's /central logic/ -- in other words, only
  the absolutely essential statements, absent which the theory would
  either collapse into fallacy or operate so differently that the
  mechanism would have to be granted another name.

Dylan fails on two points to qualify as a Lisp: it does not share
historical continuity, and its abandonment of s-expressions causes it
to operate quite differently.  Dylan *was* an intentional break from
Lisp: the lack of the letters l-i-s-p in its name is a result of that.
S-expressions are not sufficient to make something a Lisp, but surely
they are part of the central set of ideas that makes a language a Lisp
dialect.  To label Dylan a Lisp reduces the term to meaninglessness.

 [...]

I'm only saying that the symbol Lisp has a default binding, which is to Common
Lisp, in the absence of any overriding context. It does not have refer to
exactly one thing, in every context and for all time.

(define-symbol-macro lisp '(common lisp))

The short name should default to the most popular, successful, feature-rich,
best-of-breed language which claims to be some kind of Lisp. That is perfectly
fair and rational.

It's the name of a programming *language* not the name of a family.  When you
say ``I wrote it in Lisp'', it can't possibly mean ``I wrote it in a whole
family of languages at the same time''. If someone wants to use Lisp to refer
to a family, then that requires a special context in which that use is clear.
It's the wrong use for the default context, because there is an expectation
that the name refers to a concrete language; a system of symbols in which you
can write a working program.

Family is a loaded word; it implies we should all be chummy and get along
as some kind of community, and stand together against the Big Bad World or some
nonsense like that.  I don't feel that I'm in any family with Scheme users, or
Emacs lisp users or the EuLisp lunatics. Or for that matter with Common Lisp
users.  A stranger who happens to know Common Lisp is not automatically my
friend.

  (symbol-macrolet ((lisp '(emacs lisp))) ...)

$ d2c -i
gwydion> local fac(n :: <integer>) n == 0 & 1 | n * fac(n - 1) end; fac(5);
evaluated expression: {literal extended-integer 120}

On the other hand, you're calling library functions for parsing and
writing s-expressions anyways, so the complexity of parsing and
writing is something that doesn't matter to the user.  What does
matter is how easy it is to do something useful with the parse tree,
and I can think of less elegant solutions than a generic function that
dispatches on the particular syntactical element in question.

If the presence of s-expressions is the litmus test, then Dylan
certainly isn't a Lisp.  But saying "it's a lot like Lisp, just that
it doesn't have s-expressions" would be justified, I think.

Andreas

Andreas

when i first read a (somewhat superficial) description of dylan, my
first impression was that someone tried to redo common lisp with a
more conventional syntax.  this impression was strengthened by the
original specs that called for two syntaxes, one of them actually
quite lisp like

hs

--

There are also manifest differences.

The computing world would probably be a better place if Dylan had
gotten more popular instead of some combination of
[Java|Tcl|Perl|C++].  (I'd tend to think that Ada offers nice things
over those options, too, but that's another story.)

Do you mean a datatype called symbol? Sure.

But then, there are languages that have an integer data type that we don't
think of as having "integers".

For sake of argument, I'll here claim Dylan doesn't have symbols.  Not that
there isn't another possible point of view, and I fully expect someone to
raise it in response--but just to say I'm comfortable having that exchange.
Here's my claim:

To me, symbols have (at least) two parts:

 - they are interned, canonical strings
      [dylan has this, and so does java--java calls them
       canonical strings, I think--it's been a while since i checked]

 - they are not not mired in syntax.

I'll be further provocative by alleging that, to me, let's ay "in my heart",
X is a symbol if and only if X can be used unadorned as a name in data
and code.

(So, in my mind, symbols like |THIS IS A SYMBOL| are allowed in the datatype
symbol but emotionally, in my heart, they are "cheating" and are not what
symbol processing is really about... they're just an accomodation to
practicality.  I'm not saying symbol operations won't work on them, I'm
just saying that they don't represent the spirit of what symbol processing
was about--more like an exception that was patchily added afterward to
accomodate cases never really intended origionally.)

Dylan uses the notation #"foo" for what lisp would call foo.
To me, this is just not a symbol.  I strongly believe that had this been
the notation of symbols, important programs like Eliza and Macsyma would
have risked never having been written (or would have looked very different).

Processors that are supposed to take
 '(I AM NOT FEELING WELL TODAY)
as an argument but have to take
 #{#"I", #"AM", #"NOT", #"FEELING", #"WELL", #"TODAY"}
are just not, to me offering the same capability.

Processors that should take
 '(+ x (- y 3))
but instead take
 #{#"+", #"x", #{#"-", "y", 3}}
are again missing the point.

That small degree of willful failure to do user engineering means that
interactive experimentation is virtually ruled out.  IMO, no one is going
to find it "fun" to simply sit around and try things.  And so a great deal
of accidental discovery will be lost... or, so I claim.

  let (#rest words) = split("\\s", line)
  map(curry(as, <symbol>), words);

Voila, an improvement over using s-expressions as the input of Eliza.

Andreas

You have turned them in to string processing applications.

To be honest, I don't think anyone who starts with split("\\s" line)
is going to target symbol as their final datatype.  I bet they'll
write it using strings.

Of course, clueless users who don't know the value of symbols should
be slapped with the manual.

Andreas

I'm talking here about how important it is to have s-expressions in the
language because of the invention it promotes by accidentally using such a
simple device for routine play in your program, and you're saying back to me
"you can have the sophisticated understanding that this simple device is
available".  Sure, *I* can because I know the importance of using it. But
the people I'm talking about are people who don't know this importance and
won't be using s-expressions.

Separating M (or D) -expressions from S-expressions is not a recipe for
creating the "data is program / program is data" thing.  It's a way of
saying "data is data / program is program", which isn't the same thing at
all.

Does that make Dylan a non-Lisp? I dunno.  I'm not sure what's
criterial to Lisp.  Maybe I think the desire to BE a Lisp is criterial
to Lisp, and maybe I think Dylan doesn't have that.  I've seen no
active desire to be called a Lisp and some active desire to not be
called a Lisp by certain key Dylan folks over the years, and that
seems to me to be more interesting...  But at least at the level of
programming, having separate tools (parsers, printers, etc.) for
managing programs and managing data is relatively unlispy...

  Your suspicions are wrong.  Someone who comes asking for a Lisp compiler does
  /not/ want Scheme or Dylan.  They know how to ask for Scheme and Dylan if
  they want it.  Really.  Trust me.  Nobody /ever/ comes to comp.lang.lisp to
  field their inquiries into Dylan and accidentally happen to call it "Lisp".
  That is one real test of whether something is or is not a Lisp.  However,
  your disgracefully disrespectful attitude that you are right about this and
  everybody else, especially seasoned users of the language in the community
  you disrespect, is really annoying.  You think you know better than every
  single living Lisp programmer.  What gall!  What immeasurable arrogance!
  What utter cluelessness!

| No, Common Lisp is an instance of Lisp, which is a subclass of "dynamically
| typed language".

  Look, we have multiple inheritance here, and no one superclass is /defining/.

| If you look at the history of Dylan, you will see that the roots of it are in
| the Lisp community.

  Which you *abandoned* because you no longer wanted to support Lisp!

  What we in the Lisp community, if I may be so bold as to speak for the
  numerous people who take exception to your classification, and who and whose
  learned opinions you dismiss out of hand and purposefully ignore, do not
  consider Dylan a Lisp.  Deal with it.  Stop annoying people so much.  Listen
  to what people tell you.  Figure it out.  Sheesh, dude, this is /not/ hard.

| The very same people who brougt you the Common Lisp standard, CLIM, CMU CL,
| and a lot of other things worked on Dylan, and it was supposed to be the next
| big thing after Common Lisp, and an improvement over it.

  But you chucked the syntax, you frigging dimwit!  You /left/ the Lisp community
  with that choice.  You are not competing with Common Lisp, you are not at all
  "improving" on Common Lisp by taking away something that many people really,
  really value in Common Lisp.  That you think so and are apparently unable to
  back down from your religious belief is so amazingly annoying that I wish I
  could slap your stupid face and hope you snap out of it.  Sadly, you have
  demonstrated such amazing cluelessness and the arrogance to go with it that
  the impression here, if I may again interpret the /massive/ rejection of your
  claims to be a consensus, is that Dylan is the language of choice for people
  who are /utterly/ unable to deal with counter-information.  You and that
  other bozo from the Dylan camp keep arguing /here/ in order to /convince/ people
  who have no interest in your language whatsoever that it is somehow a Lisp,
  when /one look/ at Dylan will reveal that it /lifted/ a number of concepts from
  real Lisps, /spit/ on their syntax tradition and those who much prefer it over
  yeat another Algol-Pascal-whatever derivate, and then you people have the
  /chutzpah/ to tell people you disrespect and ridicule that your stolen lemon of
  a language is an "improvement" over Common Lisp!  Sure, you think so, and you
  can think so as much as you like in comp.lang.dylan.advocacy, but if you have
  to go running like a missionary to convert the heathens to your belief, you
  tell everybody that Dylan is the kind of language that is used by people who
  have no working brain, it is for /believers/ and /non-thinkers/ who accept your
  bogus claims at face value.  "Yeah, it really is a Lisp because Andreas Borg
  says so", but resistance is not futile.  We /shall not/ be assimilated.

  Appealing to authority by imputing similarity between different products just
  because the same people worked on them is such a ridiculous denigration of
  their intelligence and their work ethics that I am almost speechless.  How
  /dare/ you assume that people choose Common Lisp because persons X, Y, and Z
  worked on it?  How /dare/ you imply that persons X, Y, and Z are unable to
  accomplish more than one useful thing in their entire life, so if they do two
  things, they must somehow be the same?  How /dare/ you implicitly indicate
  that persons X, Y, and Z are unable to change direction in their life at will?

  Jesus, idiots like you make me /angry/!  And now that I had taken nearly a
  month off the newsgroup because I found that more than anything else, I wrote
  articles to clarify my own thinking instead of wanting to help the morons who
  are never satisfied, anyway.  I wrote and filed, but did not post, many a
  response, and it was so liberating to know that I would be relieved of the
  idiotic, hostile responses.  Over the past week or so, I have posted what
  I believe to be more insightful than blabbering, but cretin like yourself
  really do make me realize that newsgroups are mostly for trolls and idiots.
  Look at how many responses you have received!  And only because you are so
  blindingly stubborn and /wrong/.  Be right about something, and nobody says a
  word, write something insightful that required much thought on your end, and
  you are guaranteed silence (but occasionally some uplifting mail).  But say
  something utterly boneheaded that pisses people off simply because it is so
  stupid that people who make such rabid mistakes must be corrected, and you
  get to control the whole goddamn agenda in the newsgroup for a while.

  But people like you, Andreas Bogk, are truly incorrigible.  You are a waste
  of time for anyone to respond to.  You are unable to deal with contradictory
  information or opinions.  Your purpose here is to annoy and /pester/ people
  with your retarded beliefs that you are certainly /not/ prepared to discard in
  the face of overwhelming rejection.

| That's why I'm talking in terms of specific features.  This does produce
| something like a distance metric, and I can say things like "Dylan is much
| more like Common Lisp than like Java".

  I like to see distance metrics graphically.

    |-------------------------------------------------------------------------- |
    idiot         ^                                       common lisp programmer
                 you

  The fact is, your Dylan programs look like one of those rejected languages
  that did /not/ become that celebrated commercial success called "Ada".

  Grow a damn clue!  Dylan proselytizing and marketing is /not/ welcome here,
  yet people flock to tell you this because you are so helplessly unintelligent
  that you stick to your beliefs no matter what people tell you.  Why?  Why do
  we all (me included) get so upset about such /fucking morons/ that we just
  /have/ to post some rebuttal?  These people are positively /brimming/ with
  bovine excretions, yet neither putridity nor the methane deters people from
  trying to make it into something else.  Get this: */they will never get it/*.

  USENET has been fertilized so heavily that it is no longer fecund.  And all
  that that methane does on USENET is cause spontaneous combustion.

  See on you all August 15, provided you can stop responding to the nutjobs.

--
Erik Naggum, Oslo, Norway

Thaddeus L Olczyk <olc...@interaccess.com> writes:

Cheers

So a couple of us from Franz went to Apple to talk to the developers
there, and we asked a bunch of questions.  The major points I remembered
were:

 1. Dylan was at the time a long way from being viable as a production
language, even though it had many bells and whistles and close to a
Developer Release.  If we had taken Dylan on, we would have had a lot
of work to do to roll it out, even after DR1.

 2. The original Dylan specs had allowed for both C-like and paren
style syntax, but the developers on all Dylan projects were moving to
get _away_ from paren-based syntax, and by the time DR1 had come out
that bridge had already been burned by Apple.  I'm not sure what the
state of the other Dylan development groups had done by that time, but
in order for us to take Dylan on, we would have had to make a decision
to buck the stated desire of the Dylan community to lose the Lisp-like
syntax.

 3. Macros were not yet completely developed, and it was told to us
that they would likely be text-based pattern-matching and substitution.
We would have had to buck that trend as well.

We went away from there deciding that Dylan was not a good match for a
Lisp company to take on.  The distance from where we would have wanted
to take it was not the problem, but the direction in which it was
headed, instead.

I view Dylan as lisp-like, but certainly not as a Lisp.