From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@zsh.org
Subject: Re: Proof of concept: "static" parameter scope
Date: Wed, 30 Sep 2015 17:27:48 -0700 [thread overview]
Message-ID: <150930172748.ZM3986@torch.brasslantern.com> (raw)
In-Reply-To: <20150930203825.307d3f8f@ntlworld.com>
On Sep 30, 8:38pm, Peter Stephenson wrote:
} Subject: Re: Proof of concept: "static" parameter scope
}
} I wonder if it's easier than that. If the builtin has the BINF_ASSIGN
} flag then the module code could do that automatically without the module
} needing to declare a different sort of feature. As long as the
} interface is correct, simply adding a reserved word with the token
} TYPESET should be enough.
Indeed, simply calling reswdtab->addnode() from setup_() works fine. It
doesn't really even need to be automated by the module code.
} The trouble is it needs to know this early, because anything using this
} builtin with the assignment interface needs to be parsed properly. In
} particular, it would have to be registered as a reserved word at any
} point it wsa marked for autoload.
That is indeed a problem. It actually works much better to have the
module overload "local" (my hack to add the -S [now -P] switch) because
then the order of parsing the calling code and loading the module are
independent.
Also there are some interesting side-effects if you load the module,
then define a function that uses the new keyword, and then unload the
module again and replace the keyword with a function or an external
command.
Here's a confusing thing that's indirectly related:
torch% disable -r local
torch% zxxx() { local x=(a b c); print $x }
torch%
Eh? Why is that not a syntax error? The reserved word "local" has
been disabled, yet x=(a b c) is still parsed as an assignment.
torch% zxxx
zxxx: number expected
Enabling the builtin again does not fix this:
torch% enable -r local
torch% zxxx
zxxx: number expected
next prev parent reply other threads:[~2015-10-01 0:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-25 2:23 Bart Schaefer
2015-09-25 9:15 ` Peter Stephenson
2015-09-26 5:23 ` Bart Schaefer
2015-09-30 19:38 ` Peter Stephenson
2015-10-01 0:27 ` Bart Schaefer [this message]
2015-10-03 19:19 ` Peter Stephenson
2015-10-03 23:43 ` Autoloaded keywords (Re: Proof of concept: "static" parameter scope) Bart Schaefer
2015-10-05 21:55 ` Proof of concept: "static" parameter scope Daniel Shahaf
2015-10-05 22:17 ` Bart Schaefer
2015-10-05 22:36 ` Daniel Shahaf
2015-10-05 23:01 ` Bart Schaefer
2015-10-06 8:40 ` Peter Stephenson
2015-09-28 17:04 ` Oliver Kiddle
2015-09-28 17:58 ` Roman Neuhauser
2015-09-29 23:31 ` Andrew Janke
2015-09-30 3:06 ` Bart Schaefer
2015-09-28 19:42 ` Mikael Magnusson
2015-09-29 1:23 ` Bart Schaefer
2015-09-29 8:39 ` Peter Stephenson
2015-09-29 22:34 ` Daniel Shahaf
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=150930172748.ZM3986@torch.brasslantern.com \
--to=schaefer@brasslantern.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).