Structured variables - inconsistency in depth expression.

[Hans-Peter Sorge]

    Hi,
    
    there is some inconsistency in depth reporting:
    
          ≡ U.V.W.X.Y.Z←0
    0
    
          ≡ U
    6
    
          ≡ U.V.W.X.Y.Z←,0
    1
    
          ≡ U  
    6     ⍝ should be 7   ??
        
          ≡ U.V.W.X.Y.Z←⊂,0
    2
    
          ≡ U
    7     ⍝ should be 8   ??
    
    
    Q: Does depth on structured variables not have a different meaning? 
    
    
    
    This takes me to an ancient idea of a 'name operator'. 
    Structured variables brought the idea back to light:-)
    
    
    There are two 'name operators' in APL:      
    Nabla (∇) operates on names.  ∇function_name -> edit function.
    Dyadic Del (∆):  S∆function,  T∆function -> stop and trace a name
      
    Both operators "take" the name. They are not modifying the name
    content.
    
    One might argue the names being operated on are function names and 
    applying a plain operator to function content is not meaningful and
    the distinction, to have operators acting on strings representing
    names 
    and to have operators acting on variable content is moot.  
      
    
    Lets see what happens if we made the distinction:
    
    What is it?
    name operator ←→ NO   ⍝ I have not been looking for a
    special APL-like character yet. I just use NO for the time being. 
    
    What does it?
    My original idea was to save writing characters -> "quoting" :  
    
    suffix←'0001'
    Instead of writing  ⍎'VARNAME_' , suffix , ' ← 1234567890'
    one could write     VARNAME_  NO suffix ← 1234567890   
    ->   VARNAME_ NO suffix  ←→ VARNAME_0001
    
    suffix ← 1
    Instead of writing  ⍎'VARNAME_' , ('0005'⍕suffix) , ' ← 1234567890'
    one could write     VARNAME_  NO ( '0005' ⍕ suffix ) ←
    1234567890  -> VARNAME_  NO ( '0005' ⍕ suffix )  ←→
    VARNAME_0001
    
    Independent sets of name-characters are being joined by NO
    into a valid name.
    
    As a side effect, NO does even allow to express scarce
    arrays:  "VARNAME_  NO¨ (⍕1234567890+⍳9)"  
    as well as hashes:  "VARNAME_  NO¨ ('hash_value_a'
    'hash_value_b')"
    
    One can say in above cases NO is dyadic.
    
    
    Next, why not extending the use of NO to apply common
    operators to STRUCTURED.NAME (! not to the content STRUCTURED.NAME
    !)?. 
    
    A.B.C.D.E.F ← ⊂,0       ⍝ structured name  with data
    
    ≡ A.B.C.D.E.F     ←→  2
    
      ≡ A.B.C.D.E     ←→ DOMAIN ERRROR -> not a leaf-node
    
    
    
    NO with Left Operators:
    
    ≡NO A           ←→  6   ⍝  zero on a plain variable name
    
    ⍴ NO A.B.C.D.E.F   ←→  6    ⍝ empty on a plain variable name
    
    
    3↑NO A.B.C.D.E.F   ←→  A.B.C  
    
    1 0 1 0 1 0 / NO A.B.C.D.E.F   ←→  A.C.E
    
    
    Monadic NO, binding to name characters.
    
    NO A.B.C ⍳ NO B   ←→  2
    
    NO D ∊ NO A.B.C.D  ←→ 1
    
    NO A.B.C.D.E.F [ 5 6 ]     ←→ E.F
    
    Rename a variable:
    
    ( NO A.B.C.D.E.F [ 2 ] )   ←  NO OTHER   ← → 
    A.OTHER.C.D.E.F
    
    ... and so on.
    
    Just wondering whether those thoughts have any merit.....  
    
    Best Regards
    Hans-Peter