@RosLuP Press Ctrl+K to make your message monospace so it will look better.

I for little functions use line number as label, in one editor show them and goto instruction in the form "-->Nline x i condition" and if instruction in the form "-->Nline x i ~ condition"

and + use indentation but in codegolf is not showed..

@RosLuP For golfing, sure, but it is much clearer to use labels, and much safer too if you insert more code.

@RosLuP It does show if you use monospace as I said:

r←h w;y;c;v
r←c←y←0⋄→4
  y+←1⋄→3×⍳∼0πv←1+3×y×1+y⋄r←v⋄→0×⍳w≤c+←1
  v+←3×y+1⋄→2×⍳∼0πv⋄c+←1⋄r←v
→2×⍳w>c

@RosLuP By the way, you don't need ⍳ in the last line.

I find :if :for etc not fit well ... Possible I see the things too much near as in microscope , even not see code use extensive that , possible I have too much different experience in using goto label and jump in assembly

@Adám the "-->2xiw>c" in the last line has to be intended as the previous line because it is in the loop; iota in the last line... Yes if w>c the result is 1 goto 2; if it is 0 than goto 0 , goto exit... But when goto I would prefer one only form always the same, so I prefer the other... Yes for codegolf is not ok...

@RosLuP My father would create a utility if←/⍨ so you can write:

r←h w;y;c;v
r←c←y←0⋄→4
loop: y+←1⋄→3×⍳∼0πv←1+3×y×1+y⋄r←v⋄→0×⍳w≤c+←1
      v+←3×y+1⋄→2×⍳∼0πv⋄c+←1⋄r←v
      →loop if w>c

if←×∘⍳ works too of course.

Oh, I now notice that you have more branches.

I think this is much easier to read (although it is pretty spaghetti-ish…):

 r←h w;y;c;v;if;return
 if←/⍨ ⋄ return←0
 r←c←y←0
 →end
loop: y+←1
    →continue if ∼0πv←1+3×y×1+y
    r←v
    →return if w≤c+←1
continue: v+←3×y+1
    →loop 1 if ∼0πv
    c+←1
    r←v
end: →loop if w>c

The problem would be find the nth Cuban Prime in link codegolf.stackexchange.com/a/185632/58988

I read ⋄→3×⍳∼0πv←1+3×y×1+y⋄r←v "if that v is prime follow the line" ; →0×⍳w≤c+←1 if w<=c (after increment c) goto 0 ... Yes I would golf y+<--1 merge in the follow instruction

@Adám I never understood why it isn't the last non-assignment non-guard instead

You might've explained it to me already, but...

@Ven Because FP prohibits side effects, so if you're not assigning anything, it means that this is the result. However, people frequently abuse dfns for non-FP, so it would have been nice to not have to make dummy assignments.

It doesn't prohibit side effects -- they just are a value type too :) (and that's in Haskell, Scala/Ocaml/... care much less about that bit. You're right tho)

@Ven because they worship backwards compatibility - the perpetuation of early mistakes :)

.oO( We need another statement separator, that discard the left... )

@Ven What?

@ngn Not fair. It isn't worship of backwards compatibility, but rather a concern for the employees that need to be fed by income stemming from existing applications.

@Adám lol

@ngn Why is that funny?

@Adám what does fixing language design have to do with feeding anyone? :)

@ngn You really don't understand that‽ Our customers have hundreds of thousands of lines of code. If we change the behaviour of existing language features, that code may break.

@Adám "dear locked-in customers, this is a breaking change we're gonna make in the next major version, please rerun your tests and change your code accordingly. we're sorry, that syntax was an old mistake. now it's gone" - done :)

it depends on what language feature you're fixing, of course, but i suspect in most cases the cost of fixing your customers' code (even if you have to pay for it) would be less than supporting early mistakes indefinitely

@ngn "Dear patient that got wrong medication, your medical journal system is now based on software that is more beautiful from a language design perspective."

@Adám if that's a concern, well, don't upgrade

@ngn "Dear car crash victim, rest assured that the truck that broke your back and killed your family was planned on a system looks really nice."

@ngn And if the upgrade is required to run on modern systems? Stay on an old system with known vulnerabilities?

That being said, I think that some design mistakes are safe to fix, e.g. scalar⊤

@ngn @Ven And that's not even true. The rule about termination of dfns was very deliberate. People just abuse dfns.

@Adám i understand your desire to justify whatever dyalog happens to be doing now, but i also suspect you would never design it like that if you were starting from scratch

@ngn Wrong on both counts.

anyway, dfns do most things right. i'd rather hate tradfns :)

@ngn I see positive and negative aspects of both tradfns and dfns. I'd prefer one unified function system with the upsides of both, and without the downsides of any.

@Adám is there a way to bypass the maximum of 34 digits of ⎕PP to print in an arbitrary precision?

I found a neat solution to the pi^(1/pi) challenge

@J.Sallé You can't force more precision than ⎕FR←1287 will give you, but you can ask for any number of decimals with dyadic ⍕ and it will mark unknown digits with _.

Oooooh, nice! I'll check that out

⋄ ⎕FR←1287
⋄ ⎕←50⍕○1

@Adám
 3.141592653589793238462643383279503_________________

Yeah, ⎕FR←1287 doesn't really let me go any further

@J.Sallé
 1.439619495847590693370645390214297_______________________________________________

Oh well. I liked that answer >.>

@J.Sallé In a better world… ⍞←∞⍕○1

Is extended that better world yet? hahahahah

@J.Sallé In a better world, we'd use base-8, and there's a direct formula for the Nth digit of pi in base-8. Unfortunately, for conversion to base-10, you need to know all the previous digits.

@Adám Oh, I didn't know of that formula. TIL that and that i×⍟¯1 = pi

^ -i rather than i

@J.Sallé It is actually stated in Dyalog's documentation.

@J.Sallé 0=1+*○0j1 → ¯1=*○0j1 → (⍟¯1)=○0j1 → (0J1÷⍨⍟¯1)=○1 → (0J¯1×⍟¯1)=○1