kona
                                
                                
                                
                                    kona copied to clipboard
                            
                            
                            
                        Dot index of Nilads
Kona handles the "Dot Index" aka. "Apply" of a nilad to the empty list by evaluating the nilad:
  {42}.()
42
This appears to disagree with the description of this case in the K2.0 reference manual, p.58:
Niladic functions are handled differently. The pattern above suggests that the empty list () is argument list to niladic f, but f . () is a case of Index, and the result is simply f. Niladic Apply is denoted by f . ,_n, i.e. the right argument is the enlisted nil.
In k3.2:
  {42}.()
{42}
                                    
                                    
                                    
                                
Philosophical aside: Is it a bug or a strict-compatibility issue? Before I were sure I'd understand the rationale, if any, for why Kx's K behaved in this way. Much of what is in the documentation is post-hoc justification for oddities, tics, seams, etc.
It's hard to say. The "Apply" operator and its relationship with "Index" is quite complex and heavily overloaded. I think we need to find or write some actual programs which make use of one or the other interpretations to evaluate what makes the most sense.
On a related note, I also noticed that Kona doesn't appear to behave like K2.0 for . or @ when the left argument is a symbol:
  a:4 5 6
4 5 6
  `a @ 1
nyi error
`a @ 1
   ^
>  \
  `a . 1
type error
`a . 1
   ^
From the K2.0 reference manual, p.86, "Index Item":
If the left argument is a symbol atom then it must be a handle, and the definition proceeds as if the value of the global variable named in the symbol is used as the left argument (but see Handle in the chapter Terminology).
There is a similar sentence in the description of "Index" on p.88.
I assume that "nyi" means "Not Yet Implemented", but I can't think of a reason why the latter case should be a type error.
I agree. The latter case should not be a type error. Seems like a missing feature. I will open a separate issue for this.
`a.1 now yields 1 in Kona (like k3.2 and k2.8)
a@1 now yields 1 in Kona a@1 2 3
now yields 1 2 3 in Kona
Both of those are consistent with the null-indexing behavior you described in #279, but I believe the tests would be more meaningful if a was given a binding first. Based on the documentation I referenced I would expect the following to work:
  a:4 9 8;`a@1
9
  a:4 9 8;`a . 2
8
Commenting here just to keep the discussion for both operators in one place.
Yeah, missed that "detail" :-) (It did seem much too easy.)
a:4 9 8; `a . 1 now yields 9
a:4 9 8; `a@1 now yields 9
a:4 9 8: `a@1 2 now yields 9 8