dzaima

message 2

hello world

@RubenVerg as a "hint" that it should be stable - if it weren't, there'd be no need to have both ⍋ and ⍒, as ⍒x would just be ⌽⍋x. And of course also that grade being stable is very useful

@Adám this?

I'd maybe say that they have the same structure

@B.Wilson that's for the monadic case, which isn't defined; though, yeah, "Not Yet Implemented" isn't really accurate if there is nothing to implement

and it's all very very incomplete

@B.Wilson dzaima/APL doesn't provide anything for allowing to invoke Java things from APL, so you'd be stuck doing most things in Java. It does have a Processing integration, which'd allow you to draw rectangles & circles & stuff, but no native UI stuff

@B.Wilson 1 + 2 3 4

@B.Wilson replacing the /**/s with ##s appears to make it compile

and {(+´÷≠) 𝕩⊏˜ (⌊⋈⌈) 2÷˜¯1+≠𝕩}∘∧∘∾ is one option for avoiding the branching for the median

an alternative way to write the second function might be {⌊´ ¬∘∊⟜𝕩⊸/ 1+↕≠𝕩}, avoiding one of the 1+es by "reusing" it

@Slimey BQN is 0-indexed, so /𝕩 is just the thing you use for APLs ⍸⍵ with ⎕IO←0. If you require 1-indexing, you indeed just 1+ that, same thing you'd do for anything you want to make 1-indexed

(my internet connection to pc is absolutely dying for whatever reason)

yeah

there's certainly no reason that an APL couldn't support directly assigning dops - dzaima/APL does

@B.Wilson they're more a list of tokens; or, rather, APL code in general is a list tokens before execution, that's nothing special to dfns

actually, {}s aren't even (necessarily) parsed ahead-of-time - 2+2 ⋄ { successfully evaluates 2+2 before it realizes that the curly brace is unmatched

:)

@dzaima and it largely can't - consider {f} - is that a valid dfn? it might be if f is an array, but not if it's a function or operator. And the class of a variable can change over time

because Dyalog doesn't parse dfns before execution beyond finding the closing brace; even { ]( } isn't a syntax error before it's called

any {}-enclosed thing that doesn't have ⍺⍺ ⍵⍵, nor ∇∇, will be a function

you'll have to separate out the statements - op←{∘} ⋄ 3=⎕NC'op'

it wants to build a train, just like 3=⎕NC'op'⊣op←+ or equivalently 3=⎕NC'op'⊣+

(or put f 5 in the "Input" field)

you want ⎕←f 5

there's also ⍺⍸⍵ but that & grade are the only things that use TAO iirc

that seems more like an issue with the color scheme and not the font

(remember that APL started out like in the 1960s)

as much as doing things by codepoints makes it impossible to construct mismatched UTF-16 surrogate pairs

realistically, the "proper" attitude should be that doing things by codepoints instead of graphemes is like the "new" version of doing UTF-16 without handling surrogate pairs - works for most things, but not all; but, unfortunately, while handling surrogate pairs is feasible to do yourself, with graphemes you pretty much have to get a library and suffer a heavy performance and/or memory usage penalty

and consider things like this where you would actually want to see the combining characters on their own

@B.Wilson APL, J, and BQN all have already chosen that the character type is a codepoint, that's not gonna change without a completely new language. and k (most of them at least) is even more behind, having characters be bytes. Grapheme clusters are a very niche thing for storage (which makes sense as they're variable-size, which makes them incredibly awful to impossible to work with in non-performance-destroying ways)

and there's not even much to do here - the matrix there is a 7×2, so there'll necessarily be some unwanted padding. There are like three conflicting interests - rendering as unicode-intended text, rendering as a matrix, and having the text output be copy-pasteable or programmatically readable

e.g. (↑'öööA' 'oooB') (2 2⍴⍳4)

combining diacritics don't exist just for zalgo of course, but yes

I personally think erroring is the sanest default if going for one option; multiple options is also acceptable, but I haven't found myself ever in a situation where I need padding and the prototype/fill element is acceptable

you can do 8⍴⍳4 though, which neatly repeats all elements twice; but 5⍴⍳4 is indeed strange. No way to do the former with a ⍬n⍴ though, all you can get is the weird behavior of 5⍴⍳4

@xpqz heh, I'd say recycle would be the most surprising behavior. I can see how it makes sense as an extension of regular Reshape, but for a ⍬ 2⍴ specifically it'd always result in putting a column 1 element in column 2, which I don't think would be desired like ever, and it only recycles to a max of less than one row too

but it at least folds array literals

this would suggest that it doesn't

BQN doesn't have operator trains

@user I do have an SE APL Orchard←→Matrix bridge that I run locally for myself, but it's not published anywhere and is decently incomplete

@nathanrogers oK should probably be feasible to use for such a thing; I don't know if it has any docs, but in a couple minutes I put together var env = baseEnv(); tojs(run(parse("2+!10"), env)) just from looking at its source (which can be ran from a js console in johnearnest.github.io/ok/index.html)

@nathanrogers do you have any example of a language where, going through FFI, interoperability for GUIs is easy?

@dzaima but for the rest of the cases where the external communication is just a tiny part of your program, writing a bit of C to wrap around them, and doing the rest 99% of your program in your language of choice, is a pretty simple option

@nathanrogers you're now in the very niche corner of "a significant portion of my program is dealing with events & callbacks in the other language", and I'd say that there's a large chance that no FFI will provide a better experience than just writing everything in the language native to the API

@dzaima but if the number of functions they have is not far off from the amount of code your whole program will be, honestly, just write the whole app in the language the library was meant to be used in