Re: readability (was: Re: prompt color pbg ,pfg,pbg_bold,pfg_bold in colors function?)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.