[comp.mail.sendmail] Suggested EASE enhancements

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