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

[Mikael Magnusson <mikachu@gmail.com>]

On Fri, Mar 6, 2015 at 2:42 AM, Bart Schaefer <schaefer@brasslantern.com> wrote:
> 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.

You could argue that the documentation is already right, it uses
"before parsing", and && is interpreted in the "lexing" stage, right?
However, I don't think users can know that... :)

-- 
Mikael Magnusson