From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26650 invoked by alias); 9 Feb 2018 15:31:20 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: List-Unsubscribe: X-Seq: 42353 Received: (qmail 26946 invoked by uid 1010); 9 Feb 2018 15:31:20 -0000 X-Qmail-Scanner-Diagnostics: from out2-smtp.messagingengine.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(66.111.4.26):SA:0(-2.6/5.0):. Processed in 2.573845 secs); 09 Feb 2018 15:31:20 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: d.s@daniel.shahaf.name X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= daniel.shahaf.name; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0r58IF WBQ47hnIsGrfcn9CjOmu7Q8/86Mu4nKAO/WjI=; b=VVIwgm903V3ymxRCxwWX/6 /NW/MKYuFA0RMwQMQDlUa6Vv/sIRnBwvF0jfgZygNBxNmZBaDzeTgeOxmkIqwzxq 8DCCg/LheF6obtb+EO+htcZD5w3u+O1xG8vsbf1t6G8GJYEOtaYCwdhx+5y9MypO OcNzPCj+K28VqWv2U71K64GL74yHI4YvmHka/h5v0PMUX6A9Oq+/995ExuZ7Q0WW XbxynHdO7OmdQJbImR/uhVv6qbH0FP7k+FSfHqNJFgfooO6HiZmimBV2rcLzH0j+ mA9snW9tGP7bhLdlUcxkbGdQ7yaq7Rr7CW43CXX0JoFhmhW+py5WTx/aGqY9FhSw == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=0r58IF WBQ47hnIsGrfcn9CjOmu7Q8/86Mu4nKAO/WjI=; b=jkA7thjc8QarHSL0pajNXi F8FwnNns8LT/MNoUPQMLRADwn72rpg3+jqgJykunlDykcFAHKBIH95cKFyTKi9P1 ZL39nwd2BWgZXH7c0+z0NOgLvKEHXLWaUYapzdQKP9Ent2DQZuYL5hbaPi2gjKf1 3ZZWFYjsBldIQ660xtI1Tj5rKhom2OjTXqdi7CqTwx1yJQ1R3EGcYy2+5HReXEY1 fOHtTlLTX7R8jVv1/FDjATV9tx1o0dpvu9+vHJ3LPQI4UCp+q++ReXxP0TB08LiN xx2KIjqu1UzVLQTnw4bY+Od5PfeIc46d8b2ya8BXwsvvk1q+Q2ezManpxi7oZGJw == X-ME-Sender: Message-Id: <1518190272.2338601.1265377152.605E16CD@webmail.messagingengine.com> From: Daniel Shahaf To: Stephane Chazelas Cc: zsh-workers@zsh.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-fde26eb3 In-Reply-To: <20180208142211.GA14888@chaz.gmail.com> References: <20180207223051.GA30393@chaz.gmail.com> <4253.1518045946@thecus.kiddle.eu> <1518093995.645366.1263935336.265ED7BF@webmail.messagingengine.com> <20180208142211.GA14888@chaz.gmail.com> Subject: Re: inf and nan in arithmetic expansions Date: Fri, 09 Feb 2018 15:31:12 +0000 Stephane Chazelas wrote on Thu, 08 Feb 2018 14:22 +0000: > 2018-02-08 12:46:35 +0000, Daniel Shahaf: > > And then we could add 'inf' and 'nan' as readonly variables initialised to > > those respective values (as Oliver also suggests in the 19597 thread). There > > are compatibility implications for scripts that use these variable names, but > > there is no way around them if we want to allow explicitly doing (( x = inf )) > > in user code... > > But what value would you use for those variables? 'inf' would be positive infinity. 'nan' would be a NaN (whichever flavour thereof would be least surprising). > Or do you mean that the shell arithmetic parser would understand > "inf"/"nan" as the infinity and not-a-number numbers and not as the > variable (otherwise with inf=inf, that would do infinite recursion) Why would it be recursive? > but just make inf/nan readonly so users not be tempted to use them as > variables? That would be the simplest implementation, yes. It might suffice, or we might prefer something more elaborate. > I'd also rather "inf" be used instead of "inf." (would also > align with ksh93), but the change could potentially break some > scripts. If we also make $inf/$nan read-only variables, that > would also break scripts that use $inf/$nan variables but not > in arithmetic contexts (like for inf in *.inf), so that doesn't > sound like a good idea to me. Yes, that would be backwards incompatible. If we choose this path, those people can use 'for inf in...' use 'local inf' or 'local -h inf' to hide the float inf/nan. One option that is compatible is to make 'inf' and 'nan' only declared on an opt-in basis --- using some autoload/zmodload, or perhaps with some "This script requires zsh 5.5 or greater" directive. Cheers, Daniel