Re: Aliasing separators (Re: grammar triviality with '&&')

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mar 5,  5:40pm, Peter Stephenson wrote:
}
} Personally, I don't see why allowing someone to alias \& but not &&
} is logical; either you give users enough rope to hang themselves (and we
} do), or you limit it to non-metacharacters (and we don't).

It has nothing to do with metacharacters and everything to do with tokens.

"*" is not intrinsically a token; it's only a token when delimited by
whitespace or other tokens.  Similarly "\&" is not intrinsically a token.
If you write "**" it becomes a different thing and any alias for "*" no
longer applies.

But (unless quoted, when aliasing doesn't apply anyway) "&&" always is
a token; further it's in the class of tokens that separate other parts
of the lexical space into tokens.  Allowing separators to be aliased
doesn't just change the outcome of a parse (in the way that, say, an
alias for "fi" would), it changes the rules for constructing other
aliasable tokens.

Furthermore, ignoring "alias -g" issues which I agree are an entirely
smellier kettle of fish, it changes the definition of "in command
position".  With input like

torch% &&bar

I would argue that the "&&" is NOT "in command position" because in the
normal lexical situation "command position" ENDS just to the left of any
separator.  There's NOTHING in "command position" in that example.

Either "&&" is a separator token and should act like one, or it isn't
and in that example the alias for "&&bar" should be looked up instead.

} > Aliasing only of STRING tokens is exactly the right thing and this
} > change is simply wrong. The doc only says "before parsing" as a
} > shorthand instead of a long explaination about how the alias is
} > replaced and then parsed all over again.
} 
} If you can produce an alternative patch describing the previous position
} properly, go ahead.  I don't think anyone is actually screaming to use
} this change.

I'll think about a documation patch if that's what you mean.