Feature: Dyadic form $ should execute char strings

[kevinlawler]

when {} is the left arg, form executes the char atom or char string to the right. ."1+1" works, look there if you need a hint

  0$"27"
27
  0.0$"27"
27.0
  " "$"asdasd"
"asdasd"
  `$"sadasd"
`"sadasd
  {}$"1+1"
index error  /expected 2

[silentbicycle]

How is {}$"1+1" different from ."1+1" ?

[kevinlawler]

They're the same thing, as far as I can remember. Thinking about it I can't see a good situation where you'd want to do that. We don't have to duplicate that functionality. Maybe we could do something more useful with it? Open to suggestions

[isawdrones]

It could be used to return the string as a function:

   {}$"1+x"
{1+x}

[kevinlawler]

Good idea

[silentbicycle]

Agreed.

For the documentation, what should forms like this be called? "dyadic $ called with (empty function literal, char vector)"? `4:"cmd" is dyadic "4: called with the empty symbol and a command char vector"?

[kevinlawler]

For reference, the old K3 form of {}$"ccc" accepted any type7 noun as a left argument, not just the niladic {}. We can default to accepting any function for the new use case and have the option of filling in uses for specific functions later.

Documentation: Traditionally the names haven't been well-defined. For example, monadic ?, "range," has also been called "distinct," and been informally referred to as "unique." I've seen monadic < grade_up appear as "grade up", "upgrade," etc. The verbs were considered anonymous, in a sense, and describing them was viewed as an afterthought. As far as reading them out loud, Arthur put together some guidelines here: http://kx.com/a/k/examples/read.k (not to be confused with a complete parser), but again, there were never rigid rules.

Possible names:

{}$"string"  -"Form Function" 
`4:"cmd"  -was known as "System Get". "Synchronous System [Command]" could also work

[isawdrones]

What happens when the other type 7s are passed as arguments?

For the documentation I would make explicit references to x and y, it indicates where each argument goes. Writing them in such a form may be easier:

$

Monadic

format

x: {}

Converts x into a string

---

Dyadic

form

x: {}
y: string

Returns the contents of y as a function.

---

x: 0
y: string

Converts string into an integer

---

x: 0.0
y: string

Converts string into a float

pad

x: int
y: string

Pad string with leading spaces
More info here

[kevinlawler]

What happens when the other type 7s are passed as arguments?

What I mean is, the easiest way to implement the new idea is to check the type of the left argument without actually verifying that the function is indeed {} (There is some benefit to this. While we think of {} and { } and { } as the same function, K has no way of knowing that, and has to rely on string comparison, which says they're different.)

Later, if we decide that {}$"1+x" should return {1+x} but {2}$"1+x" should return "abc", we can go back and add an explicit check for {}.

[silentbicycle]

While we think of {} and {  } and {       } as the same function, K has no way of knowing that, and has to rely on string comparison, which says they're different.

That would likely change if I add a (likely bytecode) compiler, but that would impact a great many other things as well.

[tavmem]

Based on the discussion above: k3.2 has duplicate functionality in the syntactic forms: ."1+1" {}$"1+1" Kona has implemented the 1st form as a feature. The proposal is to use the 2nd form for an alternative capability (return the string as a function). I am changing the label for this issue from "feature" to "enhancement".

[tavmem]

c:\k3.2>k
K 3.2 2005-06-25 Copyright (C) 1993-2004 Kx Systems
WIN32 4CPU 4095MB tszczesny-e7270.corp.1010data.com 0 EVAL

  . "1+1"
2
  {}$"1+1"
2

Clearly, this is a feature, not an enhancement.