the k tree

Razetime

08:43

what dialect is ktye's I based on?

also where would you guys like a prospective K wiki to be hosted?

github?

Bubbler

Github is fine I guess. APL Wiki is another possible option (already contains multiple articles related to K), though I can imagine at least some K-ers won't like it

Razetime

yeah, I am a bit reluctant to store K related stuff on the APL wiki

anyway, the other popular array language J has its own wiki so it makes sense to follow suit

I'll setup a github pages site today

Bubbler

Does GitHub Pages support wiki software?

I thought it only allows static pages

Razetime

it supports jekyll which can be configured to have a wiki style layout

contributions will have to be pull requests/direct contributions in markdown

@Bubbler miraheze.org

this one looks too good to be real

but it looks like an exact fit for what we need

@all should i request a wiki on meta.miraheze.org/wiki/Special:RequestWiki ?

Bubbler

09:12

Oh wow, I 100% support it

ngn

11:15

@Razetime my impression of k is that its users are busier and less inclined to share knowledge compared to apl and j, so i'm not sure how successful the wiki format would be. kona's wiki, for instance, isn't very active. still, it may be worth trying.

Razetime

good

chrispsn

12:26

hey here's a question. given ngn/k filter is & based, i wonder if it can act 'deep' as well like this indexing - probably not without being able to switch between @ and . somehow...

ngn

@chrispsn i don't understand. is that any different from flattening the matrix before filtering?

chrispsn

no, but it saves the raze step

ngn

@chrispsn how would such an impl of filter know that it should act on cells rather than rows?

how deep should it go? - for rank-sensitive find that's decided based on the difference between the ranks of the left and right argument (assuming rectangularity), but for filter we only have a function (that doesn't carry much information) and one array

chrispsn

that's what makes it tricky

but if it could, that may be a true advantage of ngn/k-style filter over k9-style

because k9 style is always flat since empty list is false and non-empty list is true

you could potentially check the rank of the result of &?

ngn

12:42

@chrispsn i can't even get over the psychological damage caused by understanding rank-sensitive find :P

chrispsn

as in {x@ here:&f'x}

@ngn i don't understand it yet. i need to table a bunch of cases and predict what they do

ngn

@chrispsn well, you understand it better than me..

i thought it was a bug before you told me how it actually works

coltim

13:01

is the goal to arrive at a rigorous understanding or an intuitive one?

ngn

@coltim i guess both. i've no idea how one would go about explaining rank-sensitivity in a wiki page, for example

coltim

as for identifying potential cases, I'd say most of them would involve strings as they are easiest way to get nested data (e.g. a list of strings), and it comes up a lot when you use x in y. at the upper end there's things like "table1 in table2", which returns a boolean list of the number of rows of table1 indicating whether or not that row is present in table2

@ngn yeh I was trying to come up with an analogy. it's probably quite tortured, but...

a car is made up of a lot of parts. but when you go to a dealer and ask "where's your <<car model>>?" they point you to the closest parking spot containing that car. they don't say "well, we don't have a <<part1 that is part of the car you mentioned>>, we don't have a <<part2>>, we don't have a .... etc"

because they are an array of "cars", not an array of parts

if you went to a junkyard and asked the same question they would point you to the individual parts (presumably because some part on your car broke and you are looking for a replacement)

(and because a junkyard is an array of "parts")

I mean yeh, that's not exactly wiki page material

but car analogies are a classic!

Razetime

13:17

chrispsn and coltim, what do you guys think of a k wiki

coltim

I think the biggest challenge would be handling the variations between the different versions. a k wiki for a specific version is a lot easier than a more general one

like all I know of k2/k3 is from an old reference manual available on nsl.com

Razetime

then there's probably a decent way to organize each dialect

if it's rather unused, all the features can be put in a single page with minimal description

for K3,K4,K5,K6,K9, the dialects(that i know of) with well established implementations, maybe have individual pages documenting the symbols

coltim

another aspect (that is probably out of scope) is all the additional ecosystem stuff around the versions

Razetime

i think it's worth having a central place for finding k history, ecosystems and documentation

coltim

like I think k2 at least had some built in GUI features. k4 has q/kdb, whereas k5/k6 are more language oriented

yeh, I'm all for it. for the purposes of wiki-ness, prioritizing the language features/symbols/etc. makes a lot of sense

Razetime

13:27

ok 3 votes for the wiki so far

maybe bookmark that message

ngn

@Razetime i vote "for" too (in case that 3 doesn't include me)

Razetime

the 3 does include you :P

ngn

@coltim so, ("car0";"car1")?"car1" should return 1, that's good

should it break in this case though? ("car0";"car1";`bicycle)?"car1"

coltim

mixed rank left-sides seems unusable in practice

scrawl

13:43

if the wiki is for hobbyist/potential developers, a focus on k5+6 seems best to me. the most-used foss impls are in these dialects
k4 and k9 are proprietary and have their own docs. i know k3 is used in some places but realistically no new developers will be make use of it
like many here, i'd like to see growth in interest and development of open k impls, and k5/6 seem the best candidates to promote that interest in (they're also the nicest dialects imho :)

also there aren't many differences between k5 and k6, and John has written a nice doc outlining those differences

an open source impl not written in atw-c style would be helpful too, but that seems futile :P

Razetime

@scrawl why would it be futile?

coltim

@scrawl I think @ktye's impls may qualify, e.g. github.com/ktye/i

Razetime

yeah speaking of which

what is ktye's I implementing

is it his own spec?

scrawl

that's a joke really. it seems *most impls use the danse, macro-heavy, atw style
*i haven't seen all implementations of course

Razetime

13:58

ah ok

so there's a chance for a fast and non-C based K impl

I have a ways to go before trying that

Razetime

14:51

what is atw anyway?

dzaima

15:10

@Razetime arthur whitney

Razetime

huh. what really characterizes that style?

dzaima

no whitespace, short variable names, etc

Razetime

does it imply the style of the implementation or the K dialect

@dzaima oh. so if i write commented ginormous code for a k interpreter it would be going against tradition

dzaima

@Razetime you'd be doing something new at least. afaik this is some whitney C code (and of course the rest of the files in kparc.com/b)

Razetime

who owns kparc

scrawl

15:41

@Razetime it's not really a tradition. it just so happens that folks who implement apl and its derivations like the expressiveness of apl notation (that somewhat being the whole point :), and so they try to import the expressiveness into other languages. atw-c makes heavy use of the c preprocessor to move toward that expressive style. see ngn/k source for a good example: codeberg.org/ngn/k

Razetime

i found it quite hard to understand the ngn-k source, last i checked

scrawl

my initial point was regarding growth and development of the foss k impls. folks outside the small apl/j/k community are revolted by the hyper-dense c. more traditional whitespace and naming might help with others jumping on board with development

Razetime

i can definitely try once i understand interpreters well enough

scrawl

@Razetime i'd be lying if i said i could read it quickly, but it has been getting better. i have already started writing my c in a more condensed style (i am c-newbie, but my background is mostly q/k). the j incunabulum is a good place to start studying that style

Razetime

I started with C and Ruby

dzaima

15:49

fwiw, my C impl of an array language is of the more traditional style

Razetime

@dzaima it is very nice to read thank you

and i like ruby's looseness and allowance for formatting a lot

so i tend to go towards the "subtle whitespace" side

JohnE

16:57

the revulsion toward the implementation style is usually mirrored by the revulsion toward K syntax itself

I seriously doubt that adopting a conventional formatting style with long names and lots of whitespace would suddenly bridge the gulf between closed-minded people and the world of vector languages

none of those folks genuinely want to understand j/k/apl interpreters, they just want to glance at the codebase and say "oh, ick, this is crazy and impossible, you're all lunatics"

I even wrote a humorous article lampooning the fact that every time k is discussed on hacker news the comments are exactly the same shallow knee-jerk criticisms, and when it showed up on hacker news the comments followed the same pattern, with apparently zero self-awareness

dzaima

17:12

@JohnE or, rather, it reinforces their belief that k/apl are cult-like (similar to urbit). You have to leap over a ton of seemingly-crazy things to be able to get like anywhere with k

Razetime

i guess there's a good reason why APL family languages are more easily learned and accepted well in esolang related communities akin to code golf

JohnE

urbit is on-its-face different for the sake of being whimsically obtuse.
array languages are unlike conventional imperative languages, but broadly consistent within themselves.

dzaima

@JohnE but, without looking deeper into array languages (which is hard because crap error messages, sparse documentation, not many good options for open-source ones), you can't really see the "broadly consistent" part

Razetime

urbit?

@JohnE a well written unknown which is weird when looked at on the surface level is very difficult to differentiate from an obtuse unknown which looks about the sameas well

dzaima

@Razetime just search it up yourself. Don't really know what it is either

JohnE

17:19

I don't have single-word error messages in my interpreter, and I don't have sparse documentation either. Those are solveable problems that have nothing to do with the coding style used in the implementation

and I'd hardly call J's documentation "sparse"

Razetime

yeah the problem is getting people to have an open mind when looking at things from a non-array standpoint

dzaima

@JohnE right, but coding style is just another item on the list of crazies. Your impl is definitely one of the nicer ones

@JohnE I intentionally didn't mention J as it's decent in that aspect

JohnE

K's traditional error messages are extremely terse because arthur can't be bothered writing more elaborate ones; it's not because there is some grand zen-koan elegance to getting "rank" when you have a flaw in your code

coltim

reading the APL\360 manual and seeing the same terms (just upper case and with spaces) made something click for me

Razetime

@dzaima @JohnE @coltim btw are you guys in favour of having a K wiki hosted on miraheze

JohnE

17:26

I have no opinion

dzaima

@Razetime i mean, why not. Don't think there'd be much really to put on one. (and, fwiw, APL wiki was originally on miraheze but was migrated to whatever it is now)

Razetime

interesting

JohnE

the value of a wiki is the content in it

scrawl

> I seriously doubt that adopting a conventional formatting style with long names and lots of whitespace would suddenly bridge the gulf
i don't think so either. i simply think when people see the implementations they immediately assume that k can be read/understood only by "lunatics".
to re-iterate, my initial comment about implementation style was mostly in jest. people abhor that style of c and rather not try to understand its merits (as you say, same goes for k itself). which is truly unfortunate. [Chris pointed out](https://news.ycombinator.com/item?id=22018619) on the hacker news artic…

demonstrating k's utility outside of db,finance,code golf, seems to me to be the best course of action to pique interest. a la ike or special k. those are cool, and people notice

dzaima

@JohnE to be clear, traditional formatting definitely wouldn't "suddenly" do anything. It's definitely not worth switching if you think there's any merit to it. But it still is a thing that's easily addable to the already not small list of reasons to think k is just weird

JohnE

17:38

I wonder how many people evaluate whether C# is appropriate for their project by taking a stroll through the implementation of roslyn

scrawl

ha!

dzaima

@JohnE C# doesn't advertise itself as a tiny, simple and fast language though. Hearing a claim of "executable is under X KB" makes it a lot more likely one looks at the source code. (and, in the case of ngn/k's hn post, there's like literally nothing else to do than to look at the source code)

JohnE

which imo is not an argument about coding style at all, it's an argument that the ngn/k readme leaves much to be desired

it is terse and elegant and useful only to people who already know what it is

and maybe that's fine in the git repo, even, but if so it's a poor landing page for the project as a whole

dzaima

@JohnE but it's much harder to write a hn comment saying "please add some examples or other useful things to the readme so my first option isn't to look at the source code" than to just write about what you actually did notice

JohnE

HN is full of busy people, crabby people, and startup cultists. any interesting discussion or genuine constructive feedback is an exception, rather than the rule. The level of discourse is a bit higher than, say, /r/programming, but that's an exceedingly low bar

also there's the installation barrier.

if you search deep inside your hearts it should be rather obvious why approximately zero out of the several thousand people who saw the HN post chose to clone a repo, build it, and try the interpreter out, copying and pasting URLs and doing google searches to track down and read documentation before typing a thoughtful comment with actionable feedback

dzaima

17:58

@JohnE yeah, reasonable. The online thing exists now though

JohnE

yeah, although it doesn't seem to work properly in Safari

JohnE

18:16

this WASM stuff is all still very bleeding-edge. Asm.js seems like a massively better solution, since it had perfect backwards-compatibility. if you used it in an unsupported browser it was just slower; still worked.

coltim

it started working on iOS somewhat recently, although the font isn't monospaced

well, the font used within the user-editable boxes at least

ngn

@coltim is that how iOS displays textarea-s by default?

coltim

@ngn no idea =|

the top right byte count/time looks monospaced though?

ngn

that reminds me, i wanted to remove the timer because it's too unreliable

coltim

it's a hacky way to see if the page is still working =P (and isn't hardlocked crunching something too large)

ngn

18:30

@JohnE any idea if asm.js is as easy to compile to as wasm?

JohnE

it used to be, anyway- asm.js was the original backend of emscripten

emscripten.org/docs/getting_started/…

"Note that all modern browsers support WebAssembly, so this should only matter if you need to target legacy browsers." <- this is obviously horseshit

it is an absolute tragedy that WASM advocates steamrolled over asm.js

asmjs.org/faq.html

to the point that an alarming number of people seem to believe that WASM was unprecedented and have no awareness that asm.js existed

NaCl, which is substantially similar to WASM in many respects, probably would have succeeded had the browser landscape been as homogenous as it is today

ngn

i think if it's not too slow the extra compatibility would be worth it, at least until wasm becomes truly available in all modern browsers

JohnE

18:52

agreed. Asm.js is a bit slower, esp. in terms of startup time, but the people who complained loudest about that sort of thing were generating many, many megabytes of asm.js. For something like ngn/k I'd expect startup differences to be negligible and runtime differences to be small

I'd be shocked if you didn't still outstrip oK's performance by a wide margin, which is all that should really matter. :)

ngn

if i manage to install the right version of everything and figure out how to use emcc..

ngn

19:58

emcc is ~~taking~~ wasting too much of my time, giving up for now

chrispsn

20:42

@JohnE agree

@Razetime I get a lot out of how APL wiki draws connections between ideas and languages, so my preference would be to use that

JohnE

21:04

it would be nice to see more k content there

rak1507

it is APL wiki after all

ngn

practically dyalog wiki, so for obvious reasons i wouldn't contribute there (but i don't mind others contributing)

rak1507

only 'dyalog wiki' because up to now mostly dyalog people have contributed

no reason it has to/should be like that

Transcript for