parmelee@wayback.cs.cornell.edu (Larry Parmelee) (02/24/89)
I've seen a couple notes recently about people working on enhancements to or a new version of Ease. I'm not sure how many people use it, but I've just finished rewriting our local .cf files with Ease, and I think it's great (certainly in comparision to the raw .cf format). After my experiences with it, I wrote up a "wish list" of improvements and changes I'd like to see made to Ease, so herewith I humbly submit my suggestions to those of you who may be working on it. NOTE: I have not yet looked at Ease2.0 that was posted to comp.sources.unix a couple weeks back. -Larry Parmelee parmelee@cs.cornell.edu EASE wish list: Within a quoted string, emit a warning about dollar signs ('$') if they are not immediately followed by a '{'. ---------- Add a comment operator of some sort. For example, maybe comment{ blah blah blah }; to translate into ## blah blah blah The idea is to have something that the C-Preprocessor won't strip out. Further, I want it to start "##" in the LH column of the .cf file. The reason for "##" is that I normally "strip" the Ease output by deleting all lines that start with a single "#". This comment feature would allow me to put a few comments into the final .cf file. Prehaps as an alternative, do something like the C compiler's "asm" statement: syntax: asm(<text>); Translated by stripping off the "asm();" part and placing the <text> directly into the output file without doing anything else. This would also give you a way to handle sendmail enhancements not yet understood by "ease". ---------- Current rule syntax: <stmt-type> ::= { if | while } <match-action> ::= { next | return | retry }; <stmt> ::= <stmt-type> ( <match-pattern> ) <match-action> ( <rewriting-pattern> ) ; I would suggest changing this to: <if-action> ::= { next | return } <while-action> ::= retry <stmt> ::= { if ( <match-pattern> ) [ <if-action> ] ( <rewriting-pattern> ) ; | while ( <match-pattern> ) [ <while-action> ] ( <rewriting-pattern> ) ; } The former <match-action> would be optional, defaulting to "next" if the statement starts with "if", or "retry" if starting with "while". Further, "retry" can only be used if the statement starts with "while", and may not be used if the statement starts with "if". RELATED NOTE TO THE sendmail IMPLEMENTORS: I would suggest that the "next" option is more commonly used than the "retry" option, implying that the encoding in the .cf file should have a special $code to specify "retry", and "next" should be the default, rather than the way things currently are, which is just the opposite. In many cases I use "retry" solely because I know the resulting .cf file will be slightly smaller and I know the "retry" will fail harmlessly, not because I expect or want the "retry" to find more work to do. ---------- The re-write part of rules (corresponding to the LHS in the *.cf file) could be done better. I'd like to see the "$<digit>" stuff eliminated. Something like this: (Assume field ROUTE,ADDRESS,UUCPPATH,MAILBOX : match(1*); field HOST1 match(1); ) /* HANDLE ROUTE-ADDRESSES */ /* make sure <@a,@b,@c:user@d> syntax is easy to parse -- undone later */ while (@ ROUTE , @ ROUTE ) retry (@ROUTE:@ROUTE); /* change all "," to ":" */ if (@ ROUTE : ADDRESS ) return (<@ROUTE>:ADDRESS); /* src route is canonical */ /* Change host!host...<@host.uucp> into pure bang-path */ if (UUCPPATH ! MAILBOX < @ HOST1 . "UUCP">) retry(HOST1!UUCPPATH!MAILBOX); syntax: if ( <match-pattern> ) <match-action> ( <rewriting-pattern> ) ; Each statement is considered by itself: Each occurence of a field-name in the <match-pattern> would pair up with an occurence of the same field- name in the <rewriting-pattern>, and thus EASE can automatically determine the proper "$<digit> to use in the translated <rewriting-pattern>. In the case of the same field-name occuring more than once, the rule would be that the nth occurance of that field-name in the <rewriting-pattern> corresponds to the nth occurance of the same field-name in the <match-pattern>. There needs to be a way to override this rule, so what I would do is to allow field-names in the <rewriting-pattern> to be "tagged" by appending "-<digit>" to the field-name. The <digit> would indicate exactly which occurance of field-name in the <match-pattern> was intended to be placed at that point in the <rewriting-pattern>. For example, suppose the following rule is intended to take "a.b.c.d" and rewrite that into "a.b.d.c". The first is how it would currently be done, then the rest are equivalent forms under my suggested enhancement: (Assume field ITEM:match(1);) Current form: if ( ITEM . ITEM . ITEM . ITEM ) next ($1.$2.$4.$3); Enhanced Equivalent forms: if ( ITEM . ITEM . ITEM . ITEM ) next (ITEM-1 . ITEM-2 . ITEM-4 . ITEM-3); if ( ITEM . ITEM . ITEM . ITEM ) next (ITEM . ITEM . ITEM-4 . ITEM-3); NOTE: if ( ITEM . ITEM . ITEM . ITEM ) next (ITEM . ITEM . ITEM-4 . ITEM); Is NOT equivalent to the Current form above. It would be equivalent to the following: if ( ITEM . ITEM . ITEM . ITEM ) next ($1.$2.$4.$4); I would suggest adopting and enforcing the following rule, which would make the above illegal: Once a field-name has been tagged in the <rewriting-pattern>, all remaining occurances of the same field name must also be tagged. It might also be useful to have some flag that can occur in place of the <rewriting-pattern> to indicate that the <rewriting-pattern> should be the unchanged <match-pattern>, prehaps "-SAME-", as in the following: if ( MAILBOX < @ DOMAINNAME > ) return(-SAME-); /* Already canonical */ if ( MAILBOX < @ DOMAINNAME > ) next(rulesetname(-SAME-)); /* call rulesetname for further processing */ ---------- In a ruleset, there are times it would be nice to allow the following shorthand: rulesetname(); meaning field ANYTHING : match (1*); if (ANYTHING) next (rulesetname($1)); Prehaps this could be generalized to: (This would work best with my previous suggestion about about using field names in the re-writing field:) rulesetname(pattern); meaning if (pattern) next(rulesetname(pattern)); If this later form is allowed, it would also be useful if "return" could be used as well as a ruleset name. return(pattern); -- means if the pattern matches, return the pattern unchanged as the result of this ruleset. rulesetname(pattern); -- means if the pattern matches, call rulesetname with the unchanged pattern as its argument, then continue processing with the next rule. ----- That's all folks... -Larry
barnett@vdsvax.steinmetz.ge.com (Bruce Barnett) (03/01/89)
In article <25462@cornell.UUCP>, parmelee@wayback (Larry Parmelee) writes: >I've seen a couple notes recently about people working on enhancements >to or a new version of Ease. As far as I know, I am the only one. If anyone else is considering this, please contact me. I will be giving the enhancements to the author, who will come out with the official update. >EASE wish list: > >Within a quoted string, emit a warning about dollar signs ('$') if >they are not immediately followed by a '{'. You got it. I just added this to Ease 2.1. >Add a comment operator of some sort. For example, maybe > > comment{ blah blah blah }; > >to translate into > > ## blah blah blah > >The idea is to have something that the C-Preprocessor won't >strip out. I don't understand. The C preprocessor is run before Ease. If it gets the -C option, it does NOT delete comments. Ease 2.1 supports the C preprocessor directly so you can just type et -C file.ease >file.cf > >The re-write part of rules (corresponding to the LHS in the *.cf file) >could be done better. I'd like to see the "$<digit>" stuff eliminated. >Something like this: >(Assume field ROUTE,ADDRESS,UUCPPATH,MAILBOX : match(1*); > field HOST1 match(1); ) > retry(HOST1!UUCPPATH!MAILBOX); My first ease file for smail did this. However, I found that making the rules overly wordly confused the understanding of sendmail. In my own opinion, I would not like this new syntax. Also, I don't have time for this myself. I wanted to provide basic functionality first. The changes required are substantial, and I have Real work to do :-). But I will consider some of your ideas. -- Bruce G. Barnett barnett@ge-crd.ARPA, barnett@steinmetz.ge.com uunet!steinmetz!barnett