⍴'' => 0, ⍴'a' => nothing, ⍴'ab' => 2, ? why ⍴'a' return nothing instead 1?

@elliptic00 because it's a character scalar, not a vector

@elliptic00 ≢'a' => 1

a single character has no shape

think of it as a point

Hey everyone; was playing around with a bit of OOP and smth weird happened:

when I define a tradfn as a method of my class, and make it :Access Public, so that the tradfn is accessible to users of the class, I don't need to localise the tradfn variables??

Oh wow I just understood what is happening... this is messy :P so, if the name is not localised, then the tradfn creates the name as a "field" of the instance, except it was not defined as a field, so you cannot directly access it in the session... however, if some other function of yours randomly reads that name, then it will have been defined... e.g., with this code:

:Class PSClass
    :Field Public ps

    ∇ NewParkingSystem spots
        :Implements Constructor
        :Access Public
        ps ← spots
    ∇

    ∇ bool ← AddCar carType
        :Access Public
        newps ← ps-carType=1+⍳3
        ps ← newps⌈0
        bool ← ~¯1∊newps
    ∇

    ∇ Print
        :Access Public
        ⎕← newps
    ∇
:EndClass

Notice how the Print fn tries to print a newps variable that is not defined as a :Field at the top, but is used as an auxiliary variable in the AddCar tradfn.

      psObj ← ⎕NEW PSClass (1 1 0)
      psObj.Print
VALUE ERROR: Undefined name: newps
Print[2] ⎕←newps
           ∧
      psObj.AddCar 2
1
      psObj.Print
1 0 0
      psObj.newps
 VALUE ERROR: Undefined name: newps
  psObj.newps
            ∧

i'm guessing the behavior of creating new fields as needed in the class is identical to namespaces, and classes just have special code disallowing dot syntax reading unless the name is public

Yeah, that's probably what is going on, but it's so confusing :P

non-auto-shadowing is to blame

↑ That right there, officer.

huh, a plain trailing semicolon in tradfn headers isn't allowed. what if that auto-shadowed all new variables? (surely that's easier to implement (and faster too) than dynamic checking of arbitrary strings against a list of arbitrary strings (unless there's some pseudo-renaming during tokenizing?))

oh wait, ⎕shadow complicates stuff (but also makes any tokenization-time improvements not really beneficial/possible)

how to count number of 'a' in a vector of strings: v <- 'banana' 'apple'

if one string then it is easy, mask <- 'a'='banana' <> +/mask

'a='banana' 'apple' does not give me a vector of mask

you could do +/∊ instead of +/, or +/ +/¨ 'a'='banana' 'apple'

'a'='banana' 'apple' gives you a vector of mask vectors, so 2 masks, one per word

sounds like potentially you want the total number? in which case you can flatten the vector with ∊

∊ is like flat map?

monadic ∊ is 'enlist' or flatten

so ∊'banana' 'apple' is 'bananaapple'

it seems to me ∊ can flatten any rank to a vector?

w ← 2 3 4 ⍴ ⍳ 100, +/ 1=(∊ w w)

yeah

huh, 1≢∊1, never thought about what ∊ did on a scalar before

Can APL have infix and infix operator like Haskell? max 2 3, or. 2 max 3 ?

you can only have infix

so u can not like max 2 3

well you could, but 2 3 there would be an array, not two separate scalars

@dzaima We are indeed considering exactly that. The problem is with things like Plus←+ ⋄ var←42 ⋄ var Plus←1

@elliptic00 You can just define your function to "unpack" the single argument, or possibly apply a reduction that "inserts" the infix function between the two elements (bearing in mind that it may enclose the result). So, e.g. max←⌈/ or max←{(a b)←⍵ ⋄ a⌈b}

@Adám well, that exactly shouldn't be a problem, but if Plus was defined in the surrounding namespace, it would be

@dzaima Can you explain how that exactly wouldn't be a problem? Think of what happens in a dfn.

oh, you can change nameclass in a dfn?

@Adám oh, i had completely forgotten that modified assignment in dfns is completely broken

Btw, my proposal is that in auto-localising tradfns, one must parenthesise the names in multiple assignments and also the function with the assignment arrow in modified assignment (at least using a named function).

I assume you can't make it work in a sane way because of backwards compat?

Yup. Dfns are very broken.

for some reason i thought that 4≡{a←3 ⋄ f←+ ⋄ a f←1 ⋄ a}0 and f←+ ⋄ 1≡{a←3 ⋄ a f←1}0

… So (a b)←c and a(b←)c

@Adám yay :/

@rak1507 Not too terrible. Luckily we have tradfns ;-)

tradfns are worse

seems like dyalog needs a 3rd function type

sanefns

Tradfns are clunky, but not broken.

@rak1507 "One standard to rule them all."

with no localized names, tradfns are still pretty much broken

tradfns aren't necessarily 'broken' but they don't work in a way that I would like to use, ever

@dzaima Every programming language is "broken" if you don't use it as specified.

(alternatively, BQN. In it, everything Just Works™)

@dzaima Based on over half a century of experience with APL.

@Adám doesn't mean it's worse

@dzaima No, it means it is better.

@Adám you know what else has half a century of experience with APL? APL.

J fixed things based on experience with traditional APL.

Dyalog fixed things based on experience with J.

BQN fixed things based on experience with all of the above.

@Adám and no language is "broken" if you use it precisely as specified

@dzaima PHP?

@rak1507 Sure, and I 100% agree that it is high time for a clean-slate APL-like language. I'm not sure BQN is it, though.

@Adám what if "broken" is part of the specification? :)

;-)

@Adám what don't you like about bqn? and I wasn't necessarily saying the solution is a whole new language, rather incremental changes over several decades, like any other programming language

too late for that now though

@rak1507 APL's at the point where backwards compatibility must be broken (and broken a lot) to improve stuff

yeah

@rak1507 Right-to-left, and I'm not completely sold on the glyphs used either. I'm also worried that the versatility of the braces overcomplicated matters.

@dzaima Agreed.

@dzaima (and if you're gonna break 90% of stuff, why not go at it and break 100%?)

Exactly.

@Adám LTR - that'd scare off pretty much everyone. glyphs - any in particular (or just 𝕨𝕩𝕗𝕘…)? braces - do you mean modifier guessing, headers, or both?

@dzaima Both the double-struck ones and the minuscule modifiers. I don't even know what "modifier guessing" is, and I don't think I fully understand all the headers either. Maybe I'm just scared of what I don't understand.

(i'm not really sold that LTR would really be any better either, with the exceptions of ÷ and -)

It'd allow sane evaluation of multiple consecutive functions.

It'd allow simple breaking up of a long line by injecting a variable.

It allows straight-forward reading and explaning the code.

It'd provide sensible order of multiple consecutive input prompts.

It'd allow line-continuation without having to find the last line first.

@Adám i guess you mean the superscript 1-modifiers (`˜¨˘⁼⌜´˝). Yeah, those aren't really perfect, but they're not much of a problem usually. What I just called "modifier guessing" is getting the type of a block (function, 1-modifier, 2-modifier) from whether in contains 𝔽 or 𝔾; headers are really simple - you write an expression before : that destructures the call, and the call gets destructured (it also allows omitting some stuff, which complicates things a bit, but not a lot)

@dzaima Ah, yes, then indeed I'm not much for the modifier guessing, but I'm undecided on that. Also, I'm not sure about the function ranks for some of the functions.

@Adám splitting up a line with a variable does seem cool, but really not that hard to do otherwise (and your variable name would end up somewhere in the middle of the line, making it hard to find)

I don't think that's much of a problem at all. Sure wasn't in TI-Basic. Assignments can easily be in the middle of a line anyway.

were long-lasting codebases written in TI-basic, where you want to be able to quickly move around?

Neither. Still, I'd love to try it out, to see how it feels.

I think these issues are just splitting hairs, the wider questions to me are why would anyone ever use a new array language over an existing language with a huge ecosystem

(whenever i'm reading a part of marshall's compiler, i get confused when a variable i want to understand is defined in the middle of a line. Sure, it's possible to get used to, and an IDE could just point at the definition, but that'd still mean i'd need to point the cursor at the name)

I don't think that's enough of an argument against what I perceive as important benefits of LtR.

@rak1507 True.

@rak1507 if you mean Dyalog, the ecosystem around it is hard to find, not that big, and not wonderfully pretty either

I think he means vs using, say Python.

I wasn't meaning dyalog, I was meaning regular languages.

(I also don't see any reason anyone would ever choose to use Dyalog for a new project either)

Interesting, though, that the array languages generally do multiple "unusual things" together: terse symbols, right-to-left, and REPL-centrism.

@rak1507 in that case, you would want to prefer a shiny new arraylang (assuming it works and suits your needs) over Dyalog with its awful backwards-compatibility side-effects anyways. Sure, we could just stop using arraylangs in general

@dzaima yeah, shiny new array lang sounds good, but not good enough to warrant using a new language. Not just true for array languages, but all new languages I see my reaction is normally 'that's cool, no ones ever going to use it though'

@Adám between RTL and LTR, I'd say RTL is still closer to most traditional languages. And you can't really do "terse symbols" without RTL or LTR

Apart from if it does something so differently and better to existing things that there is a viable reason to switch/rewrite large amounts of code

@dzaima Not sure what you're trying to say regarding direction there.

Are you saying that we need either RtL or LtR, and RtL is more natural, therefore RtL?

@Adám no, I'm saying that a consistent order is necessary for terse symbols, and (in a separate discussion) that IMO there's more of RTL in traditional languages than LTR

Ah, so you're saying that "terse symbols" and RtL are really only one thing.

@Adám (but not necessarily RTL. Terse symbols and LTR works too)

@dzaima (sure, there's the fact that a+b+c is (a+b)+c, but in JS a**b**c is a**(b**c), and C doesn't define the evaluation order of the subexpressions so there's no order there either)

(and BQN isn't any more REPL-centric than, say, Python)

True, BQN is the sole exception I know of.

i think that's mostly just because it isn't trying to appeal to (or is made by) people already using & liking a REPL-centric lang

True, BQN is the sole exception I know of.

(i had to check my matrix bridge/app didn't glitch there :P)

@dzaima BQN isn't trying to appeal to array language users?

@dzaima (though, to be fair, I'm the sole owner of any proper BQN REPL, so it's of course gonna be the way I like it)

@dzaima (A reboot caused trouble.)

@rak1507 to array language users who want to be REPL-centric at least, at least currently

(but who knows, maybe someone will build a REPL-centric interface for BQN. But it's at least not an absolutely necessary part of literally everything)

@dzaima (there's a missing ⋄ a at the end of the 2nd dfn there)

For context, BQN is designed to be somewhat conservative and avoid losing the good parts of APL\360. Of course that's up to my interpretation of what the good parts are or are considered to be. So I avoid making big changes like LtR that I don't know the consequences of.

When we started working on what became BQN, I identified various "tiers" of changes: A) additive to the existing APL, B) fixing the mistakes while remaining recognisable to APLers, C) reconsidering everything. I speculate that BQN falls in an unfortunate spot between B) and C) then, i.e. foreign enough to scare off APLers, but also too unusual to attract non-APLers.

I've started to get the impression that APLers are more easily scared than I had thought. If you had a B) language they may well try it and run away at the first serious semantic difference they run into.

But of course it's impossible to speak accurately about APLers as a whole.

Right, a B) language would only fix things like ⍳ on 1-element vectors, prevent ∊ from ravelling its right argument, etc. APL′ is pretty much what I think of as B). I think the function forms (tradfn/dfn) could be remade too, without too much friction.

@Adám imo changing to LTR would very signigicantly decrease recognizability to APLers. As-is, if you learn the glyph mapping and get used to ‿-strands, things often match up. The differences in builtin behavior shouldn't be that complicated, and wouldn't matter much at first either

Agreed, but I can't see established APLers take up BQN.

There are a lot of disestablished APLers, J dabblers, and just adventurous programmers out there though.

And you don't think they'd be interested in a LtR language at all?

Monopoly is not a goal of BQN.

@Adám close-mindedness to new langs is everywhere. I don't think many would switch to anything like APL′ either, as it provides comparatively very little for still breaking programs

@dzaima True, hence my belief in going all-out C).

@Adám I don't think there'd be much more interest for a LtR lang than a RtL one (assuming "RtL" isn't used in advertising material)

;-)

RtL sounds scary, but really isn't

I mean, the main goal is to make a language which I'm happy with, which design-wise is basically met. Since I think it's a nice language I want to make it easy for other people to learn about and start using it (and contribute libraries) but it's best for it to be one option among many.

@Adám interested what that would include

Me too.

@MatthewDaniels Welcome. Interested in APL?

no? never heard of it.

just came here to check it out.

the room, I mean.

have fun talking. (:

On not breaking things from APL\360: I genuinely don't know if LtR leads to a better language. The worst case could be pretty bad. If I do four things like that I will most likely end up with something worse than APL. But I thought there should be something definitely better than APL so I didn't want to do that.

Well, the topic now is "not APL", which could be classified as a subtopic of "APL"?

sorry if I'm leaving and rejoining. suddenly got pinged.

sorry for that

it's fine. I will stay here for a while.

okay, bye. :)