Am 17.12.20 um 11:46 schrieb Dr. Jürgen
Sauermann:
Hi Hans-Peter,
see details below, but before that let me explain what happens
here.
Structured variables in GNU APL are implemented as a tree of
nested APL
values. The root of the tree is a variable "owned" by the user.
The leafs of the tree
are APL values that are also "owned" by the user, but all the
rest of the tree is
"owned" (managed) by APL.
For this scheme to work it is essential that the part of the
tree which is "owned" by
APL is always in a consistent state. If we would allow the user
to modify the inner
nodes of the tree, then every (write-) access would need to be
checked as to
whether the internal structure of the tree would remain
consistent or not.
Currently GNU APL rejectes ALL such write accesses, except for
overriding the
entire tree (A←new-value) and overriding the leafs (leaf
A.b.c←new-value).
That is, you are allowed iread all parts of the tree and to
modify the parts of the tree
that you own but not the parts of the tree that you do not own.
As a consequence, everything that potentially modifies the inner
nodes of the tree,
in particular indexed assignment and selective specification, is
being rejected.
In theory it would be possible to allow more write accesses, but
then, for example,
selective specification would require that every APL function
that can be used in
selective specification (including defined functions) would need
to become aware
of the rules that define the consistency of the tree. That is
almost impossible in
practice (and a lot of work) without an obvious beenefit. t
would also impact
performance. I therefore decided to choose rules that are
considerably simpler but
but slightly more restrictive than theoretically needed.
Best Regards,
Jürgen
On 12/16/20 1:16 PM, Hans-Peter Sorge
wrote:
Hi
Jürgen,
Concerning the erasure of a variable, other language have such
functionality too.
Like "unset VAR" or "VAR=", by that ignoring variable content.
Even ⎕EX does not care.
Protecting names is done by )PCOPY. or ⍫, though locking a
function renders it unreadable.
And as I mentioned, when using structured variables the sequence
A.B.C←1
A ← 2
will ⎕EX 'A.B'. The name-tree is not being protected:
A
2
For the reasons explained above. When you erase an entire tree,
then there is
no longer a need to maintain its internal consistency.
To
protect variables against erasure/changes, functionality should
be implemented on a common level.
eg. Quad Protect Variable -> ⎕PV
Is that ⎕PV something existing or did you make it up? I suppose my
explanation in a previous email
might have been a little misleading. When I said an innernal node
should not be overridden my
concern was not so much loss of data by an override bu rather an
inconsistent state as a result. If you
subject a variable tree to the full power of all APL functions,
then you could do rather dirty tricks
with it (for example temporarily hiding subtrees and making them
visible again later on). This would
be Pandora's Box that you cannot close once you open it.
⎕PV
'name'
0
⍝ name is unprotected.
1 ⎕PV 'name'
⎕EX 'name'
0
⍝ name is protected against erasure
2 ⎕PV 'name'
name ← 'new data'
PROTECTED
name ← 'new data'
^
⍝ name is protected against modification
0 ⎕PV 'name'
⍝ unprotect name
I have to apologize for my endless train of ideas.
Working 45 years with APL, I have 45 years worth of ideas on my
mind :-)
Best Regards
hans-Peter