autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multiline output variables.


From: Stepan Kasal
Subject: Re: multiline output variables.
Date: Tue, 8 Feb 2005 11:05:24 +0100
User-agent: Mutt/1.4.1i

Hi Dan,
   nice piece of work, thank you.

On Mon, Feb 07, 2005 at 03:55:49PM -0500, Dan Manthey wrote:
> > 3) ad: the implementation of non-recursive substitution:
> >
> > All the hacks with |address@hidden@#| are too complicated and not general 
> > enough.
> > There is a better solution.
> >
>       I agree that your solution works and makes non-recursion invisible
> to the user, but I think it's actually benefitial to have the wacky string
> that gets deleted (for instance, to disabiguate address@hidden@bar@' by
> address@hidden@|#_!!_#|bar@'), so I have not taken your suggestion here.

You are right, this is a good solution.

> I just surround all `@'s with the deleted string, and also put it at the
> beginning of each output value.

I think adding the string _after_ each `@' would be enough; IOW I propose
to change
        s/@/|#_!!_#|@|#_!!_#|/g
to
        s/@/@|#_!!_#|/g

To prove formally that it is correct, we have to prove that each 
address@hidden@'
which appears in any stage, was already in the original input.

Proof: Let's have an occurence of address@hidden@'. If its left `@' wasn't in 
the
original input, then it has to be followed by |#_!!_#|, so it's not 
address@hidden',
contradiction.  So the left `@' had to be inthe original line.
If some characters of this occurence address@hidden@' were inserted by a 
previous
substitution, then there would have to be the |#_!!_#| from the beginning
of the substituted value.
Thus the whole address@hidden@' had to be in the original line, q.e.d.

> Note that I changed the deleted string to
> be a palendrome, since that allows it to be inserted at its own center.

What?  IIRC, the previous suggestion was |#_!_#|, which is also a
palendrome.  No big deal, of course.

One more comment:

I notice that your patch contains

m4_define([_AC_SED_CMDS],m4_defn([_AC_SED_CMDS])[| sed 's/|#_!!_#|//g' ])

As I have admitted before, I don't (yet) fully understand your patch,
but this seems a bit suspicious to me.  Does this mean that you use one
more `sed' call in the pipe to remove these tokens?

It's clear that you cannot put s/|#_!!_#|//g at the end of each fragment,
But I think you can put it as the very last command of the last fragment.
Oh yes, you have to change the last fragment to:

        /@[a-zA-Z_][a-zA-Z_0-9]*@/!b end
        ...
        :end
        s/|#_!!_#|//g

but I think it's worth it.  (Perhaps it would help to put the label `:end'
at the end of each fragment, so that the first command of each fragment
will be the same.  You can decrease the number of commands for each segment
by 2 (the label plus possibly s/|#_!!_#|//g).  All this is still better
than having one more process in the pipe.

Will you find time to implement these improvements?

> My thanks go to Stepan for all the help he's given with this.

I'm glad to generate hints.  But I have stated several times that I cannot
keep pace with you and I actually don't understand your code.  ;-)

Thank you for this, Dan.  It's really inspiring work!

Have a nice day,
        Stepan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]