Re: Proof of concept: "static" parameter scope

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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