procmail
[Top] [All Lists]

Re: for John Hardin's wish list

1998-08-21 22:07:28
Liviu Daia <daia(_at_)stoilow(_dot_)imar(_dot_)ro> writes:
   Ok, how about this:

4. A more normal syntax: the _usual_ logical operators, the _usual_
arithmetical operators, the _usual_ control constructs (if-then-else,
do, while, break, continue, maybe switch too), the _usual_ {} grouping,
the _usual_ string functions, the _usual_ regexp matching rules.  The
_usual_ free format newline handling.  ...

Umm, what is "usual"?  C?  Perl?  Python?  The last, for example, does
_not_ have "free format newline handling" (and neither, strictly
speaking, does Perl or awk).  I happen to have written a couple
procmailrcs that would have been easy in Scheme, but most people appear
to break out in hives at the sight of that many parens, so I guess it's
out.  How about all the visual basic users out there?  VB is quite
structured, you know, so don't laugh.


                                      Something not unlike awk.  Keep
also the _usual_ operator precedence and associativity rules, and it
will look familiar to everybody.

Since you appear to have a particular "everybody" in mind, could
you clarify what background you're assuming they have?


   Code bloat?  If you insist, you can make it just as obfuscated as
it is now, and most people will think it's clever coding, not bloat.
Efficiency?  Just compile everything to bytecode (better yet: to ASTs),
and voila, you get something _much_ more efficient than what you have
now.

Given that >99% of all procmail invocations involve no looping but
rather just a single pass through an rcfile, I cannot believe that
compiling to bytecode will do anything but slow down procmail almost
all of the time.


Have you considered writing a tool that'll translate from some awkish
language into a set of procmailrcs?

Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>