From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28442 invoked from network); 20 Aug 2006 17:33:39 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,UNPARSEABLE_RELAY autolearn=ham version=3.1.4 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 20 Aug 2006 17:33:39 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 77064 invoked from network); 20 Aug 2006 17:33:33 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 20 Aug 2006 17:33:33 -0000 Received: (qmail 24494 invoked by alias); 20 Aug 2006 17:33:31 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 22642 Received: (qmail 24485 invoked from network); 20 Aug 2006 17:33:30 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 20 Aug 2006 17:33:30 -0000 Received: (qmail 76757 invoked from network); 20 Aug 2006 17:33:30 -0000 Received: from vms044pub.verizon.net (206.46.252.44) by a.mx.sunsite.dk with SMTP; 20 Aug 2006 17:33:29 -0000 Received: from torch.brasslantern.com ([71.121.0.226]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J4B005E04RQT6K2@vms044.mailsrvcs.net> for zsh-workers@sunsite.dk; Sun, 20 Aug 2006 12:33:27 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id k7KHXPse003617 for ; Sun, 20 Aug 2006 10:33:25 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id k7KHXPDx003616 for zsh-workers@sunsite.dk; Sun, 20 Aug 2006 10:33:25 -0700 Date: Sun, 20 Aug 2006 10:33:25 -0700 From: Bart Schaefer Subject: Re: readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?) In-reply-to: <20060820065651.GA27688@finlandia.home.infodrom.org> To: Zsh-Workers Message-id: <060820103325.ZM3615@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <20060818102602.GA24702@finlandia.home.infodrom.org> <20060818130849.GD15840@fsst.voodoo.lan> <060818110351.ZM24330@torch.brasslantern.com> <20060819064335.GA13552@finlandia.home.infodrom.org> <060819113925.ZM28549@torch.brasslantern.com> <20060820065651.GA27688@finlandia.home.infodrom.org> Comments: In reply to Matthias Kopfermann "Re: readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?)" (Aug 20, 8:56am) On Aug 20, 8:56am, Matthias Kopfermann wrote: } } > Think of it in terms of cursor motion. } } This was very helpful to me as I did not consider color to } be a cursor motion Well ... it isn't. It's a sequence of bytes that are sent to the terminal but that do not move the cursor. Hence %{ when the cursor has stopped, send output that doesn't affect the position, and then %} when the subsequent output will affect the position again. } The lack of white space is something i really suffer in } specific zsh features That's an inescapable side-effect of the long-ago decision (made long before zsh was even thought of) to define the shell grammar in terms of splitting the input at whitespace. } often and the abundance of tooooooooooo long lines. If you're referring to the completion functions, most of those went through several iterations with the operations spread across several assignments and then were optimized by collapsing them once it was felt that the function was finished and only the developers would ever need to look at it again. } Functions to having done many of these nice builtin features like } splitting, joining, uppercasing e.g. would have had a much better } effect on readability. As I said before, that limits one to using the stdin/stdout model for passing text around. Or one could pass parameter names as arguments, as a poor substitute for references. Given the choice of upper=${(U)lower} toupper -i lower -o upper upper=$(toupper $lower) the first of those is both most efficient and most primitive -- that is, you can write either of the other two in terms of the first one, but the opposite is not true. function toupper { local -A opts zparseopts -D -A opts i: o: if (( $+opts[-o] )) then # Note, this fails for array outputs, needs work typeset -g ${opts[-o]}="${(UP)opts[-i]:-$*}" else print -R "${(UP)opts[-i]:-$*}" fi } } What would I lose if I was not to go the dirty nesting way } but assign to the same variable once again? For one thing, you lose the original value of the parameter, so you can't later manipulate it some other way. OK, so assign it to some second temporary parameter. Every assignment uses three to four times as much memory as required for just storing the value, plus several passes of something slightly slower than a strcpy() to move the value through that memory. A nested expansion cuts that roughly in half (it depends on what you're doing). } When would I really suffer from efficiency lack? Ever? Again it depends on what you're doing. If you're processing several thousand lines of text, you might suffer a lot. These are all general problems with the shell language and the way its interpreters are required to behave. Zsh's internals could do better than they do, but the opportunities for, e.g., passing a parameter by reference instead of by expanding its value, are greatly limited by the imposed semantics. Piling on syntactic hints is the only way to get around this. Remember, the base technology of unix shells is at least 25 years old now, and if you want a clean language you'll have to start from something a little more recent.