Re: zsh at perl conference and few questions

[Marc Chantreux <eiro@xxxxxxxxx>]

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