From: Marc Chantreux <eiro@phear.org>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Cc: Peter Stephenson <p.stephenson@samsung.com>,
Zsh Users <zsh-users@zsh.org>
Subject: Re: zsh at perl conference and few questions
Date: Mon, 30 Apr 2018 14:52:42 +0200 [thread overview]
Message-ID: <20180430125242.GA6979@prometheus.u-strasbg.fr> (raw)
In-Reply-To: <CAKc7PVAMYg0ALgaFSiLReJydBQFN5_-BFX2WU90MpS=YO6Hbog@mail.gmail.com>
hello,
> It's an occasion to me to tell the observation that function namespaces
> would be rather more needed than variable ones.
yes, i really asked for namespaces in functions.
> plugins like z-sy-h and zsh-autosuggestions copy each widget to hook into
> it. So it's ${#widgets}**2 functions out there with those plugins loaded,
> and times of "lets see my functions print -rl -- ${(k)functions}" are over.
this is the same situation in the uze exporter mechanism and as i said:
from the "user" counterpart, everything is ok:
uze TAP :all
boolean_works () {
true ; ok "true is right"
: ; ok ": is right"
! false ; ok "false is right"
}
prove boolean_works
renders
ok 1 - true is right
ok 2 - : is right
not ok 3 - false is right
1..3
works because there is a TAP.zsh somewhere in $path that
* implements TAP/{ok,prove}
* implements uze/export/TAP populating a local variable
used by the exporter
EXPORT_TAGS=(
:all
'prove ok not_ok plan is isnt note note- expected unexpected'
)
so when you do
uze TAP :all
which prove TAP/prove
you get
prove () TAP/prove "$@"
TAP/prove () {
typeset -A TAPCTX=(index 0 start 1 plan 0)
TAP/start
"$@"
TAP/done
}
the boring part is for the implementor: to be consistent,
the file this/very/long/and/boring/ns.zsh will contain
this/very/long/and/boring/ns/foo () {
this/very/long/and/boring/ns/bar
echo bye
}
this/very/long/and/boring/ns/bar () {
echo hello
}
with namespaces, it will contain
//foo () {
//bar
echo bye
}
//bar () {
echo hello
}
and this should be renamed simply. note that if zsh had closures,
we could use the same hack the javascript world use.
() {
my _P=this/very/long/and/boring/ns
$_P/foo () { $_P/bar ; echo bye }
$_P/bar () echo hello
}
which leads me to the real motivation of this mail: zsh is realllly
powerfull and simple and in many circonstances, it could be used
instead of interpreted langages like python, perl, ruby. some claim
that shell miss nested data structures which is right but there
are workaround (or alternate way of thinking ?)
We have persistant(sic) objects, they’re called files.
— Ken Thompson
i put a demo here http://eiro.github.io/unix/zsh-oo-demo.txt.
when it comes to variables, what i miss the most are
lexical variables and closures.
see, this code
() {
local x=12
plus () l $[x++]
minus () l $[x--]
}
plus
raise an error message because
plus:6: numeric parameter x created globally in function plus
and the output is
0
the perl behavior (and recent versions of javascript)
is much more superior on this part:
* local localize a variable (the way zsh does)
* my create a lexical variable
* whenever a lexical variable of a scope is used
inside a function definition, this create a
state preserved through function calls
in zsh, it could be
counter () {
my x=${2-0}
$1/+ () { let x + $1; echo $x }
$1/- () { let x + $1; echo $x }
}
counter c 2
c/+ 2
to return 4. this case is obviously useless because it's about
one variable but it could be a way to capture a complex context.
for the moment, the only way to do this is to create subshells
and fifo to have coroutines. but it can be painful to write.
i don't know how much this topic is relevent to zsh
implementation but i really think closures and namespaces are
the 2 missing features to make zsh reasonable
on larger codebases.
plus: we need something like cpan (https://metacpan.org/) or
or pypi, crates, epm, ctan, npm, ...
regards
marc
next prev parent reply other threads:[~2018-04-30 13:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20180423093610epcas4p2248cf6f0e76bd3e81ff6fa0ef55f5c25@epcas4p2.samsung.com>
2018-04-23 9:24 ` Marc Chantreux
2018-04-23 10:06 ` Peter Stephenson
2018-04-28 10:14 ` Marc Chantreux
2018-04-30 3:30 ` Sebastian Gniazdowski
2018-04-30 12:52 ` Marc Chantreux [this message]
2018-04-30 5:28 ` Bart Schaefer
2018-04-30 12:57 ` Marc Chantreux
2018-04-30 3:06 ` Sebastian Gniazdowski
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=20180430125242.GA6979@prometheus.u-strasbg.fr \
--to=eiro@phear.org \
--cc=p.stephenson@samsung.com \
--cc=sgniazdowski@gmail.com \
--cc=zsh-users@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).