From: David Steuber "The Interloper
Subject: I don't understand Lisp
Date: 
Message-ID: <35fb182d.86050524@news.newsguy.com>
Perhaps all languages have their zealots.  Lisp certainly has a few.
I am trying to figure out why Lisp has a cult like following without
making it into the "mainstream" as a computer language.  That is, Lisp
doesn't seem, from my parochial point of view, to have the market
penetration of C/C++, VB (yuck!), or even the controversial Java
language.

I am hoping that some of the Lisp devotees here can explain to me why
Lisp is such a great language and why the rest of the world hasn't
caught on to it yet, after thirty or forty years of existence.

Why would an outsider such as my self be interested?  I am not a
troll.  I am seriously considering using Lisp.  I have Paul Graham's
"ANSI Common Lisp" book, and one from Guy Steele.  As an exercise, I
am planning to implement a Lisp interpreter.  If I can wrap my brain
around Lisp and find out what is so great about it, I would like to
embed it in another application as a control and extension language,
not unlike Emacs's usage.  My project, however, is much smaller than
Emacs.  I also don't expect to be able to implement the entire ANSI
standard, let alone CLOS.  That is unless the interpreter doesn't have
to provide to much primitive functionality and the rest can be
implemented in Lisp itself.

For the record, I am from a C++ background.  C++ is the language I am
most comfortable using, and I can think in it reasonably well.  Lisp
is quite different.  I understand the syntax, but that doesn't mean I
can write poetry or appreciate it.

With luck, I will grock this thing soon.  It will give me a new way to
think which is always a good thing.

--
David Steuber
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

If you can't trust an anonymous person on the Internet, who can you trust?

From: Sunil Mishra
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <efyww7cvhw6.fsf@aidan.cc.gatech.edu>
········@david-steuber.com (David Steuber "The Interloper") writes:

> Perhaps all languages have their zealots.  Lisp certainly has a few.
> I am trying to figure out why Lisp has a cult like following without
> making it into the "mainstream" as a computer language.  That is, Lisp
> doesn't seem, from my parochial point of view, to have the market
> penetration of C/C++, VB (yuck!), or even the controversial Java
> language.

There are lots of people that can give a good answer to this, and in fact
have. Try searching through DejaNews. You will probably find extensive
discussions of lisp vs the rest of the world.

There is also a great essay you ought to read through to understand the
nature of lisp (and some history) a little better.

http://cbl.leeds.ac.uk/nikos/tex2html/examples/good-bad-win/good-bad-win.html

Another good site to obtain materials for lisp is

http://www.elwoodcorp.com/alu/

Finally, Paradigms of AI Programming contains an example of a partial
scheme interpreter in lisp. It might prove to be a useful starting
point. You can find out more about PAIP from

http://www.norvig.com/

> I am hoping that some of the Lisp devotees here can explain to me why
> Lisp is such a great language and why the rest of the world hasn't
> caught on to it yet, after thirty or forty years of existence.

It did, and it let go. Read the essay to get a sense for why. I forgot to
mention Richard Gabriel's book, something like Patters of Software Design,
which has a lot more about his personal experience with Lucid, one of the
first common lisp vendors. It tells a whole lot about what happened to
lisp.

> Why would an outsider such as my self be interested?  I am not a
> troll.  I am seriously considering using Lisp.  I have Paul Graham's
> "ANSI Common Lisp" book, and one from Guy Steele.  As an exercise, I
> am planning to implement a Lisp interpreter.  If I can wrap my brain
> around Lisp and find out what is so great about it, I would like to
> embed it in another application as a control and extension language,
> not unlike Emacs's usage.  My project, however, is much smaller than
> Emacs.  I also don't expect to be able to implement the entire ANSI
> standard, let alone CLOS.  That is unless the interpreter doesn't have
> to provide to much primitive functionality and the rest can be
> implemented in Lisp itself.
> 
> For the record, I am from a C++ background.  C++ is the language I am
> most comfortable using, and I can think in it reasonably well.  Lisp
> is quite different.  I understand the syntax, but that doesn't mean I
> can write poetry or appreciate it.
> 
> With luck, I will grock this thing soon.  It will give me a new way to
> think which is always a good thing.

It most certainly is a new way to think. Not that I would compare *any*
experienced programmers with the undergraduates I have to TA for, but the
general tendency is to think in C/C++ and translate to lisp, once you give
them the chance to. Lisp is indeed significantly different, and I doubt you
would gain a real appreciation for it unless you have worked with it for a
somewhat extended period.

Good luck!

Sunil
From: David B. Lamkins
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <dlamkins-0909982005080001@192.168.0.1>
In article <···············@aidan.cc.gatech.edu>, Sunil Mishra
<·······@aidan.cc.gatech.edu> wrote:

>········@david-steuber.com (David Steuber "The Interloper") writes:

[snip]

>> I am hoping that some of the Lisp devotees here can explain to me why
>> Lisp is such a great language and why the rest of the world hasn't
>> caught on to it yet, after thirty or forty years of existence.
>
>It did, and it let go. Read the essay to get a sense for why. I forgot to
>mention Richard Gabriel's book, something like Patters of Software Design,
>which has a lot more about his personal experience with Lucid, one of the
>first common lisp vendors. It tells a whole lot about what happened to
>lisp.

"Patterns of Software", Richard Gabriel, Oxford University Press, 1996,
ISBN 0-19-510269-X

[snip]

-- 
David B. Lamkins <http://www.teleport.com/~dlamkins/>
From: Kent M Pitman
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <sfwzpc8ljnp.fsf@world.std.com>
········@david-steuber.com (David Steuber "The Interloper") writes:

> I am trying to figure out why Lisp has a cult like following without
> making it into the "mainstream" as a computer language.  That is, Lisp
> doesn't seem, from my parochial point of view, to have the market
> penetration of C/C++, VB (yuck!), or even the controversial Java
> language.

For the purposes of this message, I'll accept your branding of Lisp
as cult even though I don't agree 100%.  While a cult movie might
serve only a certain audience, Lisp is Turing powerful and highly
expressive and would suffice fine for any programmer unable to find
one of those other languages.  You might similarly ask what's so
great about the Macintosh if PC's are beating them everywhere, but
the answer isn't found in a technical analysis of the PC's design,
for the most part.  VHS beat out Beta Max in video tape format, too,
in spite of many saying Beta was a superior technology.  What wins
the amrket wars in the marketplace is not always technical superiority.
But ok, "cult" you say and let's go with that.

Cult is about serving a need that is not served by the mainstream.
Exactly because of the prevalance of C/C++, etc. people are driven to
Lisp all the more strongly.  Not all, but those who are cling
strongly.  And not to the language, I think, but to the ideas.  The
greater Lisp community sometimes uses other languages, but I think
never really forgets its roots.  Lisp was born of the AI research
culture supporting specific features it needed particularly.  Slowly
some of its features are adopted into other languages, and that's good.
But I think if you want one central reason Lisp is still not "killed"
yet it's that the other languages still don't have it right and,
sometimes "like it or not", people come back to Lisp to take refuge
in a certain kind of sanity.  Cult sanity, if you insist.  But
sanity nevertheless.

Features like dynamic redefinition--the obvious and yet startlingly
uncopied idea that static languages seem to hold at bay--which is that
it's useful in mid-application to be able to change a data structure
definition and still run the same image, the same code, without
restarting.  Features like GC which make painstaking headway into
other languages but are still clumsy by comparison.  Features like
multiple inheritance which aren't absolutely needed for simple
applications and so tend to cause people to simplistically say they
can be done without, but which are a safe haven for people who are
building applications big and complex enough that they can't be easily
shoehorned into a single-inheritance system.  Features like
unwind-protect which in spite of their incredible simplicity and
elegance are missing in other languages.  Features like making
integers be really integers (arbitrary precision) if they want them.
Features like optional, not required, type declarations so that
programs can be production fast if they need to be, but in prototyping
you don't have to waste time declaring things that may never be used
in production.  Features like a program-callable compiler so that code
can be not only generated on the fly but compiled and used in the same
environment without loss of efficiency.  On and on.  Lisp is full of
features still not adopted by other languages.

And then some fortuitous accidents of chance that are often, I think,
misunderstood, but are no less powerful for the doing: The famous
"program is data" thing is an example.  Many languages can represent
themselves.  BASIC could represent itself with an array of strings.
But what Lisp does that is critically important in power is to choose
a representation--maybe not even the best representation--but one that
is standard.  The willingness to decide not to fight over program
representation and simply to define it simply and understandably means
a whole army of automatic programming and program manipulation tools
(not the least of which is Lisp's rich macro packages and its long
tradition of research in compiler design) have grown up simply because
everyone understands and shares a common interchange format for
programs in a structured form that requires no special and parsing and
no weird ad-hoc quotation rules.  It's not enough for another language
to tell you you CAN define a program representation; before they match
Lisp, they must do it and do it once and for all.  Most other
languages, trying to be "small", insist on optional add-on libraries
and then have endless disputes over whose add-on library is the one
and only official standard one.  This is pain for programmers because
they have to know whose C they are using.  C claims to be portable
because it is ubiquitous, but Lisp (by which I mean Common Lisp
particularly) was designed to be and I think truly is way more
portable than C will ever dream of being.  In the modern world where
the PC dominates, one may think portable is less and less important,
but portable is REALLY about not making dependencies on the environment,
or about capturing those dependencies in an abstract way.  So CL code
speaks to the future not just to other machines.  If I have an integer
of a certain range, I can declare it (INTEGER 37 416) meaning 
"integer in the range 37-416, inclusive".  How that is optimized
may depend on the machine.  But I do not have to say "the size of
a machine word" and just hope to win.  That's only one tiny example.
Pathnames, too, are structured objects that have been designed so
that the same portable conception can work on Unix, PC, MAC, VMS,
Linux, CDC 7600, Lisp Machines, ISO 9000 file system, etc.  

> I am hoping that some of the Lisp devotees here can explain to me why
> Lisp is such a great language and why the rest of the world hasn't
> caught on to it yet, after thirty or forty years of existence.

Lisp has on and off been more popular than it is now.  I don't see
popularity as its only measure of success.  Some amount of market is
needed to keep Lisp alive and growing, and we're always happy for more
than the baseline minimum but the practical fact is that just about
any language can suffice for the low-end, and what Lisp excels at is
the harder problems.  As you yourself note, VB is very popular but no
one speaks kindly of it. I wouldn't trade Lisp's place for VB's--I'm
proud of where Lisp is.  Lisp tends to attract people with problems
that they've given up ever solving in other languages.  At Symbolics,
where I used to work before I came to Harlequin, there was a sign on
the wall (half in jest, but there was some truth to it) saying "At
Symbolics we make hard problems easy -- and vice versa".  Maybe that's
the trade, I don't know.  I think it's a fundamental fact about the
universe that a single solution can't be good for every possible
situation.  But that Lisp is the thing that does the hard problems
is enough.  Consider that there are probably more ten dollar pocket 
cameras in the world than  fancy theatrical movie cameras, but it's
not a failure for the theatrical movie guys that they make what 
they do.

One reason Lisp solves the hard problems is that initial workout
the AI community gave it.  It required a lot of memory and disk
in those days and it was expensive compared to other alternatives.
So people turned to other things.  But memory and disk get
cheaper, other alternatives get bigger, and meanwhile Lisp has held
the line on size so that it is becoming respectable again just by
waiting for others to catch up in "apparent bloat"--only Lisp still
has power packed into that size, and many other tools have grown
without offering all the power that Lisp has, so don't be surprised
if Lisp has more life in it in the future.  I think the possibilities
are really just opening up for Lisp, frankly.  It's a bit of a chicken
and egg problem because it needs market belief to do that, but
I think it can and should be done.

> Why would an outsider such as my self be interested?  I am not a
> troll.  I am seriously considering using Lisp.  I have Paul Graham's
> "ANSI Common Lisp" book, and one from Guy Steele.  As an exercise, I
> am planning to implement a Lisp interpreter.

Sounds like a good start.  Might wanna download a copy of the
Common Lisp HyperSpec(TM).  See
 http://www.harlequin.com/education/books/HyperSpec/
for (free) download info and
 http://www.harlequin.com/education/books/HyperSpec/FrontMatter/
to browse it online at Harlequin.

See also my articles 
 http://world.std.com/~pitman/PS/Hindsight.html
where I discuss the benefits of Lisp in rapid prototyping and
 http://world.std.com/~pitman/PS/Lambda.html
where I discuss the choice of language as a political rather than
technical issue.  (The remarks about status of certain standards are 
now somewhat dated, but the general thrust of the piece is still 
sound, I think.)

> If I can wrap my brain
> around Lisp and find out what is so great about it, I would like to
> embed it in another application as a control and extension language,
> not unlike Emacs's usage.  My project, however, is much smaller than
> Emacs.  I also don't expect to be able to implement the entire ANSI
> standard, let alone CLOS.  That is unless the interpreter doesn't have
> to provide to much primitive functionality and the rest can be
> implemented in Lisp itself.

Nothing wrong with subsets.  And yes, by all accounts you're best 
using as small a kernel as you can and writing the rest in Lisp.

> For the record, I am from a C++ background.  C++ is the language I am
> most comfortable using, and I can think in it reasonably well.  Lisp
> is quite different.  I understand the syntax, but that doesn't mean I
> can write poetry or appreciate it.

Just being willing to try is a good start.  If you have trouble
figuring out how to think about something naturally, this is a good
forum to discuss that.  I think you'll find people quite helpful,
and we're always interested to hear honest accounts of people's 
experiences.
 
> With luck, I will grock this thing soon.  It will give me a new way to
> think which is always a good thing.

I saw a talk by Gerry Susman in which he suggested that indeed the most key
contribution of computer science to the 20th century is not computation but
the terminology for describing process.  That is, the ability to talk about
algorithms.  That it stretches the mind, he said, and gives us ways to talk
about how that has happened rather than just repeating things over and over
until other people can parrot our actions is truly important.  So I agree
with your goal and wish you luck.
 --Kent

p.s. My recollection from the 1970's when the word seemed popular was that
     "grok" has no "c" in it.  I could be wrong, and went to check, but
     (alas) it's not in my dictionary under either spelling.  Anyone
     got a pointer to an authority on this?  It IS just the right
     word, and it's a shame it's not better accepted in the language.
From: forcer
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <slrn6vept7.e3m.forcer@forcix.roof.lan>
On Thu, 10 Sep 1998 03:40:42 GMT, Kent M Pitman
	<······@world.std.com> wrote:
>p.s. My recollection from the 1970's when the word seemed popular was that
>     "grok" has no "c" in it.  I could be wrong, and went to check, but
>     (alas) it's not in my dictionary under either spelling.  Anyone
>     got a pointer to an authority on this?  It IS just the right
>     word, and it's a shame it's not better accepted in the language.

:grok: /grok/, var. /grohk/ /vt./  [from the novel
   "Stranger in a Strange Land", by Robert A. Heinlein, where it
   is a Martian word meaning literally `to drink' and metaphorically
   `to be one with'] The emphatic form is `grok in
   fullness'. 1. To understand, usually in a global sense.  Connotes
   intimate and exhaustive knowledge.  Contrast {zen}, which is
   similar supernal understanding experienced as a single brief flash.
   See also {glark}.  2. Used of programs, may connote merely
   sufficient understanding.  "Almost all C compilers grok the
   `void' type these days."
[JARGON 4.0.0]
Hope i could help :)
	-forcer

-- 
;; Build a system that even a fool can use and only a fool will use it.
;; email: ······@mindless.com      -><- www: http://webserver.de/forcer/
;; IRC: ······@#StarWars (IRCnet)  -><- PGP/GPG: available on my website
From: Kenneth P. Turvey
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <slrn6vf6tu.2cr.kturvey@www.sprocketshop.com>
On Thu, 10 Sep 1998 03:40:42 GMT, Kent M Pitman <······@world.std.com> wrote:
>········@david-steuber.com (David Steuber "The Interloper") writes:

>> If I can wrap my brain
>> around Lisp and find out what is so great about it, I would like to
>> embed it in another application as a control and extension language,
>> not unlike Emacs's usage.  My project, however, is much smaller than
>> Emacs.  I also don't expect to be able to implement the entire ANSI
>> standard, let alone CLOS.  That is unless the interpreter doesn't have
>> to provide to much primitive functionality and the rest can be
>> implemented in Lisp itself.
>
>Nothing wrong with subsets.  And yes, by all accounts you're best 
>using as small a kernel as you can and writing the rest in Lisp.
>

You may also wish to look at Guile, the GNU extension language.  It is
an implementation of Scheme built for the kind of problem you are
discussing.  

Common Lisp would be nice, but it may not be worth the overhead in a
small application.  

-- 
Kenneth P. Turvey <·······@pug1.SprocketShop.com> 

An atheist is a man with no invisible means of support.
	-- John Buchan
From: Dimitrios Souflis
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <35F93F29.FA65383B@altera.gr>
Kenneth P. Turvey wrote:
> 
> You may also wish to look at Guile, the GNU extension language.  It is
> an implementation of Scheme built for the kind of problem you are
> discussing.
> 
> Common Lisp would be nice, but it may not be worth the overhead in a
> small application.

If you're willing to sacrifice raw speed for size (typical for some
scripting uses - mine at least) you might also want to look at
TinyScheme
at my homepage below. It's a single C module around 4000 kloc, 
but near-R5RS Scheme nevertheless.

-- 
Dimitrios Souflis                ········@altera.gr
Altera Ltd.                      http://www.altera.gr/dsouflis

*** Reality is what refuses to disappear when you stop believing
*** in it (VALIS, Philip K. Dick)
From: David Steuber "The Interloper
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <35ffee9a.337551283@news.newsguy.com>
On Fri, 11 Sep 1998 18:18:01 +0300, Dimitrios Souflis
<········@altera.gr> claimed or asked:

% If you're willing to sacrifice raw speed for size (typical for some
% scripting uses - mine at least) you might also want to look at
% TinyScheme
% at my homepage below. It's a single C module around 4000 kloc, 
% but near-R5RS Scheme nevertheless.

Thanks.  I'll take a look.  I am really more interested in Common Lisp
though.  Still, the scanning should be the same.  As far as I know, no
one has been dumb enough to do the interpreter in Java like I want to.

--
David Steuber
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

When the long night comes, return to the end of the beginning.
--- Kosh (???? - 2261 AD) Babylon-5
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3114679241611162@naggum.no>
* ········@david-steuber.com (David Steuber "The Interloper")
| I am really more interested in Common Lisp though.  Still, the scanning
| should be the same.  As far as I know, no one has been dumb enough to do
| the interpreter in Java like I want to.

  I take this to mean that you think the lexical analysis of Scheme and
  Common Lisp are similar or the same.  this is not so.  Common Lisp has a
  programmable reader that is used to read Lisp forms, while Scheme uses a
  very static syntax that is even outside of Scheme itself.  (i.e., Common
  Lisp uses READ and uses the value of *READTABLE* even for code, while
  Scheme cannot use READ because the syntax is specified as sequences of
  characters, not as forms.)

  I also don't think you really want an interpreter for Common Lisp.  it
  seems like less work to compile Common Lisp to the JVM elsewhere, and
  then compile enough Common Lisp code to sustain a development enviroment
  on the JVM itself.  I haven't seen any reports from the several people
  who have expressed interest in such a stunt over the past couple years,
  but you will certainly be a hero if you do it.

#:Erik
-- 
  http://www.naggum.no/spam.html is about my spam protection scheme and how
  to guarantee that you reach me.  in brief: if you reply to a news article
  of mine, be sure to include an In-Reply-To or References header with the
  message-ID of that message in it.  otherwise, you need to read that page.
From: Rob Warnock
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <6tgji9$26hk7@fido.engr.sgi.com>
Erik Naggum  <······@naggum.no> wrote:
+---------------
|   I take this to mean that you think the lexical analysis of Scheme and
|   Common Lisp are similar or the same.  this is not so.  Common Lisp has a
|   programmable reader that is used to read Lisp forms, while Scheme uses a
|   very static syntax that is even outside of Scheme itself.  (i.e., Common
|   Lisp uses READ and uses the value of *READTABLE* even for code, while
|   Scheme cannot use READ because the syntax is specified as sequences of
|   characters, not as forms.)
+---------------

Erik, I assume you're wearing some sort of "standards purist" hat while
saying this...?  ;-}  Yes, of course, in principle you are absolutely
correct, but in practice I don't know of a single Scheme implementation
that does *NOT* use the same lexer for the user-visible READ procedure and
the reader buried in the LOAD procedure and the top-level REPL. In fact,
now that EVAL is in R5RS, one could even make Scheme's LOAD an optional
procedure, which could be coded by the user as:

	(define (load fname)
	  (with-input-from-file fname
	    (lambda ()
	      (do ((exp (read) (read)))
		  ((eof-object? exp))		; note: returns unspec. value
		(eval exp (interaction-environment))))))

And, except for the lack of error-handling, this:

	(let loop ()
	  (display "my-repl> ")
	  (write (eval (read) (interaction-environment)))
	  (newline)
	  (loop))

is a perfectly functional REPL in every Scheme I've ever used. [O.k.,
so you have to leave off the 2nd arg to "eval" in the older ones...]

In fact, I can't see any way to *avoid* this, since R5RS explictly says
that READ "...is a parser for the nonterminal <datum>" [6.6.2], and
also, "Note that any string that parses as an <expression> also parses
as a <datum>." [7.1.2]  So it should be perfectly correct to use READ
for Scheme expressions (well-formed ones, that is).

On the other hand... There is no defined way in Scheme to extend or modify
the syntax accepted by READ. With only one or two ad-hoc exceptions (dare I
say "hacks"?), I haven't seen anything in the Scheme world that comes close
to the Common Lisp notion of *READTABLE*, and certainly nothing that works
the same way in more than one implementation. And that's quite unfortunate,
given the wide differences in lexical "extensions" supported by various
Schemes. Some allow |CaseSensitiveSymbols With Spaces InVerticalBars| and
some don't. Some allow #|multi-line comments|# and some don't. A very few
support "#."; most don't. Were there a widely-accepted readtable-equivalent,
one could gloss over these differences. But as it is, if one is trying to
write Scheme code which will be even barely portable, one must simply avoid
*everything* that's not explcitly mentioned in R5RS [or even R4RS]. (*sigh*)

Hmmmm... But on the third hand [as Niven & Pournelle say], in R5RS "READ"
is listed as a "library" procedure, which means that while conforming
implementations must provide one [it's not an "optional" library procedure]
it need not be primitive -- it can be implemented in terms of other, more
primitive features. Just start with "READ-CHAR", and parse it yourself.
(I've done that before, actually, as an exercise.) There are enough required
type-conversion routines [I'm thinking specifically of "string->symbol"
and "char->integer"] to allow building any Scheme object up out of pieces.
Maybe *that's* supposed to be "the Scheme way" to get reader extensibility...?


-Rob

-----
Rob Warnock, 8L-855		····@sgi.com
Applied Networking		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
2011 N. Shoreline Blvd.		FAX: 650-964-0811
Mountain View, CA  94043	PP-ASEL-IA
From: Jeffrey Mark Siskind
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <yq790joxbis.fsf@qobi.nj.nec.com>
  but in practice I don't know of a single Scheme implementation
> that does *NOT* use the same lexer for the user-visible READ procedure and
> the reader buried in the LOAD procedure and the top-level REPL.

Stalin uses different code to implement READ and to read in the source program.
When the source program is read in, the reader keeps track of source file
name, line, and character positions to include in error messages. READ does
not do this. In fact, the source program reader doesn't produce a typical
S expression. Rather it produces a structure of type S-EXPRESSION which
includes the encapsulated file, line, and character position.

    Jeff (http://www.neci.nj.nec.com/homepages/qobi)
From: Rob Warnock
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <6tijs5$2n0of@fido.engr.sgi.com>
Jeffrey Mark Siskind  <····@research.nj.nec.com> wrote:
+---------------
| > but in practice I don't know of a single Scheme implementation
| > that does *NOT* use the same lexer for the user-visible READ procedure and
| > the reader buried in the LOAD procedure and the top-level REPL.
| 
| Stalin uses different code to implement READ and to read in the sourc
| program. When the source program is read in, the reader keeps track of
| source file name, line, and character positions to include in error messages.
+---------------

Yes, well, o.k., I misspoke (or perhaps wasn't specific enough).  Yes, I
know of other Scheme readers (well, at least one) which annotate the source
similarly (e.g., the one in the Rice PLT group's "MrSpidey"). But what I was
referring to is that the user-visible READ *does* accept all legal source
programs, so that Erik's distinction between "prgrams defined by lexical
rules" and "programs defined by S-exprs" is, for all practical purposes, moot.

Now it is certainly the case that one could make a *mistake* in defining a
Lisp (or Scheme) by its lexical representation in such a way that there was
*not* a guarantee of equivalency, but I also suspect that most participants
in this group would consider such a definition badly broken (if only because
of the negative implications on macros).

+---------------
| READ does not do this. In fact, the source program reader doesn't produce
| a typical S expression. Rather it produces a structure of type S-EXPRESSION
| which includes the encapsulated file, line, and character position.
+---------------

Call me naive, but I don't see how this affects the issue... unless there
are files which Stalin [or some other Lisp or Scheme] will accept as programs
which its READ *won't* accept when a user program tries to read them (e.g.,
say, allowing allows "#+<sym>" or "#.<exp>" in "programs" but not in files
parsed with READ). And if there are, I'd call it broken.


-Rob

[p.s. Apologies in advance: Replies to this via email may get a
"vacation" bounce messages while I'm on sabbatical from SGI...]

-----
Rob Warnock, 8L-855		····@sgi.com
Applied Networking		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
2011 N. Shoreline Blvd.		FAX: 650-964-0811
Mountain View, CA  94043	PP-ASEL-IA
From: Jeff Dalton
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <x2r9xa7gyr.fsf@gairsay.aiai.ed.ac.uk>
Jeffrey Mark Siskind <····@research.nj.nec.com> writes:

>   but in practice I don't know of a single Scheme implementation
> > that does *NOT* use the same lexer for the user-visible READ procedure and
> > the reader buried in the LOAD procedure and the top-level REPL.

> Stalin uses different code to implement READ and to read in the source 
> program.  When the source program is read in, the reader keeps track of
> source file name, line, and character positions to include in error
> messages. READ does not do this. In fact, the source program reader
> doesn't produce a typical S expression. Rather it produces a structure
> of type S-EXPRESSION which includes the encapsulated file, line,
> and character position.

Just FYI, there's a debugging package for GCL that changes the
GCL (GNU Common Lisp, formerly [A]KCL) reader to do something
similar.  And then, when executing, it can show you where you
are in the source in an Emacs window.

-- jeff
From: David Steuber "The Interloper
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <36047e88.439933611@news.newsguy.com>
On 13 Sep 1998 12:40:41 +0000, Erik Naggum <······@naggum.no> claimed
or asked:

% * ········@david-steuber.com (David Steuber "The Interloper")
% | I am really more interested in Common Lisp though.  Still, the scanning
% | should be the same.  As far as I know, no one has been dumb enough to do
% | the interpreter in Java like I want to.
% 
%   I take this to mean that you think the lexical analysis of Scheme and
%   Common Lisp are similar or the same.  this is not so.  Common Lisp has a
%   programmable reader that is used to read Lisp forms, while Scheme uses a
%   very static syntax that is even outside of Scheme itself.  (i.e., Common
%   Lisp uses READ and uses the value of *READTABLE* even for code, while
%   Scheme cannot use READ because the syntax is specified as sequences of
%   characters, not as forms.)

Does this mean that while CL can read CL and eval it, Scheme can not
read Scheme and eval it?  I am running into confusion here.  I was
under the impression that Scheme was a dialect of Lisp.  From what you
say, Scmeme is a whole other language (like JavaScript isn't Java).

%   I also don't think you really want an interpreter for Common Lisp.  it
%   seems like less work to compile Common Lisp to the JVM elsewhere, and
%   then compile enough Common Lisp code to sustain a development enviroment
%   on the JVM itself.  I haven't seen any reports from the several people
%   who have expressed interest in such a stunt over the past couple years,
%   but you will certainly be a hero if you do it.

I still don't know if the Java byte code is flexible enough to allow
CL to be compiled to it.  Also, the JVM only accepts .class files that
have to pass the byte code verifier.  I have certainly thought of
doing that.  It seems the more I learn about Lisp, the more it makes
sense for a Lisp interpreter to be written in Lisp.  In either case,
there  would have to be support classes written in Java for presenting
a runtime for Lisp in the JVM.  It also makes sense to allow the Lisp
to use the other Java APIs via the Class class and reflect package.

This figment of my imagination has been labeled jLisp and is about as
vaporware as you can get.

This brings up another question.  It seems that Lisp is not case
sensitive.  How many people would be upset if a Lisp implementation
came out that was case sensitive?  It sure makes string comparison
easier.  This is just my view from a C++ background.

--
David Steuber
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

When the long night comes, return to the end of the beginning.
--- Kosh (???? - 2261 AD) Babylon-5
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3114753392163854@naggum.no>
* ········@david-steuber.com (David Steuber "The Interloper")
| Does this mean that while CL can read CL and eval it, Scheme can not
| read Scheme and eval it?

  well, no, it means that you need a whole different machinery to read
  Common Lisp than you need to read Scheme.  Scheme was designed in the
  fashion of static grammars, and people frequently implement the reader in
  some other language.  Common Lisp's reader is best written in Common Lisp
  -- it dispatches on characters according to a table, the READTABLE, and
  call out to functions that assemble the various types of objects.  this
  is overkill per excellence for Scheme.  also, Scheme's grammar is defined
  so that (foo 1 2 . ()) is different from (foo 1 2), although the Scheme
  reader cannot detect this difference.  therefore, you will not catch very
  important errors if you use the naive approach to Scheme.  (no, I'm not
  talking in the "standards purist" mode -- Scheme is deliberately designed
  this way, and second-guessing designers is a Bad Thing.  of course, it
  was a gross and very annoying mistake, but the designers should fix that,
  not users.)

| I was under the impression that Scheme was a dialect of Lisp.  From what
| you say, Scmeme is a whole other language (like JavaScript isn't Java).

  Scheme is not a dialect of Common Lisp.  the common heritage, if any, is
  so old and so far removed from today's reality that we're almost talking
  about a missing link.  Scheme owes more to Algol than to Lisp, in my
  view, just like Java owes more to Smalltalk than to C++.  the syntactic
  similarity is irrelevant for meaningful comparisons.  Scheme adherents
  want to tell you Scheme is a dialect of Lisp, but I don't get it.  what
  do _they_ get from confusing people like that?  is it a hope for a piece
  of the market that Common Lisp has created?  some Lispers (well, at least
  one, but he's also a Schemer) will insist very strongly that Common Lisp
  is not the only Lisp to consider.  the only merit of this latter attitude
  is that it makes the Scheme wish come true, but there aren't as many
  Lisps as there used to be 10-15 years ago.  if you spend your time
  learning any other Lisp these days, I'd say you're wasting your time
  unless, of course, the Lisp is an embedded Lisp in some product you need
  to use.  (this includes the sadly deficient Emacs Lisp.)

| This brings up another question.  It seems that Lisp is not case
| sensitive.

  well, I can't speak for "Lisp" in the sense that it is something that
  Scheme is (also) a dialect of, but Common Lisp is certainly case
  sensitive.  symbols in the COMMON-LISP package are all uppercase, but you
  would normally set *PRINT-CASE* to :DOWNCASE and (readtable-case
  *readtable*) to :UPCASE, so you could read and write them in lowercase.
  both |lowercase| and \l\o\w\e\r\c\a\s\e all have lowercase symbol names,
  so it's not like you cannot get it.  also, to maintain backward
  compatibility, you can set the readtable-case to :INVERT, which upcases
  all-lowercase symbol names and downcases all-uppercase symbol names (not
  counting characters escaped with | or \).

| How many people would be upset if a Lisp implementation came out that was
| case sensitive?

  if you make the reader preserve case, many would object to having to
  write symbol names in all uppercase.  if you invert the case of all the
  symbol names, you create a new dialect that doesn't talk to other Common
  Lisp implementations.  amazingly, there is no standard function to do
  case conversion the way the symbol reader and printer does it, so you
  have to call out to the reader or printer to get that behavior.

  case is a personal preference in my view, and Common Lisp has done the
  right thing in allowing each programmer the ability to choose his own
  style.  and it's not like it's a hard thing to change.

| It sure makes string comparison easier.

  what does?  case sensitivity or case insensitivity?  I think the latter
  is strongly preferable when dealing with protocol or user input.  btw,
  STRING= is case sensitive, while STRING-EQUAL is case insensitive.

#:Erik
-- 
  http://www.naggum.no/spam.html is about my spam protection scheme and how
  to guarantee that you reach me.  in brief: if you reply to a news article
  of mine, be sure to include an In-Reply-To or References header with the
  message-ID of that message in it.  otherwise, you need to read that page.
From: Jeff Dalton
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <x24su8esh5.fsf@gairsay.aiai.ed.ac.uk>
Erik Naggum <······@naggum.no> writes:

>   Scheme is not a dialect of Common Lisp.  the common heritage, if any, is
>   so old and so far removed from today's reality that we're almost talking
>   about a missing link.  Scheme owes more to Algol than to Lisp, in my
>   view, just like Java owes more to Smalltalk than to C++.  the syntactic
>   similarity is irrelevant for meaningful comparisons.  Scheme adherents
>   want to tell you Scheme is a dialect of Lisp, but I don't get it. 

Did you mean to say "Scheme is not a dialect of Lisp" rather
than "not a dialect of Common Lisp"?  In any case, it's unlikely
that anyone has ever claimed Scheme was a dialect of Common Lisp.

>   what
>   do _they_ get from confusing people like that?  is it a hope for a piece
>   of the market that Common Lisp has created?  some Lispers (well, at least
>   one, but he's also a Schemer) will insist very strongly that Common Lisp
>   is not the only Lisp to consider.

Well, I'll certainly insist that Common Lisp is not the only Lisp.

Even if Common Lisp were the only important Lisp today, there would
still be Lisp's history.  Lisp, like Madonna, turns 40 this year.
(I'm assuming the anniversary conference is in the right year
rather than properly checking, though).

The phrase "dialect of Lisp" has been used for many years, and
"dialect of Lisp" was taken to be a fairly broad category.
It was natural to speak of Scheme as a dialect of Lisp, and
one even finds sub-varieties of Scheme (such as T) referred
to as "dialects of Lisp".

That's the way people in the Lisp world talked (and they still do,
though not quite so much as before).  What did they mean by "dialect
of Lisp"?  One way to find out is to look at how that phrase was used
and hence at what things were said to be dialects of Lisp.  If we do
that, then it seems pretty clear that, as a matter of usage, Scheme is
a "dialect of Lisp".

But that way to talking about Lisp can mislead, and it even
became somewhat dangerous once standardisation began, because
some people claimed Lisp was just one language (albeit with
dialects) and so should have only one standard.

The US position in the ISO WG was that Lisp was a family of
languages, and I believe that position was correct.  And so
(the argument went) there should not be a standard for "Lisp"
but only for specific Lisp-family languages.  John McCarthy
said he would denounce any standard for "Lisp".

An observation that goes back to at least the 70s is that
so-called dialects of Lisp could be as different from each other
as different languages in (say) the Algol family.  That's one
reason why "dialect of Lisp" can mislead.  Another problem
with "dialect" is that dialects tend not to be taken as
seriously as languages, as in the quote about a language
being a dialect with an army.

So, all things considered, the "dialect of Lisp" way of talking
is probably more trouble than it's worth.

-- jd
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3114949049958479@naggum.no>
* Jeff Dalton <····@gairsay.aiai.ed.ac.uk>
| Did you mean to say "Scheme is not a dialect of Lisp" rather than "not a
| dialect of Common Lisp"?  In any case, it's unlikely that anyone has ever
| claimed Scheme was a dialect of Common Lisp.

  but what _is_ the Lisp that both Scheme and Common Lisp are dialects of?
  if there is no such thing (and I don't think there is, anymore, although
  there might well have been in the distant past), then it is not useful to
  talk about it.  "dialect" is not a mark of independent quality in my view
  and there's a weird interaction between "dialect of Lisp" and the effect
  the mark has on various languages that claim it: one language may try to
  capitalize on the work of another ("we're _all_ dialects"), yet it may be
  used to reduce the value of the work of another at the same time ("we're
  all _merely_ dialects").

* Erik Naggum <····@naggum.no>
| some Lispers (well, at least one, but he's also a Schemer) will insist
| very strongly that Common Lisp is not the only Lisp to consider.

* Jeff Dalton <····@gairsay.aiai.ed.ac.uk>
| Well, I'll certainly insist that Common Lisp is not the only Lisp.

  the two words "to consider" is essential to what I wrote above.  I know
  that you go ballistic every time somebody forgets to mention the myriads
  of other Lisps that you want us to remember, and that's why I attempted
  to be very specific.  I'm annoyed that you appear to continue unimpeded
  with your standard rhetoric.

| So, all things considered, the "dialect of Lisp" way of talking is
| probably more trouble than it's worth.

  I agree, including your argumentation.

#:Erik
-- 
  http://www.naggum.no/spam.html is about my spam protection scheme and how
  to guarantee that you reach me.  in brief: if you reply to a news article
  of mine, be sure to include an In-Reply-To or References header with the
  message-ID of that message in it.  otherwise, you need to read that page.
From: Barry Margolin
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <s5XL1.69$yt.1485482@burlma1-snr1.gtei.net>
In article <················@naggum.no>, Erik Naggum  <····@naggum.no> wrote:
>  but what _is_ the Lisp that both Scheme and Common Lisp are dialects of?

What is the English that both Cockney and American English are dialects of?
If you don't like the "dialect of X" terminology, then perhaps "member of
the X family" would be better, but in my mind they mean the same thing.
There's definitely some quality of Lispiness that Scheme, Common Lisp,
Emacs Lisp, Maclisp, and Dylan all share.  Like the quote someone posted
about the dictionary definition of "dog", there's no hard-and-fast set of
required qualities that a Lisp must satisfy, but if you put enough features
together you get something that most of us would agree is a Lisp.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <bmXL1.3496$K02.2025768@news.teleport.com>
In article <···················@burlma1-snr1.gtei.net>,
	Barry Margolin <······@bbnplanet.com> writes:
> In article <················@naggum.no>, Erik Naggum  <····@naggum.no> wrote:
>>  but what _is_ the Lisp that both Scheme and Common Lisp are dialects of?
> 
> What is the English that both Cockney and American English are dialects of?
> If you don't like the "dialect of X" terminology, then perhaps "member of
> the X family" would be better, but in my mind they mean the same thing.
> There's definitely some quality of Lispiness that Scheme, Common Lisp,
> Emacs Lisp, Maclisp, and Dylan all share.  Like the quote someone posted
> about the dictionary definition of "dog", there's no hard-and-fast set of
> required qualities that a Lisp must satisfy, but if you put enough features
> together you get something that most of us would agree is a Lisp.

  Dylan? I keep seeing people include Dylan in the list of "lisp languages".
Heck, Dylan doesn't even have Lots of Irritating Surpurfelous Parentheses.
What qualifies Dylan as a lisp? If you include it, why not Smalltalk? If you
include Smalltalk, why not C++?

  Mike McDonald
  ·······@mikemac.com
From: Klaus Schilling
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <87lnnj7flm.fsf@ivm.de>
·······@teleport.com (Mike McDonald) writes:

> In article <···················@burlma1-snr1.gtei.net>,
> 	Barry Margolin <······@bbnplanet.com> writes:
> > In article <················@naggum.no>, Erik Naggum  <····@naggum.no> wrote:
> >>  but what _is_ the Lisp that both Scheme and Common Lisp are dialects of?
> > 
> > What is the English that both Cockney and American English are dialects of?
> > If you don't like the "dialect of X" terminology, then perhaps "member of
> > the X family" would be better, but in my mind they mean the same thing.
> > There's definitely some quality of Lispiness that Scheme, Common Lisp,
> > Emacs Lisp, Maclisp, and Dylan all share.  Like the quote someone posted
> > about the dictionary definition of "dog", there's no hard-and-fast set of
> > required qualities that a Lisp must satisfy, but if you put enough features
> > together you get something that most of us would agree is a Lisp.
> 
>   Dylan? I keep seeing people include Dylan in the list of "lisp languages".
> Heck, Dylan doesn't even have Lots of Irritating Surpurfelous Parentheses.
> What qualifies Dylan as a lisp? If you include it, why not Smalltalk? If you
> include Smalltalk, why not C++?

List processing is central in Dylan, but a tedious thing to do in C++. Thus
Dylan belongs to the Lisp clan, unlike C++. The syntax is just a shell.
List processing is the vital core of Lisp, so any language that is critically
based on list manipulation is a Lisp dialect. In C++ one needs templates and 
similar advanced bloat stuff to get somewhere near that point. Let alone
functions as first-class objects, lambda calculus and the like which is all
alien to C++.  


Klaus Schilling
From: Pierre Mai
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <871zpabvne.fsf@dent.isdn.cs.tu-berlin.de>
Klaus Schilling <···············@home.ivm.de> writes:

> > Heck, Dylan doesn't even have Lots of Irritating Surpurfelous Parentheses.
> > What qualifies Dylan as a lisp? If you include it, why not Smalltalk? If you
> > include Smalltalk, why not C++?
> 
> List processing is central in Dylan, but a tedious thing to do in C++. Thus
> Dylan belongs to the Lisp clan, unlike C++. The syntax is just a shell.
> List processing is the vital core of Lisp, so any language that is critically
> based on list manipulation is a Lisp dialect. In C++ one needs templates and 
> similar advanced bloat stuff to get somewhere near that point. Let alone
> functions as first-class objects, lambda calculus and the like which is all
> alien to C++.  

Although I'd put Dylan in the Lisp family of languages[1], I think
including everything that can handle lists efficiently (syntax- and
semantics- wise, that is) into the Lisp language family is going a bit 
to far.  This would mean we'd have to include nearly all modern
functional programming languages (since list-comprehension monads are
arguably very powerful list manipulation constructs).

Although most of them were probably influenced by Lisp (especially Scheme),
I think they have gone a far way from being in the Lisp family, with their
static higher-order typing systems, lazy-evaluation, Monadic I/O systems,
even higher-order module systems.

I think the real family-membership-test of any language family is
looking at source-code produced for real-live programs in them.  If
you find a large overlap in idioms, then either the programmer was
programming "Fortran in Lisp"(TM), or the languages are indeed members 
of the same language family.

Regs, Pierre.

Footnotes: 
[1]  Remember also that Dylan at first _had_ prefix-syntax, and only
later on adopted a second, infix-like syntax, which was then adopted
as the primary, and finally only syntax.  But semantically, Dylan is
very nearly a "streamlined" CLOS, with integration of type/class
hierarchy, and a number of annotation possibilities to simplify the
compilers task of optimizing the whole thing ;)  (WARNING:
Oversimplification Alert!)  But in giving up on prefix-syntax, Dylan
has gone a step too far for me ;)

-- 
Pierre Mai <····@cs.tu-berlin.de>	http://home.pages.de/~trillian/
  "Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)
From: David J Cooper Jr
Subject: Lisp programs are themselves Lists -- this is the Litmus Test
Date: 
Message-ID: <ayyaf3xrjhw.fsf_-_@genworks1.i-have-a-misconfigured-system-so-shoot-me>
To me, more important than internal list processing is the fact that a 
Lisp language syntax is based fundamentally on the list structure. 

The fact that ``any Lisp program is itself a list'' is what makes powerful 
macros like defpart possible, and for me this is the crucial feature which 
makes Lisp the language of choice for doing any kind of real work in this 
world.

-- 
David J Cooper Jr					Genworks International
········@genworks.com					http://www.genworks.com

 ...Embracing an Open Systems Approach to Knowledge-based Engineering...
From: Barry Margolin
Subject: Re: Lisp programs are themselves Lists -- this is the Litmus Test
Date: 
Message-ID: <CHwM1.2$45.6131@burlma1-snr1.gtei.net>
In article <··················@genworks1.i-have-a-misconfigured-system-so-shoot-me>,
David J Cooper Jr  <········@genworks.com> wrote:
>To me, more important than internal list processing is the fact that a 
>Lisp language syntax is based fundamentally on the list structure. 
>
>The fact that ``any Lisp program is itself a list'' is what makes powerful 
>macros like defpart possible, and for me this is the crucial feature which 
>makes Lisp the language of choice for doing any kind of real work in this 
>world.

This would exclude McCarthy's original Lisp from the Lisp family!  The fact
that Lisp programs could be represented as lists was a revelation that came
a few years later, when the EVAL function was written.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Erik Naggum
Subject: Re: Lisp programs are themselves Lists -- this is the Litmus Test
Date: 
Message-ID: <3115135363710957@naggum.no>
* Barry Margolin <······@bbnplanet.com>
| This would exclude McCarthy's original Lisp from the Lisp family!  The
| fact that Lisp programs could be represented as lists was a revelation
| that came a few years later, when the EVAL function was written.

  John McCarthy went on record in comp.emacs when somebody wanted to
  replace Lisp with Perl, saying, and I quote, hopefully sufficiently
  accurately from dejanews, despite their tendency to view articles and
  headers as subject to interpretation and layout control:

    From: John McCarthy <···@Steam.Stanford.EDU>
    Date: 08 Feb 1998 00:00:00 GMT
    Subject: Re: w3 and Re: perl embedded in emacs ("no zero-indexed char arrays")
    Newsgroups: comp.emacs, comp.emacs.xemacs
    Message-ID: <···············@Steam.Stanford.EDU> 

    One of the major characteristics of Lisp is that Lisp programs are
    Lisp data and one can compute with Lisp programs present in the
    machine without parsing.  Scheme does this.  Prolog does it to some
    extent.  The original version of the late Dylan language did this.

    To what extent is this facility used in XEmacs Lisp?  Macros use it,
    and of course compilers do?

    What about Perl?
    -- 
    John McCarthy, Computer Science Department, Stanford, CA 94305
    http://www-formal.stanford.edu/jmc/progress/
    He who refuses to do arithmetic is doomed to talk nonsense.
  
#:Erik
-- 
  ATTENTION, all abducting aliens!  you DON'T need to RETURN them!
From: Barry Margolin
Subject: Re: Lisp programs are themselves Lists -- this is the Litmus Test
Date: 
Message-ID: <U1CM1.20$45.152328@burlma1-snr1.gtei.net>
In article <················@naggum.no>, Erik Naggum  <····@naggum.no> wrote:
>* Barry Margolin <······@bbnplanet.com>
>    What about Perl?

Perl has eval().  Perl is mainly a string-processing language, and Perl
programs passed to eval() are themselves strings.  Many of the things one
needed eval() for in Perl4 have been replaced by explicit Perl5 operators
(e.g. in Perl4 I would implemented nested data structures by storing
variable names and evaling them, but Perl5 has references), but the
capability is still there.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115018739186682@naggum.no>
* Barry Margolin <······@bbnplanet.com>
| What is the English that both Cockney and American English are dialects of?

  assuming this was as rhetorical as it seems, why is "the King's/Queen's
  [British] English" the _obviously_ wrong answer?

| If you don't like the "dialect of X" terminology, then perhaps "member of
| the X family" would be better, but in my mind they mean the same thing.

  it seems to mean the same thing only when X = Lisp.  otherwise, it makes
  no sense at all to claim they are the same.  English is not a dialect of
  Germanic, but it is a member of the Germanic language family.  neither is
  English a dialect of Indo-European.

#:Erik
-- 
  ATTENTION, all abducting aliens!  you DON'T need to RETURN them!
From: Jeff Dalton
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <x2n27y7cw7.fsf@gairsay.aiai.ed.ac.uk>
Erik Naggum <····@naggum.no> writes:

> | If you don't like the "dialect of X" terminology, then perhaps "member of
> | the X family" would be better, but in my mind they mean the same thing.
> 
>   it seems to mean the same thing only when X = Lisp.

I think it most likely is the case that "dialect of Lisp",
in its "traditional" Lisp-world usage, employs a nonstandard
sense of "dialect".  But that way of talking about Lisp-family
languages is so common that we're going to have to live with
it for some time to come.
From: Barry Margolin
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <wlgM1.17$4W1.341223@burlma1-snr1.gtei.net>
In article <··············@gairsay.aiai.ed.ac.uk>,
Jeff Dalton  <····@gairsay.aiai.ed.ac.uk> wrote:
>Erik Naggum <····@naggum.no> writes:
>
>> | If you don't like the "dialect of X" terminology, then perhaps "member of
>> | the X family" would be better, but in my mind they mean the same thing.
>> 
>>   it seems to mean the same thing only when X = Lisp.
>
>I think it most likely is the case that "dialect of Lisp",
>in its "traditional" Lisp-world usage, employs a nonstandard
>sense of "dialect".  But that way of talking about Lisp-family
>languages is so common that we're going to have to live with
>it for some time to come.

I agree.  Real world linguists presumably have terms for the various levels
in the language taxonomy, but most of us aren't linguists and aren't
familiar with the fine distinctions between the levels.  To a linguist, "X
family" and "dialects of X" are almost certainly very different, I'm happy
to use them synonymously in reference to Lisp.  I've also sometimes used
"flavor of Lisp" -- this has the advantage that it doesn't try to reuse an
existing linguistic term.  Programming language people also often refer to
the "Algol family", which includes languages like Algol, PL/I, Pascal, Ada,
and C -- to me, what they have in common is similar uses of block
structuring, structured data, and expression syntax.

Another thing that also can be used to determine language family membership
is design history.  This isn't something you can check by looking at a
language specification.  But it's well known that Dylan was designed by
people very familiar with Lisp (many different dialects, and several of
them were involved with the original and/or X3J13 design of CL); they took
what they thought were all the good ideas from Lisp (call by object
reference, dynamic memory management, much of CLOS), renamed them as they
saw fit, added some other features (e.g. sealed classes), and eventually
replaced the Lisp-like syntax with something more Pascal-like.  But
underneath that syntactic skin we all know there beats the heart of a Lisp.
I think they started with the following goal: knowing what we know now and
not having to worry about backward compatibility, redesign Lisp from
scratch.  Backward compatibility is the main reason why the Common Lisp
designers couldn't do what the Dylan designers did -- CL was evolutionary,
while Dylan could be revolutionary.

Perl5 is a real pastiche.  It adopts many syntactic features from C, Unix
shell, and sed/awk, and combines them with an underlying engine that's more
like Lisp, IMHO.  Given its mix-and-match origin, it's hard to say that it
belongs to any particular family.  But as a Lisp enthusiast, I don't feel
uncomfortable using it, the way I do when using C.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: David Thornley
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <oFAM1.768$Ge.1709673@ptah.visi.com>
In article <···················@burlma1-snr1.gtei.net>,
Barry Margolin  <······@bbnplanet.com> wrote:
>In article <··············@gairsay.aiai.ed.ac.uk>,
>Jeff Dalton  <····@gairsay.aiai.ed.ac.uk> wrote:
>>Erik Naggum <····@naggum.no> writes:
>>
>>> | If you don't like the "dialect of X" terminology, then perhaps "member of
>>> | the X family" would be better, but in my mind they mean the same thing.
>>> 
>>>   it seems to mean the same thing only when X = Lisp.
>>
>>I think it most likely is the case that "dialect of Lisp",
>>in its "traditional" Lisp-world usage, employs a nonstandard
>>sense of "dialect".  But that way of talking about Lisp-family
>>languages is so common that we're going to have to live with
>>it for some time to come.
>
>I agree.  Real world linguists presumably have terms for the various levels
>in the language taxonomy, but most of us aren't linguists and aren't
>familiar with the fine distinctions between the levels.  To a linguist, "X
>family" and "dialects of X" are almost certainly very different, I'm happy

To a linguist, "family" tends to imply more difference than "dialect".
Nobody calls modern Italian, Spanish, or French dialects of some
language.  On the other hand, there is no real dividing line between
two languages of one family and two dialects of one language.  It's
partly mutual intelligibility and partly politics.  ("Mutual
intelligibility" is also not well defined, nor can it be.  There are
places where one basic language is spoken, each group can talk to
its neighbors, but the ends can't understand each other.  This at
least used to be the case with the German-speaking Swiss down the
Rhine to the Netherlands.)

We're well in the mainstream here.  We call various languages dialects
of Lisp on the basis of mutual intelligibility, and we have political
reasons to consider Scheme, Common Lisp, and ISLisp dialects of one
language.  The folks who like Wirth-designed languages seem to have
political reasons for calling Modula-2 and Oberon different languages
from Pascal.  Over in comp.lang.c, the regulars are fiercely
determined to call C and C++ two different languages, for reasons of
their own (independence, I think - sort of like whether Ukrainian is
a dialect of Russian).

So we don't need to feel guilty about misusing linguistic terms.



--
David H. Thornley                        | These opinions are mine.  I
·····@thornley.net                       | do give them freely to those
http://www.thornley.net/~thornley/david/ | who run too slowly.       O-
From: Jeff Dalton
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <x2pvcu7djd.fsf@gairsay.aiai.ed.ac.uk>
Erik Naggum <····@naggum.no> writes:

> * Jeff Dalton <····@gairsay.aiai.ed.ac.uk>
> | Did you mean to say "Scheme is not a dialect of Lisp" rather than "not a
> | dialect of Common Lisp"?  In any case, it's unlikely that anyone has ever
> | claimed Scheme was a dialect of Common Lisp.
> 
>   but what _is_ the Lisp that both Scheme and Common Lisp are dialects of?

You seem to be presupposing that Lisp, Scheme, and Common Lisp are
all on the same level.  Is that how it works for natural languages?
Would one ask "Where is the Chinese that Mandarin and Cantonese
are dialects of?" with similar rhetorical intent?

(If they are, indeed, considered dialects -- I have not checked this.)

I would have thought that a language was an abstraction relative to
its dialects.  All speakers would speak one dialect or another, even
if one dialect was considered more standard than the others.

In any case, I am not saying that "dialects of Lisp" is the right
way to describe these things, only that it is established usage.
One can still criticise it as using "dialect" in a nonstandard way,
if that's the case, or whatever.  But if someone says "___ is a
dialect of Lisp", and we want to know whether they've said something
true or false, we need to understand how they were using "dialect of
Lisp".

>   if there is no such thing (and I don't think there is, anymore, although
>   there might well have been in the distant past), then it is not useful to
>   talk about it.  "dialect" is not a mark of independent quality in my view
>   and there's a weird interaction between "dialect of Lisp" and the effect
>   the mark has on various languages that claim it: one language may try to
>   capitalize on the work of another ("we're _all_ dialects"), yet it may be
>   used to reduce the value of the work of another at the same time ("we're
>   all _merely_ dialects").

"Dialect of Lisp" has been, as still is, much used to refer to
languages in the Lisp family.  That way of talking has some serious
problems, which is one reason I think the "family of languages"
approach is better.  But since many people did, and still do, talk of
"dialects of Lisp", we may want to understand what they're saying.

At the same time, if we take "dialect of <language>" in a probably
more standard sense, then these languages are not "dialects of Lisp".
As many have noted for at least 20 years now, these so-called dialects
can be as different from each other as the things that are described
as different languages in, say, the Algol family; and the "different
languages" way of talking is at least less misleading (in addition to
whatever other advantages it might have).

> * Erik Naggum <····@naggum.no>
> | some Lispers (well, at least one, but he's also a Schemer) will insist
> | very strongly that Common Lisp is not the only Lisp to consider.
> 
> * Jeff Dalton <····@gairsay.aiai.ed.ac.uk>
> | Well, I'll certainly insist that Common Lisp is not the only Lisp.
> 
>   the two words "to consider" is essential to what I wrote above.  I know
>   that you go ballistic every time somebody forgets to mention the myriads
>   of other Lisps that you want us to remember, and that's why I attempted
>   to be very specific.  I'm annoyed that you appear to continue unimpeded
>   with your standard rhetoric.

Well, since it seems to matter to you, I'm happy to say Common Lisp is
not the only Lisp *to consider* too.

Anyway, Saying that Lisp is a family of languages has a number of
advantages over talking of "dialects of Lisp", and members of a
family can be very different from each other.

The other alternative that sometimes occurs is to use "Lisp" to mean
only Common Lisp.  I don't see anything wrong with that in contexts
where it will not be misunderstood: where it's clear that it's being
used just as a shorter way to refer to Common Lisp.

But I think it's a mistake to use "Lisp" in that way when it may be
misundrstood as referring to all of Lisp.  This matters especially
when "Lisp" is being criticised, as it all too often is.  It's fairly
common for people to say that "Lisp" is a too large a language, or
makes it too hard to deliver small applications, or has various other
problems.  But often these claims are not true of Lisp in general
(some Lisps are very small languages, a Lisp could make it easy to
deliver small applications, and so on), but only of certain particular
Lisps (maybe Common Lisp), or only of certain implementations.

Another case where I disagree is where someone seems to go further
than using "Lisp" as conveniently short for "Common Lisp" and say that
Common Lisp is the only Lisp, or that "Lisp" just *means* common Lisp
(and hence that there's either no Lisp family or else no other
member).

For in fact other Lisps do exist, a number of them are still being
used, and Lisps can be significantly different from Common Lisp.

-- jd
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115057537143878@naggum.no>
* Jeff Dalton <····@gairsay.aiai.ed.ac.uk>
| You seem to be presupposing that Lisp, Scheme, and Common Lisp are
| all on the same level.

  it doesn't seem that way to me.  why does it seem that way to you?

| (If they [Mandarin and Cantonese] are, indeed, considered dialects [of
| Chinese] -- I have not checked this.)

  they are not considered dialects of Chinese by the Chinese.  Western
  non-linguists appear to find "Chinese" a useful abstraction.  it's about
  as useful as "Germanic" about Western Hemisphere _spoken_ languages.
  (Chinese the writing-system is of course a different matter altogether.)

| Anyway, Saying that Lisp is a family of languages has a number of
| advantages over talking of "dialects of Lisp", and members of a family
| can be very different from each other.

  indeed.  however, membership in the family should ideally be testable by
  some reasonably simple means.  I think the crucial element to membership
  is whether source code can be read and represented internally in the
  run-time environment as a standard data structure, and as a corollary,
  whether one can expect READ and WRITE to exist and do the obvious thing
  for all types that do not reflect "dynamic state" and without _undue_
  complexity.  that is, the old "code is data" argument.  without that, I'd
  say it doesn't matter _what_ you do to look like any member of the Lisp
  family, and I'd have to remove Dylan and Perl 5 from the family.

| But I think it's a mistake to use "Lisp" in that way when it may be
| misunderstood as referring to all of Lisp.  This matters especially when
| "Lisp" is being criticised, as it all too often is.  It's fairly common
| for people to say that "Lisp" is a too large a language, or makes it too
| hard to deliver small applications, or has various other problems.  But
| often these claims are not true of Lisp in general (some Lisps are very
| small languages, a Lisp could make it easy to deliver small applications,
| and so on), but only of certain particular Lisps (maybe Common Lisp), or
| only of certain implementations.

  on this we agree.  arguing _against_ Lisp has to be done on the essential
  elements of similiarity, not against incidental differences or qualities
  of implementations.

| Another case where I disagree is where someone seems to go further than
| using "Lisp" as conveniently short for "Common Lisp" and say that Common
| Lisp is the only Lisp, or that "Lisp" just *means* common Lisp (and hence
| that there's either no Lisp family or else no other member).

  this would depend on context.  in some contexts, it is destructive and
  confusing to insist that "Lisp is not Common Lisp".

| For in fact other Lisps do exist, a number of them are still being used,
| and Lisps can be significantly different from Common Lisp.

  while still being used, I cannot but argue against learning them apart
  from the applications they are embedded in, such as Emacs' Lisp or
  AutoCAD's Lisp.

#:Erik
-- 
  ATTENTION, all abducting aliens!  you DON'T need to RETURN them!
From: Martin Rodgers
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <MPG.1069f906229f1640989c7a@news.demon.co.uk>
In article <··············@gairsay.aiai.ed.ac.uk>, 
····@gairsay.aiai.ed.ac.uk says...

> The phrase "dialect of Lisp" has been used for many years, and
> "dialect of Lisp" was taken to be a fairly broad category.
> It was natural to speak of Scheme as a dialect of Lisp, and
> one even finds sub-varieties of Scheme (such as T) referred
> to as "dialects of Lisp".
 
I was reading about Lisp for years before I discovered Common Lisp (in 
the mid 80s, FWIW), so I associate the name "Lisp" with a language or set 
of languages that predates Common Lisp. The first Lisp book I read used 
MacLisp, but the first Lisp code I remember reading (in Byte) was for a 
very small dialect that ran on a 16K TRS-80.

So I'm rather bemused by all this fuss.

> So, all things considered, the "dialect of Lisp" way of talking
> is probably more trouble than it's worth.

A good point well put.
-- 
Remove insect from address to email me | You can never browse enough
"Ahh, aren't they cute" -- Anne Diamond describing drowning dolphins
From: Barry Margolin
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <h0XL1.67$yt.1485482@burlma1-snr1.gtei.net>
In article <··············@gairsay.aiai.ed.ac.uk>,
Jeff Dalton  <····@gairsay.aiai.ed.ac.uk> wrote:
>So, all things considered, the "dialect of Lisp" way of talking
>is probably more trouble than it's worth.

It may be like what a US Supreme Court justice said about obscenity: I
can't define it, but I know it when I see it.

I remember that there was a debate at one of the first Lisp Users and
Vendors conferences (perhaps the first one after the Symbolics Lisp Users
Group morphed into the Association of Lisp Users) about whether Dylan
should be considered a dialect of Lisp, even though they were abandoning
parentheses.

Not that anyone likely cares, but Perl (Perl 5, in particular, since almost
everything is first-class) comes pretty close to being a dialect of Lisp,
IMHO.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115018001706846@naggum.no>
* Barry Margolin <······@bbnplanet.com>
| Not that anyone likely cares, but Perl (Perl 5, in particular, since almost
| everything is first-class) comes pretty close to being a dialect of Lisp,
| IMHO.

  that's pretty amusing, considering Larry Wall's explicit hatred for Lisp.

#:Erik
-- 
  those who do not know Lisp are doomed to reinvent it
From: Barry Margolin
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <N5cM1.9$4W1.268157@burlma1-snr1.gtei.net>
In article <················@naggum.no>, Erik Naggum  <····@naggum.no> wrote:
>* Barry Margolin <······@bbnplanet.com>
>| Not that anyone likely cares, but Perl (Perl 5, in particular, since almost
>| everything is first-class) comes pretty close to being a dialect of Lisp,
>| IMHO.
>
>  that's pretty amusing, considering Larry Wall's explicit hatred for Lisp.

I didn't know about that.  What is it that he hates about it?  Presumably
not the lack of type declarations, the automatic memory management, nor the
ability to execute code generated on the fly (Perl has "eval").  Maybe the
references-based semantics (i.e. object pointers are implicit), since the
major semantic difference between Perl 5 and Lisp is the need to use
special syntax to create references to first-class objects.  Or maybe he
just doesn't like traditional Lisp syntax.

I think that the discovery that the Perl, Dylan, and Java folks hit on is
that if you can get around many people's irrational bias against Lisp's
heavily parenthesized syntax, they actually like most of the remaining
features, which just make programming easier.  Garbage collection was
probably just one of the many language features that has simply been
waiting for machine speeds to catch up -- none of the current generation of
new programmers remember the days when Lisp would hang for a minute or more
in GC, so they're not biased against this and enjoy not having to call
free().  I recall that when C++ first started gaining popularity, one of
the most frequent Usenet posts in its newsgroup was "where can I get a
class that implements garbage collection?", and soon classes that implement
reference counting or conservative GC were popping up right and left.
Similarly, draft ANSI C++'s STL is in the spirit of Common Lisp's sequence
functions, but goes even further in providing higher level data structures
(stacks, queues, sorted tables, etc.).

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Klaus Schilling
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <87yario80c.fsf@ivm.de>
Barry Margolin <······@bbnplanet.com> writes:

> In article <················@naggum.no>, Erik Naggum  <····@naggum.no> wrote:
> >* Barry Margolin <······@bbnplanet.com>
> >| Not that anyone likely cares, but Perl (Perl 5, in particular, since almost
> >| everything is first-class) comes pretty close to being a dialect of Lisp,
> >| IMHO.
> >
> >  that's pretty amusing, considering Larry Wall's explicit hatred for Lisp.
> 
> I didn't know about that.  What is it that he hates about it?  Presumably
> not the lack of type declarations, the automatic memory management, nor the
> ability to execute code generated on the fly (Perl has "eval").  Maybe the
> references-based semantics (i.e. object pointers are implicit), since the
> major semantic difference between Perl 5 and Lisp is the need to use
> special syntax to create references to first-class objects.  Or maybe he
> just doesn't like traditional Lisp syntax.
> 
And what about python, pike, ici and ruby ?

> I think that the discovery that the Perl, Dylan, and Java folks hit on is
> that if you can get around many people's irrational bias against Lisp's
> heavily parenthesized syntax, they actually like most of the remaining
> features, which just make programming easier.  Garbage collection was
> probably just one of the many language features that has simply been
> waiting for machine speeds to catch up -- none of the current generation of
> new programmers remember the days when Lisp would hang for a minute or more
> in GC, so they're not biased against this and enjoy not having to call
> free().  I recall that when C++ first started gaining popularity, one of
> the most frequent Usenet posts in its newsgroup was "where can I get a
> class that implements garbage collection?", and soon classes that implement
> reference counting or conservative GC were popping up right and left.
> Similarly, draft ANSI C++'s STL is in the spirit of Common Lisp's sequence
> functions, but goes even further in providing higher level data structures
> (stacks, queues, sorted tables, etc.).

On my machine, Emacs lisp does hang for several minutes, the swapping noise
making the Wall s tremble.

Klaus Schilling
From: Tim Bradshaw
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ey34su53a9l.fsf@haystack.aiai.ed.ac.uk>
* Barry Margolin wrote:
> I didn't know about that.  What is it that he hates about it?  Presumably
> not the lack of type declarations, the automatic memory management, nor the
> ability to execute code generated on the fly (Perl has "eval").  Maybe the
> references-based semantics (i.e. object pointers are implicit), since the
> major semantic difference between Perl 5 and Lisp is the need to use
> special syntax to create references to first-class objects.  Or maybe he
> just doesn't like traditional Lisp syntax.

I think he doesn't like the syntax.

> I think that the discovery that the Perl, Dylan, and Java folks hit on is
> that if you can get around many people's irrational bias against Lisp's
> heavily parenthesized syntax, they actually like most of the remaining
> features, which just make programming easier. 

I'm not convinced about this. I don't have an irrational bias against
Lisp (my home computer is a 3630), and I certainly *do* have a bias
against perl, whose syntax makes me feel quite ill.  But Perl gives me
important things that are hard to get in Lisp -- mostly string bashing
with good performance.  If I wrote Java I'd get at least the promise
of feasible cross-platform GUI stuff.  Those are both real immediate
benefits which it is quite hard to get from Lisp systems.  In the case
of perl especially, I would (and have) write in lispy languages in
preference, if I could do so without struggling because my scripts are
so painfully slow.

(And before someone replies with `string processing in Lisp is easy,
you're an idiot blah blah': it really isn't that easy if you want
things to be fast, small and simple.  I spent quite a long time doing
stuff in scsh, and I now have a bunch of (very pretty) scripts which
are really a pain in terms of performance compared to the obvious
rewrite in Perl.  I've done the same in elk, and CL, and it just isn't
easy to get the kind of painless performance that perl has.)

--tim
From: Reini Urban
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <36029194.28546838@judy>
Tim Bradshaw <···@aiai.ed.ac.uk> wrote:
>I'm not convinced about this. I don't have an irrational bias against
>Lisp (my home computer is a 3630), and I certainly *do* have a bias
>against perl, whose syntax makes me feel quite ill.  

strange. i love both of them, as former c but now lisp addict.
perl gives me all and 10x more what i could do in c plus most of the
lisp'ish constructs (eg: map, hashes) i love.
perl pleases my chaotic hacker mind and lisp my well-organized
intellectual mind.

as with tim,
I don't even try to do the string and database stuff in lisp what i do
now in perl since with perl it is much easier to write and it runs
faster. before the lisp has even initialized its image my perl script
has finished processing the ~100 textfiles.
and i still do like the one- or two-liners in perl, which would be six-
liners in lisp. still kind of beautiful in lisp but unavailable art.

readability (i mean perl's so claimed "non-readability") is relative.
yes, lisp is self-declarative, but i still can read and enhance my perl
scripts i wrote years ago.

i just make more errors in perl than in lisp. in lisp it's almost
impossible to make errors. in perl it's almost impossible to make no
errors at the first writing, but the compiler makes wonderful
suggestions. in c of course it's almost impossible to detect every
single error.

>But Perl gives me
>important things that are hard to get in Lisp -- mostly string bashing
>with good performance.  If I wrote Java I'd get at least the promise
>of feasible cross-platform GUI stuff.  Those are both real immediate
>benefits which it is quite hard to get from Lisp systems.  In the case
>of perl especially, I would (and have) write in lispy languages in
>preference, if I could do so without struggling because my scripts are
>so painfully slow.

---
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
From: Randy Sims
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <1998Sep18.123342.10768@srs.gov>
Tim Bradshaw <···@aiai.ed.ac.uk> writes:
> 
> (And before someone replies with `string processing in Lisp is easy,
> you're an idiot blah blah': it really isn't that easy if you want
> things to be fast, small and simple.  I spent quite a long time doing
> stuff in scsh, and I now have a bunch of (very pretty) scripts which
> are really a pain in terms of performance compared to the obvious
> rewrite in Perl.  I've done the same in elk, and CL, and it just isn't
> easy to get the kind of painless performance that perl has.)
> 
> --tim

What are your tips and techniques for string processing in Lisp?
Where (and why) does Lisp lose and Perl win?

randy.

-- 
Randal N. Sims (Randy)           |  Tel:   (803)725-1387
Westinghouse Savannah River Co.  |  Fax:   (803)725-8829
SRS, 773-A, A1128, Rm. 2         |  Email: ···········@srs.gov
Aiken, SC 29808-0001 USA         |  URL:   http://www.srs.gov (generic)

DISCLAIMER: The opinions expressed are mine and do not necessarily
	    represent Westinghouse Savannah River Co. or the
	    United States Department of Energy.
From: Donald Fisk
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <36063374.1EEF2B1C@bt-sys.spamblock.bt.co.uk>
Randy Sims wrote:

> What are your tips and techniques for string processing in Lisp?
> Where (and why) does Lisp lose and Perl win?

String processing is, IMO, one of Lisp's weak points, but it's no worse
than most other languages.   There is one language that no one here has
so far mentioned, and that is the string processing language Snobol4.
When written well, it's more readable than Perl.   It would be fairly
straightforward to write a Snobol4 pattern matcher as a Lisp macro.

Incidentally, like Lisp and Perl, Snobol4 also has an eval which takes
a piece of Snobol4 (a string) and executes it.

> randy.

--
Le Hibou (mo bheachd fhe/in: my own opinion)
"it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody.  the practical result
is that thieves and bums use C++ and nice people use CLOS."
 -- Erik Naggum
From: Kelly Murray
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3606D636.765312D@IntelliMarket.Com>
Donald Fisk wrote:
> 
> Randy Sims wrote:
> 
> > What are your tips and techniques for string processing in Lisp?
> > Where (and why) does Lisp lose and Perl win?
> 
> String processing is, IMO, one of Lisp's weak points, but it's no worse
> than most other languages. has

Actually, i think Lisp is much better off than most other languages
for these tasks, but perhaps I have a different view of what
constitutes string processing.  Lisp has an extensible syntax,
so one can define specialized languages specific to a task
that make it more useful and understandable than other languages,
at least once you become comfortable with parenthesis.

There are a few pattern matching packages for lisp.  Take a look
at Olin Shivers package, it's quite good.

But if you take a broader view, you can simply do things easier
and better by not viewing the problem as a pattern matching problem,
but tackle it a different way.  In particular, processing of HTML
documents using twisted pattern matching is particularly horrific
in my opinion.  Instead, I tackle these tasks using an object 
oriented approach -- convert HTML into objects, and then process
the objects, which is a much more general and MAINTAINABLE solution.
And if your object system is fast, then it's not really slow,
and in fact, compared to some highly compute intensive complex 
pattern matching solutions, it may even be more efficient as well.

-Kelly Murray   

;; this downloads a directory, and returns all the files as urls
(function url-directory (url)
 (loop with anchors = nil
       with html = (download-url url)
       with tags = (parse-html html)  ;; TURN HTML INTO OBJECTS
       for tag in tags
       finally (return (nreverse anchors))
     do
     (if (and (typep tag 'html-tag::A)
	      (slot-boundp tag 'href))
       then
	(push
	 (merge-urls (slot-value tag 'href) url)
	 anchors))
     ))
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115371273457872@naggum.no>
* Donald Fisk <···········@bt-sys.spamblock.bt.co.uk>
| String processing is, IMO, one of Lisp's weak points, but it's no worse
| than most other languages.

  what is it that is so weak?  I find it immensely useful that "string
  operations" in other languages actually work on _sequences_ in Common
  Lisp.  on the other hand, that sometimes does make them harder to find
  when you look specifically for string operations, and perhaps more so
  when you need a few keyword arguments to get what you really want.

#:Erik
-- 
  ATTENTION, all abducting aliens!  you DON'T need to RETURN them!
From: Barry Margolin
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <eFtN1.29$LN.735137@burlma1-snr1.gtei.net>
In article <················@naggum.no>, Erik Naggum  <······@naggum.no> wrote:
>* Donald Fisk <···········@bt-sys.spamblock.bt.co.uk>
>| String processing is, IMO, one of Lisp's weak points, but it's no worse
>| than most other languages.
>
>  what is it that is so weak?

When I think about the common string operations I do in Perl, many of them
don't exist as Common Lisp (or most other Lisp) built-ins: pattern
matching, substring replacement, inserting and deleting, splitting on
delimiters, etc.

Of course, these can be written in CL, but in string-oriented languages you
don't have to do that.  There may be a library of them already, but the
same would probably be true of other languages -- hence I agree with Donald
Fisk's point that "it's not worse than most other languages."

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Kent M Pitman
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <sfwg1dlzfb7.fsf@world.std.com>
Erik Naggum <······@naggum.no> writes:

> * Donald Fisk <···········@bt-sys.spamblock.bt.co.uk>
> | String processing is, IMO, one of Lisp's weak points, but it's no worse
> | than most other languages.
> 
>   what is it that is so weak?  I find it immensely useful that "string
>   operations" in other languages actually work on _sequences_ in Common
>   Lisp.  on the other hand, that sometimes does make them harder to find
>   when you look specifically for string operations, and perhaps more so
>   when you need a few keyword arguments to get what you really want.

I'm gonna side with Donald on this one.  The absence of regular
expressions is a shame.  Doing the equivalent with CL sequence
operations has the same feel as doing without FORMAT in I/O.  The
language has the power even without FORMAT, but the packaging really
makes it easier to do and to spot bugs and to maintain/extend.

I programmed for a while intensively in MOO (a programming language for
certain text-based virtual realities) and it used regexps intensely and
they were a ton of fun to use compared to the CL alternatives. 

I think the absence of them in CL is mostly an accident of history
because of when CL was coming together, not a willful rejection of a
good idea.  Regexps  hadn't caught on clearly enough by 1988 when we
froze the standard for there to be implementations which were
sporting them.  

On the other hand, I've heard there are contributed libraries that
cover this gap.  And given that, I can't feel too bad that what we have
is not useful.

I do also sometimes wish for the LispM's string-search-set and
string-search-not-set.
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115409412070935@naggum.no>
* Kent M Pitman <······@world.std.com>
| I'm gonna side with Donald on this one.  The absence of regular
| expressions is a shame.

  a _shame_?  I don't consider regular expressions _that_ much of a must.
  (I installed them in ACL 4.3, and it comes builtin with ACL 5.0, but I
  haven't had occasion to use it, quite unlike in Emacs Lisp, where I have
  to, and don't like the absence of everything that makes me have to.)  on
  the contrary, since their presence seem to supplant better solutions,
  like parsers that convert strings into data structures you can work with
  more intelligently, I find them akin to the mythological sirens whose
  luring songs called ships into dangerous waters.

| I think the absence of them in CL is mostly an accident of history
| because of when CL was coming together, not a willful rejection of a good
| idea.  Regexps hadn't caught on clearly enough by 1988 when we froze the
| standard for there to be implementations which were sporting them.

  would it be a workable solution if the vendors cooperated on the
  functional interface today?  it doesn't appear to be for lack of fast and
  good implementations, at least not as far as strings are concerned.

| I do also sometimes wish for the LispM's string-search-set and
| string-search-not-set.

  hm.  I found a veritable plethora of string functions in the Genera 7.2
  manual set (which Michael Cracauer kindly sent me some time ago), most of
  them seeming to _scream_ for far more general solutions (not counting
  regexps as such a solution).  it occurs to me that SEARCH should be
  sufficient with some moderately simple functions, as in

(search (set <member>...) <string> :test #'in-set-p)

  where SET and IN-SET-P could cooperate on optimizing performance, perhaps
  even at compile time.  I just don't want to limit this to strings, only.
  likewise, regular expressions that worked on sequences of all kinds with
  any type of contents would be _much_ more attractive to me.  regular
  expressions on strings is just that: a special case for _strings_, and
  the pattern matching languages involved should be far more generally
  applicable, in my opinion.  it seems "un-Lispy" to me to make something
  work only for strings when there is wider applicability.

#:Erik
-- 
  ATTENTION, all abducting aliens!  you DON'T need to RETURN them!
From: Kevin Layer
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <mkd872m2br.fsf@ultra.i-did-not-set--mail-host-address--so-shoot-me>
Kent M Pitman <······@world.std.com> writes:

> Erik Naggum <······@naggum.no> writes:
> 
> > * Donald Fisk <···········@bt-sys.spamblock.bt.co.uk>
> > | String processing is, IMO, one of Lisp's weak points, but it's no worse
> > | than most other languages.
> > 
> >   what is it that is so weak?  I find it immensely useful that "string
> >   operations" in other languages actually work on _sequences_ in Common
> >   Lisp.  on the other hand, that sometimes does make them harder to find
> >   when you look specifically for string operations, and perhaps more so
> >   when you need a few keyword arguments to get what you really want.
> 
> I'm gonna side with Donald on this one.  The absence of regular
> expressions is a shame.

Allegro CL has a regular expression package.  It was a patch to ACL
4.3 and is included in 5.0.
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <71svno$2cv$1@spitting-spider.aracnet.com>
In article <··············@ultra.i-did-not-set--mail-host-address--so-shoot-me>,
	Kevin Layer <·····@franz.com> writes:

>> I'm gonna side with Donald on this one.  The absence of regular
>> expressions is a shame.
> 
> Allegro CL has a regular expression package.  It was a patch to ACL
> 4.3 and is included in 5.0.

  Is it included in CMUCL? In MacCL? In Harlequin's? Proprietary solutions to
basic functionality do the whole CL community a great disservice.

  Mike McDonald
  ·······@mikemac.com
From: Kent M Pitman
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <sfwww59ua4y.fsf@world.std.com>
·······@mikemac.com (Mike McDonald) writes:

> In article <··············@ultra.i-did-not-set--mail-host-address--so-shoot-me>,
> 	Kevin Layer <·····@franz.com> writes:
> 
...
> > Allegro CL has a regular expression package.  It was a patch to ACL
> > 4.3 and is included in 5.0.
> 
>   Is it included in CMUCL? In MacCL? In Harlequin's? Proprietary solutions to
> basic functionality do the whole CL community a great disservice.

Well, hmmm.  I just wrote something similar myself earlier when
talking about CLTL2 and seeing the same kind of sentiment in a
different context from someone else makes me feel a need to qualify my
earlier remarks because I don't think I agree with this in this case.

With respect to CLTL2, the problem wasn't the proprietariness per se,
but the fact that in some sense it was competing with something that
wasn't proprietary (ANSI CL).  What made the CLTL2 vs ANSI CL issue
difficult was that there was not yet an ANSI CL so there was no choice
but to use the "rogue" version (CLTL2) or continue to use the previous
"standard" (CLTL1).

In this case, there is no standard being competed with by Franz, and so
I don't think they are hurting anyone by pushing the envelope.

Further, and related, standards are not about design--at least, they
oughtn't be.  They are about reifying those aspects of development
done elsewhere that has achieved a sense of stability and is ripe for
general agreement in order to build a next layer.  It is critical,
IMO, that design activity always lead standards and not vice versa.
I think if you polled them then (I recall such discussions), people
making CL would have said their hope was not to freeze proprietary
Lisp growth but to enable it.  By saying what is standard, you tell 
those people who can't afford to rely on proprietary things which
part they should use, but you also enable those who worry that 
innovation might break customers to have room to work on innovation.
Or so it was supposed to work.  In practice, if anything, there has
been less innovation than I might have wished for since the standard,
so I really do want to prod and encourage Franz, Harlequin, or any
other place that wants to to experiment with new technologies.

And, procedurally, when we used to accept proposals for
standardization in x3j13, we almost always looked much more favorably
on something that was implemented and used than something proprietary.
So it wouldn't get to be standard without going to a proprietary phase.

Now there's a difference between proprietary implementations and a
proprietary set of interface definitions.  If someone calls Franz and
they say "no, these function names and their definitions are private,
make up your own", then of course that does no one any service.  But
hopefully they'd be motivated to have others follow their lead and use
the same definitions rather than risk an incompatible standard
succeeding and leaving them to play "catch up".  Still, when copyright
is potentially involved, you should ask to avoid misunderstandings.
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <71t8if$fum$1@spitting-spider.aracnet.com>
In article <···············@world.std.com>,
	Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:
> 
>> In article <··············@ultra.i-did-not-set--mail-host-address--so-shoot-me>,
>> 	Kevin Layer <·····@franz.com> writes:
>> 
> ...
>> > Allegro CL has a regular expression package.  It was a patch to ACL
>> > 4.3 and is included in 5.0.
>> 
>>   Is it included in CMUCL? In MacCL? In Harlequin's? Proprietary solutions to
>> basic functionality do the whole CL community a great disservice.
> 
> Well, hmmm.  I just wrote something similar myself earlier when
> talking about CLTL2 and seeing the same kind of sentiment in a
> different context from someone else makes me feel a need to qualify my
> earlier remarks because I don't think I agree with this in this case.
> 
> With respect to CLTL2, the problem wasn't the proprietariness per se,
> but the fact that in some sense it was competing with something that
> wasn't proprietary (ANSI CL).  What made the CLTL2 vs ANSI CL issue
> difficult was that there was not yet an ANSI CL so there was no choice
> but to use the "rogue" version (CLTL2) or continue to use the previous
> "standard" (CLTL1).
> 
> In this case, there is no standard being competed with by Franz, and so
> I don't think they are hurting anyone by pushing the envelope.

  Pushing the envelope? A regexp package? Hmm, those backwards Unix/C folks
seemed to have come up with a workable solution for them. I use ACL5 but I
don't use their regexp package. I use one of the publicly available ones so I
can have the same syntax and symantics across CL implementations, even though
it's buggier and slower. At least it's consistant.

  To me, the largest problem with CL is the lack of standards for all of those
other utilities that a modern environment should support. Things like regular
expressions, foreign function calls, threads, GUI, ... This lack of
standardization (and I don't mean formal standardization) causes my "portable"
CL code to have more #+'s in it than my "portable" Unix/C code has #ifdef's!
And I'm constantly having to roll my own of things the competing languages
take for granted.

> In practice, if anything, there has
> been less innovation than I might have wished for since the standard,
> so I really do want to prod and encourage Franz, Harlequin, or any
> other place that wants to to experiment with new technologies.

  I'm all for the commercial implementors experimenting with "new
technologies". Incompatibilites in the early stages of innovation is all fine
and good. But calling something innovative just because it's proprietary is
silly.  But for plain ole run of the mill stuff, they've got to get their acts
together and start cooperating. From my perspective, the Lisp communittee has
suffered from a parochial NIH attitude for far too long. When the communittee
is large, it can accommodate an individual member being pig headed. But when
the communittee consists of 3, it can't afford that luxury. Especially not in
the core libraries. (And I do believe the "core libraries" should and must
include more than what the ANSI standard requires.)

> And, procedurally, when we used to accept proposals for
> standardization in x3j13, we almost always looked much more favorably
> on something that was implemented and used than something proprietary.
> So it wouldn't get to be standard without going to a proprietary phase.

  I don't follow this? From my outsider's prespective, it seemed that the
formal standardization process favored things that had "open", "portable"
implementations.

  Mike McDonald
  ·······@mikemac.com
From: Kent M Pitman
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <sfwemrhybi7.fsf@world.std.com>
·······@mikemac.com (Mike McDonald) writes:

> But calling something innovative just because it's proprietary is
> silly.

I'm going to pass on responding to this message in full, but I did
want to note that your summary of what I said has lost information
somehow.  I only said something could be innovative in spite of being
proprietary.  I didn't say the proprietariness was the cause of my
perception that innovation had occurred.

Well, ok, I'll respond to just one other point:

> But for plain ole run of the mill stuff, they've got to get their acts
> together and start cooperating. From my perspective, the Lisp communittee has
> suffered from a parochial NIH attitude for far too long.

There are good solid business reasons why what you want is unlikely to
ever happen in the way you are expecting.  Vendors can't just get
together privately and agree to do things in a cooperative way.

First, their release cycles aren't synchronized.  One would get to market
before the other and that would be the end of any future cooperation.

Second, there is a non-trivial problem organizing shared intellectual
property--it was tried with CLIM and the results were ... a problem.
No one could freely do things with it.  Indeed, there have been on and
off discussions among various vendords, never with any outcome, about
whether there could ever be a public version of CLIM, but since it's
uncertain who owns the intellectual property now that some of the 
participants have disappeared or gone on to do other things, no one is
quite sure who can authorize that and as a result, no one does anything.

Third, cooperation in early design is not healthy.  What you have
described is, if I may characterize it only slightly, basically the
Microsoft model: that no one wants in-fighting and they just want one
common solution they can depend on from everyone.  That Netscape is
bad because it's a proprietary solution that only some people can have
and that Internet Explorer is good because it's something everyone (on
PCs) can have.  Of course, we know that kind of argument misses
slightly, but it is an argument that some have made and it's
uncomfortably close to the argument I hear you making.  It's possible
the absence of open implementations hurts people, but there's no one
to blame if there is such an absence.  But if there is an open
implementation and someone (even a vendor) chooses not to use it, it's
not obviously bad--maybe it means they don't like the open standard.
Users can choose an alternative or can walk if they don't like it.
And diversity does itself is healthy.  If Franz has some layered
facility that uses regexps and you want it to use an alternate
facility, send a bug report--maybe they'll fix it. If they won't, I
bet the reason won't be control of the market, but some technical
problem that will help you to understand why they had to have their
own in the first place.  Maybe then if the public version is updated,
it can be used interchangeably and the competition will have been
healthy.

Fourth, and related to the previous point, is that when a vendor gets
together with another vendor and decides what's right, they have to
tread lightly to avoid anti-trust action.  One key role that standards
bodies play is to assure a level of fairness that insulates
cooperating companies from accusations of unfair business practice by
assuring that there is a forum for those who want to have a say to get
that say, independent of dollars.  Working outside them is an additional
risk.

The real problem, IMO, has not been the vendors but the users.
Getting users to join x3j13 has been like pulling teeth.  Some started
out in it at first, but all dropped out.  Only the vendors remained,
and the result was very vendor-centric.  Earlier this year, I
encouraged users to join x3j13, but really none did.  Further, the ALU
has consistently failed (though not for lack of trying) to get users
organized enough to help work with vendors to define what users need.
Users have to stand up for their own needs.  They have to participate
in committees.  They have to be sure their vendor knows what the
priorities are.  Mostly of late the priority has been connectivity to
standard environments--databases, corba, etc.  And I think vendors
have been responsive to that.  If there are other things that are
needed, the users need to speak with one voice.  Because from inside
the companies I've been at, I can tell you the voices are all over the
map, and the result is that vendors decide they can't please everyone
and they just do what they can to make sales numbers.

I had more to say on this, but I'll defer it to another day.
From: Howard R. Stearns
Subject: Drive the "standards" movement (was Re: I don't understand Lisp)
Date: 
Message-ID: <36434BE7.EBACDD82@elwood.com>
Kent M Pitman wrote:
> ...
> Further, the ALU
> has consistently failed (though not for lack of trying) to get users
> organized enough to help work with vendors to define what users need.
> Users have to stand up for their own needs.  They have to participate
> in committees.  They have to be sure their vendor knows what the
> priorities are.  Mostly of late the priority has been connectivity to
> standard environments--databases, corba, etc.  And I think vendors
> have been responsive to that.  If there are other things that are
> needed, the users need to speak with one voice.  Because from inside
> the companies I've been at, I can tell you the voices are all over the
> map, and the result is that vendors decide they can't please everyone
> and they just do what they can to make sales numbers.

One of the charter roles of the Association of Lisp Users is to
represent users as a group to vendors.  You are all invited to the ALU
meeting immediately following the "40th Anniversarry Lisp Users Group
meeting".  

The conference is the 15-18 of this month, in Berlely, CA.  See
http://www.franz.com/lugm98/conference/index.html

The ALU meeting is currently scheduled for the evening of Wednesday,
11/18. 
By attending, you will have the chance to introduce new business for the
ALU, and to run for and elect a governing board.

I will attempt to arrange to post here the results of the meeting.  If
anyone cannot attend, but would like to raise some issue at the meeting,
please contact me (or ·········@ai.sri.com) by mail.

Anyone who wants to see some sort of group activity should really come
(expanded and updated source code repositories, refinements or
extensions to the standards, etc.).  If you feel strongly about the need
for something, yet cannot come to the meeting, please get in touch with
me (or ·········@ai.sri.com) -- especially if you are willing to devote
time or other resources.
From: Howard R. Stearns
Subject: drive Lisp activity (was Re: I don't understand Lisp)
Date: 
Message-ID: <36434F52.17FBD8F@elwood.com>
Kent M Pitman wrote:
>
> Further, the ALU
> has consistently failed (though not for lack of trying) to get users
> organized enough to help work with vendors to define what users need.
> Users have to stand up for their own needs.  They have to participate
> in committees.  They have to be sure their vendor knows what the
> priorities are.  Mostly of late the priority has been connectivity to
> standard environments--databases, corba, etc.  And I think vendors
> have been responsive to that.  If there are other things that are
> needed, the users need to speak with one voice.  Because from inside
> the companies I've been at, I can tell you the voices are all over the
> map, and the result is that vendors decide they can't please everyone
> and they just do what they can to make sales numbers.

One of the charters of the Association of Lisp Users is to represent
users as a group to vendors.  You are all invited to the ALU meeting
that will immediately follow the 40th Anniversary Lisp conference this
month.

The conference is the 15-18 of this month, in Berkeley, CA. See
http://www.franz.com/lugm98/conference/index.html

The ALU meeting is currently scheduled for the evening of Wednesday
11/18.  By attending, you will be able to raise new business and run for
and elect a new governing board.

Anyone with interest in either standards or code repositories should
attend.  If you feel strongly about something, but cannot come, please
contact me (or ·········@ai.sri.com) and I will see to it that the issue
is raised.  I will attempt to arrange for a summary of the results to be
posted here.
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <71tfjh$nas$1@spitting-spider.aracnet.com>
In article <···············@world.std.com>,
	Kent M Pitman <······@world.std.com> writes:
> ·······@mikemac.com (Mike McDonald) writes:
> 
>> But calling something innovative just because it's proprietary is
>> silly.
> 
> I'm going to pass on responding to this message in full, but I did
> want to note that your summary of what I said has lost information
> somehow.  I only said something could be innovative in spite of being
> proprietary.  I didn't say the proprietariness was the cause of my
> perception that innovation had occurred.

  I'd go so far as to say most innovative things start out "proprietary".
Afterall, most innovations start with one person and then, hopefully, spread.
Except if it's related to CL. Then everyone will implement their own
incompatible version.

> Well, ok, I'll respond to just one other point:
> 
>> But for plain ole run of the mill stuff, they've got to get their acts
>> together and start cooperating. From my perspective, the Lisp communittee has
>> suffered from a parochial NIH attitude for far too long.
> 
> There are good solid business reasons why what you want is unlikely to
> ever happen in the way you are expecting.  Vendors can't just get
> together privately and agree to do things in a cooperative way.

  Vendors do it on a daily basis in every other industry. Now, given that 2 of
the 3 CL vendors getting together makes majority, they're might be illusion of
impapriety (sp?).

> First, their release cycles aren't synchronized.  One would get to market
> before the other and that would be the end of any future cooperation.

  Why? In just about every other industry, release cycles aren't synchronized
either. But yet they manage to support "defacto standards".

> Second, there is a non-trivial problem organizing shared intellectual
> property--it was tried with CLIM and the results were ... a problem.
> No one could freely do things with it.  Indeed, there have been on and
> off discussions among various vendords, never with any outcome, about
> whether there could ever be a public version of CLIM, but since it's
> uncertain who owns the intellectual property now that some of the 
> participants have disappeared or gone on to do other things, no one is
> quite sure who can authorize that and as a result, no one does anything.

  Yup. Having seen the copyright notices on the sources, CLIM is a mess! But
why did this come about? Because of the short sightedness of the participants!
Each wanted to enhance their own momentary economic position. There are lots
of examples in the software industry where a company, or group of companies,
released all rights to the underlying technology for the "greater" good. (And
there's lots of examples where they didn't.)

  In this case, all Franz would have to do is release the one source file
under somethng like a GPL copyright.  (Scanning thru the symbols, it looks
like it's all defined in regexp.cl.) Then Harlequin, Digitool, CMUCL, CLISP,
and users can all pick it up. That's one problem solved. But they won't, so
they must think it gives them some great competitive edge.

> Third, cooperation in early design is not healthy.

  This is NOT early design stuff. Crap, in 10 days we're celebrating the 40th
anniversary of Lisp! And we can't even get regexp

> Fourth, and related to the previous point, is that when a vendor gets
> together with another vendor and decides what's right, they have to
> tread lightly to avoid anti-trust action.  

  Yes, they have to be careful about anti-trust problems, particularly if they
get together behind close doors. If on the other hand, they conduct it in an
open manner, they have far less worries. (In this case, since the vendors are
X3J13, they could just call it a X3J13 meeting and cover their backsides! I'm
being a bit facecious. I'm assuming calling a X3J13 meeting isn't quite that
simple. Or is it?) Or, for small things like regexp packages, one of them just
builds something and releases into the open. That also works.

> The real problem, IMO, has not been the vendors but the users.
> Getting users to join x3j13 has been like pulling teeth.

  Standards committees are no place for end users, especially not individuals.
The time and money it takes to participate is beyond the reach of most users.
And a lot of this stuff doesn't require X3J13 blessing. X3J13 blessing after
there's a "defacto" standard is fine. We seem to have the chicken and egg
problem. The vendors won't agree to anything until it's blessed by X3J13. But
X3J13 won't bless anything until the members, aka the vendors, agree.
Stalemate!

  Mike McDonald
  ·······@mikemac.com
From: Raffael Cavallaro
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <raffael-0611980121110001@raffaele.ne.mediaone.net>
In article <············@spitting-spider.aracnet.com>, ·······@mikemac.com
wrote:

>Or, for small things like regexp packages, one of them just
>builds something and releases into the open. That also works.

I think this is the key point from a user perspective. All the vendors win
when *basic* functionality is portable across implementations, because
that makes Common Lisp a more attractive option when deciding what to use
for a given project.

The fact that one vendor has a proprietary regexp package only helps them
with customers that don't need portability (as one user of their product
wrote, he *avoids* their regexp package for this very reason). Basic
functionality should be released to the community as a whole, not because
we're lazy, or couldn't implement it ourselves if we took the time, but
because a vendor's freely available package would become a de-facto
standard, adding to "built-in" features of the language.

Let me just remind readers of a couple of the reasons that Java has become
so popular: It provides *lots* of basic functionality that is at the same
time very portable.The above is not to suggest in any way that I consider
Java a superior language to Common Lisp, but rather that the functionality
and portability of Java make this language a more attractive option in
many cases *in spite* of the fact that it is not as powerful or expressive
a language as Common Lisp. 

Vendors should decide whether they want Common Lisp to be another
Smalltalk - closed, proprietary, not very portable *, or very expensive if
portable and  with a correspondingly small market share - or another Java,
very portable, lots of built in functionality, relatively inexpensive, and
with a correspondingly large market share. I'll warn them though, that I,
like many users, will not be using Common Lisp much in the future if the
decision looks more like the former than the latter.

Raf


*Setting aside Squeak for the moment - it's been ported to everything from
Linux to my toaster oven, but it doesn't really run like the native OS on
any of them (it draws it's own wierd windows, for example - to me portable
doesn't mean "equally ugly on all platforms.")

-- 
Raffael Cavallaro
From: Tim Bradshaw
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ey3hfwdt8ur.fsf@todday.aiai.ed.ac.uk>
* Raffael Cavallaro wrote:
> The fact that one vendor has a proprietary regexp package only helps them
> with customers that don't need portability (as one user of their product
> wrote, he *avoids* their regexp package for this very reason). Basic
> functionality should be released to the community as a whole, not because
> we're lazy, or couldn't implement it ourselves if we took the time, but
> because a vendor's freely available package would become a de-facto
> standard, adding to "built-in" features of the language.

No I disagree.  The *definition* of the package should be freely
available, and anyone should be free to implement a compatible version
(including free versions), but I don't think it's reasonable to
require vendors to release implementations. Apart from anything this
may be impractical -- for instance a vendor may have an implementation
which gives very good performance but relies on internal properties of
their Lisp, which would be all but useless to anyone else.  Should
they therefore be write *another*, portable, version of their
extension?

--tim
From: Raffael Cavallaro
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <raffael-0611981024510001@raffaele.ne.mediaone.net>
In article <···············@todday.aiai.ed.ac.uk>, Tim Bradshaw
<···@aiai.ed.ac.uk> wrote:

>No I disagree.  The *definition* of the package should be freely
>available, and anyone should be free to implement a compatible version
>(including free versions), but I don't think it's reasonable to
>require vendors to release implementations.

Well in many cases, the definition would be the only portable thing (for
example, GUI stuff). In other cases, the full implementation could be done
in Common Lisp, and it would probably be better if it were released that
way. It would allow the community as a whole to improve it's
implementation portably, rather than having each vendor's customer
community working separately, which is now the case. A regexp package
would be an example where the whole package could, and imho should be
released in Common Lisp. 

However, I, like many others, would settle for a de-facto standard,
portable *definition* as you suggest. Anything is better than having to
reinvent the wheel multiple times.

Raf

-- 
Raffael Cavallaro
From: rusty craine
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <7206d9$7vo$1@excalibur.flash.net>
i understand lisp (well to some extent); it is the lisp community that i am
having trouble with (to a vast extent).  soooo......there is this group of
folks that decided what "setf" should do, then codify that along with the
rest of the "words" that make up the language.  From this there must be a
document produced for the public and proprietors to use to build their
common lisp.  Well i guess this is how most languages are done.

it guess it makes sense that a group of "standardizers" will flavor the
language with their particular interest.  If the common lisp standards
setters were only math guys (guess it would look like apl or J) we would
mostly likely get a different looking common lisp then we got.  This leads
to my next question.  who selects the group of "standardizers" and on what
authortiy do they select them.

Soooo...who is the Grand Poohbah of lisp and how did he/she/it get
incarnated to that illustrous postions.

What if i want to build an uncommon lisp and call it "common" lisp.  What
can the Grand Poohbah do about it?  Are what if i want to make "setf"  set
the "first" of a list to the it's next argument....Poohbah gona send me a
foo-virus or a bar-letter?

Lastly I shall put my wish lisp in.    1). take all the stuff back out of
common lisp save the primitives (standard 100 or so  words) and put it _all_
in packages  [wants small memory foot print].  2). that 100 primitive must
be written in assembler [wants fast - superman lisp].  3) all "un"common
lisp must have  inline assembler ability [to hell with C if we are going to
get to the guts lets do it].  4) besides assembler my uncommon lisp must
have functions to load registers, call machine interrupts, read and write to
DS and CS segments (and what ever they are in other platforms; i only know
intel assembler), read and write to all standard ports [ok ok so 4 is a
paradox to 3 if ya got to get to the guts why not do it?.....sometimes i'm
lazy].  oh well i'll cut the list lisp short, i guess you got some things
you might want to put in.

If ya see the grand  poohbah, tell rusty said hi and  m$ windows and common
lisp (vendor versions) are both betting pretty dang big (disk foot print, ah
well memory too)  I just bought a copy of a major vender's lisp...with help
files, demos, ide, et all  my hard drive gained 3 pound and electrons aren't
very heavy. (just kidding it is a very nice package and i actully do
understand the physics of magnetic media).

regards to the grand poohbah and poohbettes who every they are
rusty

ps i don't care if lisp solves your porblems but i better solve mine or i
will whin to #:Eric  ... :0)
From: Paolo Amoroso
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <364528fd.3091417@news.mclink.it>
On Fri, 6 Nov 1998 19:07:34 -0600, "rusty craine" <········@flash.net>
wrote:

> Lastly I shall put my wish lisp in.    1). take all the stuff back out of
> common lisp save the primitives (standard 100 or so  words) and put it _all_
> in packages  [wants small memory foot print].  2). that 100 primitive must
> be written in assembler [wants fast - superman lisp].  3) all "un"common
> lisp must have  inline assembler ability [to hell with C if we are going to
> get to the guts lets do it].  4) besides assembler my uncommon lisp must
> have functions to load registers, call machine interrupts, read and write to
> DS and CS segments (and what ever they are in other platforms; i only know

The newly released Corman Lisp http://www.corman.net/CormanLisp.html for
Windows probably offers most of this--and more--except #1. For the latter
you may consider Scheme http://www.schemers.org/.


Paolo
-- 
Paolo Amoroso <·······@mclink.it>
From: Tim Bradshaw
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ey390hkucds.fsf@todday.aiai.ed.ac.uk>
* rusty craine wrote:
> i understand lisp (well to some extent); it is the lisp community that i am
> having trouble with (to a vast extent).  soooo......there is this group of
> folks that decided what "setf" should do, then codify that along with the
> rest of the "words" that make up the language.  From this there must be a
> document produced for the public and proprietors to use to build their
> common lisp.  Well i guess this is how most languages are done.

I hope not!  I hope that instead there were a bunch of implementations
of something rather like SETF, which all clearly did pretty much the
same thing but had annoying minor differences, and that at some later
point a committee sat down and tried to	produce a suitable common
definition. 

That way standards are produced based on experience with actual
implementations.

--tim
From: Barry Margolin
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <CPH02.120$KS2.1395934@burlma1-snr1.gtei.net>
In article <···············@todday.aiai.ed.ac.uk>,
Tim Bradshaw  <···@aiai.ed.ac.uk> wrote:
>No I disagree.  The *definition* of the package should be freely
>available, and anyone should be free to implement a compatible version
>(including free versions), but I don't think it's reasonable to
>require vendors to release implementations. Apart from anything this
>may be impractical -- for instance a vendor may have an implementation
>which gives very good performance but relies on internal properties of
>their Lisp, which would be all but useless to anyone else.  Should
>they therefore be write *another*, portable, version of their
>extension?

We tried to get this to happen earlier in the decade, and it didn't fly.
When SLUG morphed into the ALU, one of the first things we did was
encourage the vendors to get together and agree on de facto specifications
for some features that most of them had, but which weren't yet compatible,
such as foreign function calling and DEFSYSTEM.  They had some initial
meetings, but it was never high enough priority that these companies, which
were strapped for resources as it was, could afford to continue.  As Kent
wrote, this effort is an investment for the long term, but it's often
difficult for companies that are living hand-to-mouth to make such
investments.  A startup company can get away with it because no one expects
them to be making a profit while they're in their growth stage, but
established companies can't run a deficit for too long or they'll go
bankrupt.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Don't bother cc'ing followups to me.
From: Tim Bradshaw
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ey33e7su01x.fsf@todday.aiai.ed.ac.uk>
* Barry Margolin wrote:
[Standard specifications of things]

> We tried to get this to happen earlier in the decade, and it didn't fly.
> When SLUG morphed into the ALU, one of the first things we did was
> encourage the vendors to get together and agree on de facto specifications
> for some features that most of them had, but which weren't yet compatible,
> such as foreign function calling and DEFSYSTEM.  They had some initial
> meetings, but it was never high enough priority that these companies, which
> were strapped for resources as it was, could afford to continue.  

OK, I can see that being a problem. Surely then the *users* should get
together and write specs for things that they want. (to which the
obvious response is: `OK, write some' at which point I go and hide in
a corner...)

--tim
From: Olivier Lefevre
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <364AA09F.4263@wdr.com>
Barry Margolin wrote:
 
> [...] They had some initial meetings, but it was never high enough 
> priority that these companies, which were strapped for resources as 
> it was, could afford to continue.  

I don't believe the low priority of standardization issues is caused
by starvation. If you look at C++, there is a tremendous need for
standardization of things like shared libraries layout (so that 
different compilers can interoperate) but it does not happen. Yet
in the large and affluent C++ market surely money is no object.

> As Kent wrote, this effort is an investment for the long term,

Precisely. I think the problem is more that most companies, affluent
or otherwise, only care about their short-term cash flow. 

-- O.L.
From: Kent M Pitman
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <sfwk9181zz4.fsf@world.std.com>
·······@mediaone.net (Raffael Cavallaro) writes:

> I think this is the key point from a user perspective. All the
> vendors win when *basic* functionality is portable across
> implementations, because that makes Common Lisp a more attractive
> option when deciding what to use for a given project.

This seems to me a completely unfair summation of the vendor
situation, and gives new (and somehow appropriate) meaning to the
subject line of this thread.  The problem is not the long term, which
is what you are addressing, but the short term.  It is not nearly so
obvious that all vendors win in the short term if they do as you say.

I've said for years that Lisp's biggest problem was reaching the
market too soon--when memory and disk were expensive.  Lisp is all
about the long term.  And in the long term, what you say might work.
But in the short term, there is no doubt that the Lisp companies need
money or there will BE no Lisp companies.  If the Lisp companies could
offer near-free software and hope that eventually they made up in
high-volume/low-margin what they lost in the beginning, the world
would be a lot simpler.  I don't know the particulars of what motivate
the Harlequin layoff recently, but if you don't read that as a sign
that short term money is an issue and that "portable" stuff is
complicated, you need to look again.

Making something portable might be a nice abstraction to you, but I
have lived and breathed it since I started doing Lisp standards work
in 1981.  I have been employed to do it sometimes, and sometimes I
have spent my own money, and sometimes I have spent my own money even
in cash-tight times like right now when I didn't have a job.
Something I've spent a good deal of my career learning about is "what
it takes to forge technical cooperation between individuals,
companies, and countries", and I can tell you it is not easy, not
cheap, and not something that just happens, nor is it something that
if one person or organization does unilaterally, they are assured of
anything other than getting taken advantage of or trampled.  It's
great when they do it, and we who are (sometimes) on the inside often
encourage them to do things that are cooperative, but sometimes (ok,
often) it is shot down for very legitimate business reasons that can't
be glossed over or treated as obstructionist.  They have to be
confronted and addressed one by one as resources permit.

I'll leave it to the vendors to say what kind of commitments they will
and won't make, but I'll say I think it's an unreasonable kind of
commitment to demand in the way you have because the community just
isn't big enough that someone can wave a wand and make it change.
Maybe back in the 1980's before AI winter when there was enough cash
to do things like that, but the fact o the cash meant no one realized
it was needed then.  We all learned a lot from the cash shortfall that
followed, but until we have another boom of cash, or until the careful
investment that's being done by vendors leaves things cushy enough
that risks can be taken, it's still hard to wave a wand and fix
everything.

(Of course, you could take the attitude that the companies don't
matter, and that they should just sacrifice themselves to the cause of
creating a world that doesn't need companies.  But look even at FSF.
They have a very popular product, but they're cash poor because
they've bred a group of people who think they can get free things and
who don't fund it to the level of the benefit they receive.  Some
thanks for a job well done.  No wonder other vendors don't aspire to
the model of "success".)

> Let me just remind readers of a couple of the reasons that Java has
> become so popular: It provides *lots* of basic functionality that is
> at the same time very portable.The above is not to suggest in any
> way that I consider Java a superior language to Common Lisp, but
> rather that the functionality and portability of Java make this
> language a more attractive option in many cases *in spite* of the
> fact that it is not as powerful or expressive a language as Common
> Lisp.

Do you REALLY think that this is what made Java succeed?

I think it's because Java had Sun's name behind it, and especially
because it had Sun's money.  Those things enabled the other things
you're talking about, not vice versa.  It doesn't mean it wasn't
a desirable outcome, but one has to be clear on the causality of
what it takes to create a certain marketplace vs what it takes to
sustain it.

I'm sure Sun didn't just magically find that they made something
portable and it was suddenly widely available. I bet they had to
invest really a lot and take a lot of risk.  Not that that's bad.  But
I find it hard to criticize someone for not taking a risk.  Risk is,
by its nature, uh, risky.  It's a personal decision what risk to take,
and even those of us who take risks don't always take the same ones.
One sometimes has to play certain things safe so they can live to
gamble another day.

> Vendors should decide whether they want Common Lisp to be another
> Smalltalk - closed, proprietary, not very portable *, or very
> expensive if portable and with a correspondingly small market share
> - or another Java, very portable, lots of built in functionality,
> relatively inexpensive, and with a correspondingly large market
> share. I'll warn them though, that I, like many users, will not be
> using Common Lisp much in the future if the decision looks more like
> the former than the latter.

That is, of course, your right.  But if you follow through on this,
and the market falls, I think you should consider yourself as much
responsible for what comes of Lisp as any vendor.

If you think it's so easy to make a working marketplace, you're
welcome to try, of course.  But if the problem is that you don't
think you'll make a quick million, or that you don't have the
short term cash to get you to the millions farther out, maybe
you're closer to understanding the issue than you think.
From: Hannu Koivisto
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <t2wsofwd2fz.fsf@lehtori.cc.tut.fi>
Kent M Pitman <······@world.std.com> writes:

| > Let me just remind readers of a couple of the reasons that Java has
| > become so popular: It provides *lots* of basic functionality that is
| > at the same time very portable.The above is not to suggest in any
| > way that I consider Java a superior language to Common Lisp, but
| > rather that the functionality and portability of Java make this
| > language a more attractive option in many cases *in spite* of the
| > fact that it is not as powerful or expressive a language as Common
| > Lisp.
| 
| Do you REALLY think that this is what made Java succeed?

FWIW, I think what Raffael said makes sense. I don't know much
about Java's history and why different people are using it, so I
am really not in a position to even think why Java succeeded,
but what I do know is why Java _could_ succeed for _me_. And
that reason is exactly what Raffael reminded us of. Perhaps that
is not the real reason why Java has succeeded among the masses
but it could be.

Just look at Python. It's a good example of a
language/implementation that has a _huge_ amount of basic
functionality, including interfaces to libraries such as OpenGL,
and is portable. From what I know Java and its libraries (which
is, I admit, very little) it seems to me Python is even stronger
than Java in this respect. Perhaps I have just had a good luck,
but for every "I wonder if Python has xyz so I can use it
instead of coding my own" thought the answer has been "yes".

Even Python hasn't been marketed with Sun's forces and it's more
like a scripting language than a "real" language like Java, it
has gained quite a bit of momentum. I learned Python a long time
before I started to make myself more familiar with CL, just
because I had programs to write and friends of mine that already
knew Python told that with it I could write them very easily.
And I did. Nowadays probably >60% of my programmer friends have
written at least something in Python, but none of them knows CL
(which is sad). Although I'm currently working towards the goal
of being able to use CL/Scheme for most if not all my
programming tasks, I still occasionally use Python if I really
need to get something done rapidly and it is not speed critical.

//Hannu
From: Pierre Mai
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <87emrgz6qa.fsf@dent.isdn.cs.tu-berlin.de>
Hannu Koivisto <·····@iki.fi.ns> writes:

> Just look at Python. It's a good example of a
> language/implementation that has a _huge_ amount of basic
> functionality, including interfaces to libraries such as OpenGL,
> and is portable. From what I know Java and its libraries (which

Exactly.  And who has written all of these libraries and interfaces?
Was it some sort of vendor?  No, most of the Python (or Perl, or tcl)
goodies that are there were written by _USERS_ and put out on the net
with a liberal licence.  The first implementations of most libraries
weren't even very good, or very portable for that matter (consider OS
portability here, not implementation portability, since there exist
only 1 or 2 current implementations of each).  But the USERS thought
that instead of keeping their quick hacks to themselves, they could
just as well put them on the net for others to use and enhance.  And
this happened, and *THAT IS WHY THERE ARE SO MANY GOODIES FOR PYTHON
AND CO*.

So instead of whining that there is no portable regexp package, take
one of those that are available on CMU and make it better and more
portable.  Or start from scratch.  Writing a RegExp package is no
rocket science anymore, especially with all the free implementations
out there, where gleaning algorithms from is easy.

BTW:  I don't consider RegExps that essential.  If you have a nice
set of string-handling functions, and some sort of lexer/parser
building machinery (e.g. monadic parsers in functional languages),
you won't use RegExps that much anymore.  The problem with RegExps is
that they are an incompatible sub-language with very bad interfaces to 
the host language, which makes semantic processing quite inelegant.

But this has been discussed here to abandon, so I'll leave it at that, 
and get back to writing something I can give to the CL community.

Regs, Pierre.

-- 
Pierre Mai <····@acm.org>               http://home.pages.de/~trillian/
  "One smaller motivation which, in part, stems from altruism is Microsoft-
   bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <71vtjt$rl$1@spitting-spider.aracnet.com>
In article <···············@world.std.com>,
	Kent M Pitman <······@world.std.com> writes:
> ·······@mediaone.net (Raffael Cavallaro) writes:
> 
>> I think this is the key point from a user perspective. All the
>> vendors win when *basic* functionality is portable across
>> implementations, because that makes Common Lisp a more attractive
>> option when deciding what to use for a given project.
> 
> This seems to me a completely unfair summation of the vendor
> situation, and gives new (and somehow appropriate) meaning to the
> subject line of this thread.  The problem is not the long term, which
> is what you are addressing, but the short term.  It is not nearly so
> obvious that all vendors win in the short term if they do as you say.

  I believe that the problem is long term, not short term. In the short term,
I think both Franz and Harlequin can muddle along and survive in some form. It
may be as consulting firms peddling CL solutions. (This has always been my
impression of Harlequin's business anyway.) By concentrating solely on the
short term, I believe that they'll guarantee their failure in the long term.
As they lose customers one at a time, they'll become even more focused on
their remaining customers. They'll never have a chance to address why all of
the previous customers have left nor why they haven't gotten any new ones.

  I don't know what they can do, given the current circumstances, to break the
cycle. I do believe that their current strategy does spell doom for them as CL
vendors.


> I'll leave it to the vendors to say what kind of commitments they will
> and won't make, but I'll say I think it's an unreasonable kind of
> commitment to demand in the way you have because the community just
> isn't big enough that someone can wave a wand and make it change.

  But something has got to change. It appears to me that the CL market keeps
getting smaller and smaller. 

> (Of course, you could take the attitude that the companies don't
> matter, ...)

  Nope, I don't think that. I like to get paid too. I just wish I could get
paid for doing CL work instead of this other junk.

>> Let me just remind readers of a couple of the reasons that Java has
>> become so popular: It provides *lots* of basic functionality that is
>> at the same time very portable.The above is not to suggest in any
>> way that I consider Java a superior language to Common Lisp, but
>> rather that the functionality and portability of Java make this
>> language a more attractive option in many cases *in spite* of the
>> fact that it is not as powerful or expressive a language as Common
>> Lisp.
> 
> Do you REALLY think that this is what made Java succeed?

  I think it was because Sun claimed it would solve some of the pressing
problems that management has with the software developement process, namely
the problem of dealing with all of the incompatible platforms out there. (Note
I'm not claiming that it actually solves that problem just that's what "sold"
it.)

>> Vendors should decide whether they want Common Lisp to be another
>> Smalltalk - closed, proprietary, not very portable *, or very
>> expensive if portable and with a correspondingly small market share
>> - or another Java, very portable, lots of built in functionality,
>> relatively inexpensive, and with a correspondingly large market
>> share. I'll warn them though, that I, like many users, will not be
>> using Common Lisp much in the future if the decision looks more like
>> the former than the latter.
> 
> That is, of course, your right.  But if you follow through on this,
> and the market falls, I think you should consider yourself as much
> responsible for what comes of Lisp as any vendor.

  I can't honestly recommend CL to my management at this point in time. None
of the commercial CL implementations offer enough value in solving my
company's problems. It has great potential to do so but I have little hope left
that that potential will be realized. Until vendors can convince me and my
management that there is hope, I can't help solve their problem, namely money.
This leads us into the current downward spiral with no easy way out.

  Mike McDonald
  ·······@mikemac.com
From: David Steuber "The Interloper
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3648acf0.449579280@news.newsguy.com>
On 6 Nov 1998 22:35:41 GMT, ·······@mikemac.com (Mike McDonald)
claimed or asked:

%   I can't honestly recommend CL to my management at this point in time. None
% of the commercial CL implementations offer enough value in solving my
% company's problems. It has great potential to do so but I have little hope left
% that that potential will be realized. Until vendors can convince me and my
% management that there is hope, I can't help solve their problem, namely money.
% This leads us into the current downward spiral with no easy way out.

I am in a similar situation.  However, that is not stopping me from
playing with Lisp on the side with the end goal of creating my own
product.  But then I don't have much of a life, so I can put some of
my spare time into programming outside of work.

I have a dream that I might be able to start my own company someday.
Then I will be my own management and I will be able to dictate what
tools are used.  I know that my chances of success are one in a
million, but that isn't going to deter me from trying when the
potential reward is so great.

--
David Steuber (ver 1.31.2a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

"Ignore reality there's nothing you can do about it..."
-- Natalie Imbruglia "Don't you think?"
From: Raffael Cavallaro
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <raffael-0611981335170001@raffaele.ne.mediaone.net>
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:

>Do you REALLY think that this is what made Java succeed?
>
>I think it's because Java had Sun's name behind it, and especially
>because it had Sun's money.  Those things enabled the other things
>you're talking about, not vice versa.  It doesn't mean it wasn't
>a desirable outcome, but one has to be clear on the causality of
>what it takes to create a certain marketplace vs what it takes to
>sustain it.

I'm sorry if it sounded like I'm blaming the Lisp vendors for their
current market situation. To a certain extent, everyone was blindsided by
Java.

However, what Sun has done with Java, (and yes, they were able to do it
because they threw money at it) , for better or worse, is now where the
bar is set for development tools. We can't undo this.

Yes, Lisp vendors need to protect their short-term revenue position, but
this is also a trap for them. Remaining relatively proprietary and
expensive when there are less expensive and more portable alternatives
keeps them in a downward spiral. How can they break out of it? I'm not
sure, but one option might be the sort of thing that Object Arts is doing
with Dolphin Smalltalk, and that Harlequin is doing with the free
LispWorks for Windows PE. However, these free-to-explore/pay-to-deploy
environments still fall short of Java portability. It is this aspect of
competing with Java that I was attempting to address in my post.

Again, if this sounds "unfair" to the vendors, it is not because I am
making unfair demands of them, but because the existence of a Java
alternative puts a heavy burden on them. If this burden seems "unfair" it
is the reality of the development tools market that is "unfair", or Sun
that is "unfair", but not the individual user (like myself) who correctly
recognizes that s/he is not in a position to redefine the state of play in
these markets. The Lisp vendors *are* in a position to redefine the state
of play in these markets, and I believe they should do so with the
explicit recognition that their real competition is not other Lisp
vendors, but Sun's more portable, less expensive Java.

I suspect that unless the Lisp vendors move in the direction I've
suggested, they will soon be out of business (or all but one will soon be
out of business). Time will tell if I'm completely out of line here or
not.

Raf

-- 
Raffael Cavallaro
From: Kent M Pitman
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <sfwn264z0uw.fsf@world.std.com>
·······@mediaone.net (Raffael Cavallaro) writes:

> Yes, Lisp vendors need to protect their short-term revenue position, but
> this is also a trap for them.

To the extent that it is, its a no win situation.  No vendor doesn't
know what you're suggesting.  But no matter how much you tell a bum on
the street that he really needs a Harvard education, you aren't going
to get him to invest in his future that way.  People and companies do
pull themselves up from the depths, but not always at the rate some
might wish.

> Again, if this sounds "unfair" to the vendors, it is not because I am
> making unfair demands of them, but because the existence of a Java
> alternative puts a heavy burden on them.

No, it is not unfair.  It is just unrealistic.  If what you're waiting
for is for Lisp to suddenly "get aware" in the sense you say, it just
isn't going to happen, or it has already happened.  The bum on the
street isn't going to disagree with you about the Harvard thing--he's
going to ask you when you're going to sign the check.  And your saying
you'll take a hike is saying he's out of luck.  It is certainly your
option, but criticizing him for doing what he is forced to is not
realistic.  It may be a great spectator sport, depending on your
personal taste in observing pain, but it's not going to get you from
point A to point B.

> The Lisp vendors *are* in a position to redefine the state
> of play in these markets,

So you say.  I claim this is an unsupportable claim that you make
without evidence.  If you think they are in such a position, you could
show it by becoming one and showing how well it works.

In general, in fact, if you have a surefire plan to make any market
win, Lisp or not, I recommend you drop whatever you are doing and 
pursue it, because there aren't very many people who have such
valuable knowledge about the future and about the behavior of others,
and such certainty of foreknowledge ought not be squandered.

 >and I believe they should do so with the
> explicit recognition that their real competition is not other Lisp
> vendors, but Sun's more portable, less expensive Java.

All of the vendors made this observation long ago.  Long before Java.
When there was only C.  The vendors are remarkably polite to one
another these days compared to the olden days, and partly because
sometime in the late 80's we realized our common "enemy" (to put it in
such terms) was not each other but other languages.  All of that said,
though, that does not mean they suddenly have the resources to do what
you suggest.  What you don't seem to understand is that there is a
difference between an available, free, portable technology and a
"product".  If you ask a customer to use something, you have to have
the legal rights to distribute it, it has to be documented, it has to
be tested, you have to be able to understand and maintain it.  And in
some cases it is more work to accept a free thing from the outside
than to build it from scratch.  Further, in some cases when you accept
the free thing it takes on an identity internally and people (either
the vendor or customers) start asking for features and reporting bugs
that you may or may not be able to get the original maintainer to
accept.  So things diverge.  And after you've been burned by this a
few times, you get more cautious about it because it is simply not a
panacea.  There are any of a number of free technologies, and CL-HTTP
is an absolutely terrific example, that are extraordinarily hard to
just incorporate into product much though one might wish to do so.
User can create trade in free software, but vendors must do what is
needed to support those customers who are paying for things, and
that's not always the same.  The reason Sun could do what it does is
almost surely (I haven't checked, I'm just speculating) that it
employs people who have no job but to track what's going on, to
promote standard things, to interact with people to make sure they
follow guidelines, to publish manuals on how to keep things in proper
line, etc.  That is a LOT of mechanism to expend and I bet the money
Sun spent on componentware is more than all Lisp companies together
spend on their entire Lisp product line (though I don't have any
numbers to back that up--it's just a guess).

> I suspect that unless the Lisp vendors move in the direction I've
> suggested, they will soon be out of business (or all but one will soon be
> out of business). Time will tell if I'm completely out of line here or
> not.

Although you are certainly right that there's some threat here, I
suspect the bigger threat is negativism.  The situation is really not
that bad.  Lisp supplies a very small market but it is a market that
is very well served by what offers.  Gradually, the vendors are coming
to understand and articulate the value they provide.  Gradually, the
vendors are starting to add specific value that broadens their market.
Lisp is not going to make its way back overnight.  But the thing
that's most likely to hurt it is either some crazy scheme to get rich
overnight or some naysaying user convincing everyone to jump ship when
things are in a fine stable state, thus upsetting a delicate cash flow
situation and producing the exact panic they're predicting.  At that
point, they/you may sit back smugly smiling at how right your
prediction is, but the same could be said of any stock market broker
who recently predicted a sudden bear market... some part predictive,
some part causal.

This will be my last response to you on this topic.  I have said
what I have to say, and you either understand me or you don't.  But
I don't need to repeat myself further.
From: Raffael Cavallaro
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <raffael-0811980039020001@raffaele.ne.mediaone.net>
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:

>But the thing
>that's most likely to hurt it is either some crazy scheme to get rich
>overnight or some naysaying user convincing everyone to jump ship when
>things are in a fine stable state, thus upsetting a delicate cash flow
>situation and producing the exact panic they're predicting.

Well when the boosters compare Lisp vendors to a bum on the street, we
don't really need naysaying users, do we. ; )

Seriously though, I'm not jumping ship. Rather, I was trying to suggest
things that might attract more users to get on board. Kent, I realize you
don't want to continue this discussion, so there's no need to reply.

I'm sorry if my suggestions upset anyone, especially Kent, who, I'm sure
we'll all agree, has been an invaluable resource here on comp.lang.lisp.
He deserves all our gratitude. I also feel I speak for everyone here when
I wish him the best of luck in whatever direction he decides to take his
career.

Raf

-- 
Raffael Cavallaro
From: David Steuber "The Interloper
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3647a338.447091313@news.newsguy.com>
On Fri, 06 Nov 1998 13:35:17 -0500, ·······@mediaone.net (Raffael
Cavallaro) claimed or asked:

% I suspect that unless the Lisp vendors move in the direction I've
% suggested, they will soon be out of business (or all but one will soon be
% out of business). Time will tell if I'm completely out of line here or
% not.

I don't think the Lisp vendors have the power to make Lisp more
popular.  There are several things working against Lisp, IMHO.

1) Parenthesis.  The Lisp syntax looks really strange and intimidating
to many people.  I think most of these people are not willing to look
past that.

2) C++.  This language got a huge mindshare.  Everyone thought it was
the silver bullet that would make the design of large, complex systems
manageable by anyone.

3) VB.  You don't even have to know how to program to do things in
this language.  When you do know how to program, you can create some
pretty neat stuff that will run in windows.

4) Java.  For some reason, toy applets in web pages made this language
a huge success.  At the moment, Java is mostly gas.  However, it has a
bandwagon, so everyone is jumping on it.

5) AI.  For some reason, AI seems to be the only field where the use
of Lisp is promoted.  Graham's "ANSI Common Lisp" is part of a series
on AI programming.  Maybe it is heretical that I am planing to use
Lisp for a non AI application.

The impression I get is that the Lisp community is very small and not
growing.  Not enough people are evangelizing the language.  It is not
enough to say Lisp can do this or that.  High profile programs have to
be written in Lisp.  They also have to be paragons of good
applications.  It should also be clear that they were written in Lisp.
Without them, Lisp is some obscure language that white coats use.
And, no, Emacs is not enough.

Lisp will only be taken seriously when a large number of programmers
see how powerful it is.  I think that the larger part of the
programmer community has been stupefied by Microsoft.  They wouldn't
consider Lisp unless Microsoft came out with their own flavor.  I'm
sure Microsoft would ruin it.

In the end, it is the _users_ of Lisp who are responsible for its
future.  The vendors will deliver what the users ask for, so long as
they get paid.  If the free Lisps are in any way inferior to the
commercial Lisps, it is because they don't have enough users
contributing improvements.

If you want the number of Lisp users to increase proportionately
faster than users of other languages, it is necessary to teach people
Lisp in high school and college.  Show them the power of Lisp so that
when they look at other languages, they feel stifled.  Teach them good
Lisp programming techniques so that they become good programmers.
People are not really getting dumber.  It is possible to teach people
how to analyze problems.  Teach the analysis from a Lisp perspective
and that will be the language they will want to think in.  They will
then find other languages inadequate to the task.  That is unless Lisp
is really not all it is cracked up to be.

Another thing to do is to contribute code to Lisp archives.  Look at
Perl with its CPAN.  Perl is a language that is not driven by any
corporate entity.  There isn't even a standard for it so far as I
know.  It is driven by the user community.  Lisp needs the same
support.  If it doesn't get it, then natural selection will kill it.

I am only one person.  I will do what I can do.  The CMUCL maintainers
are a small group.  I think they are doing a bang up job.  Follow
their example.  Whining won't help.  If you aren't putting anything
back in the form of code or cash, then you aren't really helping.
Well, the exception to that rule would be releasing applications that
use Lisp and say so.

Mindshare is everything.

--
David Steuber (ver 1.31.2a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

"Ignore reality there's nothing you can do about it..."
-- Natalie Imbruglia "Don't you think?"
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3119450241710355@naggum.no>
* ········@david-steuber.com (David Steuber "The Interloper")
| The impression I get is that the Lisp community is very small and not
| growing.

  my impression is that is dispersed, and like water in its gas stage all
  around us, the individual molecules don't precipitate enough even to form
  a visible mist, but it's there for anyone to see if they want to.

| Not enough people are evangelizing the language.

  well, once there were much too many, and that led to what several people
  refer to as the "AI Winter".  languages flare up and die with too much
  evangelization and hype.  I don't want Lisp to flare up because I know
  that will kill it.  what the world needs least of all is for all the
  amazingly incompetent people who make up the giant market for Microsofts
  languages and products to start using Common Lisp.  if that is in danger
  of happening, I want somebody to rename it Elite Lisp so as not to
  confuse anybody.
  
| It is not enough to say Lisp can do this or that.  High profile programs
| have to be written in Lisp.

  I succeeded in bringing Common Lisp to a client who needed very high
  uptime and who could not get it with the existing C-based system.  this
  is _not_ a high profile project.  it is still a success, both for me and
  for them.

| Lisp will only be taken seriously when a large number of programmers
| see how powerful it is.

  it is already taken seriously -- by some, and they are a relevant number
  of people, despite your implication.  to imply that Lisp is not taken
  seriously, as you do, is a huge disservice to the community and works
  against your own goals.  don't be stupid -- don't understate your case.

| I think that the larger part of the programmer community has been
| stupefied by Microsoft.  They wouldn't consider Lisp unless Microsoft
| came out with their own flavor.  I'm sure Microsoft would ruin it.

  Microsoft isn't everything, and they'll be history shortly, anyway.

| In the end, it is the _users_ of Lisp who are responsible for its future.

  yeah, and what helps is to buy yet another commercial license, not fight
  the vendors with yet another inferior-but-getting-better free version.

| The vendors will deliver what the users ask for, so long as they get
| paid.  If the free Lisps are in any way inferior to the commercial Lisps,
| it is because they don't have enough users contributing improvements.

  trivially, yes, but that is not the causal link you would want to work
  on.  the free Lisps are inferior because it takes tremendous effort to
  create truly high quality software, and you don't get people to do that
  day in and day out without serious compensation _and_ motivation.

| Another thing to do is to contribute code to Lisp archives.

  well, actually, what is needed is a desire to use other people's code
  instead of writing your own.

| Look at Perl with its CPAN.  Perl is a language that is not driven by any
| corporate entity.  There isn't even a standard for it so far as I know.
| It is driven by the user community.  Lisp needs the same support.

| If it doesn't get it, then natural selection will kill it.

  so according to yet another misplaced application of the theory of
  evolution, Lisp should already have died.  if living, breathing systems
  do not convince you that Lisp is alive, what would it take to make you
  stop stating the greate exaggerated rumors of its death?

| Mindshare is everything.

  in my view, it matters more what is shared than sharing it.  for some odd
  reason that I cannot quite fathom, the people who whine about the future
  of Lisp think its dead, and the people who keep it alive _don't_ whine
  about its future at all.  can we please have the whiners stop sharing?

#:Erik
-- 
  The Microsoft Dating Program -- where do you want to crash tonight?
From: David Steuber "The Interloper
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <36524c01.5397621@news.newsguy.com>
On 07 Nov 1998 17:57:21 +0000, Erik Naggum <····@naggum.no> claimed or
asked:

% | Mindshare is everything.
% 
%   in my view, it matters more what is shared than sharing it.  for some odd
%   reason that I cannot quite fathom, the people who whine about the future
%   of Lisp think its dead, and the people who keep it alive _don't_ whine
%   about its future at all.  can we please have the whiners stop sharing?

Sorry for the belated reply.

I don't want to imply that Lisp is a dead or dying language.  If
anything I said is interpreted that way, then consider it retracted.

I think Lisp is an excellent language for the disciplined programmer
who wants to create complex software.

When I have the cash, I will probably consider a commercial Lisp.
There is no denying the truth that a group of paid engineers, working
full time, stand a better chance of building a better Lisp environment
than people scattered by time and space working in their free time.

Although, Linux is pretty good for a free OS.

--
David Steuber (ver 1.31.2a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

"Ignore reality there's nothing you can do about it..."
-- Natalie Imbruglia "Don't you think?"
From: Tim Bradshaw
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ey3iugtt9c3.fsf@todday.aiai.ed.ac.uk>
* Mike McDonald wrote:
>   Why? In just about every other industry, release cycles aren't synchronized
> either. But yet they manage to support "defacto standards".

In some industries they do, in some they fail.  For instance in
word-processor formats this has failed horribly with the `standard'
being entirely controlled by one vendor who can and does change it
regularly to force people to upgrade and fight off competition.  I
think there is a bunch of economic theory on when things like
standards can work.  It depends, at least, on the clients of the
standard (the `users') being more powerful than any vendor, so if a
vendor tries to do some gratuitously incompatible thing they just go
out of business.  That's noticeably not the case for WP formats, but it
probably could be for Lisp standards, if the users actually got their
act to together and did something.

--tim
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3119445949993822@naggum.no>
* ·······@mikemac.com (Mike McDonald)
| I'd go so far as to say most innovative things start out "proprietary".
| Afterall, most innovations start with one person and then, hopefully,
| spread.  Except if it's related to CL.  Then everyone will implement
| their own incompatible version.

  amazing.  you appear not to know any history _but_ that of CL.  the Unix
  world has been under (well-deserved) attack for as long as it has existed
  for precisely this problem.  I lecture on the history of Unix, and do
  some quantitative research just for fun, and on last count, there had
  been more than 50 incompatible regexp pattern matching libraries for Unix
  and C by its 25th anniversary.  today, there are 6 widely used libraries,
  all seriously incompatible both in syntax and in calling conventions.

| Why?  In just about every other industry, release cycles aren't
| synchronized either.  But yet they manage to support "defacto standards".

  in actuality, they don't.  you just don't know them from the inside.

| In this case, all Franz would have to do is release the one source file
| under somethng like a GPL copyright.  (Scanning thru the symbols, it
| looks like it's all defined in regexp.cl.)  Then Harlequin, Digitool,
| CMUCL, CLISP, and users can all pick it up.  That's one problem solved.
| But they won't, so they must think it gives them some great competitive
| edge.

  would you stop complaining if they did?  would you demand support for
  your favorite regexp feature?  would you require Franz Inc to support
  other vendor's Lisp systems?  what would happen if one vendor decided to
  make an enhancement to the public source?  etc.  maybe it just costs too
  much to give something away.

| This is NOT early design stuff.  Crap, in 10 days we're celebrating the
| 40th anniversary of Lisp!  And we can't even get regexp

  so if you can't eat _just_ what you want, you'd rather starve?

| Standards committees are no place for end users, especially not
| individuals.

  you know not at all of what you speak.  in all the standards committees I
  have worked with through the years (eleven all told), end users have held
  the majority.  in six of them, the number of concerned individuals have
  outnumbered the vendors, too.

| The time and money it takes to participate is beyond the reach of most
| users.

  ok, so I'm not "most users", but it is _easily_ within reach for most
  professionals and there is usually somebody who can sponsor you if you
  ask them nicely.  it should not be a particularly hard job, either,
  unless you are the only user in a fairly large geographical area.

| We seem to have the chicken and egg problem.  The vendors won't agree to
| anything until it's blessed by X3J13.  But X3J13 won't bless anything
| until the members, aka the vendors, agree.  Stalemate!

  I see no evidence of this being true.

#:Erik
-- 
  The Microsoft Dating Program -- where do you want to crash tonight?
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3119297904135739@naggum.no>
* ·······@mikemac.com (Mike McDonald)
| Is it included in CMUCL?  In MacCL?  In Harlequin's?  Proprietary
| solutions to basic functionality do the whole CL community a great
| disservice.

  yeah, verily.  if everybody can't have it for free, there should be a law
  against somebody getting it, _unfairly_.  the community above all!

  you give both communism and laziness a really bad name, Mike.  it's good
  to share innovations and build a strong foundation for oneself and the
  community one is part of, and it's good to have smart people do hard work
  so other smart people can do some _different_ hard work, but community
  welfare and getting away with laziness are _results_, not starting points
  from which you reduce everything else.

  incidentally, regular expressions are not part of _that_ many languages,
  but they are available as libraries from a number of sources, proprietary
  as well as publically available.  and nobody kept you from using a regexp
  library for C with your Lisp system or even writing your own.  but I know
  why you don't write something for yourself -- it would be proprietary to
  yourself and it would be a great disservice to the CL community if you
  just went ahead and created what you need, right?

#:Erik
-- 
  The Microsoft Dating Program -- where do you want to crash tonight?
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <71vhpt$akv$1@spitting-spider.aracnet.com>
In article <··············@eho.eaglets.com>,
	Sam Steingold <···@goems.com> writes:
>>>>> In message <················@naggum.no>
>>>>> On the subject of "Re: I don't understand Lisp"
>>>>> Sent on 05 Nov 1998 23:38:24 +0000
>>>>> Honorable Erik Naggum <····@naggum.no> writes:
> >> 
> >>   you give both communism and laziness a really bad name, Mike.
> 
> ROTFL.  Communism has such a bad name already - how can anyone do it any
> worse than it did to itself?  http://www.goems.com/~sds/commies.html
> 

  Hey, what can I say? Some of us are just talented! :-)

  Mike McDonald
  ·······@mikemac.com
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <71tiag$raj$1@spitting-spider.aracnet.com>
In article <················@naggum.no>,
	Erik Naggum <····@naggum.no> writes:
> * ·······@mikemac.com (Mike McDonald)
>| Is it included in CMUCL?  In MacCL?  In Harlequin's?  Proprietary
>| solutions to basic functionality do the whole CL community a great
>| disservice.
> 
>   yeah, verily.  if everybody can't have it for free, there should be a law
>   against somebody getting it, _unfairly_.  the community above all!

  If Franz, Harlequein, and Digitool included a compatible regexp package in
their commercial implementations, I'd be overjoyed. I have no requirement that
it be free. That'd be nice but it's not a requirement. Now, one way for it to
be included in all of those commercial implementations would be for Franz to
release it freely.

  This thread is about the lack of standardization of other useful features
for Common Lisp users. The fact that Franz has a proprietary solution to this
one feature doesn't solve the problem for Common Lisp in general.

>   you give both communism and laziness a really bad name, Mike.  it's good
>   to share innovations and build a strong foundation for oneself and the
>   community one is part of, and it's good to have smart people do hard work
>   so other smart people can do some _different_ hard work, 

  The CL communitee isn't building any such foundation. Hell, in the next
paragraph, you argue that each and every user should start from a clean slate
and reimplement everything themselves. That's a great way to build a "strong
foundation" for a communitee!

>   but community
>   welfare and getting away with laziness are _results_, not starting points
>   from which you reduce everything else.
> 
>   incidentally, regular expressions are not part of _that_ many languages,
>   but they are available as libraries from a number of sources, proprietary
>   as well as publically available.  and nobody kept you from using a regexp
>   library for C with your Lisp system or even writing your own.

  No, there's nothing keeping me from solving the regexp problem for myself.
But that does nothing for solving the problem for the communitee nor for
building that strong foundation.

>   but I know
>   why you don't write something for yourself -- it would be proprietary to
>   yourself and it would be a great disservice to the CL community if you
>   just went ahead and created what you need, right?

  If it's something that other members of the communitee also needed, then
YES, it would be a disservice. The sole purpose of standardization is to
provide that strong foundation on which other components can be built, thereby
making an even bigger and stronger foundation. I believe that the ANSI CL
standard alone, does not provide a sufficient foundation to build a vibrant,
active communitee on.

  Mike McDonald
  ·······@mikemac.com
From: Tim Bradshaw
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ey3g1bxt8r2.fsf@todday.aiai.ed.ac.uk>
* Mike McDonald wrote:

>   If Franz, Harlequein, and Digitool included a compatible regexp package in
> their commercial implementations, I'd be overjoyed. I have no
> requirement that it be free. That'd be nice but it's not a
> requirement. Now, one way for it to be included in all of those
> commercial implementations would be for Franz to release it freely.

*Only* if their implementation is portable to other Lisps.  I see no
reason at all why that should be the case.

--tim
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3119353141035087@naggum.no>
* ·······@mikemac.com (Mike McDonald)
| This thread is about the lack of standardization of other useful features
| for Common Lisp users.  The fact that Franz has a proprietary solution to
| this one feature doesn't solve the problem for Common Lisp in general.

  I think you failed to get the point that Franz Inc is not obligated to do
  that.  you, as a whining loser who wants something you "can't" get, have
  an obligation to put your money where your mouth is, and help create what
  you want to exist.  but you appear to believe that this constitutes a
  disservice to the community, so what the hell do you expect to happen?
  spontanous concensus without prior communication, and fully conforming
  implementations warping into existence everywhere at once out of nowhere?

| Hell, in the next paragraph, you argue that each and every user should
| start from a clean slate and reimplement everything themselves.

  really?  I think your reading comprehension needs a serious upgrade.

| If it's something that other members of the communitee also needed, then
| YES, it would be a disservice.

  right.  thank you for your candor in this matter.

#:Erik
-- 
  The Microsoft Dating Program -- where do you want to crash tonight?
From: Duane Rettig
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <4k918ivmr.fsf@beta.franz.com>
I get a chuckle from reading about "proprietary" and "regexp" in the
same context; of all of the packages in any Common Lisp system, this
one is the most available, and least proprietary, of all.  There are
probably many implementations of regexps, likely many have extensions,
but most of them are very similar and have the same roots.  Even the
ones that don't seem to share roots are similar enough to use without
very much reorientation.  For example, I remember back in the 80's
using regexps on HP RTE-4B systems, which were very similar to the Unix
ones.  I do not know of the exact origins of regexps, but perhaps some
historians in the group can enlighten us.

The key to using regexps in any language is to know where to look for
them; on Unix systems, the names are not obvious; see the man pages for
compile(3) and advance(3) on any Unix systems.

For a complete description of the regexp parser that we implement in CL,
grab ftp://ftp.franz.com/pub/regexp/regexp.n which is a plaintext
document.  I just spellchecked it and so it is recently modified, but
it has been around since the directory was created 1 1/2 years ago.  
Also in sub-directories of the same directory are compiled lisp files
for the implementation for 4.3, and if you download the free linux
version of ACL 5.0 for linux, you get regexp.fasl free.

The fact that we do not give out source code does not make it
proprietary, in the negative sense that it is being used here.
(In fact, IMHO, release of source code increases proprietorship
since it includes copyright notices and restrictions for use
and redistribution.)

·······@mikemac.com (Mike McDonald) writes:

> In article <················@naggum.no>,
> 	Erik Naggum <····@naggum.no> writes:
> > * ·······@mikemac.com (Mike McDonald)
> >| Is it included in CMUCL?  In MacCL?  In Harlequin's?  Proprietary
> >| solutions to basic functionality do the whole CL community a great
> >| disservice.
> > 
> >   yeah, verily.  if everybody can't have it for free, there should be a law
> >   against somebody getting it, _unfairly_.  the community above all!
> 
>   If Franz, Harlequein, and Digitool included a compatible regexp package in
> their commercial implementations, I'd be overjoyed. I have no requirement that
> it be free. That'd be nice but it's not a requirement. Now, one way for it to
> be included in all of those commercial implementations would be for Franz to
> release it freely.

I can only assume from your recent postings on this thread that one (or
more) of the following are true:

 1. You didn't realize how freely-available our regexp package is.

 2. You didn't realize how compatible it is to Regular Expressions
    definitions defined in Unix

 3. Your whole emphasis is on source-availability.

Is it one of these three, or is it something else?

>   This thread is about the lack of standardization of other useful features
> for Common Lisp users. The fact that Franz has a proprietary solution to this
> one feature doesn't solve the problem for Common Lisp in general.

This portion of this thread has centered around regexps.  If you
have a problem with Common Lisp that you want to solve in general,
Kent Pitman has made cogent arguments in this thread and others,
with which I believe many of us agree, regarding standards establishment
and maintenance; please make a specific proposal about what additions you
would like to see enhanced.  And it does nobody any good to say something
like "make regexp freely available", because that is not a standards issue,
it is an availability issue.

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Chuck Fry
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <71vicu$ia$1@shell5.ba.best.com>
In article <·············@beta.franz.com>,
Duane Rettig  <·····@franz.com> wrote:
>I get a chuckle from reading about "proprietary" and "regexp" in the
>same context; of all of the packages in any Common Lisp system, this
>one is the most available, and least proprietary, of all.  [...]

>The key to using regexps in any language is to know where to look for
>them; on Unix systems, the names are not obvious; see the man pages for
>compile(3) and advance(3) on any Unix systems.

>For a complete description of the regexp parser that we implement in CL,
>grab ftp://ftp.franz.com/pub/regexp/regexp.n which is a plaintext
>document.  [...]

>The fact that we do not give out source code does not make it
>proprietary, in the negative sense that it is being used here.
>(In fact, IMHO, release of source code increases proprietorship
>since it includes copyright notices and restrictions for use
>and redistribution.)

I can't fault Franz for not releasing the source code.  What they have
done might actually be more significant.  I would hope Franz's freely
documenting a regexp API and supporting that API in their own releases
is enough to encourage other implementations, including freely available
versions, of that API.

Thanks, Duane, for the pointers to the documentation, especially that of
the Unix regexp package.

 -- Chuck
-- 
	    Chuck Fry -- Jack of all trades, master of none
 ······@chucko.com (text only please)  ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <71vkoe$gpt$1@spitting-spider.aracnet.com>
In article <·············@beta.franz.com>,
	Duane Rettig <·····@franz.com> writes:

> The fact that we do not give out source code does not make it
> proprietary, in the negative sense that it is being used here.

  It sure does too! Until Harlequin and Digitool can load ACL fasl files, it
is proprietary to Franz.

> (In fact, IMHO, release of source code increases proprietorship
> since it includes copyright notices and restrictions for use
> and redistribution.)

  Please show me the stone that it's written in that you have to put those
restrictions on it. Since you own it, you can release it under any
conditions you like. It could be your standard "If you look at it, we own
your first born male child" or GPL or BSD or anything else you and your
lawyers can dream up. It's entirely your choice. (Unless you licensed the
implementation from someone else and the restrictions are their's. If so, just
say so.)

> Is it one of these three, or is it something else?

  Something else completely. I, as a USER, want to be able to write 
(match-regexp pattern line) in all of the (at least) commercial CLs and have
it work exactly the same. I want to be able to say (defforeign ...) in all of
them and have it work. I want to be able to say (make-thread ...) and have
that work too. Ideally, I'd like to never have to use #+ again! (I realize
that's probably a unattainable goal (but that's what Java promises to my
boss!) but I'd like to at least minimize its usage.)

>>   This thread is about the lack of standardization of other useful features
>> for Common Lisp users. The fact that Franz has a proprietary solution to this
>> one feature doesn't solve the problem for Common Lisp in general.
> 
> This portion of this thread has centered around regexps.  If you
> have a problem with Common Lisp that you want to solve in general,
> Kent Pitman has made cogent arguments in this thread and others,
> with which I believe many of us agree, regarding standards establishment
> and maintenance; please make a specific proposal about what additions you
> would like to see enhanced.  

  As Ken has pointed out, formal standardization is not about design, it's
about codifying commonly accepted practice. (I hope I'm not bastardizing
Ken's description of standards too much.) For the CL vendors to say they can't
do anything in agreement without first having it blessed by X3J13 is a cop
out! 

> And it does nobody any good to say something
> like "make regexp freely available", because that is not a standards issue,
> it is an availability issue.

  Regexp is just being used as an example because ·····@franz.com threw out a
Franz only implemention as a solution to a more general Common Lisp problem,
ie the lack of compatibility and availability of basic functionality expected
by users in a modern software environment. It has nothing to do with formal
standardization. That would follow naturally if the three big CL vendors would
agree on these basic interfaces.  

  I'd like to reiterate what Raffael Cavallaro said. The CL vendors are not
competing with each other for mind share or sales. You are competing with C,
C++, Java, VB, Perl, Tcl, ... Unless the CL vendors wake up soon and recognize
the real competition, CL is in big trouble.

  Mike McDonald
  ·······@mikemac.com
From: Craig Brozefsky
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <87u30cy7z2.fsf@duomo.pukka.org>
Duane Rettig <·····@franz.com> writes:

> The fact that we do not give out source code does not make it
> proprietary, in the negative sense that it is being used here.
> (In fact, IMHO, release of source code increases proprietorship
> since it includes copyright notices and restrictions for use
> and redistribution.)

That parenthetical statement is a rationalizing crock of shit.  It's
alot easier to relax the restrictions on redistribution, modification
and use when they are a few sentence of legalese, than when those
restrictions are due to nonportable bytecode, and lack of a human
readable representation for bug fixing and modification.  Also, binary
distribution is just as capable of carrying restirctions on use and
redistribution, like the "free" linux version of ACL does.

Now please don't extrapolate from my calling you on that statement,
that somehow I hate lisp vendors and think that they, and everyone
else, should give me stuff for free.  If anything, my position towards
lisp vendors and the commercial segment of the lisp community is
ambivalence, but then again that's just my relation to the commercial
sector of any segment of the computer industry.  I understand that
they have business needs to meet, and that monetary concerns are very
important in their decision making process because they have investors
to keep happy, and more importantly, employees to feed.  At the same
time, it's important to remember that the reality of the lisp vendors
is not the only one in the lisp community.
From: Duane Rettig
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <4iugsik22.fsf@beta.franz.com>
Craig Brozefsky <·····@onshore.com> writes:

> Duane Rettig <·····@franz.com> writes:
> 
> > The fact that we do not give out source code does not make it
> > proprietary, in the negative sense that it is being used here.
> > (In fact, IMHO, release of source code increases proprietorship
> > since it includes copyright notices and restrictions for use
> > and redistribution.)
> 
> That parenthetical statement is a rationalizing crock of shit.  It's
> alot easier to relax the restrictions on redistribution, modification
> and use when they are a few sentence of legalese, than when those
> restrictions are due to nonportable bytecode, and lack of a human
> readable representation for bug fixing and modification.  Also, binary
> distribution is just as capable of carrying restirctions on use and
> redistribution, like the "free" linux version of ACL does.

Thank you for your input.  Our intentions at Franz, Inc. are to make
software available to the user community that would not otherwise
have been available.  We feel that the CL community is enhanced by
such actions.

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3119452017993412@naggum.no>
* Craig Brozefsky <·····@onshore.com>
| That parenthetical statement is a rationalizing crock of shit.  It's
| alot easier to relax the restrictions on redistribution, modification
| and use when they are a few sentence of legalese, than when those
| restrictions are due to nonportable bytecode, and lack of a human
| readable representation for bug fixing and modification.

  you might not be aware that paying customers of Franz Inc get a lot of
  source code with their support agreement.  regexp.cl is in there, and you
  can fix bugs and modify it.  if you plan on distributing an application
  with the changed version, you are probably "a few sentences of legalese"
  away from doing that -- I haven't needed to, so don't know for certain.

| Also, binary distribution is just as capable of carrying restirctions on
| use and redistribution, like the "free" linux version of ACL does.

  I'm puzzled.  what would it take for you to unquote "free"?  how does
  your quoting "free" here relate to your lack of appreciation for the
  point that source code once read is a serious liability to writing your
  own, independent version?  the "Free" Software Foundation is very adamant
  that people not even look at non-free source code when duplicating the
  functionality.  in the strictest legal sense, giving you source code that
  is not freely redistributable _does_ reduce your ability to talk about
  the problems the source code you have read solves, since you are no
  longer as free to share particulars of your experience and understanding.
  please try to understand that source availability is not itself the
  panacea it is cracked up to be -- it is the _redistributability_ that is
  responsible for the visible benefits of source availability.

#:Erik
-- 
  The Microsoft Dating Program -- where do you want to crash tonight?
From: Craig Brozefsky
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <877lx7xoxj.fsf@duomo.pukka.org>
Erik Naggum <····@naggum.no> writes:

> * Craig Brozefsky <·····@onshore.com>
> | That parenthetical statement is a rationalizing crock of shit.  It's
> | alot easier to relax the restrictions on redistribution, modification
> | and use when they are a few sentence of legalese, than when those
> | restrictions are due to nonportable bytecode, and lack of a human
> | readable representation for bug fixing and modification.
> 
>   you might not be aware that paying customers of Franz Inc get a lot of
>   source code with their support agreement.  regexp.cl is in there, and you
>   can fix bugs and modify it.  if you plan on distributing an application
>   with the changed version, you are probably "a few sentences of legalese"
>   away from doing that -- I haven't needed to, so don't know for certain.

No, since I'm not a paying customer of Franz, I was not aware of that.
That does not change my opinion that his statement about source
distribution is a rationalizing crock of shit, that opinion in turn
does not change my opinion that he and Franz rock pretty hard.  I have
no problem with Franz and their choice of distribution rights, but I
would just like to be spared the speciousness.

> | Also, binary distribution is just as capable of carrying restrictions on
> | use and redistribution, like the "free" linux version of ACL does.
> 
>   I'm puzzled.  what would it take for you to unquote "free"?  how does
>   your quoting "free" here relate to your lack of appreciation for the
>   point that source code once read is a serious liability to writing your
>   own, independent version?

I quote free because the distribution is only available for
non-commercial use, does not come with redistribution/modification
rights.  This is not something I despise Franz for, or demonize them
for, because it is truly their choice of how to distribute it.  The
quotation of "free" has more to do with redistribution/modification
and unlimited usage rights.  So I would say it has nothing to do with
my understanding, lacking or otherwise, of non-disclosure agreements
and copyright issues of source code.

>   the "Free" Software Foundation is very adamant that people not
>   even look at non-free source code when duplicating the
>   functionality.  in the strictest legal sense, giving you source
>   code that is not freely redistributable _does_ reduce your ability
>   to talk about the problems the source code you have read solves,
>   since you are no longer as free to share particulars of your
>   experience and understanding.

Unless I sign an NDA, there is no problem with me talking about the
source code, or even referring to it within the bounds of fair use.  If
written materials worked this way than I could only talk to you about
Vineland after you had bought the book, and couldn't put a nifty one
liner from it in my .sig without getting sued.  If you publish source
code, you expect people to read it, you don't expect them to copy it
tho.  There is quite a difference between talking about and discussing
a published work, and copying it.

I think the fact that you had to use the phrase "in the strictest legal
sense" is enough evidence that your stretching to the point where
you've ripped the ass out of your pants.

>   please try to understand that source availability is not itself the
>   panacea it is cracked up to be -- it is the _redistributability_ that is
>   responsible for the visible benefits of source availability.

Agreed, but I would amend it by saying that it's redistribution of
modifications that is responsible for the benefits.

Unless there are some new ground breaking theories in intellectual
property or whatever, could we bring this to a close.  I've got coding
to do.
From: Steve Gonedes
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <m21znevphg.fsf@KludgeUnix.com>
Craig Brozefsky <·····@onshore.com> writes:

< No, since I'm not a paying customer of Franz, I was not aware of that.

Why did you say this?

Maybe you're like me an just post stupid stuff without thinking it
through fully and are too embarrassed to correct the mistake because
you don't want to draw more attention to it?

Otherwise, I just don't know how to respond.

< I quote free because the distribution is only available for
< non-commercial use, does not come with redistribution/modification
< rights.  This is not something I despise Franz for, or demonize them
< for, because it is truly their choice of how to distribute it.  The
< quotation of "free" has more to do with redistribution/modification
< and unlimited usage rights.  So I would say it has nothing to do with
< my understanding, lacking or otherwise, of non-disclosure agreements
< and copyright issues of source code.

Where did you get this information - that being acl for linux is not
redistibutable and not allowed to be used "commercially"? What do you
mean by commercial? Did you talk to a Franz represenative or are you
just mumbling nonsence?

So you are implying that in order for the mentioned product to meet
your definition of free you want the right to download their program
at no monetary cost (which is currently available thanks to some very
nice and dedicated people) and then just sell it to someone else? This
is not fair, illogical, inconsiderate, frightening, and least
important; it is not a realistic option for our world - welcome to the
phantasy.

This is the first paragraph and first sentence of the license I got
with my acl for linux. I don't know what you would consider to be
liberal in respects to license agreements - and I am no lawyer so
maybe I am misunderstanding something. I believe that the license is
rather honost - maybe this is new to you?


License Agreement GL01-1039-0898

General Preamble:
-----------------

Allegro CL 5.0 Trial Edition for Linux ("Linux Version") is not
shareware, it is freeware subject to certain restrictions, and
published as a community service. Giving this Linux Version away for
free encourages more people to use it, and encourages the use of
Dynamic Object Oriented Programming. Feel free to disseminate the
complete unmodified Linux Version release package as widely as
possible. Give it to all your friends. You may post it on any web site
or electronic bulletin board.

However, commercial use of Allegro CL 5.0 Trial Edition for Linux is
strictly prohibited without Franz consent.

-- End of included whatnots...

Can you believe this? They have COME RIGHT OUT AND STATED why they are
sharing their product! They _*ENCOURAGE*_ you to share it! THEY MAKE
MENTION TO COMMUNITY! Did you talk with Franz about using your program
for commercial use or were you too busy sleeping like the rest of
them?

The rest of the license describes what they mean by commercial, gives
some contact info, and then mentions some more stuff about what you
_CAN_ do with your copy of their product (I am not mentioning it
because I think that if anyone where truly interested in it - they
would read it) The license is a total of 293 lines (last newline not
inclusive I don't think). If you cannot bring yourself to read this
much how can you learn to write programs?

If I was to give you something and then you were to spit in my face I
would be very upset. Would you care? I am glad you don't want to use
it - but Franz seems to think it's ok. Very nice of them IMHO.

P.S. I don't mean to sound confrontational or upset - I've just been
having a bad extended period of time lately and nonsence like this
doesn't help. I could be misinterpreting what you meant due to
frustration and other stuff. Please feel free to correct me (hopefully
in nicer tone than my message - for which I apologize).
From: Craig Brozefsky
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <871zneyeik.fsf@duomo.pukka.org>
Steve Gonedes <········@worldnet.att.net> writes:

> Craig Brozefsky <·····@onshore.com> writes:
> 
> < No, since I'm not a paying customer of Franz, I was not aware of that.
> 
> Why did you say this?

Because Erik said that paying customers get source access to some stuff,
and asked if I was aware of that.  I was not aware of that and
therefor told him so, and offered the reason why I was not aware of
the practice.

Let's get this over with now...  You seem to have read somewhere in my
post a disdain for Franz, and animosity towards them or anyone else
who releases their hard work, but in a manner which does not fit a
fairly well established (and completely volountary) definition of
"free", as in "free speech".  I'm not sure where you got that from,
considering that in the last two posts I already said that Franz
rocks, and explicitely said that I hold nothing against them for not
distributing source and allowing redistribution of modifications.

I think the rest of your diatribe was motivated by that false
assumption, so I'm not about to waste anyone's time responding to it.

As for the text of the license, I was reading from the 4.3 License.txt
which is basically the same as the one you quoted.  It allows
distribution of unmodified copies (tho can be augmented by other source
code with certain restriction), but dissallows redistribution of
modified copies.  The conversation I had with Erik was regarding
redistribution of modifications as being the bearer of real fruit,
versus just plain source code access, and so when I said that Franz
did not allow "redistribution/modification" this is what I was
refering too.  With regards to commecial use, their license forbades
it, but they are kind enough to give contact info for further
negotiations, presumably leading to a purchase.  I don't think I
misrepresented it at all.

May I suggest coding to soothe your nerves?
From: Steve Gonedes
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <m2af21p7of.fsf@KludgeUnix.com>
Craig Brozefsky <·····@onshore.com> writes:


< Steve Gonedes <········@worldnet.att.net> writes:
< 
< > Craig Brozefsky <·····@onshore.com> writes:

...

Sorry about that.
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3119615849918337@naggum.no>
* Craig Brozefsky <·····@onshore.com>
| Unless I sign an NDA, there is no problem with me talking about the
| source code, or even referring to it within the bounds of fair use.  If
| written materials worked this way than I could only talk to you about
| Vineland after you had bought the book, and couldn't put a nifty one
| liner from it in my .sig without getting sued.

  "fair use" is a very complex topic in copyright law.  I, who have read
  large volumes on copyright law, do _not_ pretend to be able to predict
  whether a court will agree with me except in the obvious cases.  getting
  sued is expensive even if you are vindicated.  if the court decides the
  copyright claimant had reason to sue, despite losing, you are not
  rewarded legal fees, either.  I want to be certain that what I do is
  "unsuable", and thus ask permission instead of engaging in soapboxing on
  "fair use" before or after the fact.  I also know that claiming rights
  one does not in fact have is often enough to get sued, because reasonable
  communication is no longer possible, and he who has the rights stands to
  lose if he does not protect himself.

| If you publish source code, you expect people to read it, you don't
| expect them to copy it tho.  There is quite a difference between talking
| about and discussing a published work, and copying it.

  there is also a difference between talking about, and bringing your
  increased understanding from the source code you read into a new forum,
  essentially allowing duplication of code that various agreements bar you
  from redistributing.  such duplication is _not_ covered by "fair use",
  either -- that much I can say for certain.

| I think the fact that you had to use the phrase "in the strictest legal
| sense" is enough evidence that your stretching to the point where you've
| ripped the ass out of your pants.

  feel free to interpret it that way, but I prefer to cover my butt, ripped
  pants or no, instead of being kicked out of court with enormous legal
  fees after having made a point.  that is why I say "in the strictest
  legal sense".  in the strictest legal sense, it is illegal to bring a
  number of things into the U.S., too, but there is no way you could be
  caught doing it.  that doesn't mean you can boast of having done it and
  avoid prosecution.  another silly example: when tourists enter the U.S.,
  they have to sign a paper saying they are not guilty of "genocide".  if
  you ask "how many people does it take to call it `genocide', anyway?",
  don't expect to let the immigration office let you through no matter how
  much you say "OK, I'm in the clear, then".

| Unless there are some new ground breaking theories in intellectual
| property or whatever, could we bring this to a close.  I've got coding
| to do.

  it's pretty hard to leave someone who is so adamant about not listening
  to people who know better than him alone.  people get hurt listening to
  legal advice on USENET.  heed to caution, I say.  have a lawyer tell you
  whether he believes something is "fair use" or not, not someone with an
  obvious axe to grind.

#:Erik
-- 
  The Microsoft Dating Program -- where do you want to crash tonight?
From: Donald Fisk
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3607F45F.B3199A6C@bt-sys.spamblock.bt.co.uk>
Erik Naggum wrote:

>   what is it that is so weak?  I find it immensely useful that "string
>   operations" in other languages actually work on _sequences_ in Common
>   Lisp.

What you want to do with strings is often different from what you want
to do with lists, or vectors of numbers.   Usually, some sort of lexical
analysis is required.   This is built into Snobol and Perl, but to do the
same in Lisp would either require some extra programming, or worse,
some degree of cleverness.

To choose a specific example, here is the Snobol which can separate
a URL into a protocol, machine and path:

        url arb . protocol "://" arb . machine "/" rem . path

Now, try doing that in one line of Lisp.

If this sort of thing comprises only a small part of your code,
but is used in several programs (a likely scenario), you're still better
off sticking to Lisp, after extending it with a macro which does
Snobol pattern matching.

>  #:Erik

--
Le Hibou (mo bheachd fhe/in: my own opinion)
"it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody.  the practical result
is that thieves and bums use C++ and nice people use CLOS."
 -- Erik Naggum
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115539566299174@naggum.no>
* Donald Fisk <···········@bt-sys.spamblock.bt.co.uk>
| What you want to do with strings is often different from what you want to
| do with lists, or vectors of numbers.

  this is a very limiting view.

| Usually, some sort of lexical analysis is required.

  pattern matching should work for all types, not just characters, IMO.

| This is built into Snobol and Perl, but to do the same in Lisp would
| either require some extra programming, or worse, some degree of
| cleverness.

  I fail to see the problem.  this isn't exactly rocket science, so how
  many times would you need to do it?  on the other hand, I was afflicted
  with the "don't make huge libraries yourself" illness for a long time,
  since that's how one normally works under Unix.  however, dumping a new
  Lisp image with lots and lots of functions effectively makes them part of
  the language, not your application.

| To choose a specific example, here is the Snobol which can separate
| a URL into a protocol, machine and path:
| 
|         url arb . protocol "://" arb . machine "/" rem . path
| 
| Now, try doing that in one line of Lisp.

  I'd say just (delimited-substrings url "://" "/"), but I assume the above
  really sets a bunch of variables, as well, so let's make it

(multiple-value-bind (protocol host path) (delimited-substrings url "://" "/")
  ...)

  by the way, this doesn't actually work for _URLs_.  relative URLs fail,
  the path actually _includes_ the slash, which might not even be present
  to begin with.  the "host" part may contain a username, a port, or both.
  not all protocols have paths.  not all URLs separate the protocol from
  the first "argument" with double slashes -- the syntax simply says colon,
  and parsing of the rest depends on the protocol.

  _this_ is why such simple solutions are wrong, and the only reason people
  choose them is because they don't understand the complexity of the issues
  involved.  good programmers acknowledge the complexity of the task and
  handle the trivial cases as the special cases they are when worth it,
  while bad programmers assume the trivial and special-case the rest.

  regexps are usually valid only for the trivial cases, and they quickly
  get so complex that one wonders what people were thinking when they did
  _not_ return to the drawing board and get it right with a real parser.
  
| If this sort of thing comprises only a small part of your code, but is
| used in several programs (a likely scenario), you're still better off
| sticking to Lisp, after extending it with a macro which does Snobol
| pattern matching.

  in this case, you're much better off writing a real parser for URL's.
  not surprisingly, that is shorter in Lisp than in Perl when it follows
  the _entire_ specification, not just the easy parts.  and that's why I
  hate Perl and love Lisp -- it's incredibly hard to do _all_ the work
  correctly in Perl and know that you have done it, and it's no significant
  extra cost in Lisp.  this means that Perl attracts the quick and dirty
  hackers, and Lisp those who want correctness, but what else is new?

  on the other hand, I have made at least half a living from fixing other
  people's incomplete code for one and a half decade, so the more Perl is
  used, the more work I get to do over, after the poor client has learned
  how complex the task really is, and can appreciate the correctness.
  without Perl, I would have had to convince them myself...  thanks, Perl!

#:Erik
-- 
  ATTENTION, all abducting aliens!  you DON'T need to RETURN them!
From: Donald Fisk
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <36093818.F32DDB3@bt-sys.spamblock.bt.co.uk>
Erik Naggum wrote:

> * Donald Fisk <···········@bt-sys.spamblock.bt.co.uk>
> | To choose a specific example, here is the Snobol which can separate
> | a URL into a protocol, machine and path:
> |
> |         url arb . protocol "://" arb . machine "/" rem . path
> |
> | Now, try doing that in one line of Lisp.
>
>   I'd say just (delimited-substrings url "://" "/"), but I assume the above
>   really sets a bunch of variables, as well, so let's make it
>
> (multiple-value-bind (protocol host path) (delimited-substrings url "://" "/")
>   ...)

I cannot find delimited-substrings in CLTL2.   Is it something you
wroteyourself?   If so, it proves my point: that you have to extend Lisp to
support
the string processing functionality built into Snobol.

>   regexps are usually valid only for the trivial cases, and they quickly
>   get so complex that one wonders what people were thinking when they did
>   _not_ return to the drawing board and get it right with a real parser.

Agreed.   Snobol patterns are, though, more flexible than the sort of
regular expressions built into Perl.   For example, context sensitivity
presents no problem in Snobol, e.g.

        input ":" len(1) $ x arb . output *x

finds a colon in whatever the user types in, and prints out everything
between the character after the colon (assigned to variable x) and the
next occurrence of it (e.g. if the inputs is "foo:bargackbaz" then the
output  is "argack").

I am reliably informed that this sort of thing is less straightforward in Perl,
which makes one wonder "What is the point of Perl?" given that Snobol
already existed.

But it's still not as straightforward to do string processing in raw Common
Lisp as it is in Snobol.

>    I hate Perl and love Lisp

At the risk of sounding like an AOL subscriber, "Me too".   However,there are
other languages out there that are, for certain types of task
(in this case, Snobol for string processing), better than Lisp.

> #:Erik

--
Le Hibou (mo bheachd fhe/in: my own opinion)
"it's just that in C++ and the like, you don't trust _anybody_,
and in CLOS you basically trust everybody.  the practical result
is that thieves and bums use C++ and nice people use CLOS."
 -- Erik Naggum
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115568738543631@naggum.no>
* Donald Fisk <···········@bt-sys.spamblock.bt.co.uk>
| I cannot find delimited-substrings in CLTL2.

  (CLtL2 is irrelevant.  CLtL1 or ANSI CL are the reference documents.)

| Is it something you wrote yourself?

  yes, but it's been dumped with my Allegro CL image for well over a year,
  so it is in every way indistinguishable from the other elements of this
  environment.

| If so, it proves my point: that you have to extend Lisp to support the
| string processing functionality built into Snobol.

  well, you prove half your point but you ignore that you prove more than
  half of my point at the same time, namely that programming in "Common
  Lisp" is not just about the standard.  "extending Common Lisp" is a piece
  of cake -- it is far from trivial to extend Perl or C++ the same way,
  although what's in Perl today is a testament to what people asked Larry
  Wall to extend Perl to do, and C++ got is cancerous growth from Bjarne
  Stroustrup's openness to any stray comer's wish.  in both cases, however,
  there's a market for all kinds of packages.  clearly it is OK to "extend"
  other languages.  _somebody_ wrote those packages and they weren't turned
  away.  (in fact, a good argument against both languages is not _nobody_
  gets turned away, except those who want clean design and correctness.)

  why is it not OK with Common Lisp?  why does everything have to be in the
  ANSI Standard to be usable?  give people a language they cannot adapt,
  and they adapt it, but give them a language supremely adaptable, and they
  cringe from _having_ to adapt it.  I don't understand this.

  or is it that Perl and C++ are such butt-ugly languages that nobody feels
  intimidated by their grandness to feel they are not "worthy" of extending
  them, while such an intimidation effectively prevents most people from
  "extending" Common Lisp?

| I am reliably informed that this sort of thing is less straightforward in
| Perl, which makes one wonder "What is the point of Perl?" given that
| Snobol already existed.

  to form a community of people who were left out of every other community,
  namely system administrators who usually couldn't program _anything_ and
  who were only interested in quick-and-dirty solutions that appeared to
  keep the system up and runnding and themselves busy.  Snobol couldn't do
  that, and Common Lisp certainly cannot attract that crowd.

| However,there are other languages out there that are, for certain types
| of task (in this case, Snobol for string processing), better than Lisp.

  only because somebody else went to the trouble of defining them for you.
  I don't understand why this is such a big deal.  Perl and C++ are _about_
  people not getting what they want and going ahead to create it.  now,
  Perl and C++ are living proof of what happens when you feel like creating
  a whole new language just to get a minute incremental benefits.  Lisp
  isn't like that.  as much as I dislike Scheme for giving me a bucket of
  sand and a furnace when I want a glass coffee mug, at least it embodies
  the attitude that building something yourself and then strive to reuse it
  is the right way to go.  Common Lisp is the way it is for the same
  reason, only people didn't have the needs that Perl satisfies.  I don't
  think this is a problem at all.  if you have a problem to which Perl is
  the best solution, you have at least two problems.

#:Erik
-------
(defun delimited-substrings (string &rest delimiters)
  "Return as multiple values the substrings delimited by each delimiter."
  (loop
    with substrings = ()
    for delimiter in delimiters
    for start = 0 then (+ end length)	;after last delimiter ends
    for end = (search delimiter string :start2 start)
    for length = (length delimiter)
    do (push (subseq string start end) substrings)
    until (null end)			;the string was exhausted
    finally
    (when end				;the delimiters were exhausted
      (push (subseq string (+ end length)) substrings))
    (return (values-list (nreverse substrings)))))
-- 
  ATTENTION, all abducting aliens!  you DON'T need to RETURN them!
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <xGdO1.11008$K02.5919993@news.teleport.com>
In article <················@naggum.no>,
	Erik Naggum <······@naggum.no> writes:
> * Donald Fisk <···········@bt-sys.spamblock.bt.co.uk>

>   or is it that Perl and C++ are such butt-ugly languages that nobody feels
>   intimidated by their grandness to feel they are not "worthy" of extending
>   them, while such an intimidation effectively prevents most people from
>   "extending" Common Lisp?

  Maybe "butt-ugly" languages just cry out to be extended/enhanced. Maybe the
base language is so painful to use without other people's contributions that a
culture builds up in sharing "useful" bits of code. CL, on the other hand,
seems to be used for big projects that don't encourage sharing bits and
pieces. Most CL people seem to start every project with a clean lisp image.

>| However,there are other languages out there that are, for certain types
>| of task (in this case, Snobol for string processing), better than Lisp.
> 
>   only because somebody else went to the trouble of defining them for you.
>   I don't understand why this is such a big deal.  

  Don't under estimate the attractiveness of having someone else write
something for you. There's "risk" in doing it yourself. If someone else writes
the code and it breaks, either they'll fix it or you can relish in one's own
smug superiority at the boob who couldn't even write a simple piece of code
correctly. 

> #:Erik
> -------
> (defun delimited-substrings (string &rest delimiters)
>   "Return as multiple values the substrings delimited by each delimiter."

  Thanks for the tidbit of code. It's gone into my init.lisp file for CMUCL.
Got any other useful tidbits? :-)

  Mike McDonald
  ·······@mikemac.com
From: Russell Senior
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <861zp2xxax.fsf@coulee.tdb.com>
>>>>> "Erik" == Erik Naggum <······@naggum.no> writes:

Erik> (defun delimited-substrings (string &rest delimiters)
Erik>   "Return as multiple values the substrings delimited by each delimiter."
Erik>   (loop
Erik>     with substrings = ()
Erik>     for delimiter in delimiters
Erik>     for start = 0 then (+ end length)	;after last delimiter ends
Erik>     for end = (search delimiter string :start2 start)
Erik>     for length = (length delimiter)
Erik>     do (push (subseq string start end) substrings)
Erik>     until (null end)			;the string was exhausted
Erik>     finally
Erik>     (when end				;the delimiters were exhausted
Erik>       (push (subseq string (+ end length)) substrings))
Erik>     (return (values-list (nreverse substrings)))))

Hmm.  I recently needed something like this for the Nth time and
finally cobbled something together that seems to work (see below).  It
is derived from some string splitting code of Keith Waclena that I
found thanks to Altavista.  I generalized it to work on sequences and
to optionally collapse adjacent delimiters.  It has not been bummed
sufficiently to yield good performance and is a bit messy in sections,
but it has been working (seemingly) correctly in the applications I
have needed it for.

Sometimes the files I need to ingest are white-space delimited files
(where the quantity of white-space is irrelevant) and other times the
files are #\Tab delimited and the number of #\Tab's are relevant.

(defun split-sequence (delim seq &optional (collapse t))
  "Split SEQ, returning a list of sequences corresponding to the
   subsequences of SEQ which are separated by occurrences of DELIM.  The 
   optional parameter COLLAPSE determines how multiple adjacent
   instances of DELIM are treated.  Non-nil (default) treats multiple
   adjacent instances of DELIM as one delimiter.  Nil treats each
   instance of DELIM as a separate delimiter."
  (flet ((split1 (delim seq collapse)
                 "SPLIT1 splits SEQ at the first occurrence of the
                  element DELIM, returning, as multiple values, the 
                  subsequence upto but not including DELIM as the 
                  first value, an indicator of lastness (by presence 
                  of DELIM), and the subsequence from immediately 
                  after DELIM and extending to the end of SEQ.  If 
                  the parameter COLLAPSE is non-nil, then leading 
                  instances of DELIM are eaten first."
                 (let ((seq2 (if collapse
                                 (let ((start (position-if-not 
                                               #'(lambda (val) 
                                                   (eq delim val)) 
                                               seq)))
                                   (if start
                                       (subseq seq start)
                                       nil))
                                 seq)))
                   
                   (let ((pivot (position delim seq2)))
                     (if (null pivot)
                         (values seq2 t) ; no pivot delimiter so last is T
                         (values (subseq seq2 0 pivot)
                                 nil ; pivot present so last is NIL
                                 (subseq seq2 (1+ pivot))))))))
    (if (= 0 (length seq))
        nil
        (multiple-value-bind (first last rest) 
            (split1 delim seq collapse)
          (if (and collapse 
                   (null first))
              nil
              (if last
                  (list first)
                  (if (or (null rest)
                          (= 0 (length rest)))
                      (if collapse 
                          (list first)
                          (list first nil))
                      (cons first (split-sequence delim rest collapse)))))))))


-- 
Russell Senior
·······@teleport.com
From: Barry Margolin
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <U5fO1.24$7h2.565631@burlma1-snr1.gtei.net>
In article <················@naggum.no>, Erik Naggum  <······@naggum.no> wrote:
>* Donald Fisk <···········@bt-sys.spamblock.bt.co.uk>
>| I cannot find delimited-substrings in CLTL2.
>
>  (CLtL2 is irrelevant.  CLtL1 or ANSI CL are the reference documents.)

I haven't bothered reading CLtL1 in ages.  I use ANSI CL if I want a
definitive statement of what's in the standard, but when I want something
easy to read I grab CLtL2 off my bookshelf.  It's close enough for most
purposes.

>| If so, it proves my point: that you have to extend Lisp to support the
>| string processing functionality built into Snobol.
>
>  well, you prove half your point but you ignore that you prove more than
>  half of my point at the same time, namely that programming in "Common
>  Lisp" is not just about the standard.  "extending Common Lisp" is a piece
>  of cake -- it is far from trivial to extend Perl or C++ the same way,

Just about every language allows libraries of functions to be used.  But
there's still a qualitative difference between built-in features of the
language and libraries -- you can learn how to use the former from just
about any manual or textbook for the language.  Any competent Perl
programmer would be expected to know about split() and regexps.  Similar
libraries for Lisp can and have been written, but because they're not part
of the language there's not much consistency from site to site, so the
experience isn't very portable.

>  although what's in Perl today is a testament to what people asked Larry
>  Wall to extend Perl to do, and C++ got is cancerous growth from Bjarne
>  Stroustrup's openness to any stray comer's wish.  in both cases, however,
>  there's a market for all kinds of packages.  clearly it is OK to "extend"
>  other languages.  _somebody_ wrote those packages and they weren't turned
>  away.  (in fact, a good argument against both languages is not _nobody_
>  gets turned away, except those who want clean design and correctness.)

What packages are you referring to in the case of Perl?  Its string
handling is built in, and has been for years.

In addition, Perl is easily extended with libraries and modules.  The
popularity of Perl has encouraged the formation of the CPAN, which
maintains a well-known module repository.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115617304961397@naggum.no>
* Barry Margolin <······@bbnplanet.com>
| Just about every language allows libraries of functions to be used.

  I had hoped we could avoid re-stating the bloody obvious.  the question
  is whether it is part of the pragmatics of the language and whether it is
  part of the culture of the language.  the problem to solve is how this
  came to be and what can be done about it if is not as we want it to be.

| Similar libraries for Lisp can and have been written, but because they're
| not part of the language there's not much consistency from site to site,
| so the experience isn't very portable.

  I had also hoped you would have noticed that I tried to discuss some of
  the explanations for this situation that had non-zero predictability for
  the future, not just dead "facts".  your statement is like saying "the
  media focus heavily on Clinton these days".

| What packages are you referring to in the case of Perl?

  tcp, various html tools, php, etc.  don't pretend you don't know if you
  at all know Perl.

| Its string handling is built in, and has been for years.

  don't be so damn stupid.

| In addition, Perl is easily extended with libraries and modules.

  ah, and Lisp isn't?  come on, what's your agenda here?  it certainly
  isn't discussing anything intelligently even _close_ to the topic.

| The popularity of Perl has encouraged the formation of the CPAN, which
| maintains a well-known module repository.

  I believe the popularity of Perl and CPAN have the same cause, and that
  CPAN helped create the popularity much more than it was caused by it.

  again, please try to understand that I'm trying to discuss the aspects of
  languages that make people (1) believe they can be extended easily, and
  (2) willing to use extensions.  you appear more interested in stating the
  bloody obvious and in defendng Perl.  you have only succeeded in annoying
  me with your inanities and bickering.  I hope that satisfies you.

  now, let's get back to why Lisp appears not to be extensible and why
  people are so heavily focused on what's in the _standard_ in order to do
  anything useful with Lisp.

#:Erik
From: Barry Margolin
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <7ItO1.32$7h2.945009@burlma1-snr1.gtei.net>
In article <················@naggum.no>, Erik Naggum  <······@naggum.no> wrote:
>* Barry Margolin <······@bbnplanet.com>
>| Its string handling is built in, and has been for years.
>
>  don't be so damn stupid.

We were discussing "Why is Perl better than Lisp for string processing?"
I don't think it's "stupid" to believe that the existence of standard,
built-in, high-level string processing functions would be the reason for
this.  It's the same reason why Lisp is better for applications that deal
with highly-interconnected networks of data.  You can make the equivalent
of conses in Perl, but you'd still have to replicate all the higher-level
operations that come for free in Lisp.

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Russell Senior
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <86iuiec5c6.fsf@coulee.tdb.com>
>>>>> "Erik" == Erik Naggum <······@naggum.no> writes:

Erik> (defun delimited-substrings (string &rest delimiters)
Erik>   "Return as multiple values the substrings delimited by each delimiter."
Erik>   (loop
Erik>     with substrings = ()
Erik>     for delimiter in delimiters
Erik>     for start = 0 then (+ end length)	;after last delimiter ends
Erik>     for end = (search delimiter string :start2 start)
Erik>     for length = (length delimiter)
Erik>     do (push (subseq string start end) substrings)
Erik>     until (null end)			;the string was exhausted
Erik>     finally
Erik>     (when end				;the delimiters were exhausted
Erik>       (push (subseq string (+ end length)) substrings))
Erik>     (return (values-list (nreverse substrings)))))

I have adapted Erik's code to a slightly different interface that I
find more useful.  It takes only a single sequence element for a
delimiter, rather than the &rest arguments of Erik's function.  Also,
it provides a switch to optionally aggregate adjacent delimiter
instances.  Also, it returns the values as a list of subsequences,
rather than a multi-value return.

Sometimes the files I need to ingest are white-space delimited files
(where the quantity of white-space is irrelevant) and other times the
files are #\Tab delimited and the number of #\Tab's are relevant.

(defun split-sequence (seq delimiter collapse)
  "Return list of subsequences in SEQ delimited by DELIMITER.  A
   non-nil value of COLLAPSE causes adjacent delimiters to be
   aggregated." 
  (let (subseqs)
    (if collapse 
        ;; complicated case (delimiter aggregation)
        (loop
         for start = (position delimiter seq  
                               :test-not #'eql 
                               :start 0) 
         then (position delimiter seq 
                        :test-not #'eql 
                        :start end) 
         for end = (if start
                       (position delimiter seq :start start)
                       nil)
         do 
         (when start
           (push (subseq seq start end) subseqs))
         until (null end)
         finally
         (when end
           (push (subseq seq (position delimiter seq 
                                       :test-not #'eql 
                                       :start end)) subseqs)))
        ;; simpler case (no delimiter aggregation)
        (loop
         for start = 0 then (+ end 1)
         for end = (position delimiter seq :start start)
         do 
         (push (subseq seq start end) subseqs)
         until (null end)
         finally
         (when end
           (push (subseq seq (+ end 1)) subseqs))))
    (nreverse subseqs)))


-- 
Russell Senior
·······@teleport.com
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115618937722449@naggum.no>
* Russell Senior <·······@teleport.com>
| I have adapted Erik's code to a slightly different interface that I find
| more useful.  It takes only a single sequence element for a delimiter,
| rather than the &rest arguments of Erik's function.  Also, it provides a
| switch to optionally aggregate adjacent delimiter instances.  Also, it
| returns the values as a list of subsequences, rather than a multi-value
| return.

  that's pretty amusing -- the first few versions of this function did
  indeed take a list of delimiters and return a list of values.  however, I
  have come to prefer multiple values to lists of values -- they are easier
  to deal with when binding the result to variables, and especially when
  just using the first value, which I found that I did quite often.  I also
  prefer to use APPLY when I already have a sequence, and when I was only
  hacking out the first element of a delimited string, the list-as-argument
  model became cumbersome.

  I'd have implemented COLLAPSE with (delete "" substrings :test #'equal)
  before reversing the list, and certainly made it optional once you make
  the delimiters a list of its own.  I agree that this flag is useful.

#:Erik
From: Russell Senior
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <86iuidjywp.fsf@coulee.tdb.com>
>>>>> "Erik" == Erik Naggum <······@naggum.no> writes:

Russell> I have adapted Erik's code to a slightly different interface
Russell> that I find more useful.  It takes only a single sequence
Russell> element for a delimiter, rather than the &rest arguments of
Russell> Erik's function.  Also, it provides a switch to optionally
Russell> aggregate adjacent delimiter instances.  Also, it returns the
Russell> values as a list of subsequences, rather than a multi-value
Russell> return.

Erik>   that's pretty amusing -- the first few versions of this
Erik> function did indeed take a list of delimiters and return a list
Erik> of values.  

The applications I am finding for this tend to use the same delimiter
throughout the parent sequence.  Of course, a delimiter specification
such as yours might prove useful in other more general circumstances.
Because of my own preconceptions, I was initially confused by the way
your function required the explicit provision of delimiters.  Since in
my primary application 50 or 100 or more subsequences might be
returned, using that type of calling interface was going to be
impractical for me.  On the return, I am less well-educated about the
relative merits of multiple-value returns compared to list of values,
so I chose the one I was more familiar with.

Erik>   I'd have implemented COLLAPSE with (delete "" substrings :test
Erik> #'equal) before reversing the list, and certainly made it
Erik> optional once you make the delimiters a list of its own.  I
Erik> agree that this flag is useful.

Hmm.  I think your delete idea is an interesting solution that I
hadn't considered, but this specific suggestion would violate the
sequence abstraction in that the function would then only work on
strings.  Perhaps (= (length subsequence) 0) would be a more general
and workable predicate.  Removal of empty subsequences at the end
would eliminate the parallel construction, but might also lead to
unnecessary intermediate computations of subsequences in the collapse
case.  It isn't immediately obvious to me which approach would be
faster.

Anyway, I want to thank you for posting your function.  It provided a
much cleaner basis for my solution than the previous glob of goo that
I had scraped into a misshapen, though sputteringly useful, pile.
Thanks.

-- 
Russell Senior
·······@teleport.com
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115659533092322@naggum.no>
* Russell Senior <·······@teleport.com>
| The applications I am finding for this tend to use the same delimiter
| throughout the parent sequence.  ...  Since in my primary application 50
| or 100 or more subsequences might be returned, using that type of calling
| interface was going to be impractical for me.

  this is quite interesting.  I used it to hack apart ISO 8601 date and
  time specifications (later writing a much more general parser for that
  purpose), the "standard" Unix colon-separated lines, etc, where there
  were obvious binding requirements for the return values, and fairly short
  and simple argument lists.  different needs produce different interfaces,
  meaning it's going to be exceedingly hard to get the interface right.
  this, too, could explain why what appears to be simple operations become
  less simple in Lisp because the _general_ case is bigger in Lisp than in
  other languages/tools.

| On the return, I am less well-educated about the relative merits of
| multiple-value returns compared to list of values, so I chose the one I
| was more familiar with.

  I tend to use multiple values when I expect a list to be hacked apart as
  soon as it is returned, and even more so when one value is more important
  than the others, and thus more likely to be used by itself.

| Hmm.  I think your delete idea is an interesting solution that I hadn't
| considered, but this specific suggestion would violate the sequence
| abstraction in that the function would then only work on strings.

  good point, but then we should be specializing on lists, too, since they
  have fairly different performance profiles from vectors/strings...

| Perhaps (= (length subsequence) 0) would be a more general and workable
| predicate.

  that would be the same as (eq start end) before extracting the subseq,
  and EQ is OK since we deal with fixnums.  the COLLECT clause could then be

    unless (and compact (eq start end))
    do (push (subseq string start end) substrings)

  this would be an inexpensive test.

| Anyway, I want to thank you for posting your function.

  you're welcome.  I hadn't expected this reception, to be honest.  perhaps
  there is hope for sharing Lisp code, after all.  :)

#:Erik
From: Russell Senior
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <86g1dg3j4r.fsf@coulee.tdb.com>
Russell> Hmm.  I think your delete idea is an interesting solution
Russell> that I hadn't considered, but this specific suggestion would
Russell> violate the sequence abstraction in that the function would
Russell> then only work on strings.

Erik> good point, but then we should be specializing on lists, too,
Erik> since they have fairly different performance profiles from
Erik> vectors/strings...

Russell> Perhaps (= (length subsequence) 0) would be a more general
Russell> and workable predicate.

Erik> that would be the same as (eq start end) before extracting the
Erik> subseq, and EQ is OK since we deal with fixnums.  the COLLECT
Erik> clause could then be

Erik>    unless (and compact (eq start end))
Erik>    do (push (subseq string start end) substrings)

Erik> this would be an inexpensive test.

Yes, `length' was the wrong predicate.  I like your suggestion,
however, it has one problem.  It does not handle the presence of
trailing delimiter elements neatly, because in that case `end' is NIL.

  (split-sequence " this is a  test " #\Space t)
  => ("this" "is" "a" "test" "")

The `Right Thing' IMO would be for the trailing empty subsequence to
disappear.  My solution is to add another test to the unless clause
for (eq start len) where len is a precomputed length of the parent
sequence.  It was also pointed out to me in email that the `finally'
clause is superfluous, so the new formulation is:

(defun split-sequence (seq delimiter &optional (collapse t))
  "Return list of subsequences in SEQ delimited by DELIMITER.  A non-nil 
   value of COLLAPSE causes adjacent delimiters to be aggregated."

  (let (subseqs
        (len (length seq)))
    (loop
     for start = 0 then (+ end 1)
     for end = (position delimiter seq :start start)
     unless (and collapse (or (eq start end)
                              (eq start len)))
     do (push (subseq seq start end) subseqs)
     until (null end))
    (nreverse subseqs)))

This generates the `right' result in my test case:

  (split-sequence " this is a  test " #\Space t)
  => ("this" "is" "a" "test")
 
And it works on list sequences also:

  (split-sequence '(0 1 2 3 0 0 4 5 0 6 7 0 8 9 0 0) 0 t)
  => ((1 2 3) (4 5) (6 7) (8 9))
  (split-sequence '(0 1 2 3 0 0 4 5 0 6 7 0 8 9 0 0) 0 nil)
  => (NIL (1 2 3) NIL (4 5) (6 7) (8 9) NIL NIL)

The one remaining shortcoming of this function (for my purposes) is
that the code that calls this function expects the empty sequences to
be represented by NIL, rather than empty strings or vectors, for ease
in testing.  This could be accomplished by inserting similar tests in
the push call.  For example:

  do (push (if (or (eq start end)
                   (eq start len))
               nil
               (subseq seq start end)) subseqs)

This gives:

  (split-sequence " this is a  test " #\Space nil)
  => (NIL "this" "is" "a" NIL "test" NIL)

Ahh... much better!


-- 
Russell Senior
·······@teleport.com
From: Bernhard Pfahringer
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <6uft7n$3dpk$1@www.univie.ac.at>
In article <··············@coulee.tdb.com>,
Russell Senior  <·······@teleport.com> wrote:
>
>
>(defun split-sequence (seq delimiter &optional (collapse t))
>  "Return list of subsequences in SEQ delimited by DELIMITER.  A non-nil 
>   value of COLLAPSE causes adjacent delimiters to be aggregated."
>
>  (let (subseqs
>        (len (length seq)))
>    (loop
>     for start = 0 then (+ end 1)
>     for end = (position delimiter seq :start start)
>     unless (and collapse (or (eq start end)
>                              (eq start len)))
>     do (push (subseq seq start end) subseqs)
>     until (null end))
>    (nreverse subseqs)))
>

Hi, while we are at sharing, I've rewritten the above to be completely
"loop-based" and to use NIL for empty subsequences:

(defun split-sequence (seq delimiter &optional (discard-empty-subseqs t))
  "Return a list of subsequences in SEQ delimited by DELIMITER.
   If discard-empty-subseqs is NIL, empty sub-sequences will be
   represented as NIL, otherwise they will be discarded."

  (loop for start = 0 then (+ end 1)
	for end = (position delimiter seq :start start)
	if (< start (or end (length seq)))
	collect (subseq seq start end) 
	else unless discard-empty-subseqs collect nil
	until (null end)))

cheers, Bernhard
-- 
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for  http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence          ········@ai.univie.ac.at 
From: Russell Senior
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <864stwm97x.fsf@coulee.tdb.com>
>>>>> "BP" == Bernhard Pfahringer <········@ai.univie.ac.at> writes:

BP> Hi, while we are at sharing, I've rewritten the above to be completely
BP> "loop-based" and to use NIL for empty subsequences:

BP> (defun split-sequence (seq delimiter &optional (discard-empty-subseqs t))
BP>   "Return a list of subsequences in SEQ delimited by DELIMITER.
BP>    If discard-empty-subseqs is NIL, empty sub-sequences will be
BP>    represented as NIL, otherwise they will be discarded."
BP> 
BP>   (loop for start = 0 then (+ end 1)
BP>         for end = (position delimiter seq :start start)
BP>         if (< start (or end (length seq)))
BP>         collect (subseq seq start end) 
BP>         else unless discard-empty-subseqs collect nil
BP>         until (null end)))

One more refinement.  It seems more natural for DISCARD-EMPTY-SUBSEQS
to default to NIL.  While convenience will vary by user and
circumstance, it seems to me like an optional argument should be off
by default, so that:

  (split-sequence seq delim) is eq to (split-sequence seq delim nil)

-- 
Russell Senior
·······@teleport.com
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <9tQO1.12974$K02.7029202@news.teleport.com>
In article <··············@coulee.tdb.com>,
	Russell Senior <·······@teleport.com> writes:
> 
>>>>>> "BP" == Bernhard Pfahringer <········@ai.univie.ac.at> writes:
> 
> BP> Hi, while we are at sharing, I've rewritten the above to be completely
> BP> "loop-based" and to use NIL for empty subsequences:
> 

> One more refinement.  It seems more natural for DISCARD-EMPTY-SUBSEQS
> to default to NIL.  While convenience will vary by user and
> circumstance, it seems to me like an optional argument should be off
> by default, so that:
> 
>   (split-sequence seq delim) is eq to (split-sequence seq delim nil)
> 


  If you're going to get refined :-), then you should also let the caller
specify the empty sequence marker: (just in case nil is a valid subseq.)

(defun split-sequence (seq delimiter 
                       &optional (discard-empty-subseqs nil) (empty-marker nil))
  "Return a list of subsequences in SEQ delimited by DELIMITER.
   If discard-empty-subseqs is NIL, empty sub-sequences will be
   represented as NIL, otherwise they will be discarded."

  (loop for start = 0 then (+ end 1)
         for end = (position delimiter seq :start start)
         if (< start (or end (length seq)))
         collect (subseq seq start end) 
         else unless discard-empty-subseqs collect empty-marker
         until (null end)))


  Mike McDonald
  ·······@mikemac.com
From: Daniel R Barlow
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <6ugloh$fm0@fishy.ox.compsoc.net>
In article <·······················@news.teleport.com>,
Mike McDonald <·······@mikemac.com> wrote:
>  If you're going to get refined :-), then you should also let the caller
>specify the empty sequence marker: (just in case nil is a valid subseq.)
>
>(defun split-sequence (seq delimiter 
>                       &optional (discard-empty-subseqs nil) (empty-marker nil))

This is all very interesting to read from a newbie lisp programmer 
perspective.  By the time the argument list reached that length I would
probably have used keyword arguments for discard-empty-subseqs and
empty-marker, instead of having to remember (more probably, look up) 
the order.  Would that be a good or bad thing stylistically, and 
does it have performance implications?

(I know that the performance implications are probably not worth worrying
about unless you can demonstrate it's likely to be a bottleneck, but in
the general case, are they slower?)

-dan
From: Mike McDonald
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <52SO1.13075$K02.7057378@news.teleport.com>
In article <··········@fishy.ox.compsoc.net>,
	···@fishy.ox.compsoc.net (Daniel R Barlow) writes:
> In article <·······················@news.teleport.com>,
> Mike McDonald <·······@mikemac.com> wrote:
>>  If you're going to get refined :-), then you should also let the caller
>>specify the empty sequence marker: (just in case nil is a valid subseq.)
>>
>>(defun split-sequence (seq delimiter 
>>                       &optional (discard-empty-subseqs nil) (empty-marker nil))
> 
> This is all very interesting to read from a newbie lisp programmer 
> perspective.  By the time the argument list reached that length I would
> probably have used keyword arguments for discard-empty-subseqs and
> empty-marker, instead of having to remember (more probably, look up) 
> the order.  Would that be a good or bad thing stylistically, and 
> does it have performance implications?
> 
> (I know that the performance implications are probably not worth worrying
> about unless you can demonstrate it's likely to be a bottleneck, but in
> the general case, are they slower?)
> 
> -dan

  I made empty-marker an optional only because discard-empty-subseqs was
already an optional. Mixing optionals and keys is very bad, IMNSHO. In this
case, they probably should be keys. discard-empty-subseqs and empty-marker are
exclusive of each other. If you want to specify the empty-marker, you're going
to want discard-empty-subseqs to be NIL. Having to specify the default
explicitly is silly. So it should be 

(defun split-sequence (seq delimiter 
                       &key (discard-empty-subseqs nil) (empty-marker nil))
  "Return a list of subsequences in SEQ delimited by DELIMITER.
   If discard-empty-subseqs is NIL, empty sub-sequences will be
   represented as EMPTY-MARKER, otherwise they will be discarded."
  (loop for start = 0 then (+ end 1)
	for end = (position delimiter seq :start start)
	if (< start (or end (length seq)))
	collect (subseq seq start end) 
	else unless discard-empty-subseqs collect empty-marker
	until (null end)))

  Remembered to update the doc string this time!

  Mike McDonald
  ·······@mikemac.com
From: Bernhard Pfahringer
Subject: s33plit-sequence (was Re: I don't understand Lisp)
Date: 
Message-ID: <6ugn1h$b7q$1@www.univie.ac.at>
In article <··········@fishy.ox.compsoc.net>,
Daniel R Barlow <···@fishy.ox.compsoc.net> wrote:
>In article <·······················@news.teleport.com>,
>Mike McDonald <·······@mikemac.com> wrote:
>>  If you're going to get refined :-), then you should also let the caller
>>specify the empty sequence marker: (just in case nil is a valid subseq.)
>>
>>(defun split-sequence (seq delimiter 
>>                       &optional (discard-empty-subseqs nil) (empty-marker nil))
>
>This is all very interesting to read from a newbie lisp programmer 
>perspective.  By the time the argument list reached that length I would
>probably have used keyword arguments for discard-empty-subseqs and
>empty-marker, instead of having to remember (more probably, look up) 
>the order.  Would that be a good or bad thing stylistically, and 
>does it have performance implications?
>

IMHO, it is a good thing for interfaces.
And yes, it will have some performance implications, but you should not
worry here because e.g. split-sequence is calling position (probably
more than once) with a keyword argument (:start), so if parsing keyword
arguments were a performance problem, you'd be hit seriously anyway.

The only worst case I can think of would be calling split-sequence
repeatly on empty sequences. There you might be able to measure
a speed difference attributable to &optional vs. &key.

In general, for me, interfaces get &key args, workhorses (especially
mutually recursive functions) get required arguments only.
To me, split-sequence is an interface, therefore you are right.

cheers, Bernhard
PS: and yes, I like the NIL defaults, and the EMPTY-MARKER addition.

-- 
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for  http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence          ········@ai.univie.ac.at 
From: Russell Senior
Subject: Re: split-sequence (was Re: I don't understand Lisp)
Date: 
Message-ID: <86zpboj5xs.fsf@coulee.tdb.com>
>>>>> "Bernhard" == Bernhard Pfahringer <········@korb.ai.univie.ac.at> writes:

Daniel> This is all very interesting to read from a newbie lisp
Daniel> programmer perspective.  By the time the argument list reached
Daniel> that length I would probably have used keyword arguments for
Daniel> discard-empty-subseqs and empty-marker, instead of having to
Daniel> remember (more probably, look up) the order.  Would that be a
Daniel> good or bad thing stylistically, and does it have performance
Daniel> implications?

Bernhard> IMHO, it is a good thing for interfaces.  

Hmm.  I am not so sure in this case.  I came at this from a little
different direction.  So different, in fact, that I didn't realize
immediately that aggregating delimiters and tossing empty subsequences
were equivalent.  Using a keyword style interface exposes the choice
and compells the user of the function to think about it in only of the
equivalent ways, in what otherwise would be confined pretty much to an
internal choice.  Since the empty-marker only makes sense in a non-NIL
keep-empty-subseqs context, it might be better to leave them as
&optional arguments, as in:

(defun split-sequence (seq delimiter 
                       &optional (keep-empty-subseqs nil) (empty-marker nil))

-- 
Russell Senior
·······@teleport.com
From: Bernhard Pfahringer
Subject: Re: split-sequence (was Re: I don't understand Lisp)
Date: 
Message-ID: <6uh2jd$28g4$1@www.univie.ac.at>
In article <··············@coulee.tdb.com>,
Russell Senior  <·······@teleport.com> wrote:
>internal choice.  Since the empty-marker only makes sense in a non-NIL
>keep-empty-subseqs context, it might be better to leave them as
>&optional arguments, as in:
>
>(defun split-sequence (seq delimiter 
>                       &optional (keep-empty-subseqs nil) (empty-marker nil))
>
>-- 

Well you could do the following:

(defun split-sequence (seq delimiter
		       &optional (empty-marker nil keep-empty-subseqs))
  "Return list of subsequences in SEQ delimited by DELIMITER.
   If an EMPTY-MARKER is supplied, empty subsequences will be
   represented by EMPTY-MARKER, otherwise they will be discarded."

  (loop for start = 0 then (+ end 1)
	for end = (position delimiter seq :start start)
	if (< start (or end (length seq)))
	collect (subseq seq start end) 
	else when keep-empty-subseqs collect empty-marker
	until (null end)))

Default behavior now is discarding, but if you supply any EMPTY-MARKER
explicitly (including NIL), then empty subsequences will be collected
as EMPTY-MARKERs. So you get:

USER(298): (SPLIT-SEQUENCE " this is a test " #\space nil)
(NIL "this" "is" "a" "test" NIL)
USER(299): (SPLIT-SEQUENCE "this is a test " #\space)
("this" "is" "a" "test")

Bernhard

-- 
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for  http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence          ········@ai.univie.ac.at 
From: Rainer Joswig
Subject: Re: split-sequence (was Re: I don't understand Lisp)
Date: 
Message-ID: <joswig-2609981136260001@194.163.195.67>
In article <·············@www.univie.ac.at>, ········@korb.ai.univie.ac.at
(Bernhard Pfahringer) wrote:

> (defun split-sequence (seq delimiter
>                        &optional (empty-marker nil keep-empty-subseqs))
>   "Return list of subsequences in SEQ delimited by DELIMITER.
>    If an EMPTY-MARKER is supplied, empty subsequences will be
>    represented by EMPTY-MARKER, otherwise they will be discarded."
> 
>   (loop for start = 0 then (+ end 1)
>         for end = (position delimiter seq :start start)
>         if (< start (or end (length seq)))
>         collect (subseq seq start end) 
>         else when keep-empty-subseqs collect empty-marker
>         until (null end)))
> 
> Default behavior now is discarding, but if you supply any EMPTY-MARKER
> explicitly (including NIL), then empty subsequences will be collected
> as EMPTY-MARKERs. So you get:
> 
> USER(298): (SPLIT-SEQUENCE " this is a test " #\space nil)
> (NIL "this" "is" "a" "test" NIL)
> USER(299): (SPLIT-SEQUENCE "this is a test " #\space)
> ("this" "is" "a" "test")
> 
> Bernhard

Now make the optional parameters keywords and add :test and :key.

:-)
From: ···················@my-dejanews.com
Subject: Re: split-sequence
Date: 
Message-ID: <6umb12$gja$1@nnrp1.dejanews.com>
In article <·······················@194.163.195.67>,
  ······@lavielle.com (Rainer Joswig) wrote:
>
> Now make the optional parameters keywords and add :test and :key.
>
> :-)
>
You asked for it, you'll get even more (-:

(defun split-sequence (delimiter seq
			   &key
			   (empty-marker nil keep-empty-subseqs)
			   (from-end nil)
			   (start 0)
			   (end nil)
			   (test nil test-supplied)
			   (test-not nil test-not-supplied)
			   (key nil key-supplied)
			   &aux
			   (len (length seq)))

  "Return list of subsequences in SEQ delimited by DELIMITER.
   If an EMPTY-MARKER is supplied, empty subsequences will be
   represented by EMPTY-MARKER, otherwise they will be discarded.
   All other keywords work analogously to POSITION."

  (unless end (setq end len))

  (when from-end
    (setf seq (reverse seq))
    (psetf start (- len end)
	   end (- len start)))

  (loop with other-keys = (nconc (when test-supplied (list :test test))
				 (when test-not-supplied (list :test-not test-not))
				 (when key-supplied (list :key key)))
	for left = start then (+ right 1)
	for right = (min (or (apply #'position delimiter seq
                                    :start left other-keys)
			     len)
			 end)
	if (< left right)
	collect (subseq seq left right)
	else when keep-empty-subseqs collect empty-marker
	until (eq right end)))

cheers, Bernhard
(who is posting from dejanews due to a temp news problem)
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for  http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence          ········@ai.univie.ac.at
Schottengasse 3                  Fax:   (+43 1) 533-6112-77
A-1010 Vienna, Austria           Phone: (+43 1) 533-6112-17

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
From: Harley Davis
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <6uglqe$84h$1@news1-alterdial.uu.net>
>
>>>>>> "BP" == Bernhard Pfahringer <········@ai.univie.ac.at> writes:
>
>BP> Hi, while we are at sharing, I've rewritten the above to be completely
>BP> "loop-based" and to use NIL for empty subsequences:
>
>BP> (defun split-sequence (seq delimiter &optional (discard-empty-subseqs
t))
>BP>   "Return a list of subsequences in SEQ delimited by DELIMITER.
>BP>    If discard-empty-subseqs is NIL, empty sub-sequences will be
>BP>    represented as NIL, otherwise they will be discarded."
>BP>
>BP>   (loop for start = 0 then (+ end 1)
>BP>         for end = (position delimiter seq :start start)
>BP>         if (< start (or end (length seq)))
>BP>         collect (subseq seq start end)
>BP>         else unless discard-empty-subseqs collect nil
>BP>         until (null end)))
>
>One more refinement.  It seems more natural for DISCARD-EMPTY-SUBSEQS
>to default to NIL.  While convenience will vary by user and
>circumstance, it seems to me like an optional argument should be off
>by default, so that:
>
>  (split-sequence seq delim) is eq to (split-sequence seq delim nil)


There is some logic to having optional parameters be () by default -
especially for us old InterLisp hackers - but in this case the default
semantics indicates that the right answer is to change the parity of the
parameter altogether:

(defun split-sequence (seq delimiter &optional (keep-empty-subseqs nil))
   "Return a list of subsequences in SEQ delimited by DELIMITER.
    If keep-empty-subseqs is true, empty sub-sequences will be
    represented as NIL, otherwise they will be discarded."

   (loop for start = 0 then (+ end 1)
         for end = (position delimiter seq :start start)
         if (< start (or end (length seq)))
         collect (subseq seq start end)
         else when keep-empty-subseqs collect nil
         until (null end)))

-- Harley
From: Tim Bradshaw
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ey34stxx5jj.fsf@todday.aiai.ed.ac.uk>
* Erik Naggum wrote:
> * Donald Fisk <···········@bt-sys.spamblock.bt.co.uk>
> | I am reliably informed that this sort of thing is less straightforward in
> | Perl, which makes one wonder "What is the point of Perl?" given that
> | Snobol already existed.

>   to form a community of people who were left out of every other community,
>   namely system administrators who usually couldn't program _anything_ and
>   who were only interested in quick-and-dirty solutions that appeared to
>   keep the system up and runnding and themselves busy.  Snobol couldn't do
>   that, and Common Lisp certainly cannot attract that crowd.

This reason can't be correct.  System administrators can program
everything: you don't qualify to be one unless you're fluent in at
least 5 languages, not more than one of which can be an intercal
dialect.  Most system administrators have at least one language
implementation to their credit.

Seriously: I am one of these people, and this argument doesn't hold
water.  I'm completely competent in Common Lisp (and a good number of
other languages to a lesser degree, most of them not `scripting
languages').  But I still write perl when I need to, because it gets
the job done, and it performs well enough, and it talks to everything
painlessly.  Yes, it is horrible, but I'm a utilitarian and so is
perl.

I guess the reason I don't use snobol (I have, but not for 10 years or
something) is because there's a larger available library for perl, and
I can ask lots of people questions.  Neither of which reasons explain
why perl is more popular.  I suspect that that has more to do with the
relatively painless move from awk/sed to perl, the fact that it's good
at talking to lots of other (Unix) tools, and the initial library was
quite large too. I forget too much snobol to know if it had any of
these features, but I suspect not.  CL has the third, but the library
is not full of system-hacking stuff.

--tim
From: Gavin E. Gleason
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <86pvcp9nfi.fsf@Hasdrubal.ournet.net>
Icon which can be said to be the modern child of Snobol4 has 
a free implementation on unix.  Boy would it be cool to have 
a Snobol lib for lisp :)

	Gavin E. Gleason
From: Tim Bradshaw
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ey33e9k2veg.fsf@haystack.aiai.ed.ac.uk>
* Randy Sims wrote:
> Tim Bradshaw <···@aiai.ed.ac.uk> writes:
>> 
>> (And before someone replies with `string processing in Lisp is easy,
>> you're an idiot blah blah': it really isn't that easy if you want
>> things to be fast, small and simple.  I spent quite a long time doing
>> stuff in scsh, and I now have a bunch of (very pretty) scripts which
>> are really a pain in terms of performance compared to the obvious
>> rewrite in Perl.  I've done the same in elk, and CL, and it just isn't
>> easy to get the kind of painless performance that perl has.)
>> 
>> --tim

> What are your tips and techniques for string processing in Lisp?
> Where (and why) does Lisp lose and Perl win?

I think it's tempting to say at this point `because there is no
standard regexp/pattern-matching in Lisp'.  But I think that is wrong
actually.  There is at least one system (scsh) which has good
string-bashing stuff in there and some nice macrology on top of it
which makes things easy to do (there is an `awk' macro).  And there is
an interesting proposal for lisp-style representations of regexps & so
forth which has been posted recently (I think by the scsh people).
And using a single-implementation system (like scsh or perl) is not a
problem for me so long as I have a reasonable expectation of being
able to port it to future machines.

I think the answer is actually poor I/O performance in many/all
Lisps.  Again, I know that it is often *possible* to get good I/O
performance, but it usually isn't easy compared to things like perl.

In fact the particular case where I most recently got my fingers burnt
was really not string-bashing at all.  Our dump scripts are currently
in scsh, and write a log file which is just a series of alists with
information about what was dumped & so forth.  I then have a little
program which lets you ask various questions of this file, like `when
was the last level zero dump of this partition'.  The log file gets
quite large (currently it's about 7000 records, or 0.5Mb), and there
is a search through the file to find information (so it obviously
won't scale for ever).  The query program really just loops calling
READ.  It's so slow that I typically start up an emacs, edit the file
and use search in emacs to find what I need to know.  It takes minutes
to run.  It isn't particularly cleverly written, but it isn't
*stupidly* written either.  If I had written the log file in some
format that perl/awk could hack easily, a naive script to search it
would take fractions of a second.  I suspect that I could implement
READ *in perl* and it would still be much faster.

This kind of thing is really bad news, and I've run across very
similar cases too many times.  It's particularly bad news because
being able to mash large amounts of data sitting in files like this is
increasingly important to people.  Of course, it's *possible* to do
this in Lispy languages, but it's hard enough that people won't do it.
When you have to think in terms of `I could link perl with my Lisp
image, then do the I/O using perl and just pass data back to Lisp
using some FFI' (I have thought this) you can be sure that Lisp will
not be used for these applications.

--tim
From: see.signature
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <slrn70fdla.q5.anyone@Flex111.dNWL.WAU.NL>
On 22 Sep 1998 13:18:15 +0100, Tim Bradshaw <···@aiai.ed.ac.uk> wrote:

>I think the answer is actually poor I/O performance in many/all
>Lisps.  Again, I know that it is often *possible* to get good I/O
>performance, but it usually isn't easy compared to things like perl.
>
>In fact the particular case where I most recently got my fingers burnt
>was really not string-bashing at all.  Our dump scripts are currently
>in scsh, and write a log file which is just a series of alists with
>information about what was dumped & so forth.  I then have a little
>program which lets you ask various questions of this file, like `when
>was the last level zero dump of this partition'.  The log file gets
>quite large (currently it's about 7000 records, or 0.5Mb), and there
>is a search through the file to find information (so it obviously
>won't scale for ever).  The query program really just loops calling
>READ.  It's so slow that I typically start up an emacs, edit the file
>and use search in emacs to find what I need to know.  It takes minutes
>to run.  It isn't particularly cleverly written, but it isn't
>*stupidly* written either.  If I had written the log file in some
>format that perl/awk could hack easily, a naive script to search it
>would take fractions of a second.  I suspect that I could implement
>READ *in perl* and it would still be much faster.
>

maybe your problems arise because of using READ, which "interns" all symbols
and variables in scsh (READ is really a scheme parser). This is really
different from just finding strings in a text file by pattern matching.

Marc

-- 
------------------------------------------------------------------------------
email: marc dot hoffmann at users dot whh dot wau dot nl
------------------------------------------------------------------------------
From: Tim Bradshaw
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ey31zp33hvr.fsf@haystack.aiai.ed.ac.uk>
* see signature wrote:
>> 

> maybe your problems arise because of using READ, which "interns" all symbols
> and variables in scsh (READ is really a scheme parser). This is really
> different from just finding strings in a text file by pattern matching.

yes, I know that.  But using READ gives you a lot of useful stuff --
specifically it gives you a simple extensible data format for which
you don't have to write a parser (my specific example used essentially
a property list, with functions to handle the values keyed of the
property names and a default thing to handle unknown properties).  It
would be a nice property of lisps if this was actually usable in
practice.  The alternative is to go away and write a parser, which I
might as well do in perl.

--tim
From: Tim Bradshaw
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ey37lyvw2jt.fsf@todday.aiai.ed.ac.uk>
* I wrote:
[Read is very very slow]

But I was actually not checking my facts carefully enough.  READ *in
scsh* is very very slow, it does reasonably in other Lisps and
Schemes.

I did some small tests reading a 6800 record, 500k file (very few
distinct symbols, maybe 10):

Lisp system	machine		elapsed time
--------------------------------------------------
Genera 8.3	NXP 1000	40 secs (compiled)
CMUCL 18b	Ultra 1/170	1.5 secs (variable between 1 and 2)
				2.5 secs interpreted
scsh/s48	Ultra 1/170	57 secs
Allegro 4.3	Ultra 1/170	1.8 secs (variable)
				2.8 secs interpreted
elk (version?)	Ultra 1/170	about 4 secs (no timing tool in elk)

So it looks like scsh is pretty grim.

I still think that Lisps typically have weak I/O but obviously I was
overstating my case a bit.  I know not to use scsh any more though!

--tim
From: Jorge Muruzabal
Subject: Simplify
Date: 
Message-ID: <36AC7464.38F444F7@escet.urjc.es>
Hi, Lispers

Does anyone know of freeware code for LISP arithmetic simplification ?
(a la Mathematica, etc.)

Thanks,

Jorge
From: Simon Leinen
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <aavhmgid24.fsf@limmat.switch.ch>
>>>>> "bm" == Barry Margolin <······@bbnplanet.com> writes:
> In article <················@naggum.no>, Erik Naggum  <····@naggum.no> wrote:
>> [...] that's pretty amusing, considering Larry Wall's explicit
>> hatred for Lisp.

> I didn't know about that.  What is it that he hates about it? [...]

"Explicit hatred for Lisp" is way over the top - Larry probably
wouldn't deny that Perl owes quite a bit to Lisp.

The part that he probably has most problems with is the syntax.  While
I personally like Lisp's syntax a lot, I still find most of Larry's
"linguistic" arguments quite compelling.

I didn't manage to dig up any references where he talks about Lisp
syntax specifically (someone has a very old comp.lang.perl archive?).
However, I recommend reading about his general approach to language
design under:

http://www.wall.org/~larry/natural.html

According to this, he would certainly like Common Lisp a lot better
than Scheme (for what it's worth).
-- 
Simon.
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3115456170053834@naggum.no>
* Simon Leinen <·····@limmat.switch.ch>
| "Explicit hatred for Lisp" is way over the top - Larry probably
| wouldn't deny that Perl owes quite a bit to Lisp.

  Larry Wall has been explicit in his hatred for Lisp, and has denied every
  similarity between Perl and any Lisp.  I have tried to communicate with
  him, but because of my involvement with Lisp and Emacs and the FSF, got
  an amazingly stupid flame back, not addressing anything of what I asked
  him, and this was _before_ I looked closely enough at Perl to think it's
  the worst disgrace of a language that has plagued this planet, not even
  beaten by C++.  he continued to attack Lisp whenever he had a chance, but
  in all fairness, I haven't seen anything from him in a long time, so he
  might have improved for all I care.

#:Erik
-- 
  ATTENTION, all abducting aliens!  you DON'T need to RETURN them!
From: Martin B. Pomije
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <36087CF1.64F85E73@my-dejanews.com>
Erik Naggum wrote:
> 
> * Simon Leinen <·····@limmat.switch.ch>
> | "Explicit hatred for Lisp" is way over the top - Larry probably
> | wouldn't deny that Perl owes quite a bit to Lisp.
> 
>   Larry Wall has been explicit in his hatred for Lisp, and has denied every
>   similarity between Perl and any Lisp.  I have tried to communicate with
>   him, but because of my involvement with Lisp and Emacs and the FSF, got
>   an amazingly stupid flame back, not addressing anything of what I asked
>   him, and this was _before_ I looked closely enough at Perl to think it's
>   the worst disgrace of a language that has plagued this planet, not even
>   beaten by C++.  he continued to attack Lisp whenever he had a chance, but
>   in all fairness, I haven't seen anything from him in a long time, so he
>   might have improved for all I care.
> 
> #:Erik
> --
>   ATTENTION, all abducting aliens!  you DON'T need to RETURN them!

Worst language EVER?  I don't care for Perl, but certainly TCL and
C-shell are at least as horrid.

*********************************************
Semi-encrypted email address: p_o_m_i_j_e_ a_t_ i_n_a_v_ d_o_t_ n_e_t_
From: Klaus Schilling
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <87vhmf2nsb.fsf@ivm.de>
"Martin B. Pomije" <······@my-dejanews.com> writes:

> Erik Naggum wrote:
> > 
> > * Simon Leinen <·····@limmat.switch.ch>
> > | "Explicit hatred for Lisp" is way over the top - Larry probably
> > | wouldn't deny that Perl owes quite a bit to Lisp.
> > 
> >   Larry Wall has been explicit in his hatred for Lisp, and has denied every
> >   similarity between Perl and any Lisp.  I have tried to communicate with
> >   him, but because of my involvement with Lisp and Emacs and the FSF, got
> >   an amazingly stupid flame back, not addressing anything of what I asked
> >   him, and this was _before_ I looked closely enough at Perl to think it's
> >   the worst disgrace of a language that has plagued this planet, not even
> >   beaten by C++.  he continued to attack Lisp whenever he had a chance, but
> >   in all fairness, I haven't seen anything from him in a long time, so he
> >   might have improved for all I care.
> > 
> > #:Erik
> > --
> >   ATTENTION, all abducting aliens!  you DON'T need to RETURN them!
> 
> Worst language EVER?  I don't care for Perl, but certainly TCL and
> C-shell are at least as horrid.

No, they are nowhere near as horrid as ba$ick, fortran , cobol and java.

Klaus Schilling
From: Jason Trenouth
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3608dd11.1850828@newshost>
On 22 Sep 1998 12:29:30 +0000, Erik Naggum <······@naggum.no> wrote:

> * Simon Leinen <·····@limmat.switch.ch>
> | "Explicit hatred for Lisp" is way over the top - Larry probably
> | wouldn't deny that Perl owes quite a bit to Lisp.
> 
>   Larry Wall has been explicit in his hatred for Lisp, and has denied every
>   similarity between Perl and any Lisp.  ...

Larry's book -- "Programming Perl", O'Reilly & Associates, 1990 -- surely
confesses an influence. He says at one point (p178) "That's what you get for
knowing just enough Lisp to be dangerous".

For the terminally curious, the example that causes him to say this is a code
snippet which unbuffers a chosen stream while maintaining the currently
selected stream:

        local($oldfh) = select(STERR); $| = 1; select($oldfh)

He rewrites this as:

        select((select(STDERR), $| = 1)[$[])

which causes him to compose the line I quoted above.

The Lispy equivalents would be something like:

        (let ((oldfh (select *standard-error*)))
          (unbuffer-selected-stream)
          (select oldfh))

and

        (select
          (car
            (list
              (select *standard-error*) (unbuffer-selected-stream))))

Of course a 'real' Lisper would have written it as:

        (select
          (prog1
              (select *standard-error*)
            (unbuffer-selected-stream)))

__Jason
From: Barry Margolin
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <ovbL1.17$yt.201494@burlma1-snr1.gtei.net>
In article <··················@news.newsguy.com>,
David Steuber "The Interloper" <········@david-steuber.com> wrote:
>This brings up another question.  It seems that Lisp is not case
>sensitive.  How many people would be upset if a Lisp implementation
>came out that was case sensitive?

Others have corrected your misunderstanding about Common Lisp's case
sensitivity (it's case sensitive internally, but canonicalizes case of
symbols on input by default).  But to answer your second question, the
difference in how the reader processed the case of input never seemed to
hurt the popularity of Franz Lisp or Emacs Lisp, which both have
case-preserving readers (Franz's may have been configurable as well, but
if so the default was to preserve).

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Kent M Pitman
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <sfwiuiqee42.fsf@world.std.com>
Barry Margolin <······@bbnplanet.com> writes:

> But to answer your second question, the
> difference in how the reader processed the case of input never seemed to
> hurt the popularity of Franz Lisp or Emacs Lisp, which both have
> case-preserving readers (Franz's may have been configurable as well, but
> if so the default was to preserve).

First, let's be clear: a case-preserving reader is nonconforming.
Programs which don't do anything tricky don't notice this
nonconformance, but programs that do will notice this nonconformance.
As with the Clinton situation (where some are blaming the rulemakers
and some are blaming the rulebreakers), so goes the situation with
this readtable issue.  Some will blame the language designers and some
will blame the implementors who don't implement the designed language.
Hmm.  I guess I've accidentally compared Clinton to Franz.  That wasn't
really intentional, but now I'm left with an ethical dilemma between
apologizing for it and asking Harlequin if that's bonus-worthy. 
Maybe I should take a poll.  (No, just kidding.  My mailbox is still
not clear of all the dozen or two e-mails that people sent telling me
the proper citation for "grok".  Please no followup on my bad use of
metaphor.)

Anyway, what I started out to say was that (as anyone who's done
prioritization of bug reports knows), "frequency" of problems (and
consequently of pain felt and reported by users) is a
multi-dimensional quantity.  Saying that something happens "a lot"
doesn't make clear what axis of this multi-dimensional quantity you're
saying has a high magnitude.  For example, I was once at Symbolics
when just before a major release, I found a bug in special binding of
lambda variables in a lambda combination (not just a lambda
expression; in an actual ((lambda ...)...).  "It's all packaged and
ready to ship," someone protested. "How frequently does the bug
happen?"  What was I to answer?  Every time anyone runs my code, I
told them.  But then, I don't know how often they do that.  Nor do I
know how many developers are like me.  So at minimum frequency is "how
often is code developed which exercises a given bug" along one axis vs
"how often is code containing the buggy code executed" along another
axsis vs "how often in the buggy code that's being executed is the
path reached which tickles the bug".  Maybe there are even more axes.
In the case in question, it just seemed embarrassing to have lambda
broken when you're a lisp machine company, so Symbolics fixed it.  But
oddly enough, hardly anyone then or now used lambda combinations at
all, even though they're retained in the language.  Most people use
LET instead.  And of those, VERY few use specials in the binding
list because it's mostly classical programmers and scheme programmers
who like lambda combinations, and they all hate specials.  So really
the bug was not likely to occur at all.  Except when it did.  And
then always.  So it goes.

Why does all this matter?  Well, I guess I'm just trying to point out
that while what Barry said is probably true--that it probably hasn't
materially hurt Franz's implementation in the market, it doesn't follow
that it doesn't cause individuals grief.  I bet it probably has, though
I have no stats to back me up.   And I just feel a little bad for
the people who do get hit by this that they ALSO find people implying
it's a matter of no consequence.   To the people it happens to, it is
of consequence.  Whether it's of consequence to the world that it's of
consequence to these people--well, there's an open question.

Emacs on the other hand is another story.  Emacs is not part of any
standard and since the design choice is entirely arbitrary, I
absolutely agree with Barry that it can't hurt really either way.
The important thing is just that it's defined.

The problem in the CL case is that it's defined a certain way and
(to my understanding) Franz doesn't follow the standard.

I hope Franz doesn't feel I'm picking on them here.  I don't try to
play any kind of marketing games here on comp.lang.lisp.  At
Harlequin, we're basically content to just beat them in the
marketplace.  In this forum I prefer a more collegiate atmosphere.  So
much choice of them as an example is just because Barry raised the
issue and because it's one I felt commentworthy.  Don't think I'm
telling you not to buy their products for the reasons I've cited 
here.  (There are plenty of other reasons I'd rather you use. 
... heh ... sorry, couldn't resist.)
From: Duane Rettig
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <4u32as89u.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:

> Barry Margolin <······@bbnplanet.com> writes:
> 
> > But to answer your second question, the
> > difference in how the reader processed the case of input never seemed to
> > hurt the popularity of Franz Lisp or Emacs Lisp, which both have
> > case-preserving readers (Franz's may have been configurable as well, but
> > if so the default was to preserve).
> 
> First, let's be clear: a case-preserving reader is nonconforming.
> Programs which don't do anything tricky don't notice this
> nonconformance, but programs that do will notice this nonconformance.

Conforming to what standard?  Common Lisp?  Neither of the lisps
mentioned above are Common Lisps.

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Kent M Pitman
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <sfwn2822fqk.fsf@world.std.com>
Duane Rettig <·····@franz.com> writes:

> Kent M Pitman <······@world.std.com> writes:
> 
> > Barry Margolin <······@bbnplanet.com> writes:
> > 
> > > But to answer your second question, the
> > > difference in how the reader processed the case of input never seemed to
> > > hurt the popularity of Franz Lisp or Emacs Lisp, which both have
> > > case-preserving readers (Franz's may have been configurable as well, but
> > > if so the default was to preserve).
> > 
> > First, let's be clear: a case-preserving reader is nonconforming.
> > Programs which don't do anything tricky don't notice this
> > nonconformance, but programs that do will notice this nonconformance.
> 
> Conforming to what standard?  Common Lisp?  Neither of the lisps
> mentioned above are Common Lisps.

Oh, he meant THAT Franz lisp.  I know the dialect, but I assumed
he was referring to Allegro.  Yes, I agree.  non-CL's dont have
a conformance issue.

As to Allegro, I've heard tell it uses lowercase symbol names, which
would be a potential cause of portability problems, but I have no way
of confirming this because I don't have access to your/Franz's
products.  If you'd like to correct my notion (and set the record
generally straight for others), I'd certainly welcome that.  I'd
rather work with accurate info.

Of course, as I thought I (perhaps clumsily) mentioned, my prior
remarks were not aimed at Franz at all even though it was them I was
using as an example.  It was just the example I (perhaps mistakenly)
thought was on the table when I went to react to and extend the 
other comments on the subject.\

(Sorry about all the Clinton comparisons, too, btw.  I compared
several other unrelated things to Clinton at dinner tonight and
realized this whole US government political nightmare, about which
I've been commenting in other online [non-newsgroup] forums is really
getting to me...)
From: Duane Rettig
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <4btohstaw.fsf@beta.franz.com>
Kent M Pitman <······@world.std.com> writes:

> Oh, he meant THAT Franz lisp.  I know the dialect, but I assumed
> he was referring to Allegro.  Yes, I agree.  non-CL's dont have
> a conformance issue.
> 
> As to Allegro, I've heard tell it uses lowercase symbol names, which
> would be a potential cause of portability problems,

No, Allegro has two modes of operation that can be switched on
the fly.  In the Common Lisp mode, symbol names are read and stored
as required in the Common Lisp spec (which may include lower case
symbols if they are escaped).  Also, as Erik mentioned, we have had
some bugs in some of the readtable operations regarding downcasing,
*print-escape*, etc, and have finally fixed them as of 5.0.

> but I have no way
> of confirming this because I don't have access to your/Franz's
> products.  If you'd like to correct my notion (and set the record
> generally straight for others), I'd certainly welcome that.  I'd
> rather work with accurate info.

Sure; the linux version is freely available at our website and is
representative of (i.e. the same as) what you would get if you
were a customer (without the support) ...

> Of course, as I thought I (perhaps clumsily) mentioned, my prior
> remarks were not aimed at Franz at all even though it was them I was
> using as an example.  It was just the example I (perhaps mistakenly)
> thought was on the table when I went to react to and extend the 
> other comments on the subject.\
> 
> (Sorry about all the Clinton comparisons, too, btw.  I compared
> several other unrelated things to Clinton at dinner tonight and
> realized this whole US government political nightmare, about which
> I've been commenting in other online [non-newsgroup] forums is really
> getting to me...)

OK, no problem; perhaps we all have a little Clinton in us (did I just
say that?....)

-- 
Duane Rettig          Franz Inc.            http://www.franz.com/ (www)
1995 University Ave Suite 275  Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253   ·····@Franz.COM (internet)
From: Kent M Pitman
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <sfwu329ihxi.fsf@world.std.com>
Duane Rettig <·····@franz.com> writes:

> Sure; the linux version is freely available at our website and is
> representative of (i.e. the same as) what you would get if you
> were a customer (without the support) ...

Ah, you want me to run a 5th operating system on the computers in my
office.  I agree that's -possible-....

> OK, no problem; perhaps we all have a little Clinton in us (did I just
> say that?....)

No, no.  You're supposed to say: "The apology wasn't good enough.
Try again." ;-)  But maybe you shouldn't.  It could start a very
dark spiral that spends $40M the industry could better use on other
things.

Error: End of subthread reached.
       You may continue by reading or replying to an unrelated post.
From: Erik Naggum
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <3114807139765421@naggum.no>
* Kent M Pitman <······@world.std.com>
| The problem in the CL case is that it's defined a certain way and
| (to my understanding) Franz doesn't follow the standard.

  well, they do now.  although it doesn't appear they have forgiven me
  completely for all the noise I made about it, ACL 5.0 does come with a
  very significantly improved symbol reader and printer -- they both now
  respect every relevant printer variable and print-read consistency is
  maintained in all cases, which was not the case previously.  I rolled my
  own symbol reader and printer for ACL 4.3 because I got sufficiently
  annoyed by the broken implementation then, but I'm happy to say that
  that's history.

  src.naggum.no/lisp/symbol-printer.cl (HTTP or FTP) has the code for ACL
  4.3+, if anyone's interested.  it's _very_ heavily optimized.

#:Erik
-- 
  http://www.naggum.no/spam.html is about my spam protection scheme and how
  to guarantee that you reach me.  in brief: if you reply to a news article
  of mine, be sure to include an In-Reply-To or References header with the
  message-ID of that message in it.  otherwise, you need to read that page.
From: Barry Margolin
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <EwxL1.45$yt.809859@burlma1-snr1.gtei.net>
In article <···············@world.std.com>,
Kent M Pitman  <······@world.std.com> wrote:
>Barry Margolin <······@bbnplanet.com> writes:
>
>> But to answer your second question, the
>> difference in how the reader processed the case of input never seemed to
>> hurt the popularity of Franz Lisp or Emacs Lisp, which both have
>> case-preserving readers (Franz's may have been configurable as well, but
>> if so the default was to preserve).
>
>First, let's be clear: a case-preserving reader is nonconforming.

I was answering a question that I thought was about Lisp, not Common Lisp.
So I gave some examples of well-known Lisp dialects that are
case-preserving.  I had initially started to include Multics Maclisp, which
perhaps would have made it really clear to you what I was doing, but I felt
that would be too obscure for most readers.

Others have already clarified that I was not referring to Allegro CL when I
said Franz Lisp (Kent, did you really think that *I* would be so
imprecise?).

>The problem in the CL case is that it's defined a certain way and
>(to my understanding) Franz doesn't follow the standard.

The case control features of the CL reader were added at the request of
Franz, Inc.  IIRC, they were case-preserving by default (probably as a
result of their Franz Lisp heritage), but this was under control of
proprietary variables that could be changed to conform to the CL way.  By
the time the ANSI standard came out I expect they changed the default and
switched over to the standard configuration mechanism (*PRINT-CASE* and
READTABLE-CASE).

-- 
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
From: Kent M Pitman
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <sfwiuircips.fsf@world.std.com>
········@david-steuber.com (David Steuber "The Interloper") writes:

> This brings up another question.  It seems that Lisp is not case
> sensitive.  How many people would be upset if a Lisp implementation
> came out that was case sensitive?  It sure makes string comparison
> easier.  This is just my view from a C++ background.

Common Lisp IS case-sensitive.

The Lisp reader, however, is case-translating.

Internally, these symbols are all indistinguishable (i.e., EQ) and
all-uppercase:
 foo Foo FOO |FOO| 

The following symbols are indistinguishable and are all-lowercase:
 |foo| \f\o\o \f|oo|

These symbol pairs are different (i.e., not EQ):
 Foo |Foo|    ; the former is all-uppercase, the latter is uppercase initial
 foo |foo|    ; the former is all-uppercase, the latter is all-lowercase
 FOO |foo|    ; the former is all-uppercase, the latter is all-lowercase

Further, there is no reason to make a Lisp implementation that is
case-sensitive.  It would break enormous amounts of code to do so.
The language already provides these features:

 *print-case*    - special variable 
 readtable-case  - function on readtables

Look them up in the Common Lisp HyperSpec(TM) for details.  They are
plenty powerful enough to obviate the need for a non-conforming Lisp.

Further: string comparison has nothing to do with symbols.  It's true
that FOO and |foo| are different symbols but not because they have
different names; rather because they are different objects (implicit
pointer compare).  Of course, they have different pointers because
they have different names; but that's just coincidence.  One shouldn't
confuse felicity with causality.  For example, #:FOO and FOO and :FOO 
have the same name and that doesn't make them the same symbol.
They are different pointers because one has no package, one is
in the prevailing package, and one is in the keyword package.
Then once they have different pointers, you compare them with EQ 
and string compares are irrelevant.

But if you were using strings, you can either choose to compare them
as objects (in which case "Foo" and "FOO" are different under EQ
since they can't have the same pointer if they have different
elements) or you can compare them as strings, in which case you
have to choose STRING-EQUAL (case-insensitive) or STRING= 
(case-sensitive).  I don't see that either is easier than the
other.  They are different.  And you should use the right one for
the right purpose.
From: Klaus Schilling
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <8790jn5h3l.fsf@ivm.de>
········@david-steuber.com (David Steuber "The Interloper") writes:
> 
> This brings up another question.  It seems that Lisp is not case
> sensitive.  How many people would be upset if a Lisp implementation
> came out that was case sensitive?  It sure makes string comparison
> easier.  This is just my view from a C++ background.

A problem caused by c-insensitivity mentioned in R*RS is the string-symbol 
conversion. 
Guile scheme is case sensitive by default (it can be turned off optionally.).


Klaus Schilling
From: ·······@jmu.edu
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <6tf7i6$bm5$1@lark.jmu.edu>
Dimitrios Souflis wrote:
> 
> If you're willing to sacrifice raw speed for size (typical for some
> scripting uses - mine at least) you might also want to look at
> TinyScheme
> at my homepage below. It's a single C module around 4000 kloc, 
> but near-R5RS Scheme nevertheless.

Do you mean to say 4 MLOC, or 4 KLOC or what?  Just wondering.

-- 
Greg Pfeil --- Software Engineer --- (·······@|http://)technomadic.org
"I was a victim of a series of accidents, as are we all."
                           --Malachi Constant in _The Sirens of Titan_
From: Dimitrios Souflis
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <35FCD8C4.B92967D3@altera.gr>
·······@jmu.edu wrote:
> 
> Dimitrios Souflis wrote:
> >
> > It's a single C module around 4000 kloc,
> > but near-R5RS Scheme nevertheless.
> 
> Do you mean to say 4 MLOC, or 4 KLOC or what?  Just wondering.

You are right in wondering... It is 4 kloc, or else it would be
MegaScheme ;-)

More precicely it is 4110 loc (.c+.h), which is either 4.1 kloc
or 4.0 kloc, depending on whether you use "kilo" for "thousand"
or 2^10=1024.

-- 
Dimitrios Souflis                ········@altera.gr
Altera Ltd.                      http://www.altera.gr/dsouflis

*** Reality is what refuses to disappear when you stop believing
*** in it (VALIS, Philip K. Dick)
From: Xah
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <6t899u$kds$1@nntp2.ba.best.com>
In article <···············@world.std.com> , Kent M Pitman
<······@world.std.com>  wrote:
>...

>p.s. My recollection from the 1970's when the word seemed popular was that
>     "grok" has no "c" in it.  I could be wrong, and went to check, but
>     (alas) it's not in my dictionary under either spelling...

American Heritage (electronic) Dictionary v.4 says:

grok (grÄk) v. tr. grok€ked grok€king groks
Slang 1. To understand profoundly through intuition or empathy. 
[ Coined by Robert A. Heinlein in his Stranger in a Strange Land]

(I don't know whether AHD is on-line.)

An on-line meta-dictionary is at http://www.onelook.com/

Merriam-Webster is at http://www.m-w.com/cgi-bin/dictionary
(which does not contain the word grok)

----

Many have explained why lisp isn't in mainstream. A self-serving meta-answer
is that that is the result of theory of economy. (basically, it just means
that lisp failed to become mainstream by social forces) One significant
reason is that supreme ideas takes time for the average to realize. Or,
cynically: "people are stupid". In an ideal word, suppose every programer
has deep interest and knowledge in computer science, mathematics, and
philosophy, then it is likely that lisp ideas will be the mainstream. In the
real word, not all programers are properly trained, and of the many degree
holders (a dime a dozen these days), lots are unthinking products of mass
education, whose interests in sciences are mostly career based.

It is worth noting that it is a fact that lisp is not in mainstream, and
this is so because of people. (your Providence does not play favoritism on
ideas good or bad.) 

The section "the rise of worse-is-better" of Richard Gabriel's essay at
 http://cbl.leeds.ac.uk/nikos/tex2html/examples/good-bad-win/node9.html

explains some aspects of why lisp's good ideas may be less popular. A more
detailed 
analysis along the same idea is the article "Big Ball of Mud" at
 http://www-cat.ncsa.uiuc.edu/~yoder/papers/patterns/BBOM/mud.html

This long article analyze the survival characteristics of codes we normally
call hacking (big ball of mud), and in general condone such practices. This
article fails to indicate a significant reason (the social element) in why
"big ball of mud" are popular: Most programers are average. The Average
lacks knowledge in advanced mathematics, imposing philosophy, or rigors of
discipline. It is easy to see that the Average will sloppily code away
without giving a fart to theories, especially with respect to many of the
technical reasons cited in the article (in essence, the reward of discipline
is elusive. (especially so with regards to the infant stage of computer
science.)).

With hardware faster and faster and advances in communication (esp.
internet), I think the technical reasons that hinders lisp popularity is
decreasing, and the superiority of lisp (or lisp-like modern languages (i.e.
functional languages)) will _eventually_ become mainstream. (java is not one
of them.)

(it is a folklore that "good ideas will eventually win", but it is worth
noting that if true, the process is never automatic. Mass education takes
time and effort: Lispers cannot just sit there and expect gospels to knock
the Average head. Evangelize, fight, do something!)

 Xah, ···@best.com
 http://www.best.com/~xah/PageTwo_dir/more.html
 Perl: all unix's stupidity in one.
From: Erann Gat
Subject: Grok (was: Re: I don't understand Lisp)
Date: 
Message-ID: <gat-1009981002480001@milo.jpl.nasa.gov>
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:

> p.s. My recollection from the 1970's when the word seemed popular was that
>      "grok" has no "c" in it.  I could be wrong, and went to check, but
>      (alas) it's not in my dictionary under either spelling.  Anyone
>      got a pointer to an authority on this?  It IS just the right
>      word, and it's a shame it's not better accepted in the language.

Grok comes from Robert Heinlein's novel "Stranger in a Strange Land" and
it indeed has no C.

Erann Gat
···@jpl.nasa.gov
From: David Steuber "The Interloper
Subject: Re: Grok (was: Re: I don't understand Lisp)
Date: 
Message-ID: <36028468.179293450@news.newsguy.com>
On Thu, 10 Sep 1998 10:02:48 -0700, ···@jpl.nasa.gov (Erann Gat)
claimed or asked:

% Grok comes from Robert Heinlein's novel "Stranger in a Strange Land" and
% it indeed has no C.

This is where my usage comes from.  Unfortunately, I lack conventional
spelling skills.  Sometimes words get past the spell checker.

--
David Steuber
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

When the long night comes, return to the end of the beginning.
--- Kosh (???? - 2261 AD) Babylon-5
From: Erik Naggum
Subject: Re: Grok (was: Re: I don't understand Lisp)
Date: 
Message-ID: <3114484004352474@naggum.no>
* Kent M Pitman
| p.s. My recollection from the 1970's when the word seemed popular was that
|      "grok" has no "c" in it.  I could be wrong, and went to check, but
|      (alas) it's not in my dictionary under either spelling.  Anyone
|      got a pointer to an authority on this?  It IS just the right
|      word, and it's a shame it's not better accepted in the language.

* ···@jpl.nasa.gov (Erann Gat)
| Grok comes from Robert Heinlein's novel "Stranger in a Strange Land" and
| it indeed has no C.

  FWIW, it was included in Merriam-Webster's Ninth Collegiate Dictionary,
  but had been removed in the Tenth edition.

#:Erik
-- 
  http://www.naggum.no/spam.html is about my spam protection scheme and how
  to guarantee that you reach me.  in brief: if you reply to a news article
  of mine, be sure to include an In-Reply-To or References header with the
  message-ID of that message in it.  otherwise, you need to read that page.
From: Jason Trenouth
Subject: Re: Grok (was: Re: I don't understand Lisp)
Date: 
Message-ID: <362e2dcf.185946703@newshost>
On 11 Sep 1998 06:26:44 +0000, Erik Naggum <······@naggum.no> wrote:

> * Kent M Pitman
> | p.s. My recollection from the 1970's when the word seemed popular was that
> |      "grok" has no "c" in it.  I could be wrong, and went to check, but
> |      (alas) it's not in my dictionary under either spelling.  Anyone
> |      got a pointer to an authority on this?  It IS just the right
> |      word, and it's a shame it's not better accepted in the language.
> 
> * ···@jpl.nasa.gov (Erann Gat)
> | Grok comes from Robert Heinlein's novel "Stranger in a Strange Land" and
> | it indeed has no C.
> 
>   FWIW, it was included in Merriam-Webster's Ninth Collegiate Dictionary,
>   but had been removed in the Tenth edition.
> 
> #:Erik

FTR its also in "The New Hackers Dictionary" (2nd Edition) without the "c".
According to this source the (Martian) work literally means "to drink" and
metaphorically means "to be one with".

__Jason
From: David Steuber "The Interloper
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <360384de.179411119@news.newsguy.com>
On Thu, 10 Sep 1998 03:40:42 GMT, Kent M Pitman <······@world.std.com>
claimed or asked:

% ········@david-steuber.com (David Steuber "The Interloper") writes:
% 
% > I am trying to figure out why Lisp has a cult like following without
% > making it into the "mainstream" as a computer language.
% 
% For the purposes of this message, I'll accept your branding of Lisp
% as cult even though I don't agree 100%.

I hope I didn't bring offense with the word cult.  I meant it in the
sense of a small, enthusiastic following, not the religious sense.
Minority opinions are not always wrong.  Heck, I wouldn't be surprised
if the minority views on most any issue were better thought out.

% Cult is about serving a need that is not served by the mainstream.
% Exactly because of the prevalance of C/C++, etc. people are driven to
% Lisp all the more strongly.  Not all, but those who are cling
% strongly.  And not to the language, I think, but to the ideas.  The
% greater Lisp community sometimes uses other languages, but I think
% never really forgets its roots.  Lisp was born of the AI research
% culture supporting specific features it needed particularly.

The AI connection is what attracts me to the language.  Also the
simplicity of the syntax for parsing and evaluating purposes.  My
interest is to implement an interpreter of Lisp in Java, leveraging
Java's garbage collection.  I would hate to write my own garbage
collector with my meager talents.  Also, Lisp appears to be a language
that would be exceptionally good for describing complex data
structures.  That is, I could leverage the Lisp interpreter by making
Lisp my file format.  Additional possibilities are also in my mind.
It may be useful to attach Lisp functions (or objects, I haven't seen
CLOS yet) to my data objects as properties.  I haven't got a fully
formed design in my mind yet, but Lisp should be able to completely
describe a model and its behavior.  This I may be able to do in Java
(it's like a third language to me), but I have an inkling that Lisp
may do the job better and in a more portable fashion.

% And then some fortuitous accidents of chance that are often, I think,
% misunderstood, but are no less powerful for the doing: The famous
% "program is data" thing is an example.  Many languages can represent
% themselves.  BASIC could represent itself with an array of strings.

I've done this in Perl.  Well, sort of.  I used Perl's eval function
to evaluate dynamically loaded code.  I also have dynamically created
regular expressions in Perl.  But Perl is not a language I wish to use
for my project.

% But what Lisp does that is critically important in power is to choose
% a representation--maybe not even the best representation--but one that
% is standard.  The willingness to decide not to fight over program
% representation and simply to define it simply and understandably means
% a whole army of automatic programming and program manipulation tools
% (not the least of which is Lisp's rich macro packages and its long
% tradition of research in compiler design) have grown up simply because
% everyone understands and shares a common interchange format for
% programs in a structured form that requires no special and parsing and
% no weird ad-hoc quotation rules.  It's not enough for another language
% to tell you you CAN define a program representation; before they match
% Lisp, they must do it and do it once and for all.  Most other

This is one of the features that attracts me to Lisp.

% languages, trying to be "small", insist on optional add-on libraries
% and then have endless disputes over whose add-on library is the one
% and only official standard one.  This is pain for programmers because
% they have to know whose C they are using.  C claims to be portable
% because it is ubiquitous, but Lisp (by which I mean Common Lisp
% particularly) was designed to be and I think truly is way more

Me too (Common Lisp).

% portable than C will ever dream of being.  In the modern world where
% the PC dominates, one may think portable is less and less important,
% but portable is REALLY about not making dependencies on the environment,
% or about capturing those dependencies in an abstract way.  So CL code
% speaks to the future not just to other machines.  If I have an integer
% of a certain range, I can declare it (INTEGER 37 416) meaning 
% "integer in the range 37-416, inclusive".  How that is optimized
% may depend on the machine.  But I do not have to say "the size of
% a machine word" and just hope to win.  That's only one tiny example.
% Pathnames, too, are structured objects that have been designed so
% that the same portable conception can work on Unix, PC, MAC, VMS,
% Linux, CDC 7600, Lisp Machines, ISO 9000 file system, etc.  

I don't get the need for an integer type in a certain range.  But that
is my inexperience.  However, portability is important for me.  I want
people to have sufficient reason to move away from Microsoft OS.
Therefor, I don't want to target Windows specifically.  At the same
time, I only want to do one build.  For now, Java offers me that
capability.  However, I am not certain of the success of Java.  If I
can incorporate portions of my application in Lisp, there is less to
port if Java fails.  The c.l.j.a group would hate me for saying that.

That brings up another point.  I must say that this is about the
friendliest news group I've read.  I haven't read more than about four
dozen postings.  In that small sample, all the talk has been at a high
level of politeness.  I'm not sure how else to put it.  In any of the
other news groups I've been in, I would have read several flames.

If I was in comp.lang.java.advocacy asking the same questions about
Java's following and lack of real market success, I would have had to
wear an asbestos suit!  This to me speaks very highly of the Lispers.
 
% Lisp has on and off been more popular than it is now.  I don't see
% popularity as its only measure of success.  Some amount of market is
% needed to keep Lisp alive and growing, and we're always happy for more
% than the baseline minimum but the practical fact is that just about
% any language can suffice for the low-end, and what Lisp excels at is
% the harder problems.  As you yourself note, VB is very popular but no

But if Lisp was a mainstream language, it would be much easier to
distribute software written with it.  Even more so if there was a
standard p-code form that it could be compiled to (like Java) so that
it could be distributed in binary form.

% one speaks kindly of it. I wouldn't trade Lisp's place for VB's--I'm
% proud of where Lisp is.  Lisp tends to attract people with problems
% that they've given up ever solving in other languages.  At Symbolics,

And VB, IMNSHO, is probably one of the biggest causes (if not the
biggest) of bad software.  I'm all for languages that are easy to
learn.  I hope Lisp falls into that category.  There is just one
syntax.  I just need to hear the song (Vorlon reference).

% the trade, I don't know.  I think it's a fundamental fact about the
% universe that a single solution can't be good for every possible
% situation.  But that Lisp is the thing that does the hard problems
% is enough.  Consider that there are probably more ten dollar pocket 
% cameras in the world than  fancy theatrical movie cameras, but it's
% not a failure for the theatrical movie guys that they make what 
% they do.

I wouldn't expect Lisp to perform well in an embedded system like the
Engine Control Unit in my car.  But for general computing (even
serious number crunching), why shouldn't Lisp or some other language
be the best at everything?  If you can say everything in the language,
and work with all the data types and representations, then all that is
left is to convert the human readable representation into the optimum
machine readable representation.  Or am I missing something?  I don't
have a CS degree, so it is entirely possible.  Actually, I am a
fallible human.  That is why I can't see everything.
 
% One reason Lisp solves the hard problems is that initial workout
% the AI community gave it.  It required a lot of memory and disk
% in those days and it was expensive compared to other alternatives.
% So people turned to other things.  But memory and disk get
% cheaper, other alternatives get bigger, and meanwhile Lisp has held
% the line on size so that it is becoming respectable again just by
% waiting for others to catch up in "apparent bloat"--only Lisp still
% has power packed into that size, and many other tools have grown
% without offering all the power that Lisp has, so don't be surprised
% if Lisp has more life in it in the future.  I think the possibilities
% are really just opening up for Lisp, frankly.  It's a bit of a chicken
% and egg problem because it needs market belief to do that, but
% I think it can and should be done.

Emacs is written in Lisp.  Unfortunately, PC people don't get to play
with it except for the NT Emacs at Volker's site.  I saw XEmacs on a
Sun box today.  Very nice.

AutoCad has AutoLisp for doing things.  I haven't messed with that
monstrosity in some years now.

It is as if Lisp is lurking around the corner, but just won't show
itself.  I think you are probably right except for one thing.  I have
a rule that I used to just apply to the stock market.  But I have
found that it is almost universal.  Never bet against stupidity.  I
can't help but think how much smaller and simpler Microsoft Word would
be if it was written in Lisp with a built in interpreter so that a
user could write Lisp extensions to customize Word.  I guess that
would be too much like a graphical version of Emacs!  Anyway, who
would want CaptiveLisp?
 
% Sounds like a good start.  Might wanna download a copy of the
% Common Lisp HyperSpec(TM).  See
%  http://www.harlequin.com/education/books/HyperSpec/
% for (free) download info and
%  http://www.harlequin.com/education/books/HyperSpec/FrontMatter/
% to browse it online at Harlequin.
% 
% See also my articles 
%  http://world.std.com/~pitman/PS/Hindsight.html
% where I discuss the benefits of Lisp in rapid prototyping and
%  http://world.std.com/~pitman/PS/Lambda.html
% where I discuss the choice of language as a political rather than
% technical issue.  (The remarks about status of certain standards are 
% now somewhat dated, but the general thrust of the piece is still 
% sound, I think.)

Thanks for the links.  I'll check them out as soon as I can.

% I saw a talk by Gerry Susman in which he suggested that indeed the most key
% contribution of computer science to the 20th century is not computation but
% the terminology for describing process.  That is, the ability to talk about
% algorithms.  That it stretches the mind, he said, and gives us ways to talk
% about how that has happened rather than just repeating things over and over
% until other people can parrot our actions is truly important.  So I agree
% with your goal and wish you luck.

I have found that verbal skills seem to be more important than math
skills in computing.  Sure, math is important.  But both math and
communication require abstract thinking.  We think about a process in
the abstract and then try to communicate it in a way that the receiver
forms the same abstraction.  A modern programming language is nothing
more than an interface between the human and the machine.  It does
have to pull of a neat trick though.  It has to be both machine
readable and human readable.  Natural language is full of ambiguity
that just can't exist in a computer language.  Also, it seems that the
computer language we think in shapes they way we approach a problem
much like the natural language we speak shapes the way we communicate
our ideas.  I'm sure this could be stated better.

In the English language, the phrase "the answer, my friend, is blowing
in the wind" can be interpreted at least three different ways.

Thanks to everyone else who replied to my post, both in this news
group and by e-mail.  You have bolstered my determinism to learn Lisp.
Some of you have recommended Scheme.  I was considering Scheme until I
was able to find a source for the Common Lisp standard.  It may be
myopic and parochial of me, but I want to deal with just one Lisp.
Even Emacs Lisp is an additional burden my finite mind doesn't wish to
cope with at this time.  Then again, the Scheme spec is much smaller.
Laziness might make me reconsider.

What is it that makes an engineer?  Laziness, impatience, and hubris?
Or is that why Unix and Perl are the way they are?

Well, I'll be squatting here for a while.

--
David Steuber
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

When the long night comes, return to the end of the beginning.
--- Kosh (???? - 2261 AD) Babylon-5
From: Gorbag
Subject: Re: I don't understand Lisp (Lisp in Java)
Date: 
Message-ID: <gorbag-ya02408000R1109981304220001@milano.mcc.com>
In article <··················@news.newsguy.com>,
········@david-steuber.com wrote:

> The AI connection is what attracts me to the language.  Also the
> simplicity of the syntax for parsing and evaluating purposes.  My
> interest is to implement an interpreter of Lisp in Java, leveraging
> Java's garbage collection.

Check out http://www.norvig.com/SILK.html

Scheme in Fifty KB. (in Java).

You're welcome.

-- 
Bradford W. Miller
(I have a job, but you're talking to me)

Disclaimer: There are no states, corporations, or other pseudo-individuals.
There are only people. Justify your actions without resorting to your
orders.

"Unlike me, many of you have accepted the situation of your imprisonment
and will die here like rotten cabbages."
        - Number Six's speech from "Free for All" _The Prisoner_
From: David Steuber "The Interloper
Subject: Re: I don't understand Lisp (Lisp in Java)
Date: 
Message-ID: <3601f0a6.338075907@news.newsguy.com>
On Fri, 11 Sep 1998 18:04:22 GMT, ······@my-dejanews.com (Gorbag)
claimed or asked:

% Check out http://www.norvig.com/SILK.html
% 
% Scheme in Fifty KB. (in Java).
% 
% You're welcome.

Come up with a demented idea, and someone else has already implemented
it.

--
David Steuber
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.

When the long night comes, return to the end of the beginning.
--- Kosh (???? - 2261 AD) Babylon-5
From: David B. Lamkins
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <dlamkins-0909982053540001@192.168.0.1>
In article <·················@news.newsguy.com>,
········@david-steuber.com wrote:

>Perhaps all languages have their zealots.  Lisp certainly has a few.
>I am trying to figure out why Lisp has a cult like following without
>making it into the "mainstream" as a computer language.  That is, Lisp
>doesn't seem, from my parochial point of view, to have the market
>penetration of C/C++, VB (yuck!), or even the controversial Java
>language.
>
>I am hoping that some of the Lisp devotees here can explain to me why
>Lisp is such a great language and why the rest of the world hasn't
>caught on to it yet, after thirty or forty years of existence.
>

I'll second Sunil's suggestion to read comp.lang.lisp on DejaNews.  There
have been a lot of discussions of this nature in the past.  I personally
have nothing new to add, being a relative newbie to Lisp (I got interested
in the mid-80s, after having been underwhelmed by my first exposure -- in
a college programming language survey course, of course -- in the
mid-70s).  FWIW, I'd prefer not to see yet another resurrection of the
perennial "why hasn't Lisp supplanted <insert your favorite language
here>?" thread...

>Why would an outsider such as my self be interested?  I am not a
>troll.  I am seriously considering using Lisp.  I have Paul Graham's
>"ANSI Common Lisp" book, and one from Guy Steele.  As an exercise, I
>am planning to implement a Lisp interpreter.  If I can wrap my brain
>around Lisp and find out what is so great about it, I would like to
>embed it in another application as a control and extension language,
>not unlike Emacs's usage.  My project, however, is much smaller than
>Emacs.  I also don't expect to be able to implement the entire ANSI
>standard, let alone CLOS.  That is unless the interpreter doesn't have
>to provide to much primitive functionality and the rest can be
>implemented in Lisp itself.

Those are both good books.  Graham's is a concise but thorough
introduction.  Steele's is a reasonable reference, but you should see the
HyperSpec <http://www.harlequin.com/books/HyperSpec/> for the definitive
reference to ANSI CL.  I'd also recommend Wilensky's "Common LISPcraft",
which offers more explanation, in general, than Graham's book; it is
closer to being a beginner's book, but without the patronizing
simplifications found in so many beginner's texts.

If you want to build an interpreter for the intellectual exercise, that's
great.  However, if your ultimate goal is to introduce a Lisp-ish
extension language into another project, I'd suggest that you first take a
look at freely-available source for such interpreters; you'll even find
some reasonably good compilers for both Scheme and CL.

The best modern reference for Lisp implementation, IMO, is "Lisp in Small
Pieces" by Christian Quiennec (Cambridge University Press, 1996, ISBN
0-521-56247-3).  This covers interpreters and compilers.  It has a Scheme
orientation, but makes appropriate and informative digressions to include
techniques appropriate to CL as needed.

Be aware that a lot of your implementation effort will go into runtime
support. One of the most difficult areas of runtime and implementation
tradeoffs involves garbage collection.  There is one excellent text on
this subject: "Garbage Collection" by Jones and Lins (Wiley, 1996, ISBN
0-471-94148-4).

AFAIK, Lisp is one of the few languages that, in a typical implementation,
allows implementation of "precise" garbage collection.  This is so because
there are typically a small number of well-know pointers (in the
underlying implementation, not available to the Lisp programmer) from
which all other accessible storage can be reached.  This allows the GC to
reclaim "precisely" everything that is unused by the running program.  The
alternative "conservative" approach uses hueristics to decide which
storage is still live; the hueristics must guess "conservatively" to keep
live storage from being reclaimed -- typically these GCs overestimate by a
small percentage.

>
>For the record, I am from a C++ background.  C++ is the language I am
>most comfortable using, and I can think in it reasonably well.  Lisp
>is quite different.  I understand the syntax, but that doesn't mean I
>can write poetry or appreciate it.
>
>With luck, I will grock this thing soon.  It will give me a new way to
>think which is always a good thing.

I believe that Samuel Kamin (?) has published a book (sorry, no reference
available) of interpreters implemented in C++.  I'm pretty sure that there
is a Lisp among them.

One thing I think you'll find as you learn to think and program in Lisp is
that it provides a remarkable economy of expression, which will help you
to solve real problems in less time.  (Disclaimer: If you have a problem
that's solved by simple, repetitive load-operate-store sequences, then
you'll probably solve it more concisely in C or FORTRAN.  But systems
programs -- to which Lisp is well-suited -- are generally not as tidy as
benchmarks, image processing, and numerical programs.)  Having been
through the exercise quite a few times, I'm _still_ pleasantly surprised
when a Common Lisp program is a fraction (typically 1/5 or smaller) of the
size of an equivalent C/C++ program.

-- 
David B. Lamkins <http://www.teleport.com/~dlamkins/>
From: Harvey J. Stein
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <m2d894tlbd.fsf@blinky.bfr.co.il>
········@david-steuber.com (David Steuber "The Interloper") writes:

<snip>

 > As an exercise, I am planning to implement a Lisp interpreter.

I assume you mean to implement one in C or C++, in which case, don't
do that.  You'll end up with an understanding of how a Lisp
interpreter works & how to implement one in C or C++, but you won't
end up with an understanding of programming in Lisp.

To understand Lisp, you should program in it.  As you repeatedly
become amazed at how easy & simple it is to do things that'd be hard &
complex in C or C++ then you'll start understanding why Lisp has its 
following.  When you start doing meta-programming in Lisp then
you'll start to really understand it.

Most lisp books are pretty decent, and others have recommended some.
But, I'd recommend Structure and Interpretation of Computer Programs
by Abelson and Sussman.  It's scheme & not common lisp, but it does a
good job of illustrating a variety of lisp programming paradigms.

-- 
Harvey J. Stein
BFM Financial Research
·······@bfr.co.il
From: Howard R. Stearns
Subject: Re: I don't understand Lisp
Date: 
Message-ID: <35F812A8.2C6694FF@elwood.com>
I agree with what others have said in response to your question.  I would
summarize thus:

  1. Lisp incorporates many (all?) of the good ideas in programming, in the
areas of:
        + programming style: object-oriented, functional, etc.
        + environment: libraries, interactive/dynamic development, etc.
        + computation: control structure, memory management, lambda calculus,
etc.
        etc.

  2. Lisp incorporates all these ideas not in an ad-hoc way, but in a
coordinated, integrated fashion.

  3.  The above would be enough to make Lisp a "darn good language", but
there are others to choose
        from.   Each Lisp devotee has further found at least one "killer
feature" of the language which other
        languages cannot compete with.   (For many, myself included, this
feature is the ability to use the
        full language to create program-transformation programs.  This is
enabled by the combination
        of macros, program-is-data,  and  the dynamic compilation
environment.  Perhaps any lack of
        market pervasiveness comes ultimately from the failure of most
programmers to find their own
       "killer feature" in Lisp.)

Some of these issues are mentioned at
http://www.elwood.com/alu/table/lisp.htm, and in particular, in the essays
referenced from http://www.elwood.com/alu/table/compare.htm and other places
on the site. You may find the C++ comparisons particularly useful.

With respect to using Lisp as as an extension language.  I think this is a
great idea to learn more about Lisp once you have some background, but may
not be the best way to start.  I also believe that if you want something for
serious or commercial use, you might consider one of the existing systems.
See the ALU website, referenced above.  Of course, I also recommend my
company's Eclipse product, which was designed for this purpose
(http://www.elwood.com/eclipse-info).