The idea is that an opening paren is redundant if the next character is also an open paren, and the character after the next paren at the same uneven depth (which is necessarily closed) is a closing paren. With uneven depth, opening parens have one higher depth than their closing pairs, so that last closing paren will be its pair and the one before the close pairs with the one after the open.
@ngn two backticks (on each side) never make it worse, unless your code ends with a backtick, which it probably won't in APL, or starts with a space, which it won't
@Adám that guided tour you recommended, is it just for dyalog apl? If I'm to do this I'd rather stick to J which seems more alive and is FOSS. Sorry if the question is considered rude in an APL chatroom, consider me as a stranger visiting an unknown land, not knowing the local manners
@xificurC I only know Dyalog APL well, so I can't really give a good intro course to other APLs. Yes, J is FOSS, but I wouldn't say it is more alive. The main developer of J now develops Dyalog APL, which is seeing a rapid evolution lately. But don't worry, it isn't rude at all; J is 100% on topic here.
@Adám thanks. I was just thinking, if I was ever allowed to scrub something up in an array language at work there's no way I'd get my employer to agree to buying a license. Is there the slightest chance dyalog is getting GPLed as well? If it's the same main developer :)
are the differences between dyalod apl and j significant? I'd hope both to provide the same mind bending experience and that e.g. 80% of the knowledge would be transferable
@xificurC These days, you can actually use Dyalog APL for free until you make money off it, and even then there's a threshold, and only after that, the default is 2% of the profit directly made using it, iirc. The main dev of J isn't the main dev at Dyalog. FOSSing Dyalog APL is being considered, but there are various reasons to hesitate.
I meant "if the former main J developer is now the main developer of dyalog APL". Should have been more clear. Out of curiosity, what are those reasons, to hesitate?
@xificurC The main difference between APL and J is APL's use of single symbolic glyphs, while J uses ASCII only, and often resorts to bi-glyphs or even tri-glyphs. I find it much easier to parse APL, knowing that each symbol is one thing only. Dyalog APL also has more a pleasant function definition experience. However, the J language is somewhat more consistent, having been designed with the lessons from APL. The mind-expansion is probably about the same, and quite transferable.
@Adám I guess I'll give it a spin, if your offer is still open. It'd probably go about slowly, as I'd jump back and forth during my work, if that's OK with you.
@xificurC For one, all the people that work at Dyalog live off their Dyalog salary, and Dyalog's income is almost exclusively from licence fees.
@xificurC That's fine. I'm also pretty busy at the moment (I'm presenting at an online conference next week) so I can't spend as much time teaching people as I'd want to. Do you want to begin now?
@xificurC Just to confirm, you want me to introduce you to APL, right?
@Bubbler thanks. I tried installing the full system, had to restart my machine, it rebound my keys, important ones :) Also, didn't know how to exit the interpreter :)
@dzaima setxkbmap -query to get your old setup, and setxkbmap -layout whateverIsTheOldLayout,apl -option grp:switch for altgr-keys (don't have the list of other options for grp rn). Doesn't work at all if you already have multiple layouts
@xificurC yeah. apparently some people at dyalog use it though or something, so we seem to be stuck with this extreme system-breaking stupidity
@xificurC I'm trying so hard to convince my colleagues about that. I'd really appreciate if you could write a short email to support@dyalog.com saying something like "Running Dyalog can lead to data loss because it hijacks the Super key, blocking critical functionality for those that don't have a full desktop environment, and forcing them to reboot their machine."
@dzaima The more emails, the merrier ^ ― hint, hint.
@Marshall Yeah I mean, it's cool - at a certain point might as well be an alphabet rubik's cube tho. Although... now I'm thinking it should be a take on the APL type ball? What you've got here is pretty close to a decent array langs logo for topanswers tho
@Adám I think I've changed my mind and that design by committee (including, combining logos into one logo) is trash. Let's just take the APL wiki grid of circles and be done with it?
I have asked for help on numpy here, when I first started learning APL, I was translating numpy to APL, but now more often I'm trying to translate APL to numpy
@Adám I don't think it's more alive than Dyalog, but J's been seeing a fair amount of development lately (led by my old high school teacher, Henry Rich!). The big change is a new direct definition syntax (no lexical scoping though; it's just a cover over existing explicit functions), and there are many more in the release notes.
@RikedyP Most of the credit should go to @Razetime.
@Adám From the announcement, "The importance of DD and the better readability over alternatives such as (. and ). weighed in that difficult decision." It's fully specified so I don't think you can really call it ambiguous, but it's definitely a type of word formation J hasn't seen before.
so, all array languages converged to some form of open-close punctuation to represent lambdas. given the prefix-infix syntax inherited from apl, it would have made more sense to add a pseudo-verb (just like "←" is a pseudo-adverb) that treats the rest of the expression like the body of an anonymous function.
(yes, apl has a problem with diamonds in parens, but that's a separate, more superficial issue)
@Marshall Even if the scope was just APLs and APL -descendents?
@Marshall We are deciding between scope the same as: 1) Array languages 2) APL Orchard (APL-likes J/K/BQN etc.) 3) APL Wiki (from APL's perspective) 4) Dyalog APL
@RikedyP Yeah. I felt like the circles were conveying the wiki aspect more than the array aspect (articles stretching off to the horizon) so it seems weird to use it for a non-wiki.
@RikedyP What kind of management tasks are there? I don't have moderation experience but I'd be interested in helping out if I can get a dedicated place to ask BQN questions.
@RikedyP I know, but it didn't really make sense to me in that context.
@RikedyP Yes, but that also makes it much less likely that anyone would be around to discuss BQN. Isn't that sort of separation better handled by tags?
@Marshall Well the main thing is that we're sitting on this great forum in topanswers.xyz/apl, the only thing holding back is deciding "what is the scope?" - we're tempted to just say Dyalog to start because it has TIO integration ready to go and the logo is already there
@Marshall I personally think making it same scope as the Orchard makes sense, but then what icon to go with?
@Marshall Still massively invokes "where is matlab?" "where is octave?" "where is BQN for that matter?" - I still think either 4D cube projection or APL Wiki logo is best we've got so far
@RikedyP I don't think those issues are that big of a deal? It would also be fine to say something like "this forum is focused on Dyalog, but array programming in any language that supports it is on topic".
@RikedyP The 4D cube is pretty cool. I'm not really going to push for my design (it would take a lot of polish to actually look good), but pick the logo based on the scope, not the other way around!
@Marshall @RikedyP Maybe "This forum is focused on APL, mainly the Dyalog implementation, but array programming in any language, and in particular APL-like languages, is on topic"
Technically the rule for a wide scope should be something like (0) any features of direct APL descendents (Matlab probably doesn't count?), or (1) array programming features of any language. The one-sentence summary shouldn't be that complicated though.
@xificurC Dyalog is generally a lot faster for operations on large arrays, especially if it can use booleans or small integers, since J doesn't have these. My own BQN implementation has completely horrible performance, but dzaima/BQN is all right—I'm guessing a little slower than J for large arrays but I haven't benchmarked. For code that's mainly scalar dzaima/BQN is actually the fastest since it's compiled to bytecode.
@RikedyP Lots of people say that, but I tend to find on inspection that they don't actually know what they're talking about. Not to say that it's false, just that I haven't seen much hard evidence either way.
@ngn Maybe it's the classic problem of benchmarks on specific tasks being used as evidence, when real world usage tends to muddy it up so much as to make the comparison a bit useless?
@ngn the original message literally said "Not to say that it's false, just that I haven't seen much hard evidence either way" and you still "lol"ed at it
@ngn If you're going to claim k/q are very fast relative to other languages, then yes you need to prove it. That comment wasn't directed at you; I don't remember you making any strong statements like that.
@dzaima This sounds truthy - also note that getting to the point after about a year of using an APL or APL-like you find you have most of the tools to tackle a lot of problems in fun ways (as in buliding your own solution from scratch).
@ngn Not to say you are wrong (I was saying the same thing as I'd heard it)
@ngn For the record - I personally don't care, but I've heard what I said a lot, that k/q are fast in computation but expensive in monies. You're now the one making concrete claims
@xificurC If your problem is naturally array-oriented, and you stick to array programming, a well-written Dyalog program can beat a reasonable C or Java program some of the time. The effort to make such a program ranges from trivial to heroic. Somewhat rarely, Dyalog can beat any portable C program on a current compiler because it's able to use vector instructions (they're detected at runtime). It all depends very much on the kind of problem you're solving.
@ngn things going for k in speed: no closures (should be insignificant if there are big arrays, and not be a big penalty even in bad code), smaller binary (should almost never matter either - you won't be using all of the language anyways), no GC (APLs can have that too, and it shouldn't be hard for an impl to almost never use it), and a slightly different primitive set (this i can't comment much about; including no high-rank arrays in this point for simplicity). anything i'm missing?
@Marshall This sort of goes without saying among APL users, but I should point out that code that doesn't use arrays effectively will be very slow in Dyalog and J: certainly worse than Python or Lisp. dzaima/BQN is somewhat better because of the compiler, but I doubt it beats those languages.
@dzaima i think most importantly the attitude to engineering is different. everything is simpler and smaller in k compared to apl/j. speed improvements come as a side effect. what you mentioned are instances of how this attitude is applied.
@Marshall how should I interpret the part "code that doesn't use arrays effectively"? I get that some problems are naturally fit for arrays and that some can be converted to them, but I'm not sure what are you implying, that badly written APL code will be slow or that there are problems that APL will be slow with, like algos or idk
@xificurC apl/j/k are great at doing things like 1 2 3+4 5 6, in which operations can be vectorized. in a conventional prog lang you would write a loop that iterates through the elements one by one.
a clever c compiler, for instance, might notice the opportunity for vectorization and emit appropriate code
the apl interpreter doesn't need to be that clever, as the arrays are ingrained in the language
and it has more opportunities to do things in bulk
but sometimes people who come to apl write code as if it's c/java/.. - they use loops, and thus take away the interpreter's ability to optimize the code
there are also certain classes of problems that can't be solved well with array programming - loopiness is inherent in them
@ngn that "attitude" you're speaking of shouldn't be exclusive to k. And I still don't agree that simplicity and brevity is a way to get performance (other than by either choosing to complete less, in which case it's not a fair comparison, or thinking more about how to write something definitely, which should be done regardless).
@xificurC unfortunately k5-6 is now abandoned. i say unfortunately because that was my favourite line of dialects. arthur whitney (the author of k) moved on to working on shakti (aka k9, see shakti.com) in which he made many changes.
@dzaima APLcart's purpose isn't to teach APL, though with understanding of APL's syntax, and the ability to look up the meaning of each symbol, it is fairly easy to pick out what the code does, if not why.
@xificurC so, if you're looking for something that is used a lot in finance now - you should study the previous version, k4 (which comes with q). if your horizon is like more than a few years - you should keep an eye on k9 (shakti).
@Adám as it is right now, i'd say it's often worse than just extending dfns with all its entries - they are often unreadable because of the trainification, and, unless you actually name each thing you copy, you don't have any reference of what it's supposed to be either
@xificurC dissatisfied - no. i think shakti has every chance to beat its predecessors in terms of performance and popularity. i just liked the previous syntax and set of primitives slightly better.. it might be some cognitive bias. also, shakti is under development, so things can change.
@dzaima but the apl interpreter wasn't written with such care. it's nowhere near. so, even when you write tight apl code (language issues aside), you're still at a disadvantage.
@ngn i thought i listed most of the language advantages in this list though? surely there's not much more an interpreter could do differently enough to actually give an observable performance boost
@ngn (yep, wrong link) scans are just an obvious mistake (among the other obvious primitive-level mistakes - singletons, axis syntax, etc), not an inherent thing to APL (see dzaima/APL). And scan is approximately the only one that meaningfully can affect performance (and when it does, it's obvious)
@dzaima never occurred to me that it's somewhat like k's !
(if you're somewhat concerned about another primitive changing quad, it's a better alternative to having separate branches for each value, and i definitely wanted to keep both around for a while until i could decide on one (which i still haven't))
"o" means "the function i'm currently in", like down-triangle in apl. in ngn/k i treat it as an ordinary identifier (deliberate choice), so it can't have a left argument.
@ngn no, I went through some tutorial once, using some k I don't remember. It was an html page with plaintext. Not sure which k version either :) Was a while ago
I also read like half of the J primer twice in my life, didn't stick though
@xificurC i can't offer professional lessons like adam, but ofc i'd be happy to answer any questions if you have any. there's also a dedicated k room (less active though)
@xificurC Probably best to wait until mid next week then, since I'm not really supposed to work tomorrow, though I'm still very busy preparing for my presentation.
Sorry to disappoint. I'm usually much more available.
This might be a bit of a taboo question but talking of making a living, where is the money in array languages? I like the idea of trying using one for actual real life software, but at least to me it doesn't look like there are that many options, outside of using kdb
@ngn That'll only buy you so much chocolate and wine… We have this thing called RIDE that could use some tender love and care by a JavaScript wizard, but I guess you're not interested.
@rak1507 Not taboo at all. I'm not sure what you mean by a lack of options. Money is certainly made using APL and other array languages.
Maybe I've just been looking in the wrong places, do you know of any companies that use APL and other languages to get an idea of what sort of work is done with those languages professionally?
@rak1507 A few significant examples are not on those lists. While a couple, I don't have permission to mention, among those that I can mention are the European Commision's use for economic statistics, and then there's SimCorp, whose main product, Dimension, is simply a Dyalog APL application (well, the back end is Dyalog APL; they now use a C# frontend).
@xificurC Not at all, especially not when used to implement an APL or an interface to APL. I use JS frequently (doesn't mean I like it, though), both privately and for Dyalog. E.g. APLcart is entirely written in JavaScript, and our next version of TryAPL uses a pure client-side JS frontend too.
the end user doesn't really care what's running in the background as long as it fulfills the desired goals. Nevertheless all tools need some UI, at least a command line one. And when one moves from programs to systems one needs to interface with other software, which nowadays mostly means http+json and databases, at least in my line of work
@xificurC Right, so we have a tool called HttpCommand, and a JSON/REST server (Jarvis), plus built-in conversion of arrays and objects to/from JSON: ⋄ ⎕JSON 'abc' (⍳4)
@xificurC ; is the universal separator. in (a;b) it separates list items. in f[a;b] it separates args or a[i;j] indices. in {a;b} it separates statements
Does coding in array languages influence the way you code in non array languages, particularly low level ones like C? I imagine it would be pretty hard to code in a similar style in such a low level language but does it have any influence?
And the fact that you can now imagine different solutions gives you a wider range of options to consider when you are actually about to write code... Which should help you write better solutions, if you give enough thought to what road to go down
f x without brackets is equivalent to a single-argument call f[x]
when you pass fewer args than required, a "projection" is formed (aka partially applied function, aka "currying")
so the {x*y}[5 6] you saw in the output was such a projection
one of the most beautiful things in k is the unification between function application, array indexing, and dictionary lookup - they all share the same syntax: f[x;y] - function application. a[i;j] - array indexing. d[k] - dictionary lookup
@xificurC If you're in the mood for a primer marathon, I'd also be interested in what you have to say about the two (fairly long) tutorials I've made for BQN so far. Don't interrupt your K readings for it of course.
@Adám "mods" feels like something that can keep getting applied, whereas adding an operand to a modifier changes its type. (⍠ could be called mod though, but that's unrelated to BQN)
@Adám "An orator must have subjects for its arguments" is a reasonable thing to say in English! Only problem is understanding it brings you no understanding of BQN.
@Adám Catch an error, like J's ::. It's supported in dzaima/BQN, but not my BQN. I am still pondering if there is a good way to allow it to access the error message, or if there should be block-level syntax for it instead of a modifier.
@Adám Then 𝕖 would have to work very differently from other special names. Either it's some kind of global or it just gets teleported into block functions somehow (and does it teleport into deferred block modifiers?).
@rak1507 Example from the markdown processor. The left operand gets the result of an expression; the right just says to use the string "ERROR" if that fails (it is evaluated on the original arguments, but since it's an array it acts as a constant function).
@dzaima Ah, ok, then it is safe to say that you added the proposed array notation (except forcing square brackets' major cells to rank≥1) in the spring of 2020.
When developing my Alexa skill, Each time I want to change user's screen in my skill (using APL), I return a new APL document. However, this is slow because it must load the document each time.
Is there a better way to do this instead of returning a new document each time?
I have found some info ...
