zsh-users
 help / color / mirror / code / Atom feed
From: Zefram <zefram@fysh.org>
To: Juhapekka Tolvanen <juhtolv@st.jyu.fi>
Cc: zsh-users@sunsite.auc.dk
Subject: Re: Features of rc and es to zsh
Date: Thu, 20 Jul 2000 23:32:41 +0100 (BST)	[thread overview]
Message-ID: <E13FOrx-0005pq-00@crucigera.fysh.org> (raw)
In-Reply-To: <Pine.LNX.4.10.10007210051500.10184-100000@verso.st.jyu.fi> from Juhapekka Tolvanen at "Jul 21, 2000 00:59:53 am"

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


  reply	other threads:[~2000-07-20 22:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-20 21:59 Juhapekka Tolvanen
2000-07-20 22:32 ` Zefram [this message]
2000-07-21  7:33 Sven Wischnowsky

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=E13FOrx-0005pq-00@crucigera.fysh.org \
    --to=zefram@fysh.org \
    --cc=juhtolv@st.jyu.fi \
    --cc=zsh-users@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

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).