Sparked by the desire to use, from Lisp, the Perl libraries LWP (HTTP fetcher), HTML::PullParser and perhaps a DBI (comprehensive database connector) wrapper for when things get too big.
I know Common Lisp has libraries for these things already, but I suspect I can cut a corner [even if only off the Perl programmers' learning curve] by implementing a lisp reader/writer in Perl and some pipe or socket magic.
In the best tradition of building some tools and then using them for the next layer, these things could be replaced with pure Lisp library calls when they became inconvenient.
There is a glorious troll 8-) entitled "Re: can lisp do what perl does easily?". Seems quite relevant.
My initial aim is to make something which can generate HTML-from-sexpr-ready Lisp structures: download HTML, parse it and turn it into a s-expr tree, presumably for some nefarious manipulation in Lisp.
In a long-dead project, I had an MS Access database which I needed to update from a link crawler. Perl was convenient because it can do HTTP and Win32 ODBC .. but the Windows socket implementation in the perl of the day couldn't do select(), or any other form of non-blocking IO. At least not as far as I could see.
When the single-threaded Win32-only link crawler hit the wall (too many unreachable sites to scan the database in a sane length of time), I split the perl program between Win32 and Linux, and used a TCP connection to link the two. The grubby protocol on this link guaranteed to feed the Windows half a linefeed at least every second, so the blocking problem went away.
Hence, I had one composite program which could do Win32 ODBC and multiple (non-blocking) HTTP fetches.
"Cut and shut" refers to the dangerous and, I believe illegal in the UK, practise of taking two cars that have been written off due to minor accidents and welding them together to make one that appears to be OK.
Generally they're deathtraps.
From where I stand in perl-land, Perl and Lisp appear to be complementary in some ways,
and on parallel development tracks in other senses,
I get the impression that the Lisp folks would be horrified at such a project (hmm, maybe it should be made to work also with Scheme?), but the Perl folks would think it hilarious. *g*
More importantly, I believe the project could create a flexible tool which allows programmers to straddle the gap between a language they know and one they don't.
Perl can be embedded in a C application, and some Common Lisp implementation?s are written in C. Both are garbage collected, but in their own sweet way.
Current Perl uses a ref-counter, which is not GC. Yes but generally if you're the sort of person who writes perl you don't care about the difference. You just have to remember to use a weakref when making circular references.
If I knew more about the internals of perl, and anything at all about lisp, I might be able to see where to cut and how to shut without leaving an unsightly scar/weld mark.
I don't.
[...] Anyway, most Common Lisp implementations are written in Common Lisp, but do include FFIs which might be integrable with Perl somehow. [...]
(For some reason I find it easier to comprehend a C compiler written in C, than I do a Lisp implementation written in Lisp.)
FFIs might be handy for the second-generation version, if that ever happened.
The first pass would have to be two processes linked by sockets/pipes, exchanging data for a few specific tasks. Libraries will grow... Perl can deal with Lisp syntax easily enough, although getting Lisp to generate or even store inline the perl code looks untidy.
If it turns out to be useful, perhaps it will spur some bright spark to embed Perl in SBCL.
I'm sure there are similar things in other worlds. Perl stuck in Exim's configuration language, CGI processes running from Jakarta Tomcat (Java servlet container), and so on.
This is my latest mad idea. I would appreciate comments or suggestions. -- MatthewAstley
Why link to Perl, when you can have AWK in CL? RegEx-CLAWK-Lexer
Because I've never written any awk before, and AFAIK it doesn't have a huge library of modules available for it.
Point taken though, that if I wanted regexps then it would be handy, thanks.
Well, if Perl is a better AWK, then imagine what you get combining CL and AWK! =) Don't imagine. Try scsh and see for yourself. I think AWK integrates pretty well into LISP (scheme in scsh's case) syntax. -- Andreas Fuchs
And who cares about scsh? ;-) I did say CL, didn't I? The point is that you don't have to write a whole language interpreter (cough, perl) just to get these features in a language.
Perl 6 built-inrules+grammars+parse trees analagous to methods+classes+objects. In perl 6, a (regex-match) "rule" is akin to a method, a "grammar" to a class, and a parse tree to an object. Interestingly, grammars have inheritance. Probably a little more advanced than CLAWK. Next question: But if rule+grammar+parser is like methods-in-classes (single-dispatch) OO, what's the parsing analog of CLOS-style generic function OO???
One day people will stop futzing around with parsers and actually get some real work done. Some day...
Or, following ErikNaggum's analogy, perhaps I can use unix's Swiss Army Chainsaw to cut my way out of the forest and get back on this road I've heard of...
I see on Java that there are already projects for CL <--> Common Lisp communication of various flavours.
This page is linked from: Lisp newbie perl-in-lisp
CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively