Question: K Architecture? #51

CptJimKirk commented 2023年05月03日 03:13:11 +02:00

When expanding a project, that is more than a single file, that is a single application (rather than multiple smaller applications as is the case with AOC), what is the idea with K program structure/organization/architecture?

With limited lexical scope (i.e. not lexical scope at all), and the arbitrary cap on maximum number of local variables (including function parameters????), I'm wondering what architecture looks like.

In an automation project I've been working on, I used the pattern as defined in l/runparts.k which starts another process, running another file as a script, rather than importing and calling functions (which would be preferable... if functions weren't arbitrarily knee-capped with the name limit) as the global namespace gets very polluted as single character names with any meaning quickly deplete.

I know very little about how k namespaces work, and I don't see any examples which use namespaces, because most examples are single files, mostly 1-5 LOC.

/ tl;dr
Any clarification on the following would be helpful:

1. \l files in another directory without abs path. Or rather how do you allow fellow collaborators to install your application without dictating the installation directory unless you have relative imports?
2. How to organize functions/modules to be imported? or is `x really how people run larger k applications?
3. namespaces, how they're used, how to organize the namespaces to be imported in a scalable, organized fashion.

When expanding a project, that is more than a single file, that is a single application (rather than multiple smaller applications as is the case with AOC), what is the idea with K program structure/organization/architecture? With limited lexical scope (i.e. not lexical scope at all), and the arbitrary cap on maximum number of local variables (including function parameters????), I'm wondering what architecture looks like. In an automation project I've been working on, I used the pattern as defined in `l/runparts.k` which starts another process, running another file as a script, rather than importing and calling functions (which would be preferable... if functions weren't arbitrarily knee-capped with the name limit) as the global namespace gets very polluted as single character names with any meaning quickly deplete. I know very little about how k namespaces work, and I don't see any examples which use namespaces, because most examples are single files, mostly 1-5 LOC. / tl;dr **Any clarification on the following would be helpful:** 1. `\l` files in another directory without abs path. Or rather how do you allow fellow collaborators to install your application without dictating the installation directory unless you have relative imports? 2. How to organize functions/modules to be imported? or is `x really how people run larger k applications? 3. namespaces, how they're used, how to organize the namespaces to be imported in a scalable, organized fashion.

growler commented 2023年05月03日 08:16:18 +02:00

Some of the knee-capping you refer to appear to me to be concessions to a language developed as a hobby for the purpose of better understanding ATW's design methods.

It's probably best to keep this in mind when framing your expectations. I think the vast majority of users of ngn/k users use it for very short projects so there aren't a ton of examples out there.

The situation is different for proprietary languages such as Kx and so are the answers. Best to follow up on their forums for questions about them.

Specific questions about how the language itself works rather than how it is suggested to be used are much easier to answer.

Some of the knee-capping you refer to appear to me to be concessions to a language developed as a hobby for the purpose of better understanding ATW's design methods. It's probably best to keep this in mind when framing your expectations. I think the vast majority of users of ngn/k users use it for very short projects so there aren't a ton of examples out there. The situation is different for proprietary languages such as Kx and so are the answers. Best to follow up on their forums for questions about them. Specific questions about how the language itself works rather than how it is suggested to be used are much easier to answer.

CptJimKirk commented 2023年05月03日 22:46:13 +02:00

(Apologies for the open/close, was intending for a comment, but didn't mean to close at the same time. )

For the sake of discussion:

https://codeberg.org/CptJimKirk/kpl/src/branch/master/apl.k

I updated the "fork operator" (because the arbitrary variable cap inside functions made the much nicer previous definitions irrelevant) placing subfunctions for each monadic/dyadic operators into a namespace, which I bring up only in response to my question regarding namespaces. I was looking at chris's unparser, and saw he created a namespace for the unparser, which got me thinking, namespaces may be the modules I'm looking for.

I've built a cli tool which queries a collection of large spec files, and produce relevant docs and references. Upon parsing the cli args, I am starting a new k process using `x, to select which script to execute. Instead, I may create files containing namespaces each of which contain the same names, pass in the correct module to a function, giving me a sort of polymorphism in that I'd be able to call methods of the same name, reducing much of the repetition.

---

My question about relative pathing comes to mind, however. Unless I specify an absolute installation directory of the cli tool in a build/make (which I would like to avoid), how do you import files when you don't know the abs path in advance? Especially when the various portions of the cli tool are compartmentalized into subdirectories?

I suppose if I bundle the binary, argv[] can give me the full path to the K executable in the root of the zip file, and I can use that as my abs path, and use that to generate the \l imports at the top of the module files (does ."\\l ",abspath,"/file.k" work?)... but that seems inappropriate somehow.

I would really like to get some resolution on how others have built larger projects, if anyone even has.

(Apologies for the open/close, was intending for a comment, but didn't mean to close at the same time. ) For the sake of discussion: https://codeberg.org/CptJimKirk/kpl/src/branch/master/apl.k I updated the "fork operator" *(because the arbitrary variable cap inside functions made the much nicer previous definitions irrelevant)* placing subfunctions for each monadic/dyadic operators into a namespace, which I bring up only in response to my question regarding namespaces. I was looking at chris's unparser, and saw he created a namespace for the unparser, which got me thinking, namespaces may be the modules I'm looking for. I've built a cli tool which queries a collection of large spec files, and produce relevant docs and references. Upon parsing the cli args, I am starting a new k process using `x, to select which script to execute. Instead, I may create files containing namespaces each of which contain the same names, pass in the correct module to a function, giving me a sort of polymorphism in that I'd be able to call methods of the same name, reducing much of the repetition. --- My question about relative pathing comes to mind, however. Unless I specify an absolute installation directory of the cli tool in a build/make (which I would like to avoid), how do you import files when you don't know the abs path in advance? Especially when the various portions of the cli tool are compartmentalized into subdirectories? I suppose if I bundle the binary, argv[] can give me the full path to the K executable in the root of the zip file, and I can use that as my abs path, and use that to generate the \l imports at the top of the module files (does `."\\l ",abspath,"/file.k"` work?)... but that seems inappropriate somehow. I would really like to get some resolution on how others have built larger projects, if anyone even has.

CptJimKirk commented 2023年05月04日 23:01:03 +02:00

Re: the function local variable count cap, dictionaries may be a good alternative to using variable names when needed.

Re: the function local variable count cap, dictionaries may be a good alternative to using variable names when needed.