Sun thinks about switching Java to S-expression syntax: Lava
Rainer Joswig
Barry Margolin
s-expressions for data files, but not for representing programs themselves.
This actually has some precedents. If anyone remembers WAIS, take a look
at the format of its "source" records (the developers of WAIS were mainly
Lisp folks at Thinking Machines). And even Sun has used s-expressions
internally -- take a look at the files in /var/spool/calendar, which are
used by their OpenWindows Calendar Manager application.
S-expression is probably one of the simplest ways to represent nestable
data structures in text. I applaud the article.
--
Barry Margolin, bar...@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.
Kelly Murray
> http://www.performancecomputing.com/columns/java/9903.shtml
With Sun/Netscape hiring up all the ex-lispers, maybe I can
stop trying to make Lisp better, Java will soon be good enough?
BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
Seems most people laughed at the name. Having Netscape/Sun use it
perhaps makes it not so funny anymore?
My language is now called NiCLOS(tm), the name is funny,
but is the language?
-Kelly Murray k...@niclos.com
Rainer Joswig
> The Subject line is a bit of an overstatement.
See the smiley in the body of the posting.
David Bakhash
> BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
> Seems most people laughed at the name. Having Netscape/Sun use it
> perhaps makes it not so funny anymore?
> My language is now called NiCLOS(tm), the name is funny,
> but is the language?
So what's Lisp-like and what's Java-like in your language? Does your
langage compile down to Java VM code? Do you have a uniform way to
use Java classes via CLOS? I can't see how this is even remotely
possible, considering that:
1) Java has no multiple inheritance
2) Java's class definitions are lexical with respect to methods, if
you consider a class file as a lexical entity.
3) Java has no multimethods, and dispatch depends only on the class of
a single object.
I am surely no expert, but I work closely with Java and Lisp
development, and I really don't see how this would work. Where can
one read about this?
dave
Per Bothner
>s-expressions for data files, but not for representing programs themselves.
I was surprised he didn't mentioned XML, since this is largely what XML
is all about. (And, yes, they are also writing programming languages
based on XML. See XSL <http://www.w3.org/Style/XSL/> and contrast with
the Scheme-based DSSSL for doing the same task.)
XML is basically S-expressions with some bells and whistles
(as McCarthy pointed out at the Lisp User's conference).
It has a more verbose but easier checkable syntax.
As such, any proposal to use S-expressions *for Java* as Detlefs
proposes is both DOA and wrong-headed. People should be using
XML instead, because more tools will be able to handle it, and
because it will be more familiar to more people.
--
--Per Bothner
Cygnus Solutions bot...@cygnus.com http://www.cygnus.com/~bothner
Erik Naggum
| See the smiley in the body of the posting.
maybe these smileys destroy communication? maybe they detract from the
effort of being good at sarcasm, jokes, irony, or plain old lunacy.
at one point in my life, I became acquainted with the habit of thinking
that lying was OK if you held two fingers crossed behind your back. I
couldn't figure out why this was important to people. if I lied, it was
to protect something much more important than whoever I lied to, not to
play stupid tricks on people. I could play much better tricks on people
by making them believe something that would hurt them without my actually
telling them anything for which they could directly fault me. it has
since been a puzzling experience to see people fool _themselves_ so
thoroughly that if you told them the truth, they think you're lying.
"I have never had a sexual relationship with that women, Miss Lewinsky."
did you see his hands? could he have crossed his fingers or made some
other secret gesture by which he meant "the laugh's on you, buster"? and
then it got out of hand because "I was only kidding" didn't work with the
kid-me-not Kenneth Starr. maybe all the Democrats were in on it and the
moralistic Republicans will be laughed out of politics? that'd be cool.
meanwhile, there's not a single smiley on Kenneth Starr's pornographic
report, either, not even the smirk you'd expect from someone digging up
so much personal dirt about others. I think he forgot to include it:
"There is Substantial and Credible Information that President Clinton
Committed Acts that May Constitute Grounds for an Impeachment :>"
#:Erik
Barry Margolin
>* jos...@lavielle.com (Rainer Joswig)
>| See the smiley in the body of the posting.
>
> maybe these smileys destroy communication? maybe they detract from the
> effort of being good at sarcasm, jokes, irony, or plain old lunacy.
I think I assumed that the smiley in that posting was just expressing
happiness, like a true smile. I didn't realize it was a "tongue in cheek"
smiley.
Jim White
>http://www.performancecomputing.com/columns/java/9903.shtml
>
>;-)
Great. A Sun Java researcher who apparently likes LISP but doesn't know
about Kawa[1] (the Scheme for the JVM). Not only does it have
S-expressions but even compiles them to bytecodes including the
useful-seperate-from-scheme gnu.bytecode package so you can make classes
from whatever you want.
Now if they were only researching the JVM change that is really needed:
continuations.
If the JVM specification had been based on continuations instead of the
implementation-minded threads stuff they would not only have avoided
having to deprecate the whole damn thing as they have, but would have a
machine model that could/would be amenable to formal analysis (as it is
no one tries - they simply ignore the threading stuff).
jim
[1] <http://www.cygnus.com/~bothner/kawa.html>
-------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC
Bradley Yearwood
>Kelly Murray <k...@IntelliMarket.Com> writes:
>
>> BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
>> Seems most people laughed at the name. Having Netscape/Sun use it
>> perhaps makes it not so funny anymore?
>> My language is now called NiCLOS(tm), the name is funny,
>> but is the language?
>
>So what's Lisp-like and what's Java-like in your language? Does your
>langage compile down to Java VM code? Do you have a uniform way to
>use Java classes via CLOS? I can't see how this is even remotely
>possible, considering that:
>
>1) Java has no multiple inheritance
>2) Java's class definitions are lexical with respect to methods, if
> you consider a class file as a lexical entity.
>3) Java has no multimethods, and dispatch depends only on the class of
> a single object.
Could someone please remind me of what exactly we gain by abandoning
Lisp and moving to Java?
Here is all I am able to come up with:
1) Unprecedented momentum of hype
2) Infix notation to avoid frightening dogs and small children
2.5) Reduced wear on parentheses keys on keyboards
3) Some slightly challenging concepts like macros are made to vanish
4) Some slightly suspicious hand-waving claims that useful integrity
checks can be performed on portable bytecode before running it
5) An opportunity for yet another generation of enthusiasts to reinvent
compilers, operating systems, utilities, interactive development
environments, and special purpose hardware for the nth time in ever slower
and bulkier forms
6) An opportunity to slip some sizable loads of ignorance of prior art past
snoozing patent examiners, and thus lay down potentially lucrative legal
minefields
Brad Yearwood b...@crl.com
Cotati, CA
Christopher R. Barry
> Could someone please remind me of what exactly we gain by abandoning
> Lisp and moving to Java?
Well...
* You can download a full, uncrippled Java implementation + IDE for
any major platform absolutely free, and in the case of the JDK even
get the source code. AFAIK you can only do this with the Unix
platform for Common Lisp.
* Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
* True keyboard and mouse control (you can distinguish between a
keyboard down-press and release, so you can give your text fields
Emacs-like incremental searching and bindings or do sophisticated
word completions or any other cool thing you could think up. And of
course, completely standard and cross-platform.
* On Linux (and probably other platforms), you can choose if you want
the threads in a single process (Allegro CL style), or if you want
OS-level threads. It doesn't get any better than that (as if one
standard, cross-platform interface to threads wasn't convenient
enough).
* Graphics, low-level networking, applets in browsers, sound,
look-and-feel support, the kitchen sink.... It actually seems to be
a larger language than Common Lisp, and it gives you all the access
to the primitive hardware, windowing-system and networking
functionality that you really want but in a way that will work on
Unix, Windows, Mac or whatever without even needing to recompile for
that platform. ANSI Common Lisp gives you little more primitive
hardware control and system access than ANSI C (not including CLIM,
but IMO that doesn't really count).
It's funny, my Java instructor at the college was talking about how it
took them 6-8 years or so to start offering C++ classes, but only 3
months to offer Java classes. He said a big factor in this was that
you can download everything for free to all the computers in the
lab. Lisp has yet to be offered, and probably will never be (I think
they teach a little AutoLisp though in the CAD classes).
I think every ounce of hype Java has recieved is deserved. As a
language itself, I think it's better than C, C++, Eiffel, ADA,
etc... and just about any other non logical/functional programming
language out there. But none of the logical/functional languages can
compete with it's level of standardization and the platform
independent system control it gives you. And Common Lisp sure can't
compete with its real cost in most situations (all things considered).
It would be nice if Common Lisp could at least standardise some of the
networking, threads and i/o functionality you get in Java, and if it
had a standard, accessible and reasonably priced GUI toolkit.
In a fantasy world, you could even have Common Lisp compile to Java
byte-code and run wherever the Java Runtime Environment runs and do
all the system-level stuff that Java does (yes, I've heard of Kawa
scheme).
Christopher
Marco Antoniotti
cba...@2xtreme.net (Christopher R. Barry) writes:
> It would be nice if Common Lisp could at least standardise some of the
> networking, threads and i/o functionality you get in Java, and if it
> had a standard, accessible and reasonably priced GUI toolkit.
I'd settle for DEFSYSTEM, MULTIPROCESSING and FFI.
>
> In a fantasy world, you could even have Common Lisp compile to Java
> byte-code and run wherever the Java Runtime Environment runs and do
> all the system-level stuff that Java does (yes, I've heard of Kawa
> scheme).
I am no expert, but I'd almost think that compiling Common Lisp could
be easier than Scheme. The lack of CALL/CC might be a facilitating
factor. Anybody care to comment?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
Erik Naggum
| * You can download a full, uncrippled Java implementation + IDE for
| any major platform absolutely free, and in the case of the JDK even
| get the source code. AFAIK you can only do this with the Unix
| platform for Common Lisp.
www.franz.com offers Allegro CL Lite to any stray comer. includes IDE.
(but use LOAD-COMPILED instead of COMPILE-FILE and LOAD.)
| * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
none of the CLIM providers charge you money for trying it out before you
decide to buy it or not.
| I think every ounce of hype Java has recieved is deserved.
???
| As a language itself, I think it's better than C, C++, Eiffel, ADA,
"Ada" is named after Ada Lovelace. it's a proper name, not an acronym.
(I helped start the "Ada in Norway" user group in 1985. it's my "other"
language, and my company logo still carries symbols from the Ada world.
that people write ADA, like they write LISP, is a pet peeve.)
| And Common Lisp sure can't compete with its real cost in most situations
| (all things considered).
I don't think you are a competent judge of that, _especially_ not the
parenthetical remark.
| It would be nice if Common Lisp could at least standardise some of the
| networking, threads and i/o functionality you get in Java, and if it had
| a standard, accessible and reasonably priced GUI toolkit.
I'm still confused as to this standardization issue. yes, it would be
nice if it were standardized, but why can't you use something today?
Common Lisp is a standard _because_ it was used and gaining solid support
for a number of really complex things. if people who do not understand
how these things work refuse to use something _until_ it's standard, it
will likely never become a standard, and if, against all odds, it should,
you guys will complain and not use it, anyway.
some of us prefer languages that don't change a lot, that aren't in the
middle of the fight between good and evil, and on which long-term
investments may actually be made with solid profit expectations. Common
Lisp has a problem in that only mature people use it _after_ they have
become disgusted with other languages and their hype.
#:Erik
David B. Lamkins
R. Barry) wrote:
> b...@crl3.crl.com (Bradley Yearwood) writes:
>
>> Could someone please remind me of what exactly we gain by abandoning
>> Lisp and moving to Java?
>
> Well...
>
> * You can download a full, uncrippled Java implementation + IDE for
> any major platform absolutely free, and in the case of the JDK even
> get the source code. AFAIK you can only do this with the Unix
> platform for Common Lisp.
There are downloadable versions for Mac (Digitool trial version, and Roger
Corman's $50 shareware), PC (both Franz and Harlequin), and Linux (Franz
full version). Digitool will give you a 30-day evaluation key for the
asking. Franz's Linux version is for noncommercial use.
OTOH, if you're developing a commercial application, Lisp vendors require
that you pay for a supported version of the product (and sometimes, even for
a distribution license).
If you're building a product that can't reasonably be done except in Lisp --
and there _are_ products in that space -- then the extra cost is
justifiable. Face it, you're going to pay one way or another. Hidden costs
that I've seen with "low-cost and popular" IDEs are: lost time to market,
extra programmers, tracking down vendor bugs, being blocked 3 to 9 months
for a release that fixes a problem in the compiler, etc.
>
> * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
Have the Lisp vendors denied your request for an evaluation copy? Have you
even asked?
>
> * True keyboard and mouse control (you can distinguish between a
> keyboard down-press and release, so you can give your text fields
> Emacs-like incremental searching and bindings or do sophisticated
> word completions or any other cool thing you could think up. And of
> course, completely standard and cross-platform.
Of course, completely standard and cross-platform... Hmm, didn't Microsoft
make an argument that it had to break from the Pure Java fold because Sun
didn't want to support 3-button mice?
>
> * On Linux (and probably other platforms), you can choose if you want
> the threads in a single process (Allegro CL style), or if you want
> OS-level threads. It doesn't get any better than that (as if one
> standard, cross-platform interface to threads wasn't convenient
> enough).
So, aside from having a choice, what are the benefits? Can you do OS-native
threads in a platform-independent manner?
>
> * Graphics, low-level networking, applets in browsers, sound,
> look-and-feel support, the kitchen sink.... It actually seems to be
> a larger language than Common Lisp, and it gives you all the access
> to the primitive hardware, windowing-system and networking
> functionality that you really want but in a way that will work on
> Unix, Windows, Mac or whatever without even needing to recompile for
> that platform. ANSI Common Lisp gives you little more primitive
> hardware control and system access than ANSI C (not including CLIM,
> but IMO that doesn't really count).
Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
on the Sun platforms. But their portability claims are _vastly_ oversold.
I tried their Java-based browser (HotJava?) on a Sun workstation and was
very pleased. Later the same day, I tried it on my Mac; I threw it away
after counting some two dozen cosmetic, usability, and functional flaws in
five minutes. (Note: Given all of the hype about Java's portability, you
might ask why Sun has different HotJava versions for different platforms.)
You might be surprised to know that Common Lisp implementations also give
you access to low-level OS and hardware functionality via their FFI. Not
portable, but then neither are Mac OS APIs portable to Win32.
And of course Java doesn't have to be recompiled because it's transferred in
a platform-neutral format: byte code. Did you know that some Lisp systems
(CLISP, CMUCL) have the same capability? Do you understand that Common Lisp
source code is _highly_ portable because it doesn't encode issues of
machine-level data representation? (Yes, Java gets this half-right by
specifying fixed representations for data types. I wonder what Sun will do
when 128-bit machines hit the market. How many times has the Java
"standard" already changed?)
>
> It's funny, my Java instructor at the college was talking about how it
> took them 6-8 years or so to start offering C++ classes, but only 3
> months to offer Java classes. He said a big factor in this was that
> you can download everything for free to all the computers in the
> lab. Lisp has yet to be offered, and probably will never be (I think
> they teach a little AutoLisp though in the CAD classes).
Ah, yes. The popularity argument. A real classic. (Not now, Ethel -- I'm
busy. Just hit Ctrl-Alt-Delete, maybe it will work better next time.)
>
> I think every ounce of hype Java has recieved is deserved. As a
> language itself, I think it's better than C, C++, Eiffel, ADA,
> etc... and just about any other non logical/functional programming
> language out there. But none of the logical/functional languages can
> compete with it's level of standardization and the platform
> independent system control it gives you. And Common Lisp sure can't
> compete with its real cost in most situations (all things considered).
Every ounce of hype Java has received is still just hype. I have observed
early adopters foundering and failing with Sun's
not-quite-ready-for-primetime "free" products, and with not-free derivatives
thereof. Since these folks were actually trying to bring something to
market, there's a real cost involved. (Three or four programmers for six
months is going to cost a company about $200K to $250K in the US. That's a
lot of time and money to throw away on the basis of favorable hype,
particularly when the actual outcome doesn't meet expectations. In this
context, the expenditure of a couple tens of thousands of dollars for mature
tools and training isn't such a big deal.)
>
> It would be nice if Common Lisp could at least standardise some of the
> networking, threads and i/o functionality you get in Java, and if it
> had a standard, accessible and reasonably priced GUI toolkit.
Yeah, standards would be nice. OTOH, I can already get all of this
functionality in a platform-dependent manner and write (if needed) thin
abstraction layers around it. Frankly, I don't mind "rolling my own" while
waiting for a standard to emerge based upon actual experience. One of Sun's
own wrote a "dissenting opinion" on the perils of premature
standardization...
>
> In a fantasy world, you could even have Common Lisp compile to Java
> byte-code and run wherever the Java Runtime Environment runs and do
> all the system-level stuff that Java does (yes, I've heard of Kawa
> scheme).
And _why_ would I want to run interpreted or JIT-compiled bytecode when I
can run native code? (Remember, mobile code is handled quite nicely in Lisp
by transporting and compiling the source.)
>
> Christopher
--
David B. Lamkins <http://www.teleport.com/~dlamkins/>
Wintel is the Yugo of the computer world: cheap to buy, costly to keep.
Steve Gonedes
b...@crl3.crl.com (Bradley Yearwood) writes:
<
< In article <cxjpv7f...@engc.bu.edu>, David Bakhash <ca...@bu.edu> wrote:
< >Kelly Murray <k...@IntelliMarket.Com> writes:
< >
< >> BTW, I tried to get Franz to create "Lava" about 3-4 years ago.
< >> Seems most people laughed at the name. Having Netscape/Sun use it
< >> perhaps makes it not so funny anymore?
< >> My language is now called NiCLOS(tm), the name is funny,
< >> but is the language?
< >
< >So what's Lisp-like and what's Java-like in your language? Does your
< >langage compile down to Java VM code? Do you have a uniform way to
< >use Java classes via CLOS? I can't see how this is even remotely
< >possible, considering that:
< >
< >1) Java has no multiple inheritance
< >2) Java's class definitions are lexical with respect to methods, if
< > you consider a class file as a lexical entity.
< >3) Java has no multimethods, and dispatch depends only on the class of
< > a single object.
<
< Could someone please remind me of what exactly we gain by abandoning
< Lisp and moving to Java?
<
< Here is all I am able to come up with:
<
< 1) Unprecedented momentum of hype
< 2) Infix notation to avoid frightening dogs and small children
< 2.5) Reduced wear on parentheses keys on keyboards
< 3) Some slightly challenging concepts like macros are made to vanish
< 4) Some slightly suspicious hand-waving claims that useful integrity
< checks can be performed on portable bytecode before running it
< 5) An opportunity for yet another generation of enthusiasts to reinvent
< compilers, operating systems, utilities, interactive development
< environments, and special purpose hardware for the nth time in ever slower
< and bulkier forms
< 6) An opportunity to slip some sizable loads of ignorance of prior art past
< snoozing patent examiners, and thus lay down potentially lucrative legal
< minefields
You forgot that you can run Java programs on every windows and Solaris
computer in the world!
Steve Gonedes
cba...@2xtreme.net (Christopher R. Barry) writes:
< b...@crl3.crl.com (Bradley Yearwood) writes:
<
< > Could someone please remind me of what exactly we gain by abandoning
< > Lisp and moving to Java?
<
< Well...
<
< * You can download a full, uncrippled Java implementation + IDE for
< any major platform absolutely free, and in the case of the JDK even
< get the source code. AFAIK you can only do this with the Unix
< platform for Common Lisp.
Really? You mean Java runs on every Java platform - Solaris and
windows. You do know that all software is portable right?
You can get the source code for Java on _Solaris_ if you sign an NDA,
I think you can do this for lisp as well.
Steve Gonedes
"David B. Lamkins" <dlam...@teleport.com> writes:
< Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
< of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
< on the Sun platforms. But their portability claims are _vastly_ oversold.
< I tried their Java-based browser (HotJava?) on a Sun workstation and was
< very pleased. Later the same day, I tried it on my Mac; I threw it away
< after counting some two dozen cosmetic, usability, and functional flaws in
< five minutes. (Note: Given all of the hype about Java's portability, you
< might ask why Sun has different HotJava versions for different platforms.)
This is due to the fact that Java is portable. Portable, being an
undesirable, non-existant situation which requires work to make it go
away. All software is portable, unless it just works of course.
Unix software is portable.
< And _why_ would I want to run interpreted or JIT-compiled bytecode when I
< can run native code? (Remember, mobile code is handled quite nicely in Lisp
< by transporting and compiling the source.)
I wonder why they call it `Just in Time' compiler. Sounds like some
kind of marketing savior.
Don't get me wrong, I love Java and it's cross platform OO
capabilities. Plus it makes writing mission critical easy.
Tim Bradshaw
>
> I wonder why they call it `Just in Time' compiler. Sounds like some
> kind of marketing savior.
>
Isn't computing & compiling code `just in time' one of the things that
people have been whining at Lisp -- specifically CLOS with things like
lazily computed effective methods -- about for years? I mean, it
means you have to have the compiler in memory all the time, and we
can't have that, can we? Oh, well, we can *now*.
It's just like GC: for years, `Lisp was crippled because it had GC'
now Java has it, why GC is suddenly fine. (It's really amusing
teaching Lisp to people now, suddenly they don't go all funny when you
talk about GC).
There was recently some work on class redefinition in C++, so that's
probably OK now too.
I guess we need to invent some new and outragous features for people
to complain about. (Well, there's already the CLOS MOP, but it's not
quite universal enough to be a real target for derision.)
--tim
Barry Margolin
>I guess we need to invent some new and outragous features for people
>to complain about. (Well, there's already the CLOS MOP, but it's not
>quite universal enough to be a real target for derision.)
We still have the corner on the market for parentheses. The one new
language that was going to adopt our syntax (Dylan) gave in and switched to
algebraic/imperative notation. Even the article that started this thread
only suggested using S-secpressions for data files, not programs.
Christopher R. Barry
> * cba...@2xtreme.net (Christopher R. Barry)
> | * You can download a full, uncrippled Java implementation + IDE for
> | any major platform absolutely free, and in the case of the JDK even
> | get the source code. AFAIK you can only do this with the Unix
> | platform for Common Lisp.
>
> www.franz.com offers Allegro CL Lite to any stray comer. includes IDE.
> (but use LOAD-COMPILED instead of COMPILE-FILE and LOAD.)
It's crippled, and you must pay if you want to use it commercially.
> | * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
>
> none of the CLIM providers charge you money for trying it out before you
> decide to buy it or not.
I would feel dishonest if I contacted Franz about getting an
evaluation copy of CLIM. I know that no matter how much I liked it, I
could not at this point in my life afford it.
It would be nice if it could be obtained under the same terms as the
Allegro CL Linux Trial Edition, where you can use it as long as you
like, and not feel obligated to purchase it. After having been able to
use Allegro CL so extensively, I know that at some point in the future
I would definately buy it if using Common Lisp for a big project.
> | It would be nice if Common Lisp could at least standardise some of the
> | networking, threads and i/o functionality you get in Java, and if it had
> | a standard, accessible and reasonably priced GUI toolkit.
>
> I'm still confused as to this standardization issue. yes, it would be
> nice if it were standardized, but why can't you use something today?
I am. When it comes down to it, I still _definitely_ do not prefer
Java over CL. You know, _interpreted_ Garnet gui code seems smoother
and GCs much less than Java (though the pauses are longer - scrollbars
can really suck, gotta take care of this...). There are a number of
things that Java gets right though, like knowing how to actually get a
little mind share.
> Common Lisp has a problem in that only mature people use it _after_
> they have become disgusted with other languages and their hype.
Well, certainly not disgusted yet....
Christopher
Christopher R. Barry
> cba...@2xtreme.net (Christopher R. Barry) writes:
>
> > It would be nice if Common Lisp could at least standardise some of the
> > networking, threads and i/o functionality you get in Java, and if it
> > had a standard, accessible and reasonably priced GUI toolkit.
>
> I'd settle for DEFSYSTEM, MULTIPROCESSING and FFI.
At least Mark Kantrowitz's defsystem runs on just about every CL out
there. The Allegro one is kinda nicer, but I think Mark's has all the
functionality you really need to get the job done. Standardization
would not hurt though.
Christopher
Christopher R. Barry
> > * On Linux (and probably other platforms), you can choose if you want
> > the threads in a single process (Allegro CL style), or if you want
> > OS-level threads. It doesn't get any better than that (as if one
> > standard, cross-platform interface to threads wasn't convenient
> > enough).
>
> So, aside from having a choice, what are the benefits? Can you do OS-native
> threads in a platform-independent manner?
Maybe some time in the future.... You can't choose from within the
Java API itself if you want OS or in-process threads. I'm sure you're
familiar with the benefits of using one over the other in different
situations.
> > * Graphics, low-level networking, applets in browsers, sound,
> > look-and-feel support, the kitchen sink.... It actually seems to be
> > a larger language than Common Lisp, and it gives you all the access
> > to the primitive hardware, windowing-system and networking
> > functionality that you really want but in a way that will work on
> > Unix, Windows, Mac or whatever without even needing to recompile for
> > that platform. ANSI Common Lisp gives you little more primitive
> > hardware control and system access than ANSI C (not including CLIM,
> > but IMO that doesn't really count).
>
> Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
> of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
> on the Sun platforms.
Actually, it seems that Windows is the finest Java platform these days
and the most supported. All the fastest JVMs/JITs are for Windows, and
when Java 1.2 came out, the Windows version was the final one while
the Solaris one was supposed to still be beta or evaluatory or
something.
> But their portability claims are _vastly_ oversold. I tried their
> Java-based browser (HotJava?) on a Sun workstation and was very
> pleased. Later the same day, I tried it on my Mac; I threw it away
> after counting some two dozen cosmetic, usability, and functional
> flaws in five minutes.
I've never heard of any bad things about the Metroworks Java tools for
the Mac.
> You might be surprised to know that Common Lisp implementations also
> give you access to low-level OS and hardware functionality via their
> FFI. Not portable, but then neither are Mac OS APIs portable to
> Win32.
Probably because there's so little interest in such a thing. I'm sure
there are Win32 API layers that sit atop of the MacOS API though. But
Java gives you everything you really need from the platform specific
API without needing to use it.
> And of course Java doesn't have to be recompiled because it's transferred in
> a platform-neutral format: byte code. Did you know that some Lisp systems
> (CLISP, CMUCL) have the same capability?
Not quite in the same league.
> Do you understand that Common Lisp source code is _highly_ portable
> because it doesn't encode issues of machine-level data
> representation?
I understand that ANSI Common Lisp is highly portable. ANSI C also
will never, ever break when moving from 32 to 64 bits if you code
properly. It's just way easier to screw up.
> (Yes, Java gets this half-right by specifying fixed representations
> for data types. I wonder what Sun will do when 128-bit machines hit
> the market.
Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
about 64-bit platforms? What will it do when we've got 128-bit ones?
> How many times has the Java "standard" already changed?)
It's been updated twice, and the runtime environment and browsers all
still have to run the 1.0 code and 1.1 code too.
> Ah, yes. The popularity argument. A real classic. (Not now, Ethel -- I'm
> busy. Just hit Ctrl-Alt-Delete, maybe it will work better next time.)
Why can't Lisp become more popular? What's stopping it? Do you think
that the reasons outlined in "The Rise of Worse Is Better" are the
_real_ reasons?
> And _why_ would I want to run interpreted or JIT-compiled bytecode when I
> can run native code? (Remember, mobile code is handled quite nicely in Lisp
> by transporting and compiling the source.)
You could write applets in CL and basically gain all the advantages
and cross-platform functionality Java has. You can't do sockets or
threads in CL without a hell of a lot of #+ and #- and have it work in
any CL providing access to these features. And many are reluctant to
ship source code.
Christopher
Christopher R. Barry
> You forgot that you can run Java programs on every windows and Solaris
> computer in the world!
And almost every Unix computer (even Crays), and the MacOS, and NeXT,
and ...within 2 web browsers that run on OSs covering 99% of the OS
market share.
Christopher
Jon S Anthony
We use Java extensively here. We also use CL extensively here.
> * Swing, unlike CLIM, doesn't cost $4000-$7000 to even try out on Unix.
It's also bigger and _way_ slower.
> * On Linux (and probably other platforms), you can choose if you want
> the threads in a single process (Allegro CL style), or if you want
> OS-level threads. It doesn't get any better than that (as if one
> standard, cross-platform interface to threads wasn't convenient
> enough).
Yes, but oddly enough "green threads" (single process style) are
stunningly slow. Native threads on Solaris also suck unless you get
the right patches to run the production version - and even then they
require mind numbing amounts of cpu power to do much. Of course this
_could_ be fixed, but then why bother?
> * Graphics, low-level networking, applets in browsers, sound,
> look-and-feel support, the kitchen sink.... It actually seems to be
Sort of. Anybody actually using this stuff in real world situations
knows that there is more hype here than reality. Yes, some of it
actually works and some of it is more convenient than using something
else in certain situations. But it isn't even remotely anything like
the panacea that it is made out to be - and it often just plain
doesn't work.
> language itself, I think it's better than C, C++, Eiffel, ADA,
That's Ada - a proper name. Like Eiffel...
> independent system control it gives you. And Common Lisp sure can't
> compete with its real cost in most situations (all things
> considered).
How can you make such a claim? "Most situations" meaning..., what?
Toy oneoffs? Simple minded university class projects? Maybe. Maybe
not.
> It would be nice if Common Lisp could at least standardise some of
> the networking, threads and i/o functionality you get in Java, and
> if it had a standard, accessible and reasonably priced GUI toolkit.
Yes, it would be great if CL had a standard thread/tasking definition
- it's an important fundamental piece of functionality. Networking
stuff is really a shoulder shrug wrt "standardization" in the
language. Probably too specialized to even be appropriate.
But all of that is irrelevant in this context when you consider the
_fact_ that _nothing_ in Java is standardized! Not even the basic
constructs of the language let alone any of the libraries/APIs and
such. A _standard_ means something accepted by a _real_ standards
body - like ANSI or ISO. Sun is not a standards body and it can (and
often _does_) just change things out from under you - and then (adding
insult to injury) deprecate those changes in a future release.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
Rainer Joswig
Hmm, last time I wanted to install Solaris via a Java interface:
- HotJava crashed
- Netscape on a PC had a version conflict with the Applet
- Netscape on a Mac did not really wanted to accept
my click on an install button
Well, I switched to a terminal...
Rainer Joswig
> Common Lisp has a kinda oddball size for FIXNUMs.
Which size? In MCL:
? MOST-POSITIVE-FIXNUM
536870911
On a MacIvory:
Command: most-positive-fixnum
2147483647
Simon Leinen
> s-expressions for data files, but not for representing programs themselves.
> at the format of its "source" records (the developers of WAIS were mainly
> Lisp folks at Thinking Machines). And even Sun has used s-expressions
> internally -- take a look at the files in /var/spool/calendar, which are
> used by their OpenWindows Calendar Manager application.
Yeah, I'm always pleased when I see Lispy syntax hidden in
"mainstream" applications.
Checkpoint Firewall-1 uses S-expressions to store the firewall
configuration that you (are supposed to :-) generate using a
relatively nice GUI.
I think Confluent's "Visual Thought" drawing package also uses a Lispy
representation of its drawings.
> S-expression is probably one of the simplest ways to represent nestable
> data structures in text. I applaud the article.
--
Simon.
Christopher R. Barry
> In article <87soc6f...@2xtreme.net>, cba...@2xtreme.net (Christopher R. Barry) wrote:
>
> > Common Lisp has a kinda oddball size for FIXNUMs.
>
> Which size? In MCL:
>
> ? MOST-POSITIVE-FIXNUM
> 536870911
>
> On a MacIvory:
>
> Command: most-positive-fixnum
> 2147483647
I'll retract my statement. I believed in error that the standard
required fixnums to be 30 bits, but it says that they must be at least
16 bits (well, have a range of 2^15-1 to -2^15). Pretty much the same
requirement as the ANSI C "int" type.
Christopher
Raymond Toy
Simon> Yeah, I'm always pleased when I see Lispy syntax hidden in
Simon> "mainstream" applications.
Simon> Checkpoint Firewall-1 uses S-expressions to store the firewall
Simon> configuration that you (are supposed to :-) generate using a
Simon> relatively nice GUI.
Simon> I think Confluent's "Visual Thought" drawing package also uses a Lispy
Simon> representation of its drawings.
Add to that Rational Rose. It looks like the entire UML model is
stored in some Lispy representation, including window position
information.
Ray
Erik Naggum
| about 64-bit platforms? What will it do when we've got 128-bit ones?
geez, why do you care? Common Lisp doesn't _have_ sizes of such things.
implementations do. C and C++, however, _do_ have sizes of such things.
C/C++ have the problem you allude to. Common Lisp just runs with a
little less consing on a machine with bigger machine integers.
| Why can't Lisp become more popular?
why can't opera be more popular? why can't football be less popular?
| What's stopping it?
people like you.
| You can't do sockets or threads in CL without a hell of a lot of #+ and
| #- and have it work in any CL providing access to these features.
just because you can't doesn't many other people can't. the simplest way
to do this is to write a thin veneer, perhaps using compiler macros, to
present a uniform, standard interface to the underlying implementation
(which, by the way, differs between _socket_ implementations, too), stuff
this in a file that is loaded only on the platform it applies to.
porting your system is a matter of making a new copy of this file. this,
by the way, is how intelligent people _implement_ real portability. only
if the differences are very small and very localized does it make sense
to use #- and #+. personally, I use #- and #+ only in configuration
files and in DEFSYSTEMs.
feel free to complain that this veneer isn't standardized. I fully
expect you to, but also that you will complain about whatever you get,
the same way people complain about the pathname abstraction prohibiting
them from running the whole gamut of file system options and operations
on their particular implementation.
#:Erik
Jon S Anthony
> > * True keyboard and mouse control (you can distinguish between a
> > keyboard down-press and release, so you can give your text fields
> > Emacs-like incremental searching and bindings or do sophisticated
> > word completions or any other cool thing you could think up. And of
> > course, completely standard and cross-platform.
>
> Of course, completely standard and cross-platform... Hmm, didn't Microsoft
> make an argument that it had to break from the Pure Java fold because Sun
> didn't want to support 3-button mice?
Another point here is that the behavior is (sadly, even depressingly)
quite platform dependent.
> > * On Linux (and probably other platforms), you can choose if you want
> > the threads in a single process (Allegro CL style), or if you want
> > OS-level threads. It doesn't get any better than that (as if one
> > standard, cross-platform interface to threads wasn't convenient
> > enough).
>
> So, aside from having a choice, what are the benefits? Can you do OS-native
> threads in a platform-independent manner?
Oh, yes. OTOH, the Java thread model is stunningly impoverished.
> Wow. You've been reading the Sun PR hype, haven't you? Ever try to run any
> of this stuff on a Mac? Or even a PC? Look, Sun does a nice job with Java
> on the Sun platforms. But their portability claims are _vastly_ oversold.
In our experience, the stuff (JDK 1.2) actually runs better overall
(less bugs and better performance) on an NT.Intel box than on a
Solaris.Sparc box. Go figure.
> Every ounce of hype Java has received is still just hype. I have
> observed early adopters foundering and failing with Sun's
> not-quite-ready-for-primetime "free" products, and with not-free
I believe this is too strong. There are definitely some good things
about Java, especially wrt (more or less) platform independent GUI and
connectivity work. While it's true that due to various central flaws,
Java will never be more than a *yawn* in the space of programming
language design, in the nuts and bolts world it does have some
advantages over other players. I suppose Java is best characterized
by the following scenario: upon first looking at it the response is
something like, "Hey, this is pretty cool"; upon further examination
and use the response becomes something like, "Wow, this could have
been a _lot_ better..."
David J. Cooper Jr.
Visula is an electronic CAD system which stores its database in a Lisp
(S-expression) format. Ironically they only use it internally and it is not
supported or documented - you have to use their (licensed, C-based) API functions to
gain access to their database.
So when I once wrote an ICAD App for circuit board design rule checking of circuits
designed in Visula, a C programmer on the project kindly offered to write some
C routines for me -- to generate the circuit board database into a Lispy syntax
again, that I could easily read into the ICAD app! But at least we were able to
document and support that format!
Erik Naggum
| www.franz.com offers Allegro CL Lite to any stray comer. includes IDE.
| (but use LOAD-COMPILED instead of COMPILE-FILE and LOAD.)
* cba...@2xtreme.net (Christopher R. Barry)
| It's crippled, and you must pay if you want to use it commercially.
sigh. what _are_ the other crippled features of this version? that you
can't use it for a full-fledged commercial projects? why do you expect
to be able to do that? the Java freebies are _marketing_ stunts, not
technical arguments. do you have any idea how much money has been sunk
into Java and when the break-even time is expected to be? do you not
realize that it is an instrument of mass market destruction to reduce
Microsoft's hegemony and that Common Lisp doesn't fight that kind of wars?
and I find it slightly amusing that you, too, keep adding conditions that
make you not choose Common Lisp, no matter how people answer your gripes.
| I would feel dishonest if I contacted Franz about getting an evaluation
| copy of CLIM. I know that no matter how much I liked it, I could not at
| this point in my life afford it.
yeah, and I'm sure this is CLIM's fault. you said "Swing, unlike CLIM,
doesn't cost $4000-$7000 to even try out on Unix." which was an outright
lie, so now you would feel dishonest if you asked for a demo version, but
you didn't feel dishonest when you lied to begin with?
| It would be nice if it could be obtained under the same terms as the
| Allegro CL Linux Trial Edition, where you can use it as long as you like,
| and not feel obligated to purchase it.
you can't use it as long as you like. can't you even read licenses?
(yeah, I'm expecting another silly gripe, now.)
you clearly confused what "would be nice" with what people think they
might one day be able to profit from providing you. there ain't no such
thing as a free lunch, remember?
| After having been able to use Allegro CL so extensively, I know that at
| some point in the future I would definately buy it if using Common Lisp
| for a big project.
good for you. I won't hold my breath.
| When it comes down to it, I still _definitely_ do not prefer Java over CL.
are you desperate for reasons to use Common Lisp? is that why you bitch
and moan and invent "flaw" after "flaw" as your previous "flaws" have
proven not to be flaws? it sure doesn't look constructive to me.
| There are a number of things that Java gets right though, like knowing
| how to actually get a little mind share.
yes, by lying, overstating, hyping, misrepresenting the facts, etc.
somehow, I prefer to buy from Common Lisp sales people, not used car
sales people who jumped on the Java bandwagon.
| Well, certainly not disgusted yet....
you will, and the company that'll bring you to it: AT&T.น
#:Erik
-------
น sorry if the ad spoofed on is a little old.
Christopher R. Barry
> * cba...@2xtreme.net (Christopher R. Barry)
> | Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
> | about 64-bit platforms? What will it do when we've got 128-bit ones?
>
> geez, why do you care? Common Lisp doesn't _have_ sizes of such things.
> implementations do. C and C++, however, _do_ have sizes of such things.
> C/C++ have the problem you allude to. Common Lisp just runs with a
> little less consing on a machine with bigger machine integers.
The specification for C's "int" and CL's "FIXNUM" are virtually
identical.
> | Why can't Lisp become more popular?
>
> why can't opera be more popular? why can't football be less popular?
I think your analogy is not the most suitable one. I think using Lisp
over C or Java boils down to more than just personal taste and factors
analogous to your analogy.
> | What's stopping it?
>
> people like you.
Okay, what can I realistically do to make it more popular?
> | You can't do sockets or threads in CL without a hell of a lot of #+ and
> | #- and have it work in any CL providing access to these features.
>
> just because you can't doesn't many other people can't. the simplest way
> to do this is to write a thin veneer, perhaps using compiler macros, to
> present a uniform, standard interface to the underlying implementation
> (which, by the way, differs between _socket_ implementations, too), stuff
> this in a file that is loaded only on the platform it applies to.
> porting your system is a matter of making a new copy of this file. this,
> by the way, is how intelligent people _implement_ real portability. only
> if the differences are very small and very localized does it make sense
> to use #- and #+. personally, I use #- and #+ only in configuration
> files and in DEFSYSTEMs.
Has anyone done this already? Can I download a pre-done layer of
documented macro definitions from somewhere that will at least work
across CMUCL and Allegro CL? If I have to do it myself, not a huge
deal as long as I only do it for functions I use and not everything,
but standardization just makes it *that* much easier.
> feel free to complain that this veneer isn't standardized. I fully
> expect you to, but also that you will complain about whatever you get,
> the same way people complain about the pathname abstraction prohibiting
> them from running the whole gamut of file system options and operations
> on their particular implementation.
A little while back before my homework caught up with me I actually
kinda started to work on making a uniform interface between the ext:
and excl: file operation functions of Allegro and CMU Common Lisp
which provide a lot of the same functionality so that I could write
some intelligent Debian package management utilities for my personal
use to make up for where Apt and dpkg don't get it right for my
purposes. I don't want to commit to using only CMUCL or Allegro CL for
this or anything else just yet. CL-HTTP has been helpful though....
It's just *that* much more of an (IMO) unnecessary inconvenience.
Wasn't the whole point of Common Lisp that a lot of implementations
were providing largely equivalent functionality with a slightly
different interface? Everyone does sockets and threads these days and
a lot of the extension functions across implementations do almost the
exact same stuff. Are there any large, sophisticated, real-world apps
that are written these days in CL that don't do threads?
I should mention that CL-HTTP includes a lot of functions and macros
that unite some of the extension features found in all the CLs and
I've found it very useful and it's saved me a lot of time already. It
was obviously a lot of work to put all of that together and it would
be nice if this stuff could just always be relied upon to be there.
Christopher
Pierre Mai
> Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
> about 64-bit platforms? What will it do when we've got 128-bit ones?
???? ANSI Common Lisp doesn't have any size for FIXNUMs. It only
mandates that FIXNUM be a supertype of (signed-byte 16). But FIXNUMs
can grow to any size the implementation can support, i.e. given that
most current 32bit implementations use 2 tag bits, I'd guess that
64bit implementations would offer FIXNUMs with 62bit range. OTOH
there might be better uses for some of the added bits, who knows.
But the most important point is, that the size of FIXNUMs in CL
matters only for points of speed, which is as it should be. In CL you
don't worry about integer bittyness, unless you really need to, which
is either for speed or data-layout reasons, where you get the tools
for doing what needs to be done. And this doesn't change one jota even
if your plattform evolves. You just get the benefits, without the
hassles.
The standard doesn't have to change in any way to accomodate 2^n
plattforms for n>16.
> > How many times has the Java "standard" already changed?)
>
> It's been updated twice, and the runtime environment and browsers all
> still have to run the 1.0 code and 1.1 code too.
Which is twice too often for a standard of a language that's only been
around for 4-5 years. But of course this is to be expected, which is
why you just don't use languages this young for real work. You don't
even start standardization efforts, with a language this young. This
is the really unprecended thing about Java that scares me! We never
ever had so large a rush to one language which as yet hasn't even
started to settle down, let alone matured to any sufficient point.
Even C++ only ever got that amount of hype and public attention after
6-10 years of it's first definition (C with classes dates to 1980, in
1984 it started to be called C++, and most of the core features were
there).
> Why can't Lisp become more popular? What's stopping it? Do you think
> that the reasons outlined in "The Rise of Worse Is Better" are the
> _real_ reasons?
If anything, things have gotten worse: Whereas prior generations
preferred Unix (which went 90% of the way) to Multics&Co. (which
tried to go 100%), in more recent times, people have gotten less
critical, accepting 80%, 70%, 60% and less, without even flinching.
They only got slightly upset, when Microsoft consistently tried to
only go 20% of the way, and mocking those who complained. But who
will we be rescued by? Java/Sun, who will be hailed for going 40% of
the way?
It seems to me that much of Java's "success" stems from the fact, that
current users/programmers prefer an application that gives you
internet access, draws pretty pictures, is slow as hell even on the
most modern machines, insecure and so buggy that it crashes
about every 5-10 minutes to a program that works reliably and
stand-alone on reasonable machines and is rock solid. Mostly because
the first application is "cool", and the other one isn't[1].
Of course CL will never be able to match Java in coolness, since
coolness and reliability are mutually exclusive in the real world,
where resources are limited, and will be distributed according to
priorities. Dito for Ada. Is this a bad thing? Not in my book.
As long as the value-system and priorities of the masses are so at
odds with my priorities, I don't want the languages and tools I choose
to go mainstream and get popular. We don't have to change CL to make
it popular[2], we have to change popular priorities and value-systems.
Then popularity will follow naturally.
Regs, Pierre.
Footnotes:
[1] Just look at WWW browsers to see a real world example of this.
[2] We may of course see the need to change and expand CL to meet
demands of its user community, w.r.t to certain features or
clarifications. There are enough things to think about, but
popularity is not the driving force here.
--
Pierre Mai <pm...@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]
Pierre Mai
> I'll retract my statement. I believed in error that the standard
> required fixnums to be 30 bits, but it says that they must be at least
> 16 bits (well, have a range of 2^15-1 to -2^15). Pretty much the same
> requirement as the ANSI C "int" type.
Yes, and no. The important difference to C is:
a) Unless you actively prohibit this, FIXNUM arithmetic will overflow
correctly and automatically into BIGNUMs, so that a wrong estimate
on your part on the size of FIXNUMs will only cause performance
degradation and not wrong results.
b) There are additional type-specifiers that allow you to clearly
specify types based on your range and/or bit bestimates, so that
none of that "long int is 32bit, long int is 64bit, ..." guessing
is needed.
Regs, Pierre.
Pierre Mai
> > geez, why do you care? Common Lisp doesn't _have_ sizes of such things.
> > implementations do. C and C++, however, _do_ have sizes of such things.
> > C/C++ have the problem you allude to. Common Lisp just runs with a
> > little less consing on a machine with bigger machine integers.
>
> The specification for C's "int" and CL's "FIXNUM" are virtually
> identical.
No, they are not, since, as Kent Pitman has said here many times, you
cannot evaluate language features and their specs in isolation, but
must always consider the whole ecosystem provided by their standards,
environments etc. Your thinking that since both C and CL standards
require int/fixnum to be 16bit or more is any kind of counter argument
to Erik's statement, just very nicely demonstrates the dangers of not
doing this.
For more details on why C's int and CL's FIXNUM are not in any way
comparable, see my previous postings.
> Wasn't the whole point of Common Lisp that a lot of implementations
> were providing largely equivalent functionality with a slightly
> different interface? Everyone does sockets and threads these days and
> a lot of the extension functions across implementations do almost the
> exact same stuff. Are there any large, sophisticated, real-world apps
> that are written these days in CL that don't do threads?
So get your CL vendor to raise the point at the next meeting of the
standards comittee, should it be decided that the standard should be
revised, rather than reapproved.
If it is so, that all available threading and socket-based networking
APIs differ only in minor details, then taking this area into the
standard might be possible and sensible. Otherwise, the other vendors
and members of the comittee will surely object ;)
> I should mention that CL-HTTP includes a lot of functions and macros
> that unite some of the extension features found in all the CLs and
> I've found it very useful and it's saved me a lot of time already. It
> was obviously a lot of work to put all of that together and it would
> be nice if this stuff could just always be relied upon to be there.
So you got all of your functionality, for all the plattforms you care?
So you can actually do everything you want, don't you? You just want
the standards body to bless this, so you can sleep better at nights?
Well, sure this would be _nice_. But nice is not important, is it?
There are so many things that would be nice. The art of engineering
is dividing up the nice from the essential and then providing the
essential. If any resources are left over, you provide as much of the
nice as seems reasonable.
Steve Gonedes
< threads in CL without a hell of a lot of #+ and #- and have it work in
< ship source code.
<
< Christopher
Actually I just saw the neatest idea for handling the `#+' in the
scigraph program. It uses a reader macro called `#FEATURE-CASE'.
Really made things easier to read.
Also, in cl-http there is a wrapper layer for threads and I think
there is another one floating around on the net.
Kent M Pitman
> ANSI Common Lisp doesn't have any size for FIXNUMs. It only
> mandates that FIXNUM be a supertype of (signed-byte 16).
And doesn't it also say that the fixnum type has to be big enough that
all array indices can be declared fixnum? That's actually a pretty
important constraint on it, almost as important as the bitcount.
It's late and I'm too lazy to go browsing to be sure, though.
> The standard doesn't have to change in any way to accomodate 2^n
> plattforms for n>16.
Yes, and incidentally, Maclisp (parent of Common Lisp) ran on a 72 bit
architecture (Multics) back in the late 1970's. And I vaguely recall
there was a Common Lisp for the CDC 7600 in the mid to late 1980's, so
this biz of what are we going to do when we get to 64 bit
architectures is kinda funny...
Tim Bradshaw
> Common Lisp has a kinda oddball size for FIXNUMs. What is it doing
> about 64-bit platforms? What will it do when we've got 128-bit ones?
CL doesn't specify fixnum sizes (well it says they have to be bigger than
some small number of bits I think). RTFM before you flame.
--tim
Erik Naggum
I'm baffled. have you _read_ the specifications? a fixnum is simply a
more efficient integer, and some implementation-defined limits are less
than or equal to MOST-POSITIVE-FIXNUM, but you have know your compiler
real well before (+ fixnum fixnum) does not cause a bignum when needed.
what, precisely, is you gripe with the size of FIXNUM, anyway? methinks
you just have a fixation that you're trying blame Common Lisp for.
| > | Why can't Lisp become more popular?
| >
| > why can't opera be more popular? why can't football be less popular?
|
| I think your analogy is not the most suitable one. I think using Lisp
| over C or Java boils down to more than just personal taste and factors
| analogous to your analogy.
my point was that you ask a useless question that has no useful answer.
it is rare that you can explain why something is popular at any given
time. (and "marketing" begets the question "why did it work?", which all
marketing people will tell you is not something you sit down and predict.)
| > | What's stopping it?
| >
| > people like you.
|
| Okay, what can I realistically do to make it more popular?
you can stop posting drivel and actually go read the specification and
ask questions instead of posting wrong answers to questions people don't
ask. you see, people are _detracted_ from a gravitation towards Lisp as
they gain experience in their field and want self-improvement. this is
not at all the path you get if you ask about or measure popularity.
| Has anyone done this already? Can I download a pre-done layer of
| documented macro definitions from somewhere that will at least work
| across CMUCL and Allegro CL? If I have to do it myself, not a huge deal
| as long as I only do it for functions I use and not everything, but
| standardization just makes it *that* much easier.
I think your doing it yourself is a valuable exercise in understanding
(1) how this stuff should have been implemented, (2) the effort that goes
into standardization, and (3) the effort that goes into sharing quality
code with other people. maybe then you will realize what you're asking
for when you want everything for free.
| A little while back before my homework caught up with me I actually kinda
| started to work on making a uniform interface between the ext: and excl:
| file operation functions of Allegro and CMU Common Lisp which provide a
| lot of the same functionality so that I could write some intelligent
| Debian package management utilities for my personal use to make up for
| where Apt and dpkg don't get it right for my purposes. I don't want to
| commit to using only CMUCL or Allegro CL for this or anything else just
| yet.
this at least explains your problems. what you're doing is a waste of
time, although the purpose and goal is clear, so consider this: what you
sit down and design because CMUCL and Allegro CL do not agree on some
interface design is something you barely know how works and what you will
actually need from it once it does work. once it works well enough for
you to build something on top of, you will need to redesign it after you
have started to build something. only if you chose one implementation
and got enough stuff working to start feeding data back into the design
process can you hope to get the design right. what you're doign is
premature abstraction without an actual purpose or goal. "to make it
work in both Allegro CL and CMUCL" should not be a goal, it should fall
out your efforts as a result.
| It's just *that* much more of an (IMO) unnecessary inconvenience.
programming is all _about_ "unnecessary inconveniences", and every step
of progress tries to reduce their number. that's why good programmers
choose languages that have less unnecessary inconveniences than other
languages, but if you think you can avoid unnecessary inconveniences, I
think you should consider death and taxation first.
| Wasn't the whole point of Common Lisp that a lot of implementations were
| providing largely equivalent functionality with a slightly different
| interface?
yes, historically, this was the motivation for the standardization, as it
is with most good standardization, incidentally.
| Everyone does sockets and threads these days and a lot of the extension
| functions across implementations do almost the exact same stuff.
also true, but standards are basically removing functionality from the
market. the issue changes from "do you support FOO" to "do you conform
to the specification of FOO". the former is a feature if true, but
otherwise draws a blank. the latter draws a blank if true, and is
otherwise a reportable bug. to make standards work, all vendors must
agree to stop considering their features features, and start viewing them
as requirements. incidentally, this process parallels your Java vs CL
attitude: you argue against CL because you regard features in Java as
requirements of CL. this is, to put it mildly, hopelessly naive.
| Are there any large, sophisticated, real-world apps that are written
| these days in CL that don't do threads?
I cannot imagine otherwise. why do you?
| I should mention that CL-HTTP includes a lot of functions and macros that
| unite some of the extension features found in all the CLs and I've found
| it very useful and it's saved me a lot of time already. It was obviously
| a lot of work to put all of that together and it would be nice if this
| stuff could just always be relied upon to be there.
well, you have the CL-HTTP sources, and it is apparently not a problem
for you that you cannot use it commercially (which was a gripe you had
with Common Lisp implementations, so I have a minor problem understanding
what your actual and real concerns are).
#:Erik
Christopher R. Barry
> * cba...@2xtreme.net (Christopher R. Barry)
> | It's crippled, and you must pay if you want to use it commercially.
>
> sigh. what _are_ the other crippled features of this version?
Can you develop GUIs with it? The whole Java experience has been very
refreshing for me. I downloaded the JDK, Swing, an Emacs IDE and an
8MB tutorial + 3MB of API documentation (and there's still many more
docs to download) all for free and very conveniently and it included a
number of cool demo GUI apps and everything I needed to do anything.
Just like that. It felt *nice*. It's so *easy* to learn as well. It's
like I have 15 million classes to choose from I can just strap
together a neat little app in 10 minutes that I could also probably do
without difficulty in CL but I'd have to write like 10 different
classes first.
> and I find it slightly amusing that you, too, keep adding conditions that
> make you not choose Common Lisp, no matter how people answer your gripes.
I never _chose_ anything. Someone flamed Java and I said what I
thought Java did right. I like my Lisp systems a lot more than my JDK,
but Java has made me aware of stuff I'd like to be able to do in Lisp.
> | I would feel dishonest if I contacted Franz about getting an evaluation
> | copy of CLIM. I know that no matter how much I liked it, I could not at
> | this point in my life afford it.
>
> yeah, and I'm sure this is CLIM's fault. you said "Swing, unlike CLIM,
> doesn't cost $4000-$7000 to even try out on Unix." which was an outright
> lie, so now you would feel dishonest if you asked for a demo version, but
> you didn't feel dishonest when you lied to begin with?
Come on Erik, be fair. If you look at the history of this thread
you'll see that I said that before being informed otherwise. Now tell
me, do you think it would be okay if I asked to evaluate it for free
when I know I can't afford it right now?
> | It would be nice if it could be obtained under the same terms as the
> | Allegro CL Linux Trial Edition, where you can use it as long as you like,
> | and not feel obligated to purchase it.
>
> you can't use it as long as you like. can't you even read licenses?
> (yeah, I'm expecting another silly gripe, now.)
Hmm... sigh. Another assumption on my part. I'll have to get around to
reading that license. Sometime.
> you clearly confused what "would be nice" with what people think they
> might one day be able to profit from providing you. there ain't no such
> thing as a free lunch, remember?
They've got to get us using their products while we're young and still
in school so we know to tell our managers that we want to use CL for a
project once we're hired instead of thinking only in terms of how to
implement a solution using C++, Perl or Java.
All the other people in my Java class have pretty much only seen C,
VB, C++ or whatever and they're probably liking Java a lot more than
even I am.... They'll never learn to think Lisp.
> | After having been able to use Allegro CL so extensively, I know that at
> | some point in the future I would definately buy it if using Common Lisp
> | for a big project.
>
> good for you. I won't hold my breath.
Thanks. I love you to. :-)
> | There are a number of things that Java gets right though, like knowing
> | how to actually get a little mind share.
>
> yes, by lying, overstating, hyping, misrepresenting the facts, etc.
Or by letting me download everything at once and overwhelming me with
all its features and functionality and cool demonstration programs and
documentation and making suddenly aware of some things I'd really like
to be doing in Lisp....
> | Well, certainly not disgusted yet....
>
> you will, and the company that'll bring you to it: AT&T.¹
:-)
Christopher
Christopher R. Barry
> Raymond Toy wrote:
>
> > >>>>> "Simon" == Simon Leinen <si...@limmat.switch.ch> writes:
> >
> > Simon> Yeah, I'm always pleased when I see Lispy syntax hidden in
> > Simon> "mainstream" applications.
> >
> > Simon> Checkpoint Firewall-1 uses S-expressions to store the firewall
> > Simon> configuration that you (are supposed to :-) generate using a
> > Simon> relatively nice GUI.
> >
> > Simon> I think Confluent's "Visual Thought" drawing package also uses a Lispy
> > Simon> representation of its drawings.
> >
> > Add to that Rational Rose. It looks like the entire UML model is
> > stored in some Lispy representation, including window position
> > information.
> >
> > Ray
>
> Visula is an electronic CAD system which stores its database in a Lisp
> (S-expression) format.
While we're naming everything that uses Lispy representations we can
think of, let's not forget RTL, the intermediary representation of GNU
compilers.
Christopher
Erik Naggum
AFAIK, that was the whole idea, but since I don't use GUIs, I'm not
entirely sure what it can do. but why not try to read what Franz Inc
writes about this and ask them directly? on the Net, people argue about
whether year 2000 is a leap year or not, so it's not as if you can rely
on the answers you get.
| Hmm... sigh. Another assumption on my part. I'll have to get around to
| reading that license. Sometime.
before your next gripe about it would be a good value of "sometime".
| They've got to get us using their products while we're young and still in
| school so we know to tell our managers that we want to use CL for a
| project once we're hired instead of thinking only in terms of how to
| implement a solution using C++, Perl or Java.
does the medical profession provide kids with scalpels and syringes while
still in school so they get used to using them by the time some of them
will enter medical school? if not, why not?
seriously, I wonder where this wacky idea of yours comes from. lots of
people think that you have to accomodate kids, novices, and idiots in
order to _succeed_. that isn't quite true -- you need to do that to make
a mass market with millions of users. this always has enormous costs in
what you have to do to attract them. e.g., you think in terms of
"unnecessary inconveniences" instead of understanding that programming is
all about removing inconveniences that arise in your particular
application, and you want people to give you things instead of creating
them. that's lazy in the wrong way.
| All the other people in my Java class have pretty much only seen C, VB,
| C++ or whatever and they're probably liking Java a lot more than even I
| am.... They'll never learn to think Lisp.
oh, they will, in time. people come to Lisp for reasons of their own.
you can't push Lisp on people -- you can't push good taste on people.
#:Erik
Christopher R. Barry
> | A little while back before my homework caught up with me I actually kinda
> | started to work on making a uniform interface between the ext: and excl:
> | file operation functions of Allegro and CMU Common Lisp which provide a
> | lot of the same functionality so that I could write some intelligent
> | Debian package management utilities for my personal use to make up for
> | where Apt and dpkg don't get it right for my purposes. I don't want to
> | commit to using only CMUCL or Allegro CL for this or anything else just
> | yet.
>
> this at least explains your problems. what you're doing is a waste of
> time, although the purpose and goal is clear, so consider this: what you
> sit down and design because CMUCL and Allegro CL do not agree on some
> interface design is something you barely know how works and what you will
> actually need from it once it does work. once it works well enough for
> you to build something on top of, you will need to redesign it after you
> have started to build something.
Isn't this kinda like prototyping or "throwing the first one away", a
practice that as far as I know you do not believe in? But, I'm really
liking your advice so far.
> only if you chose one implementation and got enough stuff working to
> start feeding data back into the design process can you hope to get
> the design right. what you're doign is premature abstraction
> without an actual purpose or goal. "to make it work in both Allegro
> CL and CMUCL" should not be a goal, it should fall out your efforts
> as a result.
So far I've been using both CMUCL and Allegro about equally as much. I
often run both of them at the same time in a split Emacs frame, and
send each the same input when I'm trying new stuff from the
HyperSpec. It's interesting to observe all the differences in error
handling and formatting and compiler messages and GC time and
frequency and other things. I've been trying very hard to avoid using
one dominantly, and have been focusing heavily with portability
between the 2. But I guess I have to make a choice now of the one I'm
going to commit to writing a full application in first before looking
into portability to the other. I guess this isn't as bad as I've been
thinking it is and I'll have to accept this as just the way it is.
> | It's just *that* much more of an (IMO) unnecessary inconvenience.
>
> programming is all _about_ "unnecessary inconveniences", and every step
> of progress tries to reduce their number. that's why good programmers
> choose languages that have less unnecessary inconveniences than other
> languages, but if you think you can avoid unnecessary inconveniences, I
> think you should consider death and taxation first.
That puts some interesting perspective on it.
> | Everyone does sockets and threads these days and a lot of the extension
> | functions across implementations do almost the exact same stuff.
>
> also true, but standards are basically removing functionality from the
> market. the issue changes from "do you support FOO" to "do you conform
> to the specification of FOO". the former is a feature if true, but
> otherwise draws a blank. the latter draws a blank if true, and is
> otherwise a reportable bug. to make standards work, all vendors must
> agree to stop considering their features features, and start viewing them
> as requirements. incidentally, this process parallels your Java vs CL
> attitude: you argue against CL because you regard features in Java as
> requirements of CL. this is, to put it mildly, hopelessly naive.
Okay, I'll get over it.
> | Are there any large, sophisticated, real-world apps that are written
> | these days in CL that don't do threads?
>
> I cannot imagine otherwise. why do you?
I was imagining being able to do this in an CL though kinda like with
Java, "imagining" being the operative word. Sigh.
Christopher
Espen Vestre
> The specification for C's "int" and CL's "FIXNUM" are virtually
> identical.
others have pointed out that you're wrong.
I'd just like to point out that I think it's a good motto to
stay away from fixnum declarations until your profiler suggests you
to consider using them. CLs general integers has saved lisp programmers
from a *lot* of problems, and will still do (-> the 2038 problem).
--
(espen)
Tim Bradshaw
> The specification for C's "int" and CL's "FIXNUM" are virtually
> identical.
Erm, no. If you overflow an int in C you die horribly, if yu overflow
a fixnum things just get a bit slow. What happens in C when your nice
32bit int time type overflows? What happens in CL when the time
overflows a fixnum (hint: it already has for any implementation I know
of).
> I should mention that CL-HTTP includes a lot of functions and macros
> that unite some of the extension features found in all the CLs and
> I've found it very useful and it's saved me a lot of time already. It
> was obviously a lot of work to put all of that together and it would
> be nice if this stuff could just always be relied upon to be there.
Well, better than complaining would be to put some work into a
proposed standard <x> interface for CL and post it for comments.
--tim
Erik Naggum
| practice that as far as I know you do not believe in? But, I'm really
| liking your advice so far.
there's a nuance here that seems to get lost all the time. first, some
people _believe_ in prototyping (in another language), i.e., they do it
whether it makes sense or not. sometimes, it makes sense to do it.
second, "throwing the first version away" is something you do if you need
to, not something you should out to do, because then you'll end up maybe
having to throw the second version away, too.
my argument against what you're doing is that you involve yourself in
low-level stuff long before you know how to do either low-level or
high-level stuff. you will learn the wrong thing from this experiment
and will retain whatever was reasonably simple to implement, not what is
good design. simplifying the design is sometimes necessary when the cost
of implementing it proves too costly. if you implement it in one of the
environments at a time, you may call it prototyping. if you implement it
in both, you're trying to evolve production code. this will fail.
| I was imagining being able to do this in an CL though kinda like with
| Java, "imagining" being the operative word. Sigh.
well, maybe Java has a place in the grand order of things, but to make
Java really work, I want serious protocol engine support, since the Java
applet is going to talk to a server, and it'd be nice if that was using a
reasonably standard protocol. as far as I know, CORBA support is not
"standard" in Java, and despite it's cost and the introduction of yet
another language (IDL) is the most promising way to deal with this mess.
#:Erik
Johan Kullstam
> cba...@2xtreme.net (Christopher R. Barry) writes:
>
>
> > The specification for C's "int" and CL's "FIXNUM" are virtually
> > identical.
>
> Erm, no. If you overflow an int in C you die horribly, if yu overflow
> a fixnum things just get a bit slow. What happens in C when your nice
> 32bit int time type overflows? What happens in CL when the time
> overflows a fixnum (hint: it already has for any implementation I know
> of).
nod.
however, what if i actually *want* a wrap around. i do not want an
integer but a number from the ring Z_n.
this is not an idle question. i could actually use this. for
example, i am measuring angles on a satellite dish pedestal and my
sensor equipment maps the angle to a number from 0 to 65535. it'd be
nice to wrap around automatically, since the concept i am trying to
handle - angles - do this.
i.e., (+ angle1 angle2) should return a new angle in the canonical
angle format 0 to 65535.
other times it'd be nice to have a wrapping integer type is for
periodic time-varying filter operations in a modem.
the books i have seen are a little weak on the number crunching, bit
banging side of the house. i hear that lisp can be as fast as fortran
on numeric problems. i have come to lisp out of disgust with C++ and
i am finding that i like lisp. but is they any information on how to
solve those problems which are traditionally done in fortran or C?
--
Johan Kullstam [kull...@ne.mediaone.net] Don't Fear the Penguin!
Howard R. Stearns
>
> You forgot that you can run Java programs on every windows and Solaris
> computer in the world!
Well that's the idea, and indeed, I do believe that a good byte code
format that can be compiled once and run anywhere is a good thing, and
if it existed, should be widely used. However:
1. That is a function of the Java Virtual Machine (JVM), and not a
feature of the Java programming LANGUAGE. Other languages could use the
JVM, too, if it worked right.
2. I don't believe that your statement is correct -- you can't reliably
run it anywhere. Anecdotaly, I read this week about some drug maker
that had a lot invested in some client-server apps. They used a Java
applet on the client side, and ALL THEIR CLIENT MACHINES WERE RUNNING
WINDOWS. Unfortunately, the Windows implementation of the JVM was
broken and the app didn't run. They had to have someone (Oracle?) build
them a special JVM for Windows.
Now instead of having an application that was written once and running
on all platforms, they have an application that was written more than
once and running only on one. And this BECAUSE OF, not despite, the
fact that they relied on the univerality of the JVM.
Now this is just one story, and I can't even recall the source
(Performance Computing???) Furthermore, I get a lot of free magazines
and they're worth every penny I pay. So take this all with a grain of
salt.
Nonetheless, I think the point is fair that the JVM is MARKETED as
universal, but in practice it is technically no closer than, say, CLISP
byte-code. You might believe that market forces are likely to make that
dream a reality sooner for JVM than for alternatives, but that's another
story, and it's not quite what you said.
Tim Bradshaw
> however, what if i actually *want* a wrap around. i do not want an
> integer but a number from the ring Z_n.
You can use MOD &c to get this. You might either define some new type
(which would probably be slow because you'll have to wrap the
numerical value in something), or you can do mod-n arithmetic on
ordinary numerical types. If you really want `+' &c. to do mod-n
arithmetic you can manipulate the package system so that it does (or
rather, the symbol named "+" in the current packages does). You can
choose what n you want, though declaring it a constant might (?) help
the compiler at the cost of flexibility.
If your numbers are close to being bignums you might have to be clever
about avoiding doing (MOD (+ .... lots of numbers ...) n), but that
would really depend on what code actually got generated I guess.
It ought to be the case that, if the numbers are fixnums and if you
can tell the system they are, that you get pretty good performance
from this.
--tim
Ian Garmaise
wrote:
>
>Checkpoint Firewall-1 uses S-expressions to store the firewall
>configuration that you (are supposed to :-) generate using a
>relatively nice GUI.
>
>I think Confluent's "Visual Thought" drawing package also uses a Lispy
>representation of its drawings.
>
I just downloaded a demo of a UML design and reverse engineering
package called Pragmatica. Very nice. Uses lisp as a scripting
language to handle code generation.
Ian
Duane Rettig
> Tim Bradshaw <t...@tfeb.org> writes:
>
> > cba...@2xtreme.net (Christopher R. Barry) writes:
> >
> >
> > > The specification for C's "int" and CL's "FIXNUM" are virtually
> > > identical.
> >
> > Erm, no. If you overflow an int in C you die horribly, if yu overflow
> > a fixnum things just get a bit slow. What happens in C when your nice
> > 32bit int time type overflows? What happens in CL when the time
> > overflows a fixnum (hint: it already has for any implementation I know
> > of).
>
> nod.
All this talk of fixnums gives one a headache. Fixnums are the wrong
way to think in CL; even seasoned CL programmers get into the bad
habit of thinking in terms of fixnums instead of ranged integers.
They (we) tend to fall back on our knowledge of the size of our lisp's
fixnum out of laziness. What we tend to mean when we say "fixnum" is
really "some small intgeger that will not get slow in calculations".
The canonical form of the fixnum type specification is
'(integer #.most-negative-fixnum #.most-positive-fixnum)
which at least one CL I know of converts to at its first chance:
USER(1): (excl::type-canonicalize 'fixnum)
(INTEGER -536870912 536870911)
USER(2):
> however, what if i actually *want* a wrap around. i do not want an
> integer but a number from the ring Z_n.
Tim Bradshaw goes on to give you the correct answer for this, using
MOD. However, saying that you do not want an integer is not quite
correct; you really do want an integer, restricted in range.
> this is1 not an idle question. i could actually use this. for
> example, i am measuring angles on a satellite dish pedestal and my
> sensor equipment maps the angle to a number from 0 to 65535. it'd be
> nice to wrap around automatically, since the concept i am trying to
> handle - angles - do this.
>
> i.e., (+ angle1 angle2) should return a new angle in the canonical
> angle format 0 to 65535.
If you want to provide declarations for the intgeer range to match
this hardware, you would specify '(integer 0 65535). Better would
be to use a deftype:
USER(14): (deftype dish-angle () '(integer 0 65535))
DISH-ANGLE
USER(15): (subtypep 'dish-angle 'fixnum)
T
T
USER(16): (subtypep 'bit 'dish-angle)
T
T
USER(17):
--
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 du...@Franz.COM (internet)
Duane Rettig
>
> > You forgot that you can run Java programs on every windows and Solaris
> > computer in the world!
>
> and ...
The same can be said about CL; at least one CL implementation runs on
just about every Unix; usually there are two or three on each. At
least one CL (though not ours) runs on MacOS. Our lisp used to run
on both Crays and NeXT boxes, but we discontinued them for business
reasons. (And you forgot IBM 360/370; Amdahl had a Unix called UTS
and we ran on that ...)
> and ...within 2 web browsers that run on OSs covering 99% of the OS
> market share.
You can run a CL plugin on either Windows browser. As for the Unix
browsers, we have theorized that it may be possible to run a plugin
on a Unix Netscape without needing native os-threads, but we choose
to follow the path to get native os-threads out first, and then the
browser plug-in capability will be much easier. Perhaps the former
would be a good project for you; you have the tools you need: linux,
a free netscape, a free lisp, the ability to load it into a non-lisp
environment and call it as subroutines ...
Raymond Toy
Johan> the books i have seen are a little weak on the number crunching, bit
Johan> banging side of the house. i hear that lisp can be as fast as fortran
One starting point on number crunching in Lisp can be found in the
CMUCL User's Guide (see www.cons.org). It's written for CMUCL, but
the hints there probably apply to all implementations of Lisp.
Johan> on numeric problems. i have come to lisp out of disgust with C++ and
Johan> i am finding that i like lisp. but is they any information on how to
Johan> solve those problems which are traditionally done in fortran or C?
You can solve them in exactly the same way, I would think. Your Lisp
code might look more like Fortran or C, but so what? It works now,
and if you want, you can redo it later.
Ray
Paolo Amoroso
wrote:
> i am finding that i like lisp. but is they any information on how to
> solve those problems which are traditionally done in fortran or C?
You may check:
"Fast Floating Point in Common Lisp"
K.A. Broughan, R.J. Fateman, D. Rettig, D.K. Willcock
ftp://peoplesparc.berkeley.edu/pub/papers/lispfloat.ps
"Floating Point Performance of Common Lisp"
Christopher J. Vogt
ACM SIGPLAN Notices, Vol. 33, N. 9, September 1998, page 103
Paolo
--
Paolo Amoroso <amo...@mclink.it>
Steve Gonedes
Johan Kullstam <kull...@ne.mediaone.net> writes:
< nod.
<
< however, what if i actually *want* a wrap around. i do not want an
< integer but a number from the ring Z_n.
<
< this is not an idle question. i could actually use this. for
< example, i am measuring angles on a satellite dish pedestal and my
< sensor equipment maps the angle to a number from 0 to 65535. it'd be
< nice to wrap around automatically, since the concept i am trying to
< handle - angles - do this.
<
< i.e., (+ angle1 angle2) should return a new angle in the canonical
< angle format 0 to 65535.
<
< other times it'd be nice to have a wrapping integer type is for
< periodic time-varying filter operations in a modem.
<
< the books i have seen are a little weak on the number crunching, bit
< banging side of the house. i hear that lisp can be as fast as fortran
< on numeric problems. i have come to lisp out of disgust with C++ and
< i am finding that i like lisp. but is they any information on how to
< solve those problems which are traditionally done in fortran or C?
<
< --
< Johan Kullstam [kull...@ne.mediaone.net] Don't Fear the Penguin!
You can define a new type and keep the number withing a range using
ldb.
(deftype signed-short () '(signed-byte 16))
(defun add-signed-shorts (x y)
(the (signed-short)
(ldb (byte 16 0) (+ x y))))
(add-signed-shorts 65535 12)
=> 11
The declaration is really just cosmetic, but maybe useful for readers
of your program. The call to `ldb' is like `ash' with my
implementation. It just provides you with a nice abstraction.
Erann Gat
R. Barry) wrote:
> Steve Gonedes <sgon...@worldnet.att.net> writes:
>
> > You forgot that you can run Java programs on every windows and Solaris
> > computer in the world!
>
> And almost every Unix computer (even Crays), and the MacOS, and NeXT,
> and ...within 2 web browsers that run on OSs covering 99% of the OS
> market share.
Actually, Common Lisp also runs on nearly everything. I'm not sure
about Crays and NeXT (who uses NeXT any more?) but CL definitely
runs on Mac, Wintel, Linux, Suns, and even vxWorks. CLisp will run
on pretty much anything that has a C compiler.
E.
Christopher R. Barry
> as far as I know, CORBA support is not "standard" in Java, and
> despite it's cost and the introduction of yet another language
> (IDL) is the most promising way to deal with this mess.
CORBA is now "standard" in Java 1.2. <http://java.sum.com> links to
some good documentation of it.
Christopher
Mike McDonald
Kent M Pitman <pit...@world.std.com> writes:
> Yes, and incidentally, Maclisp (parent of Common Lisp) ran on a 72 bit
> architecture (Multics) back in the late 1970's. And I vaguely recall
> there was a Common Lisp for the CDC 7600 in the mid to late 1980's, so
> this biz of what are we going to do when we get to 64 bit
> architectures is kinda funny...
And conses were "interesting" too. They had three fields, CAR, CDR, and I
think CXR. CXR was used as a property list! (Addresses were 22bits so three of
them would fit in a 72bit word.)
Mike McDonald
mik...@mikemac.com
Johan Kullstam
> Johan Kullstam <kull...@ne.mediaone.net> writes:
> > however, what if i actually *want* a wrap around. i do not want an
> > integer but a number from the group Z_n.
>
> Tim Bradshaw goes on to give you the correct answer for this, using
> MOD. However, saying that you do not want an integer is not quite
> correct; you really do want an integer, restricted in range.
no, i do *not* want an integer (at least in the mathematical sense).
i want elements of Z_n = Z - <n> which is not the integers Z but
equivalence classes on Z, i.e., Z modulo multiples of n. the math in
Z - <n> is different from integer math. mapping elements of Z - <n>
into a subset of fixnum or bignum would be a particular
representation. operations on the group elements do not follow the
`conventional' integer operations.
eg in Z_2 let the elements be denoted z2_0 and z2_1. define the `+'
operation to do
z2_0 + z2_0 = z2_1 + z2_1 = 0 and z2_0 + z2_1 = z2_1 + z2_0 = z2_1.
integers do not work this way. they follow different rules.
modern algebra such as groups rings and fields has not only variable
values, but the operations like `+' are also a `variable'. however the
operations follow some rules (eg associative commutative &c) and
deductions can be based on that.
it'd be interesting to see if lisp can set up eg functions which
depend upon group operations. the particular group (its elements,
their representation and how the operation acts) would be specified
later.
Kent M Pitman
Uh, I think CXR (pronounced "COOK-sir") was the Maclisp hunk accessor.
If memory serves, the CDC7600 Lisp used CSR (I think pronounced "Kisser")
for the "middle" of a cons. Also, I thought the CDC wordsize was 64 bits.
But I might be wrong. Anyway, none of this contradicts the main point.
People should start making permanent records, e.g., in web pages or
archival media of some form, documenting these parts of computer
history. Very little of what was done between 1960 and 1994 (birth of
the web) will survive if aggressive work is noe done to preserve it
now while there are people alive who remember. And so much of it was
on now-yellowing line printer paper... I'm working aggressively on the
Maclisp piece and making progress slowly. But I don't know to what
degree there's any historical record of the CDC Lisp. Of course, some
people have written books. But that's a lot of work and considerable
stuff gets lost that's interesting for lack of someone willing to do
the formal effort of a book. Not to mention the expense. Sigh.
Mike McDonald
Kent M Pitman <pit...@world.std.com> writes:
> mik...@mikemac.com (Mike McDonald) writes:
>
>> In article <sfwn22d...@world.std.com>,
>> Kent M Pitman <pit...@world.std.com> writes:
>>
>> > Yes, and incidentally, Maclisp (parent of Common Lisp) ran on a 72 bit
>> > architecture (Multics) back in the late 1970's. And I vaguely recall
>> > there was a Common Lisp for the CDC 7600 in the mid to late 1980's, so
>> > this biz of what are we going to do when we get to 64 bit
>> > architectures is kinda funny...
>>
>> And conses were "interesting" too. They had three fields, CAR,
>> CDR, and I think CXR. CXR was used as a property list! (Addresses
>> were 22bits so three of them would fit in a 72bit word.)
>
> Uh, I think CXR (pronounced "COOK-sir") was the Maclisp hunk accessor.
> If memory serves, the CDC7600 Lisp used CSR (I think pronounced "Kisser")
> for the "middle" of a cons. Also, I thought the CDC wordsize was 64 bits.
> But I might be wrong. Anyway, none of this contradicts the main point.
How about 60bit words with 18bit addresses. I remember the cons had 6bits
for the type code and there wasn't much memory.
Mike McDonald
mik...@mikemac.com
Rainer Joswig
> well, you have the CL-HTTP sources, and it is apparently not a problem
> for you that you cannot use it commercially (which was a gripe you had
> with Common Lisp implementations, so I have a minor problem understanding
> what your actual and real concerns are).
People are using CL-HTTP in commercial products.
Felix Winkelmann
>
> I am no expert, but I'd almost think that compiling Common Lisp could
> be easier than Scheme. The lack of CALL/CC might be a facilitating
> factor. Anybody care to comment?
>
There still is the thing about function-invocation (dynamically), where
you must wrap every procedure into its own class and call some
'apply'-method then. This looks very expensive to me.
Actually, how fast are Scheme-implementations like KAWA ?
William Paul Vrotney
In article <gat-170299...@milo.jpl.nasa.gov> g...@jpl.nasa.gov (Erann
Gat) writes:
>
> > Steve Gonedes <sgon...@worldnet.att.net> writes:
> >
> > > You forgot that you can run Java programs on every windows and Solaris
> > > computer in the world!
> >
> > And almost every Unix computer (even Crays), and the MacOS, and NeXT,
> > and ...within 2 web browsers that run on OSs covering 99% of the OS
> > market share.
>
> Actually, Common Lisp also runs on nearly everything. I'm not sure
> about Crays and NeXT (who uses NeXT any more?) but CL definitely
Yes. I have Allegro, GCL, Clisp running on my NeXT. Although I mostly use
my Linux box now, I miss the elegance of NeXT and sometimes wish Linux could
have a nice well developed alternative to X windows.
--
William P. Vrotney - vro...@netcom.com
Erik Naggum
| I'm not sure about Crays and NeXT (who uses NeXT any more?) ...
when he first NeXT cube arrived at the U of Oslo, I found two interesting
things: (1) it had a _real_ dictionary on it, Merriam-Webster's Ninth
Collegiate, and (2) it had a _real_ Common Lisp on it, Allegro CL from
Franz Inc. unfortunately, it was locked up in a room and was not even
made accessible to the systems hackers, only academic employees and some
graduate students.
#:Erik
Erik Naggum
| no, i do *not* want an integer (at least in the mathematical sense).
the MD5 algorithm requires a number of operations on 32-bit machine
integers. it would have cost them approximately nothing to require them
to be bignums (the algorithm is basically written in machine language,
and it appears only foolish to try anything else). the solution is to
use LOGAND to mask out the number bits. I'm probably going to rewrite
MD5 in assembler -- the C code is amazingly non-optimal, too.
#:Erik
Erik Naggum
| People are using CL-HTTP in commercial products.
so people keep telling me, but it is not quite what I asked. people are
using Microsoft source code in commercial products, too, but that doesn't
mean it is something you can just go and buy. so, what kind of license
are the people you refer to using? whose is the actual signature on the
license agreement? why can I not find something that allows _everybody_
to use it commercially? (yes, I have looked. the license agreeements
that come with CL-HTTPD is worse than the GPL in its restricions.)
#:Erik
Christopher R. Barry
> You can run a CL plugin on either Windows browser.
This got me interested enough to actually download Allegro CL 5.0 Lite
(I've been meaning to look at it for a while) and Netscape 4.5 for
Windows and reboot to the thing for the first time in 1999 (God knows
how many months it's really been). Allegro for Windows is really,
really different... the Common Graphics thing is a lot like the Garnet
interface builder (at least from the 45 seconds I played with it).
Anyways, there are four files I'm supposed to copy into the Netscape
plugins directory, including one called lnkacl.dll that is supposed to
be in #p"sys:". Netscape gives me an error dialogue when I try to run
the thing, but seems to indicate that the plugin is registered okay.
Was the lnkacl.dll accidentally not included in Lite? The docs
specific to Lite say that a prebuilt *.dxl for the plugin is provided
since Lite doesn't have the capability to generate it, and you guys
probably wouldn't provide this without intending that people with Lite
be able to run the plugin example.
Christopher
Jim White
>Steve Gonedes wrote:
>>
>> You forgot that you can run Java programs on every windows and
Solaris
>> computer in the world!
>1. That is a function of the Java Virtual Machine (JVM), and not a
>feature of the Java programming LANGUAGE. Other languages could use
the
>JVM, too, if it worked right.
Quite true. Here is a list of about 60 of them:
<http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html>
There are a dozen LISP dialects, including a *very* nice compiling
Scheme called Kawa (free - open source):
<http://www.cygnus.com/~bothner/kawa.html>
No CL though (yet).
The Java VM platform greatly enhances the value of having many
languages. The (evolving) cross platform capability, large library of
very useful stuff, secure networked deployment, and tremendously
enhanced interlanguage compatibility provide immense benefit right now.
By virtue of the fact that performance is directly a function of
resources devoted to development, as time and resources continue to be
devoted to the JVM, it will eventually outperform practically every
other language compilation/runtime solution.
jim
-------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC
Tim Bradshaw
> no, i do *not* want an integer (at least in the mathematical sense).
> i want elements of Z_n = Z - <n> which is not the integers Z but
> equivalence classes on Z, i.e., Z modulo multiples of n. the math in
> Z - <n> is different from integer math. mapping elements of Z - <n>
> into a subset of fixnum or bignum would be a particular
> representation. operations on the group elements do not follow the
> `conventional' integer operations.
Yes, I agree you don't want integers. But if you want an efficient
representation, you probably do need to represent them as integers,
because languages (even lisp) find it difficult to provide new
`nuerical' types that the hardware does not support a representation
of with any reasonable efficiency without sneakily using one that it
does. And choosing a representation matters unfortunately.
(of course, most HW *does* support Z_n but typically only for n =
2^8,2^16,2^32 and 2^32).
--tim
Tim Bradshaw
>
> so people keep telling me, but it is not quite what I asked. people are
> using Microsoft source code in commercial products, too, but that doesn't
> mean it is something you can just go and buy. so, what kind of license
> are the people you refer to using? whose is the actual signature on the
> license agreement? why can I not find something that allows _everybody_
> to use it commercially? (yes, I have looked. the license agreeements
> that come with CL-HTTPD is worse than the GPL in its restricions.)
>
I guess this should be on the CL-HTTP list, but I agree with this
strongly. The license was unusable, and also very unclear as to what
it actually meant, about 2 years ago, and I got no response at all
when I asked about a more liberal & clear one (say BSD/X11-style).
Right now if I had to do serious work using a Lisp web server, I'd
probably have to write one, which is a tragedy. If the CL-HTTP people
are listening, please clarify this stuff!
(And can we avoid a huge argument about the GPL? At least on this group.)
--tim
Marco Antoniotti
cba...@2xtreme.net (Christopher R. Barry) writes:
> Marco Antoniotti <mar...@copernico.parades.rm.cnr.it> writes:
>
> > cba...@2xtreme.net (Christopher R. Barry) writes:
> >
> > > It would be nice if Common Lisp could at least standardise some of the
> > > networking, threads and i/o functionality you get in Java, and if it
> > > had a standard, accessible and reasonably priced GUI toolkit.
> >
> > I'd settle for DEFSYSTEM, MULTIPROCESSING and FFI.
>
> At least Mark Kantrowitz's defsystem runs on just about every CL out
> there. The Allegro one is kinda nicer, but I think Mark's has all the
> functionality you really need to get the job done. Standardization
> would not hurt though.
MK Defsystem is what I use. I know that it runs on *all* the major CL
implementations. Unfortunately, Mark Kantrowitz disappeared from the
face of the ... well at least this newsgroup.
Franz's is a little nicer, but nut that much. I personally find that
(aparto from a couple of "semantic" glitches) MK:DEFSYSTEM is a very
elegant program.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - (0)6 - 68 10 03 17, fax. +39 - (0)6 - 68 80 79 26
http://www.parades.rm.cnr.it
Raymond Wiker
> MK Defsystem is what I use. I know that it runs on *all* the major CL
> implementations. Unfortunately, Mark Kantrowitz disappeared from the
> face of the ... well at least this newsgroup.
Hum. I did a little searching a while back, and came up with
something that appears to be a recent and valid address for Mark
Kantrowitz. See http://www.ptf.com/ptf/staff/P/kantrowitz.shtml
--
Raymond Wiker, Orion Systems AS
+47 370 61150
Matthew X. Economou
HRS> Other languages could use the JVM, too, if it worked right.
Last year, from about April to May, a group of us wrote a Tiger-to-JVM
compiler (in Java) for a Compilers course at Rose-Hulman. The course
was 10 weeks long, and it took us about 8 weeks to get a featureful
compiler. Tiger is Andrew Appel's ML knock-off used in his (very
good, IMHO) _Modern Compiler Implementation_ text book. The version
of Tiger we implemented included record types and top-level function
definitions, but not closures or nested functions (couldn't figure out
how to cleanly build environments, plus we ran out of time).
Our Tiger compiler generated JVM 1.1 bytecodes using the wonderful
JASMIN package (which itself, in part, uses Scheme).
--
"When I was a kid, I used to think that Dammit was God's last name, just like
Christ is Jesus' last name." - Kimberly Chapman in rec.humor.oracle.d
Peter Van Eynde
>Erik Naggum <er...@naggum.no> writes:
>
>>
>> so people keep telling me, but it is not quite what I asked. people are
>> using Microsoft source code in commercial products, too, but that doesn't
>> mean it is something you can just go and buy. so, what kind of license
>> are the people you refer to using? whose is the actual signature on the
>> license agreement? why can I not find something that allows _everybody_
>> to use it commercially? (yes, I have looked. the license agreeements
>> that come with CL-HTTPD is worse than the GPL in its restricions.)
>>
>
>I guess this should be on the CL-HTTP list, but I agree with this
>strongly. The license was unusable, and also very unclear as to what
<AOL>Me too</AOL>
I actually went out and asked the Debian mentors about the license
and the responses went from "strange" to "you're not even allowed to
copy this code, let alone compile and use it!".
>it actually meant, about 2 years ago, and I got no response at all
>when I asked about a more liberal & clear one (say BSD/X11-style).
I pleaded that inclusion in Debian would result in a larger penetration and
therefore would get it more users/developers (the Debian CMUCL release
is aimed at beginners/students). The response was "cl-http has enough
users already". :-(
>(And can we avoid a huge argument about the GPL? At least on this group.)
I don't care what license it has, as long as I can understand it!
(even if the license is "forbidden to copy, compile, distribute or
use" I would know that I should be looking elsewhere... now...)
Groetjes, Peter
--
It's logic Jim, but not as we know it. | pvan...@debian.org for pleasure,
"God, root, what is difference?",Pitr | pvan...@inthan.be for more pleasure!
Erik Naggum
| By virtue of the fact that performance is directly a function of
| resources devoted to development, as time and resources continue to be
| devoted to the JVM, it will eventually outperform practically every
| other language compilation/runtime solution.
to get this behavior from the business community, you would have to
encourage investors with a linear growth in features. once you go
logarithmic on investors, they find something else with exponential or
linear growth. Microsoft's pyramid game of trust in its future ability
to fix past mistakes will be killed just this way.
I'm frankly suspicious of the high interest in Java at the moment -- from
what I have read about the "AI summer", people's hopes and expectations
were so high that actual achievements were disappointing, and after that
followed the "AI winter" and reasonable, realistic people turned away
from AI out of a sense of having been fools to have believed the hype.
the still frosty reactions to Lisp stem from this period.
the treatment that AI got was bad enough, but I don't see any evidence
indicating that something of importance has been learned from it, and
this is a bit surprising considering the number of Lisp people in the
core Java community.
so I'm frankly not sure Java will sustain investor interest long enough
to overtake much anything since the principle attractor is currently a
disturbing (to me) growth in features with premature specifications,
which only _add_ to the distance between Java and mature languages. add
to this that fancier features require significantly more resources to
specify well because fewer people really know how they should work and
much fewer people will have the mental capacity to relate them to the
rest of the language if they are not well-designed.
Java effectively killed the investments in C++ that were also slated to
outperform every other language according the hype that has now been put
to shame. _perhaps_ Microsoft's Java killer "COOL" (geez, how nerdy can
you _get_?) will just be enough of an investment detractor that COOL will
be another Microcruft product and Java will struggle with buggy and fancy
features for a long time to come?
I hate it when political overtake technological reasons for success, but
Java may well have put itself in such a position by having its own
political motivation and in effect playing Microsoft's con game. those
who live by politics will die by politics.
#:Erik
Rainer Joswig
> I actually went out and asked the Debian mentors about the license
> and the responses went from "strange" to "you're not even allowed to
> copy this code, let alone compile and use it!".
I don't know what part of the license would be the reason for that.
Maybe somebody can explain it to me.
The license:
> License Agreement for
> The Common Lisp Hypermedia Server (CL-HTTP)
>
>
> CL-HTTP is Copyright (c) John C. Mallery, 1994-1998. All rights reserved.
> Some files carry copyrights by other parties, which should be respected.
>
> CL-HTTP is distributed in the hope that it will be useful but WITHOUT ANY
> WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
> A PARTICULAR PURPOSE.
>
> By using the server or retaining a copy of the distribution, you acknowledge
> that you accept the terms and limitations of this license.
>
> Personal, educational, and commercial uses are allowed and may incorporate
> CL-HTTP into applications provided that:
>
> a. The licensee preserves all original copyrights in the CL-HTTP
> files;
>
> b. The licensee clearly separates their own code from the distributed
> sources;
>
> c. The licensee submits any extensions or improvements to CL-HTTP to
> the developers at bug-c...@ai.mit.edu;
>
> d. The licensee prominently displays the fact that your application
> uses CL-HTTP;
>
> e. The licensee prominently indicates that CL-HTTP was developed by
> and is owned by John C. Mallery;
>
> f. The licensee advises their users that they may obtain the latest
> release of CL-HTTP from ftp://ftp.ai.mit.edu/pub/users/jcma/cl-http/
>
> g. The licensee advises their users that that the homepage for the
> server is located at
> http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
>
> h. The licensee informs the CL-HTTP user community of any novel or
> significant uses in a timely manner by submitting a short description
> of the server to www...@ai.mit.edu
>
> However, all academic or commercial publication rights for CL-HTTP server in
> any form are hereby reserved.
>
> Additionally, all rights are reserved to any derivative works based on the
> Lisp source code in the CL-HTTP distribution, in particular but not limited to
> any automatic or manual translation of the source code into other computer
> languages or executables.
>
> Any rights not explicitly waived are retained.
>
> Subsequent versions of CL-HTTP may have different copyright statements and
> license requirements once it becomes clear precisely what arrangements best
> serve the Lisp community.
>
> In the meantime, the right to change this license for CL-HTTP in anyway at
> anytime is hereby reserved, any prior clauses notwithstanding.
>
> If any of elements of this agreement are found to be unenforceable, the others
> will remain in effect.
>
> This license agreement is governed by the laws of the Commonwealth of
> Massachusetts and the United States of America.
>
> The author can be contacted at:
>
(Address not posted).
To me it sums up to following:
- I can use the code
- I have to tell that I use the code and I have to submit
extensions/improvements back to the developers
If some people cannot live with that, their problem. But, for example
telling that it generally is not usable in a commercial way
is plain wrong.
Sorry, but this whining about CL-HTTP really pisses me off. People
have contributed a lot of time and effort that it runs
on a variety of platforms and they try to keep track
of standards (read the HTTP 1.1 standard and you might get an idea).
I'm not really sure if other people really appreciate how
much work and knowledge has gone into this stuff
(for example just to make TCP/IP actually work in some Lisp
implementations). I really don't like CL-HTTP to go the route
of some other "closed" or "open" Lisp packages -> "dead end".
Lisp users have the luck to have access to a system that
incorporates some real cool stuff and a large library of
networking code. Some users have built even more cool
applications on top of that. Actually CL-HTTP is thought
as an enabler to develop these cool applications and
to make Lisp usable for web applications - whereas most people
think you can't write a web server in Lisp.
If people have real problems with the license and they have a real
need for a web server in Lisp: write your own. There are more
web servers out there - some of them even written in Lisp/Scheme/...
James A. Crippen
> the books i have seen are a little weak on the number crunching, bit
> banging side of the house. i hear that lisp can be as fast as fortran
> on numeric problems. i have come to lisp out of disgust with C++ and
> i am finding that i like lisp. but is they any information on how to
> solve those problems which are traditionally done in fortran or C?
(This is a bit off topic, but considering the drift of this thread
nobody should notice.)
I've been noticing more and more "I came to Lisp because {C,C++}
churns my stomach and leaves spots before my eyes" comments. As the
Lisp family of languages slowly (re?)infiltrates the commercial
computing community can we expect better design of competing
programming languages and development systems in response? It seems
that modern development environments are finally starting to approach
the awesome standard that *Emacs presents, and in some cases non-Lisp
development systems are approaching the almost unreal capabilities
offered by Genera (though I'm sure nothing will be *that* nifty and
well integrated for n years, where n is a suitably large positive
integer). And the programming languages are attaining respectable
heights of capability as well. But Lisp is just kinda plodding along,
something new here and something new there, but nothing truly
astounding seems to be going on. Lisp is subverting other systems,
but it doesn't appear to be doing much itself, IMHO.
I'm of the opinion that we need some sort of free implementation of a
total-Lisp environment analogous to the Lisp Machines of yore.
Something that anyone who has enough marbles to run a FreeNIX can
download and install on YA partition and run, and presumably in a few
weeks of fooling around realize the Way Things Should Be.
Perhaps it all goes back to Gabriel's "Right Thing" versus "Worse is
Better". And the only people who know that there's another way,
specifically the "Right Thing" way, are Lisp programmers and their
friends in the research communities. Everyone else steals ideas from
Lispish systems and implements them with a "Worse is Better"
philosophy which creates constant problems with integration,
completeness, orthogonality, and so forth. Everything we've come to
expect from modern commercial software.
Anyway, just had to rant a bit.
james
--
<crippenj at saturn math uaa alaska edu> Kallisti! <james at cryptology org>
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS/MU/O d?(--) s: a--(?) C+++(++++)>$ UBLOS*+++(++++)>$ P+>+++ L+++>$ E++++
W-- N++ o+ K+++>++++ w--- O- M- V--- PS+@ PE@ Y+ PGP>+++ t++@ 5? X? R* !tv
b++++ DI++++ D--- G++>++++ e* h* r--- y-- NT{-} A48 HH++++>* PP+++
------END GEEK CODE BLOCK------
Rainer Joswig
> development systems are approaching the almost unreal capabilities
> offered by Genera (though I'm sure nothing will be *that* nifty and
> well integrated for n years, where n is a suitably large positive
> integer)
A bignum or a fixnum?
> I'm of the opinion that we need some sort of free implementation of a
> total-Lisp environment analogous to the Lisp Machines of yore.
> Something that anyone who has enough marbles to run a FreeNIX can
> download and install on YA partition and run, and presumably in a few
> weeks of fooling around realize the Way Things Should Be.
I think so. But it will not happen very soon:
- bad reputation of Lisp (parentheses, XYZ is cooler, lacks static typing, ...)
- not enough mass of experience Lisp hackers
- no real concrete need for a Lisp OS
Frank A. Adrian
60-bit machine (Seymour Cray was idiosyncratic, ya know) with 18-bit
addresses. Since three such addresses could fit in a single word, there
were three address field in a CONS - the CAR, the CDR, and the CSR. The
latter was used infrequently, as you may well imagine. Another odd thing
about this architecture was that it used a six-bit character. The system
software for some languages actually supported a mixed 6/12 bit char set
(which got real interesting). The Lisp stuff, though, was straight six
bits. The Lisp system had a built in assembler which made use of the
wonderfully wierd architecture.
faa - who used this system for his first exposure to Lisp and was thus
irrevocably warped
Kent M Pitman wrote in message ...
>mik...@mikemac.com (Mike McDonald) writes:
>
>> In article <sfwn22d...@world.std.com>,
>> Kent M Pitman <pit...@world.std.com> writes:
>>
>> > Yes, and incidentally, Maclisp (parent of Common Lisp) ran on a 72 bit
>> > architecture (Multics) back in the late 1970's. And I vaguely recall
>> > there was a Common Lisp for the CDC 7600 in the mid to late 1980's, so
>> > this biz of what are we going to do when we get to 64 bit
>> > architectures is kinda funny...
>>
>> And conses were "interesting" too. They had three fields, CAR,
>> CDR, and I think CXR. CXR was used as a property list! (Addresses
>> were 22bits so three of them would fit in a 72bit word.)
>
>Uh, I think CXR (pronounced "COOK-sir") was the Maclisp hunk accessor.
>If memory serves, the CDC7600 Lisp used CSR (I think pronounced "Kisser")
>for the "middle" of a cons. Also, I thought the CDC wordsize was 64 bits.
>But I might be wrong. Anyway, none of this contradicts the main point.
>
Peter Van Eynde
On Thu, 18 Feb 1999 17:05:06 +0100, Rainer Joswig wrote:
>> I actually went out and asked the Debian mentors about the license
>> and the responses went from "strange" to "you're not even allowed to
>> copy this code, let alone compile and use it!".
>
>I don't know what part of the license would be the reason for that.
>Maybe somebody can explain it to me.
>
>The license:
>
..
[In an email I got:]
From: da...@xs4all.nl (Richard Braakman)
Subject: Re: Licences ok?
To: debian-...@lists.debian.org
Date: Fri, 10 Apr 1998 14:30:25 +0200 (CEST)
Message-Id: <m0yNcws-001NHcC@night>
..
> Additionally, all rights are reserved to any derivative works based on the
> Lisp source code in the CL-HTTP distribution, in particular but not limited to
> any automatic or manual translation of the source code into other computer
> languages or executables.
This makes the Lisp code non-free.
I have no idea why they want to forbid compilation of their code.
> In the meantime, the right to change this license for CL-HTTP in anyway at
> anytime is hereby reserved, any prior clauses notwithstanding.
This also makes it non-free in my book, but the DFSG is not clear about it.
As far as I'm concerned it makes the entire license meaningless; there's
nothing you can do with the code that they cannot revoke whenever they
feel like it.
[end of email. The DFSG are the Debian Free Software Guidelines. A mutant of
this is now used as the Open Source(TM :-) definition]
As far as I'm concerned, I simply _do_ _not_ _understand_ the license.
All this talk of "all rights reserved" has a very restrictive tone to
me, but I don't understand it. I understand the GPL, LGPL, Artistic License,
BSD license, even the Microsoft licenses, but I don't understand _this_.
So I ask the experts... The result is pretty depressing.
I emailed professor Mallery and asked him to explain the license for me. I
got as reply was that "the license is what it says" and the possibility
of a commercial license. I then thought I had explained my case badly and
I tried to get a more definite answer. I got it:
|We presently have enough users and do not need
|any more at this time.
[I might add that he also expressed that this was software-in-development
and that a newer version might be better. But 1 year and 2 months later I
still see people complaining about ACL support...]
>Sorry, but this whining about CL-HTTP really pisses me off. People
>have contributed a lot of time and effort that it runs
>on a variety of platforms and they try to keep track
>of standards (read the HTTP 1.1 standard and you might get an idea).
>I'm not really sure if other people really appreciate how
>much work and knowledge has gone into this stuff
>(for example just to make TCP/IP actually work in some Lisp
>implementations). I really don't like CL-HTTP to go the route
>of some other "closed" or "open" Lisp packages -> "dead end".
You're talking to the guy who wanted to package it up for Debian...
More users -> more bugs found -> more developers.
What I wanted was to package up CMUCL+CL-HTTP and give them
to the people at university doing lisp course with a few
simple examples. Just so that they could use a web-interface
for their project instead of format and read-line... People talk about
the lack of interest in Lisp but when I tried it several years
ago on an ST I got a window with:
?
That's it. No documentation, no nothing. With CMUCL you get:
CMU Common Lisp 18a+ release x86-linux 2.4.7 6 November 1998 cvs,
running on slartibartfast
Send bug reports and questions to your local CMU CL maintainer,
or to pvan...@debian.org
or to cmucl-help@XXXX (prefered) [email censored]
type (help) for help, (quit) to exit, and (demo) to see the demos
Loaded subsystems:
Python 1.0, target Intel x86
CLOS based on PCL version: September 16 92 PCL (f)
* (help)
Welcome to CMUCL for Linux.
.. [lot's of help deleted]
Ok. I admit, the docs need updating ;-)
>Lisp users have the luck to have access to a system that
>incorporates some real cool stuff and a large library of
>networking code. Some users have built even more cool
>applications on top of that. Actually CL-HTTP is thought
>as an enabler to develop these cool applications and
>to make Lisp usable for web applications - whereas most people
>think you can't write a web server in Lisp.
The truly, truly sad thing is: I totally agree with you. Utterly.
But I can't use CL-HTTP, because the license isn't clear. Now is this
not sad? If you think you are annoyed because people whine about
CL-HTTP, just imagine how annoyed I must be...
Bruce R Miller
"Frank A. Adrian" <frank_...@firstdatabank.com> writes:
>The Lisp for the CDC 6600 Series was done at UT Austin. The 6600 was a
>60-bit machine (Seymour Cray was idiosyncratic, ya know) with 18-bit
>addresses. Since three such addresses could fit in a single word, there
>were three address field in a CONS - the CAR, the CDR, and the CSR. The
>faa - who used this system for his first exposure to Lisp and was thus
>irrevocably warped
Likewise!
A friend of mine's wife was (according to him) a Computing Genius.
Knowing my love of Lisp, he was teasing me with a report his wife had
written condemning Lisp. She had used the CDC lisp for her `study'.
While I was trying to explain that that really wasn't an ideal lisp
implementation to base the comparison on, he went on to explain
how she found lisp to be bad at data structures --- Say WHAT? ---
Yeah, it's real clumsy for doing doubly linked lists. (!?!?!?!?)
Some people just dont get it.
--
--
bruce....@nist.gov
http://math.nist.gov/~BMiller/
Duane Rettig
> In article <g183k7l...@lambda.uaa.alaska.edu>, crip...@saturn.math.uaa.alaska.edu (James A. Crippen) wrote:
>
> > development systems are approaching the almost unreal capabilities
> > offered by Genera (though I'm sure nothing will be *that* nifty and
> > well integrated for n years, where n is a suitably large positive
> > integer)
>
> A bignum or a fixnum?
Yes.
--
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 du...@Franz.COM (internet)
Rainer Joswig
> jos...@lavielle.com (Rainer Joswig) writes:
>
> > In article <g183k7l...@lambda.uaa.alaska.edu>, crip...@saturn.math.uaa.alaska.edu (James A. Crippen) wrote:
> >
> > > development systems are approaching the almost unreal capabilities
> > > offered by Genera (though I'm sure nothing will be *that* nifty and
> > > well integrated for n years, where n is a suitably large positive
> > > integer)
> >
> > A bignum or a fixnum?
>
> Yes.
Which one?
Rainer Joswig
> > Additionally, all rights are reserved to any derivative works based on the
> > Lisp source code in the CL-HTTP distribution, in particular but not limited to
> > any automatic or manual translation of the source code into other computer
> > languages or executables.
>
> This makes the Lisp code non-free.
> I have no idea why they want to forbid compilation of their code.
I don't see how it forbids compilation of the code.
> |We presently have enough users and do not need
> |any more at this time.
Sounds like the mail is authentic. ;-)
> [I might add that he also expressed that this was software-in-development
> and that a newer version might be better. But 1 year and 2 months later I
> still see people complaining about ACL support...]
Support for ACL has to come from users. Franz does not support CL-HTTP, AFAIK.
> You're talking to the guy who wanted to package it up for Debian...
> More users -> more bugs found -> more developers.
Yep.
> What I wanted was to package up CMUCL+CL-HTTP and give them
> to the people at university doing lisp course with a few
> simple examples.
I really don't get it. ;-) CL-HTTP has been used in several projects
at Universities. I'm using it myself in a joint project with
the AI lab of the University of Hamburg. What do they do that others can't?
> Welcome to CMUCL for Linux.
> .. [lot's of help deleted]
>
> Ok. I admit, the docs need updating ;-)
Good work.
Christopher R. Barry
> You're talking to the guy who wanted to package it up for Debian...
> More users -> more bugs found -> more developers.
Will Garnet ever be packaged for Debian?
Christopher
Duane Rettig
> Duane Rettig <du...@franz.com> writes:
>
> > Johan Kullstam <kull...@ne.mediaone.net> writes:
>
> > > however, what if i actually *want* a wrap around. i do not want an
> > > integer but a number from the group Z_n.
> >
> > Tim Bradshaw goes on to give you the correct answer for this, using
> > MOD. However, saying that you do not want an integer is not quite
> > correct; you really do want an integer, restricted in range.
>
> no, i do *not* want an integer (at least in the mathematical sense).
But since you're trying to implement a mathematical concept in a
computer language, I resubmit that you really want integers (in
the computer-language sense), plus some way to restrict them so as to
model the math concept you desire.
I wouldn't have answered this with an argument if I didn't also have
what I think is useful information to add, so read on...
> i want elements of Z_n = Z - <n> which is not the integers Z but
> equivalence classes on Z, i.e., Z modulo multiples of n. the math in
> Z - <n> is different from integer math. mapping elements of Z - <n>
> into a subset of fixnum or bignum would be a particular
> representation. operations on the group elements do not follow the
> `conventional' integer operations.
>
> eg in Z_2 let the elements be denoted z2_0 and z2_1. define the `+'
> operation to do
>
> z2_0 + z2_0 = z2_1 + z2_1 = 0 and z2_0 + z2_1 = z2_1 + z2_0 = z2_1.
>
> integers do not work this way. they follow different rules.
>
> modern algebra such as groups rings and fields has not only variable
> values, but the operations like `+' are also a `variable'. however the
> operations follow some rules (eg associative commutative &c) and
> deductions can be based on that.
>
> it'd be interesting to see if lisp can set up eg functions which
> depend upon group operations. the particular group (its elements,
> their representation and how the operation acts) would be specified
> later.
Try the following - this should work for any ring size, and could be
expanded to check arguments for validity (although any reasonably
small integer should be properly incorporated into the result with
the proper modulus). The macro is a Zn_+ constructor, asking for n
and creating the desired Z<n>_+ operator. The resulting operator
is simplistic, but it does what you ask, and could easily be
enhanced to take on more features.
On an x86:
USER(1): (defmacro make-Zn_+ (n)
(let ((name (intern (format nil "Z~d_+" n)))
(n-type `(integer 0 ,(1- n))))
`(defun ,name (x y)
(declare (optimize speed (safety 0))
(type ,n-type x y))
(the ,n-type (mod (+ x y) ,n)))))
MAKE-ZN_+
USER(2): (make-zn_+ 2)
Z2_+
USER(3): (z2_+ 0 0)
0
USER(4): (z2_+ 1 1)
0
USER(5): (z2_+ 0 1)
1
USER(6): (z2_+ 1 0)
1
USER(7): (compile 'z2_+)
Z2_+
NIL
NIL
USER(8): (disassemble 'z2_+)
;; disassembly of #<Function Z2_+>
;; formals: X Y
;; code start: #x204d4944:
0: 55 pushl ebp
1: 8b ec movl ebp,esp
3: 56 pushl esi
4: 83 ec 24 subl esp,$36
7: 03 d0 addl edx,eax
9: 33 db xorl ebx,ebx
11: b3 08 movb bl,$8
13: 8b c2 movl eax,edx
15: 99 cdq
16: f7 fb idivl ebx
18: 8b c2 movl eax,edx
20: f8 clc
21: c9 leave
22: 8b 75 fc movl esi,[ebp-4]
25: c3 ret
USER(9):
I was surprised at first to see that this function forced the stack
to be linked in (as opposed to creating a leaf function) but then
I remembered that the mod/rem primitive requires specific registers
to be certain places in order to work, and it was easier at the time
to just force the linkin; I'll probably revisit that issue in the
near future. Meanwhile, here is the same function disassembled on
an rs/6000, which does not place extra requirements on primitive
rem/mod operations, and which thus compiles into a leaf function:
USER(4): (disassemble *)
;; disassembly of #<Function Z2_+>
;; formals: X Y
;; code start: #x30513234:
0: 7c832014 a r4,r3,r4
4: 3a600008 [cal] lil r19,8
8: 7c649ad6 divs r3,r4,r19
12: 7c6002a6 [mfspr] mfmq r3
16: 3a000001 [cal] lil r16,1
20: 81a1000c l r13,12(r1)
24: 4e800020 br
USER(5):
Christopher R. Barry
> > Additionally, all rights are reserved to any derivative works
> > based on the Lisp source code in the CL-HTTP distribution, in
> > particular but not limited to any automatic or manual translation of
> > the source code into other computer languages or executables.
> > This makes the Lisp code non-free.
> > I have no idea why they want to forbid compilation of their code.
>
> I don't see how it forbids compilation of the code.
Indeed, in this respect it only seems to indicate that all rights are
reserved on compiled files generated from the CL-HTTP source. It
doesn't say that you are forbidden to make derivative works from the
automatic translation of source to machine-code.
Christopher
Carl R. Witty
Early NeXTs also came with Mathematica, which I thought was kind of
cool; especially its "interesting" approach to documentation. I'm
pretty sure that the first NeXT version of Mathematica (that came with
OS version 0.8) was documented by taking the Macintosh documentation
and doing a global search-and-replace of NeXT for Macintosh. I base
this conclusion on several oddities in the documentation:
1) It mentioned the NeXT Color Picker (at a time when all NeXTs were
4-level grayscale).
2) It described how to exchange graphics with (paraphrased) "other
NeXT applications, such as MacPaint and MacDraw".
3) It pluralized NeXT as NeXTes.
:-)
Carl Witty
cwi...@newtonlabs.com
Erik Naggum
| Sorry, but this whining about CL-HTTP really pisses me off.
some of us are sufficiently legally trained or experienced to see danger
signs in legal material. I don't know that it pisses anyone off, but it
sure says "no go". some of us believe in the sanctity of contract, and
sometimes a very legitimate reaction is "I can't honor that contract".
some of us work very hard to ensure that everything we do is according to
all applicable laws, not because we're afraid of punishment, but because
by breaking some laws, we would also lose its protection. if we broke a
contract or were even challenged for it, our own contracts would lose
legal force in the minds of very many people.
like, does anyone _really_ respect Microsoft's license agreements? I
sure don't, but this is one of my best arguments against ever installing
anything owned by Microsoft on my computers -- people who do actually and
usually unwittingly allow Microsoft officials or anyone acting on their
behalf to search their entire computing environment for illegal copies of
unrelated software, except that you _cannot_ agree to this in any country
on earth and still be held legally responsible for it, but Microsoft will
try and crush you regardless of your legal standing and rights. as long
as their opponents go away, Microsoft is happy, and if the law come into
play, so much the better. threats and force actually work. that's why
most countries have severe penalties for fraud and make fraud a crime,
instead of just a matter of agreements.
yes, the issue is this big if you actually take agreements seriously.
| I'm not really sure if other people really appreciate ...
now you're being destructive and paranoid. drop it.
| I really don't like CL-HTTP to go the route of some other "closed" or
| "open" Lisp packages -> "dead end".
I don't think you appreciate that others may have the same goal.
| Lisp users have the luck to have access to a system that incorporates
| some real cool stuff and a large library of networking code. Some users
| have built even more cool applications on top of that. Actually CL-HTTP
| is thought as an enabler to develop these cool applications and to make
| Lisp usable for web applications - whereas most people think you can't
| write a web server in Lisp.
all of this is true. all of this is extremely irrelevant to the terms of
the license agreement.
| If people have real problems with the license and they have a real need
| for a web server in Lisp: write your own.
well, that _is_ the problem with the license. thank you for agreeing.
Rainer, let me be blunt: that license is a toy license, written by a
legal incompetent. e.g., "by retaining a copy of the distribution, you
acknowledge that you accept the terms and limitations of this license",
which means that just picking up the distribution is an encumbrance upon
the user. in most countries, this clause is unenforceable -- I don't
know that it is unenforceable in the Commonwealth of Massachussetts, but
I would be greatly surprised if it weren't. and the right to produce an
"executable" is reserved. what does that mean? does it mean compiling
it? does it mean dumping it with your Lisp image? but what if there is
no executable mentioning, only various loadable files? and what _is_ the
actual _license_? "personal, educational, and commercial uses are
allowed", it says. this is freaking _meaningless_ in the precise legal
terms required for licensees to know _exactly_ what they are allowed to
do -- I have no idea whether what I'd like to do is considered a
"commercial use" or not. _real_ legal documents define all these things.
finally, and this is really a fundamental issue; where is MIT's grant to
John Mallery that he can claim ownership of this in the first place? my
understanding is that it has been developed over a long time while he has
been a graduate student at MIT. in case you didn't know, MIT retains a
number of interesting rights to _anything_ students or employees do, but
they routinely waive them -- they idea is simply to default to MIT
ownership. therefore, I expect to see a waiver and grant from MIT to
John Mallery. I haven't found it, and since I'm not a legal doofus who
can reasonly claim ignorance of the law, as if that were even a valid
excuse, or having acted in good faith, the whole thing is in danger of
being invalid and someone might come along and claim it, including
anything I might want to retain rights to. this may not be a real issue,
but it sure is a hell of danger sign.
my own endeavors to publish software other people can use, have faltered
on the legal work to do it right, which alone would set me back tens of
thousands of dollars, which I have a very hard time defending, so I don't.
I'm sure CL-HTTP is great, but the license agreement is useless, and so
it is _irrelevant_ to me whether the product is great or not. it would
not cross my mind to argue against the quality of the code based on the
lack of quality of the license agreement. although programming is a lot
like legal matters, few programmers think it's worth the effort, and thus
the computer industry, and especially the amateur scene, is littered with
unenforceable licenses that would make a lot of people _really_ unhappy
if they were broken. I'm unhappy that they are breakable without peril
of legal consequence, because it means those who think nothing of such
issues can have a field day if they want it.
#:Erik
Erik Naggum
| I don't see how it forbids compilation of the code.
are you a lawyer trained in intellectual property? who cares what some
layman sees or doesn't see?
| What do they do that others can't?
they ignore the consequences of vague and meaningless licenses.
#:Erik
Tim Bradshaw
> >
> > This makes the Lisp code non-free.
> > I have no idea why they want to forbid compilation of their code.
>
> I don't see how it forbids compilation of the code.
Object files are `a derived work'.
--tim
Johan Kullstam
> In article <4r9rno...@beta.franz.com>, Duane Rettig <du...@franz.com> wrote:
>
> > jos...@lavielle.com (Rainer Joswig) writes:
> >
> > > In article <g183k7l...@lambda.uaa.alaska.edu>, crip...@saturn.math.uaa.alaska.edu (James A. Crippen) wrote:
> > >
> > > > development systems are approaching the almost unreal capabilities
> > > > offered by Genera (though I'm sure nothing will be *that* nifty and
> > > > well integrated for n years, where n is a suitably large positive
> > > > integer)
> > >
> > > A bignum or a fixnum?
> >
> > Yes.
>
> Which one?
maybe it's a long-float?
--
Johan Kullstam [kull...@ne.mediaone.net] Don't Fear the Penguin!
Johan Kullstam
thanks duane!
sorry to have gotten snippy on you.
i have saved your functions and will work on understanding and
implementing this. it will also help me on my to manipulating GF(256)
in my quest to produce a reed-solomon codec.
once again, i was thinking the wrong way for lisp. the C++
brain-damage is slowly getting undone...
jon....@totient.demon.co.uk
>
> I emailed professor Mallery and asked him to explain the license for me. I
> got as reply was that "the license is what it says" and the possibility
> of a commercial license. I then thought I had explained my case badly and
> I tried to get a more definite answer. I got it:
>
> |any more at this time.
>
Obviously, the expectation for the number of users is rather low.
http://www.netcraft.com/Survey/Reports/9902/
Shows 16 CL-HTTP servers on the internet, as of 1999-02-01
CL-HTTP sites by top-level domain
Domain Number Percentage
com 6 37.50%
Other 10 62.50%
Sites in .COM running CL-HTTP
web2.keokukia.com
als-demo.lavielle.com
stony-brook.scrc.symbolics.com
www.symbolics.com
164.zami.com
cambridge.zami.com
Jon
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Raymond Toy
Johan> i have saved your functions and will work on understanding and
Johan> implementing this. it will also help me on my to manipulating GF(256)
Johan> in my quest to produce a reed-solomon codec.
Doing GF(2) arithmetic is easy as Duane's code shows. In fact rather
than doing the mods, you could just use logxor and logand to implement
+ and *.
GF(256) arithmetic is quite a bit different. You can't use modulo
arithmetic on integers. You have to manipulate polynomials whose
coefficients are from GF(2). You can, represent the polynomials as
bit-vectors or integers, however.
Oblisp: I had written a lisp package for GF(p) (prime p) long ago in
the hope of doing BCH (and Reed-Solomon) codes over any field, but
never quite completed it. Bummer.
Ray
Will Fitzgerald
Erik Naggum wrote in message <31283662...@naggum.no>...
> [snip]
>
> I'm sure CL-HTTP is great, but the license agreement is useless, and so
> it is _irrelevant_ to me whether the product is great or not. it would
> not cross my mind to argue against the quality of the code based on the
> lack of quality of the license agreement. although programming is a lot
> like legal matters, few programmers think it's worth the effort, and thus
> the computer industry, and especially the amateur scene, is littered with
> unenforceable licenses that would make a lot of people _really_ unhappy
> if they were broken. I'm unhappy that they are breakable without peril
> of legal consequence, because it means those who think nothing of such
> issues can have a field day if they want it.
>
>#:Erik
Here's my experience, with a commercial point of view.
We were exploring the use of CL-HTTP for an AI-ish question answering system
a couple of years ago. Our prime customer was very concerned about licenses
for components of the software we were building (and rightly so). It was
clear to me that the CL-HTTP license was vague and confusing enough that it
was going to raise a number of questions, so we basically dropped it, moved
to a "servlet" approach, and basically interacted with the AI-ish part via a
TCP/IP interface.
It's been clear to me for some time that the CL-HTTP folks are simply not
interested in wide-spread use of CL-HTTP. That's OK; nobody says you have to
share your intellectual property. It's confusing that so much effort has
gone into making it platform and Lisp implementation independent and have it
not be marketed. My impression is that the CL-HTTP people really like to
write great software (and it is really good software in general) but don't
really care whether it gets used. I could be wrong; maybe there will be a
future push. But Erik's warnings are important to heed, and I would be very
hesitant to build anything commercially or not that depended on the CL-HTTP
code.
On the other hand, a basic HTTP server is relatively easy to build. Franz
has had a number of Tech Notes on this (with an Allegro-centric view, of
course), starting with:
<http://www.franz.com/tech/technotes/unixserver.main.html>
(By the way, they also have a tech note for getting CL-HTTP running under
ACL at hyperserver.main.html in the list above).
Also, there's a Scheme-based (Scheme 48/scsh Scheme) of an HTTP 1.0 server
available at:
<ftp://ftp-swiss.ai.mit.edu/pub/scsh/contrib/net/su-httpd.html>
Most of it is under Olin Shiver's copyright.
--
Will Fitzgerald
VP, R&D
Neodesic Corporation
Kelly Murray
> ...
> total-Lisp environment analogous to the Lisp Machines of yore.
> Something that anyone who has enough marbles to run a FreeNIX can
> download and install on YA partition and run, and presumably in a few
> weeks of fooling around realize the Way Things Should Be.
>
Good idea. Now that Linux is becoming more mainstream
and gonna be bundled-in with PC
hardware by IBM (and others), the "something different,
something better" crowd (of which I'm a member) might actually
have a chance to build something "different and better."
At least the "inferior because its popular" crowd (of which
I'm NOT a member) might have to look for something else to champion.
-Kelly Murray k...@niclos.com
NiCLOS -- New Internet Common Language Object System
where there isn't an Operating System, only an Object System
where there isn't Bits in Memory, only Objects
where there isn't Bytes in Files, only Collections of Objects