I have succeeded in getting my employer to consider the possibility of
using lisp! I am now spitting out Business Cases and other things they
didn't teach me about in COMPSCI 101 in order to bring this to
fruition. Please help save me from the evil hell of writing this in
(shudder) C or (darn!) Perl.
There are two basic projects which I am trying to do in Lisp. The
second I will discuss in another posting. The first is PICL (see
below.) The reasons I bring this up are: 1. If this stuff already
exists, please point me there! No new wheels invented here. 2. If it
doesn't, why write it a million times? I would like to collect it all
and make it available to the masses. 3. If anyone has any commments,
suggestions, old code lying around which might be useful, etc. I would
like to hear it/have it.
I have unofficially started what I am calling the "Perl In Common
Lisp" or PICL (pro: pickle) project which will include all the various
things in PERL which make it nice to program CGI scripts in. (I seem
to remember that 'pickle' in some form or another has been taken as an
acronym. I don't care! I am going to try a hostile take-over!)
NOTE: this is not a CL-HTTPD such as what is going on a MIT. This is
NOTE: independant of the http server. It should run on anyones server.
NOTE: although, there might be overlap.
I have determined (more or less) what those things are and have started
designing/implementing/best->finding already written libraries.
PERL 5 regular expression matching. I did find the nregex
stuff. Its a good start but having examined it closely, I am
thinking it could use a rewrite. Plus, It would be tricky (read:
messy) to add PERL 5 regex extensions. Question, are there any other
regex libraries? I want to create a reader macro that looks like -->
#/hel+o/i
which would return a lambda expression. All other (replacement, etc)
uses could be derived from this.
String variable interpolation. i know this is LISP-EVIL(tm) so
those who have weak stomachs, skip to the next paragraph. This will
be simply a reader macro that looks like this:
#"hello, my name is $name" --> (format nil "hello ... is ~a" name)
where name could possibly be a lisp expression- have to think about
that one. this should be fairly trivial to write. While i'm at it and
since I gave the warning at the beginning of the paragraph #>EOF and
#>>EOF could be used for interpolated and non-interpolated "Here"
files. (is this bad? am i wrong here?)
Array/ hash access. this is just a few routines to make
hashtables and arrays just a bit friendlier. a reader macro for
hashtables, creation routines for hashtables, a (get ..) and
(setf (get ..) ..) generic function that works for hashtables, etc
but which allows arrays to be treated like hashes. string splitting
into arrays, etc. This should all be easy to do...
File stuff. CL file stuff isn't bad but some per line loops,
etc. macros might be interesting/useful. ideas here?
CGI libraries. this is open ended but equivalent to the stuff
in Perl. I would definitely like to have fast-cgi. that would allow
me to reverse the HTTP modeless control structure and have a
persistent, session based CGI. also, stuff to parse forms, etc.
Anyways, thats the idea. CGI programming is not very exciting but I
thought it would be less painful and possibly more powerful if done in
CL.
This could be a new area for Lisp to become more respected as a
commercially viable language. Its biggest competitor is PERL, which
does a decent job. Lisp could sneak in as being faster and better
built for the task (if the libraries get written.)
Frank DiCostanzo
Strategic Interactive Group
(load "disclaimer.legal")
fdicostanzo at sig.bsh.com
#-flame
P.S. I don't like getting into those X vs. Y wars but...
Lisp being more abstract than C makes it easier to create
better algorithms which is a far better improvement over some
constant increase in performance from compilation. Besides, Lispers
know that most of the time is spent in some tiny part of the code
which can be individually optimized or even written in C. Therefore,
it seems like a non-issue to me.
#+flame
Frank DiCostanzo <···········@sig.bsh.com> writes:
<lots of good ideas>
> This could be a new area for Lisp to become more respected as a
> commercially viable language. Its biggest competitor is PERL, which
Or Java?
What Common Lisp needs real fast is an elegant, easy-to-use sockets
implementation to compete with what Perl and Java offers in that
respect.
(btw, it's quite sad to see that people are still making stupid claims
about Lisp being *slow*, while the world embraces Java, which is
still mainly running amazingly slow inside some of the most severely
bug-infected fatware implementations the world has ever seen. Sigh :-(
)
--
(espen vestre)
disclaimer:
I'm not religious anti-Java, I even occasionally wear a Java t-shirt ;-(
From: Emergent Technologies Inc.
Subject: Re: So I said, "How about Lisp....?"
Date:
Message-ID: <5rd1cr$6sh$1@newsie2.cent.net>
Frank DiCostanzo wrote in article <··············@kiwi.sig.bsh.com>...
>
>I have succeeded in getting my employer to consider the possibility of
>using lisp!
>
Congrats!
First, I'd highly recommend taking a good look at SCSH. Olin Shivers
spent a *lot* of time figuring out how to integrate Unix shell utilities
into
Scheme, and after using them for a while I appreciate the amount of
design that went into it.
You may want to use SCSH directly. Olin wrote the SU-HTTPD (Scheme
Underground Http demon), and has CGI support files, etc. This would
certainly get you producing running code in a hurry. If you don't wish
to use Scheme (some people prefer Common Lisp), you should at
least look at the design of his extensions.
I'd also like to donate whatever you find useful at
http://www.eval-apply.com/Scheme/
(note case sensitive URL) The code is a couple of months old, so
if you download it and have difficulty running it, I'll help you blow the
dust off. I use a functional approach to HTML generation rather than
a wrapper based one. Again, this could be easily ported to CL if
you prefer (although the explosion of funcall and #'(lambda might
be painful).
> PERL 5 regular expression matching. I did find the nregex
> stuff. Its a good start but having examined it closely, I am
> thinking it could use a rewrite. Plus, It would be tricky (read:
> messy) to add PERL 5 regex extensions. Question, are there any other
> regex libraries? I want to create a reader macro that looks like -->
> #/hel+o/i
> which would return a lambda expression. All other (replacement, etc)
> uses could be derived from this.
Perish the thought, but if PERL 5 is freeware, you could rip the regexp
compiler out of it and link it in to the Lisp you are running.
> String variable interpolation. i know this is LISP-EVIL(tm) so
> those who have weak stomachs, skip to the next paragraph. This will
> be simply a reader macro that looks like this:
> #"hello, my name is $name" --> (format nil "hello ... is ~a" name)
> where name could possibly be a lisp expression- have to think about
> that one. this should be fairly trivial to write. While i'm at it and
> since I gave the warning at the beginning of the paragraph #>EOF and
> #>>EOF could be used for interpolated and non-interpolated "Here"
> files. (is this bad? am i wrong here?)
I dunno about ``here'' files, but string variable interpolation isn't
necessarily
evil, you just have an odd syntax for something I've seen called
replace-regexp.
> Array/ hash access. this is just a few routines to make
> hashtables and arrays just a bit friendlier. a reader macro for
> hashtables, creation routines for hashtables, a (get ..) and
> (setf (get ..) ..) generic function that works for hashtables, etc
> but which allows arrays to be treated like hashes. string splitting
> into arrays, etc. This should all be easy to do...
All this sounds good. I wish you luck.
>
>Frank DiCostanzo
>Strategic Interactive Group
>(load "disclaimer.legal")
>fdicostanzo at sig.bsh.com
>
>#-flame
>P.S. I don't like getting into those X vs. Y wars but...
> Lisp being more abstract than C makes it easier to create
> better algorithms which is a far better improvement over some
> constant increase in performance from compilation. Besides, Lispers
> know that most of the time is spent in some tiny part of the code
> which can be individually optimized or even written in C. Therefore,
> it seems like a non-issue to me.
>#+flame
True. It is the high level abstractions that allow you to write massive
amounts of functionality.