rc-list - mailing list for the rc(1) shell
 help / color / mirror / Atom feed
From: malte@TechFak.Uni-Bielefeld.DE
To: rc@hawkwind.utcs.toronto.edu
Subject: builtins and more
Date: Wed, 22 Sep 1993 08:52:32 -0400	[thread overview]
Message-ID: <9309221252.AA00848@dahlie.techfak.uni-bielefeld.de> (raw)

If simplicity is often the same as useability, then let me remind you
of the shift operator. Can there be a cleaner concept than the existing
of list and variables ? And isn't * just another variable except for the
property of being initialized at function invocation ? So how comes that
shift cannot shift variables other than * ? Probably because in sh variables
aren't lists. I find it much harder to remember to include some file to
overload the shift functionality. Not talking about the additional security
checking involved if a script may be executed by root. So consequently
simplicity means enhancing the shift operators functionality. And even if
you think this is false, have you ever thought about
    "x = ( 1 2 3 ) echo $x(0)" ?
Why is $*(0) a special case ? Wouldn't it be cleaner to have another special
variable for that ? And what about omitting shift ? Here's the sceleton of
a function as a replacement for shift:

fn shift {
    switch( $#* ){
        case 0; echo cannot $0 >[1=2];
                return 1;
        case 1; return 0;
        case *; n = ( 1 1 ){
                        echo $*($#n);
                        if( ~ $#n $#* ) {
                        } else {
                            n = ( $n 1 )
                return 0
Instead of "shift" you'll have to type * = `{ shift $* }

So, having raised all these questions: I think there is a very close connection
between datastructures and algorithms on them. With the fundamental data-
structure being lists, I miss the necessary operators (operations).

About the performance of a backquote-style read:
I have checked the difference between
    while(){ echo `{ /bin/echo true }}
    while(){ echo `{ echo true }}
on my favourite machine. It seems to me that the exec(2) is by far more
expensive than the fork(2). So the backquote solution may be a good compromise
between clearity and performance.

Btw, I dimly remember Byron asked for a rc wish list sometime around Xmas.
Wasn't this meant to be a request for possible improvements ? I mean, even
changes to rc syntax and semantics ?


             reply	other threads:[~1993-09-22 12:53 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1993-09-22 12:52 malte [this message]
1993-09-22 16:57 ` Chris Siebenmann
1993-09-22 16:49 Alan Watson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9309221252.AA00848@dahlie.techfak.uni-bielefeld.de \
    --to=malte@techfak.uni-bielefeld.de \
    --cc=rc@hawkwind.utcs.toronto.edu \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).