@ngn I kinda was hoping for a real answer. Do you plan to take it beyond the spec, or leave it as the spec but provide extensions, or do you plan for people to hook in and modify it on their own... what's the plan
@nathanrogers initially i just wanted to make a free, albeit slower, imitation of k5, and maybe attract developers and have an ecosystem for building something like a libre kOS. but then shakti appeared and arthur made k9 radically different from its predecessors. most developers naturally followed him and his new language.
i imagine if i integrate ngn/k with something (a graphics library, a web server, more crypto, etc..) it could be a useful base for building applications in a simple, pleasant vector language. but there's no specific plan. i just enjoy implementing languages.
I'd be happy to contribute some J labs type stuff, maybe write some stupid simple tutorial scripts to help out scrubs like me
I want to figure out how to help because I'm not an implementor, I don't have the domain knowledge for array programming or C tooling or parsing... but I want to help
@ngn quick question, how can I tell if something is a number
@nathanrogers thanks for your readiness to help. there's plenty of work around an implementation, as you became painfully aware from my lack of docs. in order to help, one doesn't have to be a c programmer.
I just don't know what things are, so I don't know how to handle documentation either, I'm sat here wondering why my ? lookup won't work, and how to check if something is a number :O
and I guess I technically don't need to know if its a number
@nathanrogers @x should return one of `b`h`i`l (byte, short, int, long - 8, 16, 32, 64bit). eventually i'm gonna merge these into a single user-facing int type.
@chrispsn so, I'm doing some kind of node lookup in a table, if it isn't found, I need to return the value as an int, so I guess I don't need the branching thing anyway
@nathanrogers I'm not sure how it's handled in ngn/k but in e.g. k4 there's separate LHS args for strings ("I"$"123" returns 123i versus "i"$"123" returning 49 50 51i)
@nathanrogers @x should return one of `b`h`i`l (byte, short, int, long - 8, 16, 32, 64bit). eventually i'm gonna merge these into a single user-facing int type.
@nathanrogers I think part of this may be from .: being more like "evaluate" than "parse string to number". so . x does a lookup in the global namespace of a variable named x, which apparently was already defined in your session (versus not in @dzaima's)
I don't just get to pick what logical operations are
they're pretty well defined
b16 :(16#2)\
shift :{
pad:{(y*x .y,0)#0}
b:b16 y
2/((#b)*× x)#(pad[<;x]),(x_b),pad[>;x]}
LSHIFT:shift
RSHIFT:{shift[-x;y]}
AND :{2/&/b16'x,y}
OR :{2/|/b16'x,y}
NOT :{2/~b16 x}
@ngn different uses. \h is much better for quickly finding a thing and giving a general overview, \+ etc is better for learning more about the specific thing
(also maybe a general syntax page may be helpful, e.g. comments, strings (+ single characters), typed & generic lists, noun/verb/adverb (maybe include the grammar?), maybe the fact that {} is a noun, $, whatever else seems important)
@ngn I think having a separate comparison page would be better, listing all differences, instead of that being scattered around the docs, which you'd only use to find how to do something in ngn/k
when searching for the function to get the type of an object, i certainly don't care if it differs from k5/k6. And when comparing ngn/k to k5/k6 for any reason, I don't think I'd want full docs about every builtin surrounding that info
@nathanrogers did you figure out what the problem with your ⍸ was?
i can boil it down to two things: how prototypes work (e.g. why ("ab";"cde") is " " and not "") and how find works (x?y could be used instead of ⍸) in ngn/k vs original k's "rank-sensitive" version
when ⍸ (it should really have been ⍳ ..) couldn't find the variable name in v, it returned an empty list, then you used that as index in pd and got an empty result, and * (first) of that result was not what you thought it would be - it wasn't an empty list.
@ngn I think the former. i'd say parsing strings like this comes up most often when dealing with external data (where I'd have to imagine space-separated ints are pretty rare)
