From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12389 invoked from network); 20 Jul 2000 22:32:53 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 20 Jul 2000 22:32:53 -0000 Received: (qmail 25027 invoked by alias); 20 Jul 2000 22:32:33 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 3311 Received: (qmail 25020 invoked from network); 20 Jul 2000 22:32:29 -0000 Subject: Re: Features of rc and es to zsh In-Reply-To: from Juhapekka Tolvanen at "Jul 21, 2000 00:59:53 am" To: Juhapekka Tolvanen Date: Thu, 20 Jul 2000 23:32:41 +0100 (BST) CC: zsh-users@sunsite.auc.dk X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: From: Zefram Juhapekka Tolvanen wrote: >But is that true? Or is that document outdated? If that document is right, >what and when you zsh-developers are going to do to rectify situation? Woo. rc and es are so fundamentally different from zsh that we really can't adopt all their features. We certainly aren't going to get zsh emulating rc -- rc syntax is just so fundamentally different from sh-type syntax. > zsh rc es >Low level command redefinition N N Y I don't see this happening within zsh's current architecture, nor do I think that we'd want to. >Has anonymous functions N Y Y The sh-style language architecture makes this impossible. There's just no concept of a value or an object the way that rc has. If you want this kind of feature, use Perl. >Lexically scoped variables N N Y This could be done only in a very limited form. The concepts that give lexical scoping are quite alien to Bourne-style shells, and, while some of them could be added, without a concept of function objects the utility of lexical scoping would be minimal. I think the most minimal version of lexical variables -- declared variables that become invisible to called functions -- would be useful in itself, and reasonably feasible to implement. Closures (and the nested scopes they imply) would be too big a change. >Exceptions N N Y Possible, but it'd mean a *lot* of internal changes, and there'd be visible limitations on the mechanism. Subshells, being separate processes, can only return an 8-bit status, so exceptions there wouldn't be able to propagate into an enclosing shell. (When writing the Elate shell I gave it string-valued exceptions, which in addition to being used as exceptions were also used to implement several other flow control operations. In fact, the "return" command was itself a shell function. This subshell problem exists there and is a documented part of the shell semantics.) -zefram