@LdBeth This gives 1 2 3 with 2 on the left and 1 1 1 on the right

Oh wait, it's guaranteed there's only one solution. Never mind.

I have a question on code style (if this isn't adequate for the chat, do tell and I'll refrain from talking about this in the future)

Let's suppose I'm dealing with CSV data for a Person entity, and I know each row brings me data in the following order, Id, Name, Job and Date of Birth

I created an of operator defined as of ← {⍵⊃⍨⍵⍵⍳⊂⍺⍺}

And given PersonModel ← 'Id' 'Name' 'Job' 'DoB', I can use this operator as such: 'Job' of PersonModel ⊢ rowData

(which, supposing rowData is 1337 'John Doe' 'Developer' '1991-01-01', this would return 'Developer')

Now, while this is nice as a DSL, would this be overly complicated / overly verbose for APL standards?

no that's not an uncommon way of going about things

more so if you do like a {⍵[⍵⍵⍳⊆⍺⍺]}, then you can select 1 or several columns

of course you get a nested result, but you'd need that for multiple anyway

Adám sometimes speaks of his father defining where←⌿⍨so you can do items where condition

Hmmm, interesting

of course soon you'll be getting into the notation debate once you start abstracting in this way

should people lean on the shared core notation? or are we all making DSLs?

or is the point to have a DSL for your app, where the underlying code can be understood by any APLer?

I'd say it's hard to standardize stuff when APL itself doesn't have a standard, but... I guess Dyalog is the standard

We don't have a standard for how to use Dyalog, though.

I guess the community just isn't big enough for a standard to be formed, then?

well some organisations have code styles

but yeah there's not really one that a lot of people point to and go "if you want to adhere to a standard, try that one"

and what it should be is still kind of up for debate

just do not try reinvent SQL

You mean not to reinvent SQL with APL operators, or not to reinvent SQL as a "transforms-into-valid-SQL" DSL inside APL?

It is, learn the lesson from trying to make the statement like natural language but ended up having readability issue in complex statements. I would rather do (Id Name Job DoB)←⍳4 and then rowData[Job].

Btw, an issue I have with J is, after all that learning I still do not know wtf are the adverb verb conj thing, I think if there's a BNF that would be much easier.

In my many ideas of creating an APL variant (of which I never even started any), I once thought about enabling macro-like syntax so I could somehow translate a valid (or almost valid) APL expression into valid SQL (among other things)

Kinda like how .Net does its expression fuckery for Entity Framework

@AndréLeria For most applications, if you write more than a trivial amount of code for a particular problem, you will end up with a DSL of some sort. Programming effectively and productively requires removing duplication of code and applying useful names to things. Either you end up with organized DSL or you end up with a mess of unmaintainable duplication and inconsistency. I would quibble with your particular implementation for this problem, but that is a different question.

So, it's definitely not over verbose.

Also, I'm talking about internal or embedded DSLs, which are just APL functions and operators and and normal APL parsing and syntax.