Just learned that Dyalog APL 17.1 is available without registration (non-commercial); neat!

@TessellatingHeckler I see that in 17.0 too, but not in 16.0 or 18.0. I'll report it. Thanks!

@scrawl Hi, interested in APL too, or just hanging out in k-space?

@Adám i'm in limbo between the two :)

i was actually wondering if people have discussed/explained solutions to this problem

i have a k solution but it's pretty unwieldy. and so long it's not worth posting haha

@scrawl Well, I'm not the one to tell you what to do. Both have upsides and downsides.

i still haven't had a chance to play with the APL + j solutions, but i'm not very familiar with those languages so not sure if i'll have any success!

@scrawl I'll be happy to assist if I can. The main paradigm difference is the array model. Maybe read this?

sorry. let me clarify some things because i've not been clear: by day i'm a q developer and so i generally use some flavour of k to solve puzzles. i've been recently reading into the history of k and am intrigued by APL / j and want to wet my feet - partly due to them often having shorter solutions in CG challenges :)

anyway, as mentioned, i have a hideously long k solution for the above-linked challenge. and the issue is definitely in my approach and not just a case of golfing the current solution. i'm trying to port one of the APL or j solutions, but i don't quite understand APL's stencil or j's sub-array operators

@scrawl apl uses more information per character - 8 bits. k (before shakti) is limited to printable ascii.

yes i'm aware!

presumably apl doesn't have overloaded operators. or at least, far few overloads as a resul

*result

@scrawl they even left some out, e.g. monadic ⊥ is still unused

@scrawl @dzaima has just solved it :)

@ngn neat! will look into it when i get home :)

@scrawl 18 bytes in ngn/k, i won't publish them yet

much shorter than mine... i will work on it again later

explaining my golfed version is a nightmare..

@dzaima i was trying to improve it when:

SyntaxError: both operands of dyadic ∘ must be functions

by design?

@ngn what would be an exception?

Exception in thread "main" APL.errors.SyntaxError: both operands of dyadic ∘ must be functions
	at APL.types.functions.builtins.dops.JotBuiltin.call(JotBuiltin.java:39)
	at APL.types.functions.DerivedDop.call(DerivedDop.java:25)
	at APL.types.functions.trains.Fork.call(Fork.java:35)
	at APL.types.functions.trains.Atop.call(Atop.java:31)
	at APL.types.functions.builtins.dops.RepeatBuiltin.call(RepeatBuiltin.java:46)
	at APL.types.functions.DerivedDop.call(DerivedDop.java:25)
	at APL.Exec.update(Exec.java:182)

(and yes, that's by design, as that's currently a message specifically written in ∘'s impl)

but... how does ⍬∘⍮ work?

@ngn it's called monadically

should i reword "dyadic ∘"?

ah... got it

fancy error messages :)

if you use dyalog terminology, ⍬ and ⍮ are the operands of ∘, and ⍬ isn't a function, so the error message is misleading

@ngn "both operands" indeed applies ⍬ and ⍮, and expects both of those to be functions (which ⍬ isn't)

@dzaima but it says just that they "must be functions" without mentioning that that's only for the dyadic case

@ngn "dyadic ∘"

@dzaima dyadic operator ≠ dyadically applied derived function

∘ is called a dyadic operator because it accepts 2 operands, not because it can accept 2 arguments

@ngn hence why i asked if i should reword "dyadic ∘". is there a shorter version than that "dyadically applied derived function"?

@dzaima i can't think of anything reasonable

let's see what dyalog reports in this case

SYNTAX ERROR: The function does not take a left argument

that's probably why i went with the short version, hoping that from the context it'd be obvious i wasn't for some reason explaining that ∘ is a dyadic operator :)

@ngn yeah, that's a completely different approach at where the error probably comes from (which does make more sense too)

"syntax error" still sounds wrong to me, in a different way from "dyadic ∘" :)

and k would've probably printed a helpful 'nyi here :D

@ngn in many cases syntax error (at least in my usage) is really type error, but splitting that out doesn't really feel worth it

@dzaima ⍛ is not in differences.txt

@ngn indeed, and i found a couple other things not mentioned. that file's a mess anyways :/

@dzaima in my languages: no docs - no problems :)

@ngn no users - no problems :)

i think it's best to piggyback on the big companies' docs and mention only the diffs like you did

@dzaima right, i've had a file for that uncommitted for a while - is % an okay character for that?

@dzaima 7 bytes as a proper function