From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <6e3e309b1e44a3d737f3271614aef222@plan9.bell-labs.com>
From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] bug or a feature?
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="upas-maynnyhcvayqufuguwxgmikgwp"
Date: Sat, 27 Jul 2002 08:10:44 -0400
Topicbox-Message-UUID: d4ea8bd2-eaca-11e9-9e20-41e7f4b1d025

This is a multi-part message in MIME format.
--upas-maynnyhcvayqufuguwxgmikgwp
Content-Disposition: inline
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Running

if(test -e /){
	echo musthappen
	if(test -e /notthere)
		echo wonthappen
}
if not{
	echo canthappen
}

yields just 'musthappen'

You were perhaps afraid it would also print canthappen?

Looks like td sets the variable to true before the
comparison and to false on the way out of an if body
(see Xwastrue and where its emitted).  No reason to
have a stack.
--upas-maynnyhcvayqufuguwxgmikgwp
Content-Type: message/rfc822
Content-Disposition: inline

Received: from plan9.cs.bell-labs.com ([135.104.9.2]) by plan9; Fri Jul 26 22:44:44 EDT 2002
Received: from mail.cse.psu.edu ([130.203.4.6]) by plan9; Fri Jul 26 22:44:42 EDT 2002
Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.18.6])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP
	id 0F9B219A08; Fri, 26 Jul 2002 22:44:12 -0400 (EDT)
Delivered-To: 9fans@cse.psu.edu
Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84])
	by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 3595D19988
	for <9fans@cse.psu.edu>; Fri, 26 Jul 2002 22:43:34 -0400 (EDT)
Received: from user-vcautp3.dsl.mindspring.com ([216.175.119.35] helo=rakitzis.com)
	by gull.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
	id 17YHYL-0001YY-00
	for 9fans@cse.psu.edu; Fri, 26 Jul 2002 19:43:33 -0700
Received: (from byron@localhost)
	by rakitzis.com (8.11.0/8.11.0) id g6R2hMc04796
	for 9fans@cse.psu.edu; Fri, 26 Jul 2002 19:43:22 -0700
From: Byron Rakitzis <byron@rakitzis.com>
Message-Id: <200207270243.g6R2hMc04796@rakitzis.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] bug or a feature?
Sender: 9fans-admin@cse.psu.edu
Errors-To: 9fans-admin@cse.psu.edu
X-BeenThere: 9fans@cse.psu.edu
X-Mailman-Version: 2.0.11
Precedence: bulk
Reply-To: 9fans@cse.psu.edu
List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu>
List-Archive: <https://lists.cse.psu.edu/archives/9fans/>
Date: Fri, 26 Jul 2002 19:43:22 -0700

>i'm happiest with
>
>        if foo
>                bar
>        if not
>                baz

Maybe someone can settle this for me.

I found "if not" an atrocity because it's not something lexically
scoped. This is apparently legal rc according to the grammar:

	if not foo
	if not bar
	if not baz

It's up to the interpreter to flag it as an error.

Granted there are many "runtime" as opposed to "parse" errors which
rc will flag for you, but it strikes me as singularly awful that the
control structure of the language should be one of those things.

Also, without thinking really hard about it, I'm not sure how
if not would work for nested ifs. Does this work the way you
would expect?

	if (foo) {
		stuff
		if (bar) {
			more stuff
		}
	}
	if not {
		!foo stuff
	}

A peek at the plan9 rc source suggests there is a global variable
called "ifnot" which makes me very, very nervous. But I don't run
plan9 at home so I can't test this code sample. What if foo is true
and bar is false?

TD was justifiably proud of rc's yacc grammar -- I suppose I felt I
was doing it one better by bringing "if .. else" under that umbrella
also.

Byron.
--upas-maynnyhcvayqufuguwxgmikgwp--