The APL Orchard

dzaima

00:41

progress; left are inner blocks, ·-related things, ⍎, read/write •, and then deciding on what level do i want to integrate this (it'll be less debuggable, but as it'd probably be used for anything that needs to be fast, i can afford to make my interpreter more about debugging)
https://dzaima.github.io/paste/#0xRzLjtvI8a6vaMxcJOyAw36Q3dTEAbxje@OFvXBie4Fkd2BQGs5Ya5kUKMr2ZmEghyBINjnklhxzzT1AcguQ/ZP5knQ3H032g6Lkka3DDNVdXVVdr66uIgQAmHyXvImXIL753X9nN3/4K@T/Ax/c/Pn3gH/9J6wef/ob/4Lk83h885cfb/7497EXjG9@/M9nk8kEfPa/f/3075s//WMi0EhUIzrin9VmtlzMwXwZr9fg819@5V0nqQ@Sd0WSXq7B3SePvCLLlmvvyy@SdATA60Wa5eBNkq…

Marshall

01:02

@dzaima Plain • should be replaced with functions •in and •out, where •in has some argument saying how much you want to read (number of lines?).

dzaima

01:14

@Marshall i'll keep that in mind, but first i want to get it to work on the current things

dzaima

02:09

the Utf8 string constant thing in java class files.. doesn't actually encode the strings in utf-8. ಠ____ಠ

dzaima

04:02

@dzaima yay

dzaima

04:17

and it actually speeds things up

Bubbler

08:24

CMC: Given ⍺←0 or 1 and ⍵←any vector, remove the ⍺-th element from ⍵ (0-based indexing).

xpqz

@Bubbler ⍺ can only be ⍬ or 1?

Bubbler

@xpqz Zero or one, not zilde.

xpqz

@Bubbler How about

(0@⍺⊢1⍴⍨≢⍵)/⍵

ngn

08:55

@Bubbler @xpqz ↑,1↓↓

in k (k6 or earlier): _ with swapped args

xpqz

09:16

@ngn It feels like a small but significant victory that I managed to un-tacit that to

(⍺↑⍵),1↓⍺↓⍵

Adám

09:42

CMC: Given an array, determine if it a "⎕OR".

ngn

@Adám {1⍬≡(≡⍵)(⍴⍵)}

Adám

@ngn I have 7.

ngn

@Adám 1≡≡∧⍬≡⍴

Adám

That's a nice one. I had 1≡⍥,≡,⍴

ngn

@Adám 1≡⍴⍴≡

Adám

09:51

Real golf, super inefficient, but short.

RGS

10:19

@xpqz a nice vector of 1s is =⍨⍵

RGS

10:31

@Adám random idea for aplcart/quiz: allow to filter for estimated difficulty, e.g. easy/hard or easy/medium/hard; some descriptions already have words like "medium" and "hard" characterising the task so I figured this wouldn't be too difficult

Adám

10:42

@RGS They all have a difficulty stated. And yes, I thought about having three buttons: [Next easy task], [Next medium task], [Next hard task].

xpqz

@RGS Or maybe ~≡¨?

RGS

11:20

@xpqz I believe that one might give an error

xpqz

@RGS How so?

      ~≡¨1 2 3 4
┌→──────┐
│1 1 1 1│
└~──────┘

RGS

@xpqz depends on what's in the major cells

But I was being completely general; for your use case above ofc it works

dzaima

@xpqz that only works on arrays of scalars. On those you can even do ≢¨

RGS

@RGS it even shows it can error of the rank of the things in the major cells is geq to 2

xpqz

Interesting -- the way =⍨ drills into nested arrays I think means that ⍵/⍨0@⍺⊢=⍨⍵ wouldn't "do what I mean"

RGS

11:30

But in the spirit of your approach I'd say 1⍨¨ is nicer, although one byte longer than ≢¨

ngn

11:50

@xpqz no need for ⊢ there. to support nested, it could be ⍵/⍨⍺≠⍳≢⍵.

dzaima

12:55

@dzaima constant folding

Marshall

@dzaima But note that I've deliberately computed large constants outside of functions, based on the assumption that dzaima/BQN doesn't have constant folding. I don't think this choice has any effect for DGenFn, but I moved rcp and or outside of Compile for example. There are more cases of this in md.bqn.

dzaima

@Marshall oh, it doesn't touch variables, nor does it call any functions ever. (at least not until i do something about variables, i do want to have a non-hashmap variable system for when there are no ⍎s in sight)

it's just for array constants & derived primitives & trains

Marshall

13:16

@dzaima That probably shows up a lot more often actually. Would also be interesting to see inlining/expansion for primitive modifiers and trains.

@dzaima Would be nice to have the typical frame/index format for lexical variables so I can do the lexical scoping in the compiler.

dzaima

@Marshall right, for the java-compiled version it'd probably be better than the regular operator tree walking

@Marshall how does what you have in mind handle accessing parent frame variables?

Marshall

@dzaima That's what the frame number is for. I don't remember the details exactly; let me see if I can find a page on it somewhere...

dzaima

@Marshall ah, so every load/store has 2 number args

Marshall

@dzaima Yes.

dzaima

13:36

@dzaima hmm, is it correct to get whether hashmap variables must be used just by looking at if there's an ⍎ in the body?

Marshall

@dzaima Sounds right, to my surprise. And I guess if the variables are numbered then all you need is a list of names for them, which never has to be accessed outside of ⍎.

dzaima

@dzaima (note that to be able to jump in the middle of the bytecode i need a jump per wanted location, so currently only jumping to start & after a RETN work)

Marshall

Some literature on compiled lexical scoping.

That's probably harder than just making each scope have a pointer to its parent, which seems like the obvious solution but takes more time to access variables in enclosing scopes. You could also combine the frame and variable index into one by going to the next higher scope if the index is higher than the number of variables in the scopes viewed so far. Or you could keep a pointer to every enclosing scope so accesses are constant time.

dzaima

14:00

@Marshall i still plan to keep using my Scope objects which hold a pointer to their parent, just add an alternate variable storage & alternates for VARO/VARM

the case of accessing a variable 10 scopes up should be rare enough for me to not worry about it currently

Marshall

@dzaima Probably best to do the single-index thing then.

dzaima

i'll go with a parent count & index for now

(pushed the current changes)

dzaima

16:23

I think i'll be switching to the block arguments (𝕨𝕩𝕗𝕘𝕊𝕣) being indexed variables, and the two systems can just live together (the hashmap system could even fall back to searching linearly trough the index system, e.g. if you )cs into an index-based function and want to make new variables or something)

dzaima

16:33

@dzaima or the hashmap system could be fully removed, and the indexed system just extends the table if that's needed. The variable resolution and slot allocation still happen at compile-time and so not be slow ever (except if you're compiling many things)

that'd have the side-effect that x←1 ⋄ {𝕊: ⍎"x←2" ⋄ x∾⍎"x"}0 gives 1‿2; that's just fine for the REPL, and easy enough to get around for code usage (just use ↩)

the only needed change to the bytecode is that variables must now also store their depth, the strings could be kept around if that's desired

Marshall

17:15

@dzaima Not sure exactly what you're proposing but I would say the hashmap should just just be a map from variable name to slot index. I'd be inclined to say ⍎ shouldn't be able to declare variables (more generally, only ← that's lexically inside a particular block, or headers, should be able to declare variables), but you could also make it add slots along with entries in the hashmap.

And of course there's nothing preventing you from storing a list of names initially and only turning it into a hash map when you feel like it.

dzaima

@Marshall the thing with allowing ← in ⍎ is that the REPL needs to be able to create new variables in an existing scope, and once that's possible, extending ⍎ is trivial

the "easy" way of getting around ⍎s weirdness would be that it creates a new scope for itself, so any ←s aren't visible outside, but that's purely a restriction

Marshall

18:52

c.bqn now compiles all but two lines of testref.bqn, about 5kB. Scaling looks linear.

dzaima

@Marshall tests pass with the new variable system, though nothing's actually using it (variables stored in a Value[], names in a String[], and a HashMap<String, Integer> for lookup)

Marshall

@dzaima Does it have a bytecode interface yet?

dzaima

@Marshall not quite (and i'm still undecided on how exactly to handle 𝕨𝕗𝕊𝕣𝕘𝕩 as being able to write those without lookup would be nice)

Marshall

@dzaima They should just be local variables with no names, right? The ordering's not obvious but maybe 𝕤𝕩𝕨𝕣𝕗𝕘.

So the number of special names is 0 for f, 2 for m, 3 for d plus 3 for non-immediate, and the index of a special name is its index in that overall order minus 3 for immediate.

   𝕤𝕩𝕨𝕣𝕗𝕘
f1 ······
f0 012···
m1 ···01·
m0 01234·
d1 ···012
d0 012345

dzaima

19:17

@Marshall that's nice; if ignoring immediate modifiers, a contiguous segment starting from 0 is used by them (allowing for actual variables immediately after), and writing doesn't need to care about what's the type written to, and the 3 potentially wasted slots for immediate operators is fine. (otherwise they would still be regular named variables, included in whatever will govern the variable information for •COMP)

Marshall

@dzaima Given that by far the most common case should be referring to a variable by index, I'd say to do the extra index computation when accessing special names by string and save the 3 slots.

dzaima

@Marshall i guess that's also an acceptable method. i was thinking header dispatching would make that more complicated, but headers don't actually care about the raw argument variables themselves

code_report

23:13

can someone enlighten me why: '1'≡⍕1 returns 0 and not 1?

Moonchild

@code_report '1' is a character scalar, but ⍕ returns a vector

@code_report (,'1')≡⍕1

code_report

23:27

@Moonchild thanks! that solved my problem (on to the next one)

Transcript for