zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Eric Blake <eblake@redhat.com>, zsh-workers@zsh.org
Subject: Re: static vs. dynamic scoping
Date: Wed, 10 Nov 2010 08:50:30 -0800	[thread overview]
Message-ID: <101110085030.ZM6206@torch.brasslantern.com> (raw)
In-Reply-To: <4CD9C64E.8060307@redhat.com>

On Nov 9,  3:08pm, Eric Blake wrote:
}
} 1. Implementation aspect:
}   How hard would it be to add static scoping to zsh?

Just to elaborate on this, as I've been fooling with parameter scopes a
bit lately (http://www.zsh.org/mla/workers//2010/msg00719.html) ...

Zsh currently maintains scopes as [what amounts to] a parallel stack
alongside the function call stack, with scope depth indexed by the
call stack depth.  A variable expansions finds its object at the
uppermost frame of the scope stack in which that variable's name has
been "mentioned" with either typeset/local/declare or undef; if it is
not found at all, assignment creates it in the global frame.  Note,
though, that the global frame is simply the bottom of the stack, not
handled separately except for some special cases for stack depth 0.

Therefore it's at least moderately difficult to add static scoping.

}   Is it something that can be added in addition to dynamic scoping, via
} the use of an option to select the non-default mode (for example, 'local
} -d' to force dynamic, 'local -s' to force static, and 'local' to go with
} default scoping)?

It might be possible to flag a variable in a given frame as static and
thereby cause it to be skipped when the current call depth does not
match the stack depth where the variable was "mentioned", but due to
the details of the implementation [*] I can't think of any reasonable
way to mark entire frames static or dynamic as implied by having two
different function styles.  Maybe that doesn't matter as long as all
undeclared variables in either kind of scope are global, because then
the state of the frame matters only when "local" is used in that frame.

[*] Cf. "what amounts to" -- in reality, every variable has its own
independent stack which comes into being only when the variable is
"mentioned", so that it's not necessary to walk the stack to find
the uppermost frame for a given variable.

}   If both scoping forms are supported, is it worth making the default
} scoping dependent on posix compliance (for example, 'local' means
} dynamic scoping for 'emulate zsh' but static scoping for 'emulate sh'),
} or should it be the same default for both modes?

As it'd probably be controlled by an option, this probably doesn't
change the difficulty either way.


  parent reply	other threads:[~2010-11-10 16:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-09 22:08 Eric Blake
2010-11-10 11:10 ` Peter Stephenson
2010-11-10 16:50 ` Bart Schaefer [this message]
2010-11-10 17:28   ` Eric Blake
2010-11-10 17:43     ` Eric Blake
2011-05-29  6:38     ` Thorsten Glaser
2010-11-10 17:22 ` Bart Schaefer
2010-11-10 17:30   ` Eric Blake
2010-11-10 18:01     ` Bart Schaefer

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=101110085030.ZM6206@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=eblake@redhat.com \
    --cc=zsh-workers@zsh.org \
    /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).