Referencing undefined variables should be an error

[refi64]

ryan@DevPC-LX:~$ rlwrap k
K Console - Enter \ for help

  a
  b

ryan@DevPC-LX:~$ rlwrap k2
K 2.8 2000-10-10 Copyright (C) 1993-2000 Kx Systems
Evaluation. Not for commercial use. 
\ for help. \\ to exit.

  a
value error
a
^
parse error
  b
value error
b
^
parse error

ryan@DevPC-LX:~$ 

[tavmem]

This was an intentional deviation from k (from the inception of Kona)
However, the evolving consensus seems to be that Kona should behave like k2.8 and k3.2.
So ... I'll keep this open, and label it a "feature"..

[tavmem]

Note that k4 also yields an "error" in these cases:

q)\
  a
'a
  b
'b

[refi64]

@tavmem I'm not sure I know of any times this would be desired behavior... :O

[tavmem]

By "this" I take you to mean the current Kona behaviour.
If so, I tend to agree with you.

[tavmem]

k2.8 and k3.2 are inconsistent in the treatment of variables that do not exist.

K 3.2 2005-06-25 Copyright (C) 1993-2004 Kx Systems
WIN32 2CPU 4000MB inspiron.home 0 EVAL

  a
value error
a
^
parse error

  {a}0

  .`
.((`k
   .,(`a;;)
   )
  (`t;-6.039527e+008;))

  a

After being used in a subfunction (when it does not exist), a is added to the KTREE with a null value.

[tavmem]

A good first step might be to eliminate Kona's propagation of function parameters to the k-tree.
In Kona:

   f:{x}
{x}
  .`
.((`k
   .((`f;{x};)
     (`x;;))
   )
  (`t;-6.035375e+08;))

In k2.8

  f:{x}
  .`
.((`k
   .,(`f;{x};)
   )
  (`t;-603537454;))

[tavmem]

The idea expressed above (Nov 16) is not worth pursuing.
In Kona consider 2 cases: Case 1:

  a
  .`
.((`k
   .,(`a;;)
   )
  (`t;-5.978785e+08;))

Case 2:

  v:3
  .`
.((`k
   .,(`v;3;)
   )
  (`t;-5.978769e+08;))


`a `v are both added to the KTREE by the parser (BEFORE any execution begins).
They get null values when added to the KTREE by the parser..
`v is assigned the value 3 by the execution process.  
`a is left on the KTREE with a null value.

If I stop the parser from adding the symbols to the KTREE, we get the following. Case 1:

  a
  .`
.((`k;;)
  (`t;-5.978767e+08;))

Case 2:

  v:3
  .`
.((`k;;)
  (`t;-5.978766e+08;))
  v
  .`
.((`k;;)
  (`t;-5.978766e+08;))

Case 1 seems to work OK (except for a missing "value error" message).
The execution module fails in Case 2.
In the Case suggested on Nov 16, both f and x are placed on the KTREE by the parser (with null values) before execution begins. The execution module assigns the value {x} to f. The symbol x stays on the KTREE with a null value.

It may be possible to differentiate the state of a symbol added to the KTREE by the parser as a placeholder versus a symbol subsequently assigned a null value by the execution module.

An attempt by the execution module to display (or use) the value of a symbol in a placeholder state could trigger a "value error".

Then, at the completion of each command, it may be possible to remove placeholder symbols from the KTREE.

[tavmem]

To summarize: Currently in Kona:

1. New symbols with null values are added to the KTREE by the parser.
2. The execution code needs these new symbols to be on the KTREE in order to work.

Objective: Implement "value error" and have a KTREE that only contains symbols that have been assigned values by amend, w/o having to redesign all of Kona.

There are at least 2 paths that could work. Both seem a bit kludgey.

First: Create a new k-type (type 8) which would be almost identical to type 6 (Null). The parser would add type-8-nulls to the KTREE. The execution code could amend these symbols to other types. Any attempt to display or use a type-8-null in a calculation would result in a "value error". At the end of a command (during the "cleanup"), all type-8 symbols would be removed from the KTREE.

Second: The third element of each entity in the KTREE dictionary is currently unused (see sample below). I believe that it was supposed to be used for attributes that were used by the k2.8 gui. Since the gui will not be implemented in Kona, this "spot" is available. The parser could add the usual type-6 nulls to the KTREE, but with a marker in the attribute position. The execution module could update these marked nulls to other types (or to assigned nulls with no marker). However, any attempt to display or use these marked nulls in a calculation would result in a "value error". The "cleanup" at the end of processing a command would remove marked nulls from the KTREE.

Not clear which is a better route.
Comments?

sample

  v:3
  .`
.((`k
   .,(`v;3;)
   )
  (`t;-5.978314e+08;))

[tavmem]

There could, of course, be other other ways that are better.

[tavmem]

And, it's useful to keep in mind that Kona uses recursive descent.
So, you have parsing, then execution, then parsing, then execution, ...... , till you get the result.