procmail
[Top] [All Lists]

Re: syntax enhancement dreams

1997-08-27 13:53:50

"David" == David W Tamkin <dattier(_at_)wwa(_dot_)com> writes:

David> | what i am claiming (and i'll use one of your example responses below
David> | to illustrate this) is that something like this:
David> | 
David> |   if ((A || B) && (C || D)){
David> |     action;
David> |   }
David> | 
David> | is vastly easier for people to look at, vaguely understand, and build
David> | upon than your equivalent:
David> | 
David> |   :0
David> |   * !A
David> |   * !B
David> |   { }
David> |   :0E
David> |   * !C
David> |   * !D
David> |   { }
David> |   :0E
David> |   action

David> If exposure to C or something similar has already made them
David> familiar with "&&" and "||" and "{ ... ;}" while total
David> strangeness from procmail has kept them from ever learning what
David> ":0E" means, then yes.

Firstly, they just need &&, ||, and {}. For your stuff they need :0,
!, E, *, {}, as well as the rule that condition lines are ANDed. Not
only that, but yours needs De Morgan's laws to be understood by anyone
other than a first-order logic major. And as you know if the
expression were just a little more complex, your recipe would become
more inscrutable very rapidly, but the perl statement would not.


Secondly, (and this should be the end of you :-)), an a priori
condition motivating all my comments in this thread is that we ARE
dealing with people who have no exposure to procmail recipe syntax
("total strangeness from procmail" as you say). The subset of people
coming to procmail for the first time who already have procmail recipe
syntax exposure is empty. On the other hand (my hand), the subset of
people coming to procmail for the first time who already have exposure
to C or perl or awk (as Peter Galbraith points out), or any
programming language for that matter, is far greater than zero.  If
you agree with this (and how could you not?), then you may also agree
that the perl solution will be more accessible (to these procmail
novices).


David> My sole argument for advocating the latter form is to save
David> forking perl when you're already running procmail.

OK, I'm with you all the way on this. If you can avoid forking
processes I think that's great, but some of the things you need to do
to make sure of this should be done in the privacy of your own
.procmailrc file, and not forced upon innocent newcomers.

My only argument, and one that I think you have helped me make, is
that the bizarro procmail syntax (especially if extended in some of
the ways that have been suggested) will be more difficult to newcomers
than something like a bit of perl (in either case backed up by
examples).


Terry> what i am claiming that given a set of examples of each,
Terry> that the perl would be simpler for novices to understand,
Terry> copy, and modify ... 

David> ... under the assumption that these novices are not novices in
David> C.  If you're already fluent in Spanish, Catalan is a lot
David> easier to learn than Cantonese.

No, it's not under that assumption at all (see second point
above). You're advocating inflicting obscure logic and syntax on
people who are novices with your "language" by definition. I'm
advocating inflicting a programming language style on people who may
very well have had some prior exposure to a programming language.
There's no assumption there. Plus, I think, the perl solution is
cleaner by a mile (by weight of syntax (your measure), and just
objectively to any reasonable person :-)).

  [Just to address your language analogy directly, yes you're
  right. What I am saying is that seeing as we have many people
  already conversant to some degree with Spanish (C, C++, java, perl,
  awk, etc.), asking them to learn a bit of Catalan (perl) is a good
  idea. Much better than asking them to learn Cantonese (obscure
  ex-nihilo procmail recipe language), which by definition no-one
  knows anything about a priori.]


Sorry for sounding pedantic and verbose, I'm not like this really.


regards again,
Terry.

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