Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Parse error (lack thereof) on incomplete loops
- X-seq: zsh-workers 43608
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxx
- Subject: Re: Parse error (lack thereof) on incomplete loops
- Date: Fri, 05 Oct 2018 13:26:32 +0000
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=message-id:from:to:mime-version :content-transfer-encoding:content-type:references:subject :in-reply-to:date; s=fm1; bh=83kEo6ZCDs7FtJPMeW7XpuVygdQp5NoV3I7 Y9ZUVnjo=; b=YK3DB0iw5erSLvy9GnX4x4dqKnkD432KZyskIjE8txYbp/bIP3c 4K2NSMQXW+DzPnxfanMMWCOVcNEO/W/PTX0gaxvUZPpD12QXQgbVCrXHabxtSux1 pqMLpcRKnEZSIgwAz+x+ayrWKTDlYLVP6hLDrL8iEJ9p6aV7cbebpetHfKG7VHzp Oh3l4VoN5249PSICYTtmLaUHLDmyXmC0mU2wztrUsEZwDQ1SUbcYWcJ4sixLur3Q W8QJdiPIph4B/OhnNynNOP012MYNgciJTEF3Koxx13RSAGLMbHeQnpJvTdkxEdO1 MYqA9y+4UmspR99tdTLj+RnyJ1LjoyYBgkQ==
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=83kEo6ZCDs7FtJPMeW7XpuVygdQp5NoV3I7Y9ZUVn jo=; b=buClABXse9mazqfbr6aENFVUXqSKOQd7+hNcjT4y0HRmhvcbAKxJXWI9A WdfRwNn6tWTTrsTeq87u30GBQGTRmr2Nf/nZ14kJ26rggC0gWEWhHy/4jZRIBDSs oajbIY/h+tKZXYTL9o+6QHf+b3B3lBarYab8q0rxnzZKVtB9jBnvniVtN5l5fyhD FLCeB0t3q8BLE/kbkvvjf3vpx+dh2dwPOcF9slPaw6f3VNdRmQDle8bX48tExvrY o8EdJEpbkhnzF0IYlTKhfNNgKwobsH0SrnLoIV25l9+z1yVEhB75HToNSGGLHZ3g Ud6LjvPUCtObG2GAO1SyKzQBTxUJA==
- In-reply-to: <20181005091435eucas1p26edaafb362de339b01c3cb5780fbd108~aq5QQQ6pF1496014960eucas1p2g@eucas1p2.samsung.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- References: <CGME20181004154947epcas4p2441e109a2c4e060bf39f0f6925e98241@epcas4p2.samsung.com> <CAH+w=7awbwDuX2RXcB7pK6Hhbi8fjs=NvwkTAEGmY7gvNpLCqA@mail.gmail.com> <20181004163158eucas1p234a045be013b5463d8db44314ed217dc~adN28lJmq0822408224eucas1p2F@eucas1p2.samsung.com> <CAH+w=7ZLJ5iiph8jpsSiLKdhkozqH+o_kJk7=zfK3DLBegft8g@mail.gmail.com> <20181005091435eucas1p26edaafb362de339b01c3cb5780fbd108~aq5QQQ6pF1496014960eucas1p2g@eucas1p2.samsung.com>
Peter Stephenson wrote on Fri, 05 Oct 2018 10:14 +0100:
> {
> while false
> true
> }
...
> Without a "do" while doesn't know where the expression ends. That's
> fundamental to how SHORT_LOOPS works and why I regard it as so
> ill-defined as to be useless in all but the simplest cases. This new
> (accidental) feature is giving it a particularly straightforward way of
> telling it where the expression ends.
>
> Anyway, I'm perfectly happy either restoring the parse error or not,
> depending on the opinions of people more likely to use or fall foul of
> this kind of syntax but I don't think the reason "it's all a bit weird"
> is good enough on its own for restoring it. Short loops *are* weird.
Point taken :-)
Can we come up with a one-sided parsing rule for syntactically valid cases?
That is, a rule that says guarantees that some constructs are syntactically
valid, but doesn't necessarily say anything about other constructs.
(I'm thinking of something like the last paragraph of users/23696, though
I have no opinion on what the rule should be. My only intersection with
shortloops is that I use the short form of 'for' in interactive shells.)
Cheers,
Daniel
Messages sorted by:
Reverse Date,
Date,
Thread,
Author