In article <············@early-bird.think.com> ···@jazz.al.alcoa.com (Peter Van Sickel) writes:
>Lispers,
>
>Here's your chance to become influencial in LUV-92, maybe even famous.
>We (the LUV-92 planning committee) are looking for a theme for the
>conference. We have some in mind and would like some feedback on them.
>
>Choice 1: Delivering to the Customer in Lisp.
>
I think this is a bad choice for a theme. While I may be second-guessing
people too much, I have the feeling that such a title will invoke
negative thoughts about Lisp as a delivery language. In other words,
announcing the conference theme as "how to deliver in Lisp" will imply to
many people that one *can't* deliver in Lisp. I fully agree that this
issues of delivery needs discussion in the community; however, to promote
the entire conference on this premise will send the wrong message to the
public -- I fear it will only fuel thoughts that Lisp is some obscure
language for a small niche of eccentrics and AI researchers (redundant? ;-)
rather than a mature, robust, standardized, *wonderful* language.
>Choice 5: Write in. You get to dream something up.
>
Perhaps we could permute the above theme a bit into something like
"Lisp as one of the oldest, mature, standardized, robust, full-featured
languages with the most advanced and powerful software development
environment in the world." Ok, the title needs shortening and I'm a little
zealous. But seriously, I cease to be amazed at why Lisp isn't considered
as more of a "regular" language. Perhaps it's the name's semantic association
with a speech impediment (suffering some of the same negative naming
conflicts as "fuzzy" logic). Perhaps it's as one of my collegues said: People
can get their hands around C from a thin Kernighan & Richie book, whereas
Steele is 1000+ pages -- Lisp offers more than people want to learn/tackle.
People are killing themselves trying to produce effective s/w development
tools for C, Fortran, etc. when the Lisp machines have had this technology
for years. There seem to be so many reasons to develop and deliver in Lisp
I fail to see why it's not chosen more often over the "more conventional
languages" (or even where the notion of "more conventional" originates!).
I don't know the answer, but this is what I'd like to see addressed at the
conference.
--
Bill Davis ······@trc.amoco.com
Amoco Production Research (918) 660-4129
P.O. Box 3385, Room 1A10 fax 660-4163
Tulsa, OK 74102
Please send responses to the Theme and Speaker Quest to Peter Van Sickel
<···@al.alcoa.com>, the organizer of the conference, rather than posting
them here or sending them to me. He doesn't read these newsgroups, so he
won't see your followups. I put "Followup-to: poster" and "Reply-to:
···@al.alcoa.com" in the header for a reason.
I've forwarded the responses and followups I've seen so far to him.
--
Barry Margolin, Thinking Machines Corp.
······@think.com
{uunet,harvard}!think!barmar
From: Mark Johnson
Subject: FP in Lisp (was: LUV-92 Theme and Speaker Quest)
Date:
Message-ID: <96946@brunix.UUCP>
The one CL implementation I understand the internals of just slightly
does a pretty inefficent job with floating-point calculations because
floats are not represented as immediate values, but (because they are
not 32-bit quantities) are stored on the heap, and hence storage must
be allocated (often a more costly operation than the FP calculation itself)
for each FP argument and result of a function invocation. On the face of it,
I can't see how to implement efficient FP arithmetic in a language
where types are not apparent at compile-time because of the difficulties
in passing arguments and results of different sizes in function calls.
Are there efficient ways of implementing FP arithmetic in Lisp that
don't require FP quantities passed as arguments to be stored on the heap?
Mark Johnson.