@StevanApter it was, but was called 'name' or 'string'
@StevanApter i don't fully understand why k9 can't have projections like this. k7 had 2/3/4 arg versions of @, for example, and it wasn't a problem there
@ktye i find the spacey verb idea quite like the builtin functions in k3, where they all have a leading underscore, like _sin, iirc. except that your idea expands it to non alphabet characters.
working with nested arrays is hard, you have to do something like "under disclose" a lot
also: "f each" is "f rank 0"
but it's a lot of fun to golf in j
@chrispsn #x for no match in "find" is just easier to implement, i guess. if nothing's been found after the search loop you just return the iterator variable as-is.
@chrispsn -1 for no match in "bin" makes more sense mathematically
this reminds me of the old "cut" and the slices - inclusive on the left, exclusive on the right
"bin" slices the integers like that, and there's an implicit leftmost slice that spans from -infinity to *x
@ngn until some point k7 also returned 0. i considered it a bug and reported. arthur fixed it. i used bin for finding the index (after adding 1) in a sorted array. in the apl/k version it does not need a special case.
@ktye probably not so much of a "bug" as different design. i guess in j they wanted the result from I. to be usable as indices in another array without the need for 1+.
@ngn it's certainly pointless to implement all of apl. but for giving current k an apl skin, it would be nice. however, sth like arthurs monad/dyad overloading would be needed. otherwise it's impossible to give two different implementations for a single apl character.
but things like phi pi epsilon are also good names for variables(nouns). not so simple. if you need to distinguish them, you may have to look for the unicode range. is it within apl range(verb) otherwise(noun). it's not exactly a simplification.
and you should't use an apl alpha/omega but a greek one.
@ngn any comments on this? https://chat.stackexchange.com/transcript/message/53485307#53485307 your current UNQ has worst case complexity for sorted input, while it could be much faster than the general case.
a stupid question: why do we assign some function to a precious ascii operator even if its fastest implementation is done with pure k? and in the meantime, ask for non-ascii verbs? i know it's very important for code-golfing, though. more generally, what is the right granularity of a programming language?
@ksi why do we assign some function.. - i need some level of syntactic compatibility with the original k because that's what people are familiar with. if i start making up too much syntax of my own, i fear nobody would be interested.
what is the right granularity - depends on the point of view
@ksi the set of primitives is a pragmatic choice: the most useful for the estimated use case. it's not the bare minimum everything else can be build upon.
we are mixing a few things here. k9 has the new .z.k mechanism that allows to define built-ins for both monadic and dyadic versions. ngn implemented a tokenizer that parses single unicode chars as symbols(varnames). i suggested a parser which handles 'x specially. my use-case was meant for embedding and extending k, which might be done with native code.
@ngn struggling to build ngn/k, but do you use 'whole array' filter (as opposed to -per-element filter)? advantage being you could write as {(!#x)=x?x}# or maybe {(!#x)=?}#
@ngn i did port ngn/k on macos using function wrappers for syscall like what, once you pointed out, arthur did in b. i am not sure why the direct syscall doesn't work, though. i notice that you have one calling procedure for all syscalls, no matter their function signature. how does that work?