@nathanrogers See post above..

about throwing money around?

I mean, I'd be much more prone to stick with the platform I've been using, which is CL/April

It was a reply. I meant the post above what it was replying to.

which has taught me the inconveniences of one language embedded within another. Unless you have a very clean delineation between business logic and the outside world, what I find is that you're never in the correct language context you would prefer

@doug I was mid typing that response when tim and dzaima replied, so that should be read in line with my preceding comment as a train of thought

@nathanrogers FFI, sockets, and webservers may be "fundamental features" for you, but that's certainly not everyone. I haven't used sockets ever, haven't used webservers outside python3 -m http.server to get around CORS, and have used FFI only a tiny bit in CBQN to do some basic multithreading, and in Java to import some custom C code to do some simulations faster

Now imagine that that C program is the REPL.

@dzaima I don't mean to imply that it is, and I've taken the effort to convey that in nearly every single message "the features I require/my purposes/etc"

@doug so basically just the K repl, what am I missing

Yes. You said you’re not interested in embedded K when embedded K is all you need.

How then does one call library code in C inside the K runtime?

The idea is that the C code just 1) unpacks the K arguments to C values; 2) passes them to the external function; 3) packs the result(s) back into a K value

unless your external functions deal with very messy data structures, all those steps should be very simple

So I would then need to define wrapper functions for any of the library functions I'm interested in calling, yes?

yeah

I see, and that's what this k.h is providing?

You may have to be a little careful about which side owns the memory.

this is where my lack of skill in C becomes a concern for any non-integrated approach to calling foreign functions

@nathanrogers k.h provides an interface for C code to read & create K objects, and import C functions which only take & return K objects into k, as far as my understanding goes

I think it's more of a C problem. like whenever you use a C library you need to understand whether or not the library code is handling memory stuff (malloc'ing or free'ing things on its own, versus just working directly with whatever pointers are passed into it)

In all lower level languages you explicitly allocate and deallocate memory. If one library allocates and another deallocates you might run into trouble because the one is unlikely to know of the other.

@dzaima e.g. this does that, where the "external function" is a+b

The external function is “add” and it’s registered with KR().

It takes two arguments.

@doug yes, this management is something I wanted to avoid

Maybe change your goals if they’re mutually incompatible.

@nathanrogers well, you'd have to do it to some extent with any FFI

When I began APL, it was with the express purpose of building a desktop application, but I got far enough with the project that I needed to write native C++ code and I stopped... if I wanted to write C++ I wouldn't be using APL. If I wanted to write C++ I'd just write the bloody thing in C++

hmm, I wonder how well decker/lil fits in here

Or pay someone to do it for you.

@doug they wouldn't have to be if these were native features, and since they're not, they need to be implemented some how, the least costly way would seem to me to be an FFI, instead of native implementation

@nathanrogers there is also such a thing as writing just enough C++ to get by, and doing most things in APL still

I think that’s what most people do.

@dzaima not for my use, as much of the library I was hoping to use expects pointers to functions as callbacks...

so much of the application would need to be written as native C++ functions, that sure I could then pass around as call back in APL, but I couldn't ever pass an APL function as a callback

then it sounds like indeed a thing for which APL just isn't meant to be

which is the same issue I'm running into with CL/April

If ifs and buts were candy and nuts we’d all have a merry Christmas - Jack Gifford

as I said earlier, when dealing with 2 languages in one application, you never seem to be in the right context for the right part of the application, and the tradeoffs for switching contexts is unmanaged complexity

unless you have a clean delineation between the business logic and the architecture

hmm, what do you think of web applications? as far as I am aware unless you're writing the backend only in node (and not interacting with databases except via ORMs or something) you're going to be mixing languages

unix design philosophy does that just fine, cobbling together C libraries with high level languages

@coltim not what I'm talking about. You're not calling a python function from your javascript. Instead you're using a protocal to send a message to black box somewhere else... whatever language that is, it is a different application

@nathanrogers that's only if you have to do a ton of the external language stuff. If it's just a couple things, it's very not hard to stay in your preferred language for most of it

Kx has a wire protocol.

@dzaima I find in my experiments with CL/April, from one line to the next, I'd prefer CL for this part, and April for the next part, and constantly jumping back and forth is a non-starter

@doug yes, I know they have integrated features I am looking for, but was hoping to find something similar in a non-paid option

@nathanrogers you could also.. not jump around, if you felt that that'd be better

I mean, J is an... "option"

Again those goals that appear to be mutually exclusive...

@nathanrogers hmm, I guess from one perspective, yes. but if your frontend code is hitting a route that's essentially "run this backend function and return the results to me"...

@dzaima yes, but it still proves the point that one is rarely in the correct context one would prefer to be in unless there is a clear delineation between business rules and architecture

@coltim yes, what I'm referring to specifically is embedded languages. April is embedded within Lisp, so you get all the libraries Lisp has, and all the organization and project architecture stuff from Lisp, but you can implement a nice clean business rule layer in pure APL... at least in theory

you call April functions from CL and Cl functions from April, and pass them back and forth

@nathanrogers what I'm suggesting is that you write the bare minimum necessary external-language code; that's a pretty simple delineation

but at some point my CL code might consume an API that could be implemented in any language whatsoever, but in between they speak the same protocol, sockets/http/soap/...

@dzaima and what I'm saying is that in the course of experiementing with design patterns, for desktop libraries, especially graphical libraries, there is NOT a clean delineation, you just keep stubbing your toe on different parts of the library that require native code

and substantial quantities of native code

.. but for a Tensing Norgay ..

desktop applications seem a messy space

especially cross platform ones

@nathanrogers I'm pretty sure a "minimum necessary" could be easily met for any and all libraries, no matter how many functions they have

yeah, it appears that in earlier versions of libraries, there was limited reliance upon function pointers, and so passing values would have made such things possible, but the modern libraries all seem to handle messaging and event handling etc via function pointers as callbacks

@dzaima but if the number of functions they have is not far off from the amount of code your whole program will be, honestly, just write the whole app in the language the library was meant to be used in

@dzaima unless system and window events are all handled via function pointer callbacks, which means every single event one would want to handle would need to be implemented in native code...

which is a majority of the application

Of course, I could call from the host language, to the native language, which calls back into the host language... which may call back into the native language....

which is what I've said 3 times at this point, that one is rarely if ever presently in the desired context unless there is a clear delineation, which there isn't

perhaps you're correct that an FFI might not be a good solution

I'll just reiterate that specifically desktop applications are thorny. they're built on top of many layers of abstraction. it's hard to short circuit them (a la way the array programming languages short circuit a lot of OOP-style abstraction)

it does seem to be the case that writing in the language native to the API in question would be the best approach.... and then scripting my API together in a higher-level language...

but that is why I've abandoned the project, because I care less about the project than I do finding a project that would give me sufficient excuse to use an array language

because that's what I want to do... more than I care about the application in question

@dzaima but for the rest of the cases where the external communication is just a tiny part of your program, writing a bit of C to wrap around them, and doing the rest 99% of your program in your language of choice, is a pretty simple option

@coltim I imagine the correct way is taking a page from game engines, building an abstraction layer upon the dependant libraries, and scripting them together... but the leading theory on that front is that scripting is massive complexity not worth the cost, and its just better to implement in the native language

@dzaima yes, a web server or rest client would be simple in that respect

if you want a true GUI I think the path of least resistance is writing a frontend in some javascript framework/library and then wiring that up to a backend that either is written in an array language or essentially shells out to one

yeah, I think it'd be simple to port the shakti nodejs snippet someone shared in the email group

and embed k inside nodejs in some kind of wasm

I'd much rather k be embedded in some kind of managed language like JS, as the ecosystems and availability of connectivity and interactivity with feature-rich libraries is free

but as for guis, I think the interoperability complexity cost is still real

@nathanrogers do you have any example of a language where, going through FFI, interoperability for GUIs is easy?

I think I still have Jay Foad's experiment with old OpenGL, but "modern OpenGL" is all event handling using function pointeres

not to mention the Win32 API which is also heavily reliant upon callbacks using function pointers

but no not really

@nathanrogers oK should probably be feasible to use for such a thing; I don't know if it has any docs, but in a couple minutes I put together var env = baseEnv(); tojs(run(parse("2+!10"), env)) just from looking at its source (which can be ran from a js console in johnearnest.github.io/ok/index.html)

Thanks everyone for the discussion. Helped add some much needed resolution to the subject of feature sets across k-implementations

can oK define unicode primitives?

is there a quick list of primitive differences between K5/6 or is it entirely different? I've gone through the oK manual before, and I'm glancing over it now, but I don't see any obvious dramatic differences

k6 feature-wise was an incremental revision on k5, it just happened to be a ground-up rewrite because arthur had some different ideas about internal representations

where does one find such information about these design changes and internal representations, when it seems these were all internal products/personal experiements that weren't released to the public?

k5 and k6 were never released to the public. oK started as k5 and grew toward k6 late in development. The state of oK and ngn/k are for all intents and purposes the current definition of "k6"

confusing

arthur can never be bothered to write documentation beyond a refcard and rarely writes test fixtures, and his interpreters often have bugs. Anyone who wants to try to make something compatible is entirely on their own, including teasing apart what is broken, what is weird for a good reason, and what is simply unfinished

you'd think with such a short spec, documentation would take an afternoon

usage a second afternoon

an accurate and complete spec for K would not be short

there are lots of operators, lots of overloads, fairly complex syntax, many subtle details of semantics

It's just a shame that the iterative learning and experience in language design and data structure optimizations will be lost to time

@JohnE where can I find the source for lil?

if any? is the page highlighted just a spec?

the JS implementation is quite a bit longer because that file also includes the Decker stdlib and DOM

can some explain me this? limits: 8 locals/args, 64 consts, 256 bytecode

i understand the first part which says 8 locals

what are the last two?

@PyGamer0 max constants and max bytecode size per user-defined function