kona

kona copied to clipboard

not a bug, just a question for kona devs: do you intend to mimic a more recent dialect than k3 in the future?

No. I can't speak for the other 23 contributors to Kona, but I have no plans for a more recent dialect.

I think that you are doing a really good job on a k7 subset already ... though as you say ... it is not FOSS, but you can can do with it what you want.

thanks. actually i'm targetting k5-k6 syntax now and i'm trying to assess if k7 would be worth following.

is it due to lack of resources (time, motivation, number of active contributors, ..) that you prefer to stick with k3 or something in the language itself?

My future plans ...

• Finish resolving all open bugs and crashes in Kona (more continually keep popping up).
• Improve my Python competence (since Shakti is using it as a context).
• Become more familiar with Shakti k.
• Get https://github.com/tavmem/buddy to work (early veraion of A+ from ATW at Morgan Stanley).
• Address https://github.com/kevinlawler/kona/issues/552 (Ackerman's function). Check whether A+ https://github.com/tavmem/a outperforms Kona here, similar to how k3 does. If so, study the A+ code to see how ATW achieved this and incorporate the techniques in Kona.
• Resolve any remaining inconsistencies between Kona and k3.

One additional point regarding my stance on not replicating a more recent dialect:

When I started working on Kona (an implementation of k3), ATW had already moved on to q and KDB. k3 was obsolete and no longer available from kx Systems.

I am not sure, but it seems that k5-k6 is still part of the production product available for sale from kx Systems. k7 (shakti k) is currently the primary product available from Shakti.

I am uncomfortable trying to replicate someone else's current product line as FOSS.

k5-k6

i thought those died with kos and only k4 survived as q

uncomfortable

i've no qualms but no great hopes either

Thanks for the clarification (I haven't been following the different versions). Looks like k4 and k7 are off limits (for me), but k5-k6 might be fair game.

Still, I would rather focus on using k7 and Python than trying to replicate k5-k6.

afaik shakti has no dependency on python, and anaconda is used only to distribute binaries for the trial version

there's a shakti-python bridge (thanks to alexander belopolsky), separate from the interpreter

I agree. I did not think that k7 had a dependency on Python.. The Shakti website does mention "3rd party language APIs (Python, Julia etc.)". Both are excellent tools for data science, and I'm interested.

But to get back to the original question ... k3 was a successful, important language, with a reference manual, but is no longer available. k4 and k7 are off limits (for me). k5 and k6 "died with kos", and were never successful.

My plan:

• continue to improve Kona
• move on to other things (maybe usiing k7 with Python and/or Julia)

It will be a very long while before any open source clone of k7 gets anywhere close to Whitney's work in terms of completeness and performance and most likely by then he would have moved on to k8 or even k9! Woof!

But IMHO it is worth thinking about building a good platform for experiments in array processing. What I would suggest is to separate the frontend and the backend. Something like

frontend -> abstract array assembly language -> backend

More than one array language can then make use of the backend. The backend can also be evolved separately. e.g. using vector processing native instructions or even transparently distribute (very large) computations across machines or even JIT compiling it etc. Now I don't mean building something elaborate like llvm but something much more constrained and streamlined. No idea if this is even feasible but something I think about now and then!

It will be a very long while before any open source clone of k7 gets anywhere close to Whitney's work in terms of completeness and performance and most likely by then he would have moved on to k8 or even k9! Woof!

it's a losing battle but it must be fought

abstract array assembly language

like bytecode?

abstract array assembly language

like bytecode?

Yes. But where memory, stack and any registers hold k objects. The trick would be to find the "right cut". We should take this offline if any interest.

FWIW, I haven’t completely grokked what @ktye is doing here but my understanding is that there is some intermediate language that stuff is compiled to which might fit the description above.