Here's an antidote to all the random flamage here.
I'm working on (yet another) system to markup text files in a way less
painful than *ML (not hard) but yet easily convertible to HTML. I
wrote a little parser (inspired by a casual aside by Erik) to do this.
I'm now writing its manual, which of course is written in the markup
language.
The parser is actually more general than just an HTML preprocessor,
and the HTML conversion is a trivial application of its `event driven'
mode - you give it a handler function which gets called on interesting
events like start-of-an-element &c. The best thing about this is the
handler also gets called on `unwind' events which happen on the way
out when something goes wrong, all done by UNWIND-PROTECT. Because of
this its virtually impossible to generate bad (in the sense of
unreadable-by-a-browser, rather than not-conforming-to-the-dtd) HTML:
if something bad happens you get a nice series of little messages
saying `oops' followed by appropriate close tags. You can just look
at the generated file to see where things went wrong. This works both
for typos in the source, and much more significantly most parser bugs,
of which there have been some. The whole thing is fantastically easy
to use.
On top of this I wrote a trivial application which puts a bunch of
buttons on the screen to convert various files (only doing the
conversion if need be, and doing various path name hackery to create
suitable source & target filenames -- oh, but isn't the CL pathname
system meant to be so broken this is really hard? apparently not).
If this gets an error you get a debugger, from which you can tell what
went wrong, then just casually abort and the HTML cleanup stuff makes
sure the generated file is OK. The main problem with this is my
laptop runs windows with braindead click-to-type (the user interface
for people who have to prod you before they can talk to you) so
clicking the little compile-this buttons steals the focus from emacs,
and you have to click on emacs to select it again which moves point
and... ick. This (non-portable, of course) button application is 37
lines (including all the pathname hacking and file-date checking). I
actually store it in a file now its got so big and complicated rather
than typing it at a listener each time.
And finally, the markup language itself is so trivial that writing an
emacs mode for it is also trivial - 115 lines including hairy
comment-indentation support. PSGML (which is a really good system) is
thousands and thousands of lines because SGML-derived markup languages
are such vastly overcomplex pigs.
And really finally, I have a caching system for all this stuff. If I
need an HTML version of one of my files I just use
WITH-OUTPUT-TO-STRING, run the converter, stash the resulting string
in a table with some time information, and then I serve up the HTML
when its needed with a single WRITE-SEQUENCE, and no disk I/O. This
can easily saturate the I/O on any machine I can afford (trying to by
a Sunfire 15k on the web just caused my credit-card supplier to get
cross, sigh). Isn't Lisp meant to be slow, or something? Of course
you can probably do this in C as well, but I'm not sure how - probably
you'd run the conversion to a temporary file and then read this into a
string, leaving a trail of orphan files because you don't have
UNWIND-PROTECT to make sure you clean them up. Maybe someone has
written WITH-OUTPUT-TO-STRING for C/C++ by now.
I don't really care that CL is behind the times in terms of having
APIs to every transiently fashionable system, it is still just
fantastically more productive than anything else I've used. I don't
even want to think how hard this would be - and how many APIs I would
have to know - to do this in any of the fashionable language - and
this is *simple* stuff, if I had to do anything complicated I'd just
give up and do something that didn't involve computers.
--tim
This is a significant point. Maybe some of the other lads who make a
living with Lisp could comment on this aspect of the language.
Tim Bradshaw wrote:
> it is still just
> fantastically more productive than anything else I've used.
Here's a much different angle on productivity, not sure if it's what yer
lookin for:
We are working on a big project. I like to shuffle things up all the
time. Now youse guys tell me, how long does an edit-link-test cycle take
with a big system if one changes a key class definition seen by 80% of
the code?
Hell, with Lisp I can hit a backtrace, diagnose the bug, recompile and
continue from some stack frame without having to set up the failed
situation again, never mind sit thru a link or even the recompile of
more than a single form.
kenny
clinisys
Steve Long wrote:
>
> This is a significant point. Maybe some of the other lads who make a
> living with Lisp could comment on this aspect of the language.
>
> Tim Bradshaw wrote:
>
> > it is still just
> > fantastically more productive than anything else I've used.
In article <···············@davros.tardis.ed.ac.uk>, "Tim Bradshaw"
<···@tfeb.org> wrote:
> Here's an antidote to all the random flamage here.
>
> I'm working on (yet another) system to markup text files in a way less
> painful than *ML (not hard) but yet easily convertible to HTML. I wrote
> a little parser (inspired by a casual aside by Erik) to do this. I'm now
> writing its manual, which of course is written in the markup language.
> --tim
Any chance you'll post some sort of info about it? Maybe prominently so us
lurkers will see it. I'd love to take a look at your system if you're
willing to share it with a Free license.
in any case, thanks Tim for the info about what sounds like a cool
project.