@jordancurve in src/vm.h, on line 6, change the 2 to a -1, and rebuild. Should solve the issue, at the cost of a bit slower scalar code, until i figure things out tomorrow
@jordancurve (might you be on an arm architecture machine?)
@dzaima (actually, I don't think that'd even change anything, but IIRC at least one other person has CBQN working on macOS. The JIT relies on the base code being below address 2^31 to be able to make relative calls to it, and -no-pie has so far made that be the case)
¯\_(ツ)_/¯ guess -no-pie doesn't guarantee code location. Will try to make JIT work without that tomorrow. The problem is that x86-64 call instructions are limited to a 32-bit offset, so JIT code must be allocated within 2^31 of anything it calls, but there's not a trivial way to just request memory in a specific range (but it should be possible to request somewhere nearby (and retry if it didn't work))
@EliasMårtenson It works as an if statement, but there are two limitations: 1) it is allowed only inside a dfn {...}. 2) when the guard condition is met, the dfn returns right away, so it's hard to use in the scenarios like {y←if(a){b}else{c} ⋄ some computation on y ⋄ return something later}.
K has a proper if-then-else built-in using its own syntax for high-adic functions $[if1;then1;if2;then2;...;else], but it isn't easily adaptable to APL.
Kap can leverage the defer feature which can be used in some cases. Let's say you have a value X, and you want to call either functions F0 or F1 or argument Y depending on whether X is true or false. You can do this: X ⌷ (F0 defer Y) (F1 defer Y)
@EliasMårtenson I'd write y ← Z ⊣⍣(X≡⍬)⊢ X however if you allow constant operands to represent constant functions (as @ and ⍨ do, and as BQN does in general) then ⊣ can go away, and if you get rid of implicit stranding (as SHARP APL, J, and BQN do) then you can get rid of ⊢ giving you y ← Z ⍣(X≡⍬) X which is nice imo.
@EliasMårtenson GNU APL uses this anomalous syntax:
Given a list in APL I would like to check that each adjacent pair is in order.
So, given (a0, a1, ..., an), I would like to calculate:
(a0 ≤ a1) ∧ (a1 ≤ a2) ∧ .... ∧ (a[n-1] ≤ an)
I don't want to compute an equivalent form and I want to use tacit programming.
My solution is ((¯1↓⊢)∧.≤(1↓⊢)) but i...
@EliasMårtenson BQN has ◶ which is both more versatile and uses normal syntax.
It works like this: (a>b)◶⟨{2+⍵}⋄{1+⍵}⟩ 100
Has the benefit that the "condition" is actually an index into the right operand array of functions, so you can have numbers greater than 1.
The left operand can (as always in BQN) be a function or an array. If it is a function, it is applied to the argument(s) and the result is used to choose with.
And of course, the elements of the right operand can be arrays instead of functions too.
So your original statement can be written as y ← (0=≠)◶⟨z⋄⊢⟩ x but of course, BQN also has z⍟(0=≠) x
(Here I use 0=≠ which is equivalent to 0=≢ in APL because BQN doesn't have ⍬)
Speaking of functions, I was under the impression that Dyalog derived a function from an expression without a right argument? I.e. (2+) 3 would work. Or something like add2 ← 2+ being equivalent to add2 ← {2+⍵}
That doesn't seem to work. Was there another APL that did this?
@EliasMårtenson (Pedantic: They are not strictly the same. {2+⍵} is equivalent to 2+⊢ in that they both ignore their left argument. 2+ would be equivalent to 2∘+ in prohibiting a left argument.)
@EliasMårtenson Only for code golf. Maybe where I most often want it is for constructs like ∧/2≤/⊢ where ∧/2≤/ seems "cleaner".
I tend to use A∘f over Af⊢ because it indicates that the function is only ever intended to be used monadically. Lack of such indication is one of the things people complain about when it comes to tacit functions.
@Adám Yeah. I'm trying to solve them in a more clean way.
I've come to realise that Kap does need something like Dyalogs :⋄ using similar semantics. The if/else statements in the part04 solution is really ugly.
@EliasMårtenson In general, dfn guards work well for what they are for. Only where you'd use inline ternaries in other languages can they be a little ugly.