@RGS And you are using operators instead of functions because…?

@RGS Relevant.

@RGS Dyadic operators are 4th class citizens. They cannot be "returned", only named and applied. You can do _Each←¨ but not _Power_←⍣. Does it have to be this way? Not really.

@Adám Can you delete this I mistakenly created?

@Adám So arrays (1st) > functions (2nd) > mops (3rd) > dops (4th)?...

@Adám because these will later be applied to functions

@Adám this was relevant but didn't solve my issue, or did it?

(I have no idea if that "did it?" is proper English)

@RGS I meant strings, these will later be applied as functions to strings

@Bubbler I would've guessed arrays (0th) then monadic functions (1st) then dyadic functions (2nd)

@Bubbler Done.

@Bubbler Yes.

Thanks. I just checked the doc for A+ right after I created the redirect, and found that it does something different.

@RGS No it didn't. It just shows that you're not alone. APL's syntax is nice, but the cost is not being a full functional language.

@Adám ok so what would you suggest? Creating the string of code and then evaluating it with ⍎?

@RGS Can S not take a vector of characters and S does the looping?

@Adám it can for now because I only have simple parsers yet. However S is supposed to be much more general and later it will be applied to more complex functions, so I was looking for a more general solution

Polyglot of all APLs in the world?

@Bubbler Using ⎕AV:

+1 ×3
÷1 ×2
*0 ⌈1
~0 ↑1
!0 ⍕1
⍪1 ≢3 ⍝ +2
!1 ≢7 ⍝ +6

@ab5tract Not an oversight, just not quite got there yet. For one thing @Bubbler pointed out that 18.0 currently refers to the wrong version of RIDE, and that has led to me (a) fixing that problem and (b) working on adding zero footprint RIDE to all non-Windows installations.

@AndyS +1 for (b). Having ZF-RIDE by default will give huge advantage for cloud usage.

@Bubbler Indeed. I shall put my head down and get on with it ..

Is the Dyalog dfns workspace open for suggestions/submissions?

@xpqz Yes, in principle, but not practically. One of my side projects for 19.0 is to move it to GitHub, and then we can take suggestions and submissions in a more orderly manner.

Given a vector of integer pairs:

m1←(5 3)(5 6)(7 5)(4 7)(1 8)(2 4)(1 2)

I'd like to group based on the first element of each pair to produce:

m2←(5 (3 6))(7 (,5)) (4 (,7)) (1 (8 2)) (2 (,4))

Here's what I did:

data←(↑m1)[⍋(↑m1)[;1];]
k←⊣/data
v←⊢/data
↓⍉↑(∪k)(k⊆v)

Which does what I want. But is there a smarter/more concise way?

(order in teh resulting vector doesn't matter)

@xpqz play with k{⍺⍵}⌸m1, although tbh that's what you've got here I think

@xpqz There's probably a better way to make it format how you want but (⊃¨m1){⊂⍺,(⊂⊃∘⌽¨⍵)}⌸m1

@xpqz yours also seems faster right now due to lack of ¨

@xpqz Same idea as @RichardPark: ⊃¨{⊂⍺⍵}⌸⊢/¨ or purely tacit in 18.0: ⊃¨⊂⍤,∘⊂⌸⊢/¨

Thank you @RichardPark @Adám.

Actually, shorter and purely tacit in all versions: ↓⊃¨,∘⊂⌸⊢/¨

Reading tacits doesn't come natural to me still, even if I can just about work it out on a piece of paper.

@AndyS @AndyS thanks for the update!

@xpqz Trying to understand by converting to dfns helps, but it definitely takes a bit of time to internalise - I can't say I'm quite there yet

@xpqz Need translations?

@xpqz spaces - ↓ ⊃¨ ,∘⊂⌸ ⊢/¨; from that its clear that there are 4 parts (each a function) - ,∘⊂⌸ gets the args of ⊃¨ and ⊢/¨, and the result is ↓ed; ,∘⊂⌸ is an idiomatic usage of ⌸ and the rest is basic APL

(right, we now have ⍥; ,⍥⊂⌸ would be more 'correct' imo even if it doesn't matter here)

Yeah, might be a bit early to assume people have 18.0. Speaking of which, I need to start updating APLcart…

@Adám adding 18.0 entries? Also, have you thought of any way to tag or in any other way alert users to the version in which a given entry works?

@RGS Not so much adding, as much as updating existing entries to use 18.0 features. I think I'll just go with expecting people use the latest version.

I kind of follow @dzaima's process and normally manage to decipher -- I'm just not able to do it in my head, at a glance, yet.

@xpqz The important thing is to know which symbols are operators, and then isolate the non-train derived functions first.

@xpqz i did have to group those parts in my head, which can take a while. i find it easier to just copy-paste & add proper spaces, it gets way easier then

@Adám ok sounds reasonable, good luck !

@dzaima Nice!

@dzaima (of course much nicer with BQNs ⁼, otherwise it's unclear if ⍣1, ⍣¯2 etc would also work)

{x (∇⍣n) y → …}? (i think this is going too far :p)

@dzaima {(f∇) x → … ⋄ (F∇) x → … ⋄ (_f∇) x → …}?

{∇0→∇1→ 1 ⋄ +/∇¨⍵-1 2}? (again, probably too far)

ok i'll stop playing around with the header idea and get back to actually working on stuff

@dzaima Function terminates when it reaches a header?

@Adám i guess that's an assumption i've made

it can't really continue, there's nothing it could bind the new inapplicable variables

@dzaima Maybe there has to be a return statement before the next header.

@Adám but for the last header?

@dzaima Maybe not. Maybe nice to be explicit about returning.

Either that, or the separator before a header should not be a statement separator.

@Adám i remember a long long time ago i was thinking of having "returning" statements be ended by a ;

but i don't think there's a particular need for explicit returning here

@dzaima There is a named function definition in BQN2NGN. For example (a‿b F c)←a-b-c. You can distinguish it from selective assignment because that has to use ↩. No reason you couldn't allow separate monadic and dyadic definitions with this form or (F⁼ x)←….

But it is kind of a weird form of assignment. The body can only be a single expression, and nothing is allowed to the left of it.

@Marshall 1 2((a‿b F c)←a-b-c)3 ?

@Adám That's disallowed at the syntax level because it breaks the rule that assignment should return the thing to its right.

@Marshall But isn't the thing to its right a function?

@Adám a-b-c is a function body, not a function.

@Marshall shouldn't that apply to dfns then too? In both cases it's special syntax

@dzaima Huh? F←{𝕨+𝕩} is ordinary function assignment, if that's what you mean. The thing on the right is a function that you could use anywhere.

@Marshall ah, i misunderstood how that syntax was supposed to be used

wait, this works in dzaima/APL?

@dzaima Oh no! Please ban that.

@dzaima Huh:

> a←⊢
⊢
> b←⊢
⊢
> a
⊢
> b
⊢
> (a b)(c d)←(1 2)(3 4)
┌───┬───┐
│1 2│3 4│
└───┴───┘
> a
⊢
> b
⊢
> a b
(⊢ ⊢)
> a b c d
┌───┬───┐
│1 2│3 4│
└───┴───┘

@Adám (a b)(c d)←(1 2)(3 4) ≡ (a b) ⊢ ((c d)←(1 2)(3 4))

@dzaima Ah yes.

Then all is fine.

this is interesting, but isn't necessarily broken

(the way this works is that (a b)(c d) is a "mutable" object, and it is composed of mutable objects, and assigning works recursively, which is already required for the a b←c case; if a and b are functions, the mutable object can't be created)

TIL:

      n←1
      (n⊃(a b))←42
      ⎕NC⍪'ab'
2 0
      ⎕CLEAR
      n←2
      (n⊃(a b))←42
      ⎕NC⍪'ab'
0 2

and now in dzaima/BQN or whatever

i'm writing a good amount of cleanup TODOs for dzaima/APL while making this (most importantly, scrapping the whole "tokenizer", it sucks)

@dzaima interestingly enough (yes it's still using pretty much regular APL syntax otherwise)

@Marshall is it intentional you don't allow x←+ (as you can do x←⊑⟨+⟩)?

@dzaima Yes. I don't think there's a problem with val←Func, but Func↩val starts to look like modified assignment. I'm not sure there are actually any conflicts yet, but I don't want to have to worry about it when designing.

ah, understandable

and now, dynamically typed BQN... :p