Martijn Dekker <martijn@inlv.demon.nl> wrote:
> Op 07-06-2023 om 19:39 schreef Javier:
>> BTW, does anybody know why the shell does not allow the nested
>> brace syntax ${${variable}} for indirect variable reference?
>
> The abandoned 93v- beta of AT&T ksh93 (and hence also the derived and
> equally abandoned AT&T ksh2020 project) supported a ${$variable} syntax
> for indirection, though nested braces are a syntax error.
>
> I've found multiple bugs in their implementation of it

From your response I see that somebody already tried to implement the
feature in ksh. And it seems like the reason for abandoning it was to
keep the parser implementation simple (which I am in favor of).

One question: do shells use an intermediate bytecode compilation step
as in lisp/python/perl? I'm guessing that might be one of the reasons
for shells to keep very simple syntax rules.

Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> The obvious question there is, how late is the binding?

Apparently the nameref feature works differently in ksh and bash.
I found this old message in the bash mailing list:

Chet Ramey <chet.ramey@case.edu>
Date: Sat, 15 Dec 2012 22:58:22
Newsgroups: gnu.bash.bug
Subject: Re: Requesting an alternate nameref feature

On 12/12/12 1:04 PM, Dan Douglas wrote:

> Hello. Could we possibly modify or create an additional variant of
> "typeset -n" which produces "real" references rather than just
> dynamic references by name? In other words, I'd like to be able
> to create reference variables that always point to the instance of
> a variable that was visible at the time the reference was created,
> similar to the way ksh93's nameref works.

This is the `pointer' implementation, as opposed to the `symbolic link'
implementation I chose.

The problem is the same as any use of pointers: what happens when the
object you point to goes out of scope? Or would you restrict it, like
declare -g, to only use the global scope?