@ngn Thanks! It works great!

The fact that oK executes the scan-while loop at least once forced me to use 'cond' in my initial solution. Thank you for your interpreter!

hmm, how about moving my whole apls indexing from array of position vectors to vector of direction arrays? i.e. ⍳vec → ϼvec, this kind of @, etc? seems way more APLy and memory efficient

also the fact that matrices are indexed by y x instead of x y makes me want to make APLP5s G.rect, etc called with G.rect y1vec x1vec y2vec x2vec

Here's a question: if {1+⍣{check}⍣⍵⊢0} gets you the ⍵-th item of the sequence that satisfies {check}, is there an easy way to get the first ⍵ terms of a sequence without have to rerun the whole thing ⍵ times with {1+⍣{check}⍣⍵⊢0}¨⍳10?

Or a way to get only the second, third, and fifth terms, but in one go

@Sherlock9 No, unfortunately, there's no easy way. You'd have to modify the function to concatenate a new value to the list of old ones, using the newest existing one as argument this time around.

@Sherlock9 I've wanted to allow ⍣2 3 5 in my Extended APL, but it seems to be broken right now.

@Adám Hullnuts. That's going to take a lot of fiddling with the code, I can tell

@Adám Best of luck and thanks again

@Sherlock9 It does work!

@Adám Huzzah!

@Sherlock9 No guarantees though ;-)

@Sherlock9 my APL

@dzaima So ⍡ is exactly like ⍣ but returns a list of all stages until n or stable?

@Adám it's exactly ⍣ but cumulative

no stableness anywhere, unless ⍹ is ≡ in which case there obviously is

@dzaima That's what I meant.

@Sherlock9 for golfing or speed?

@dzaima So ⌽⍣0⊢1 2 3 gives 3 2 1‽

@Adám ⍹≤0 for ⍡ currently is equal to ⍹≡1 (aka do nothing), returning ⍬, so no

@dzaima Ugh, so -⍡1⊢42 is 42…

@dzaima pushed making it equal to ⍣

@Adám now it's ¯42

@dzaima Oh, good. Phew.

@Adám well the old version still made sense

@dzaima Ah, hold on, I think it should begin with 0

@Adám yeah, 0 is when it broke

new output

@dzaima so that now is just 1∘+⍣c⍡10⊢0

@dzaima No, I mean for 0 it should return ⍵. For 1 it should return ⍵(f⍵). For 2 it should return ⍵(f⍵)(f f⍵)

@Adám yeah, i did ಠ_ಠ at and fix the off-by-one

@dzaima grammar?

"I did ((disappointedly look at) ∧ (fix)) the off-by-one error"

@dzaima Much better. Hooray for formal logic and deterministic precedence.

@dzaima Grammar AND formal logic in the same sentence. Melikey

@dzaima That's a train btw, as ಠ_ಠ at and fix are applied to the off-by-one error and their results become the left and right args for and

:D

@ngn I'm Extending with ⌂fnname to call dfns, makes sense?

@Adám why the ⌂?

if it's a golfing language, i would put everything in the default namespace and even abbreviate the useful stuff to single letters

@ngn Because it is kind of similar to ⎕ (I thought if adding them all as ⎕DFNNAMES, but there were clashes) and because it is already in the character set, and it is kind of the "home" group of fns.

@ngn Extended Dyalog isn't a golfing language. It is just showing how powerful Dyalog APL could easily become.

@Adám i see. in that case, why not ⎕ instead of ⌂, in accordance with apl tradition? hard to parse?

@ngn Literality just told you that I thought if adding them all as ⎕DFNNAMES, but there were clashes.

if of

@Adám i don't know... ⌂ is probably ok, you use many squiggles anyway. renaming them is another option.

@ngn Renaming?

@ngn The alternative was a ⎕DFNS…

@Adám for instance if there's ⎕abc in the core language and abc in the dfns namespaces, you could make the dfns' one availble as ⎕def

@Adám what should the function do?

@ngn Oh, that's what you meant. Then it can't be automated (except appending "2" or something ugly like that).

@ktye It isn't a function, it is like the ⎕ prefix, but instead of referring to the system functions, it refers to the content of the dfns.dws library.

@ktye E.g. the dfns library has a function called cal. It will be available as ⌂cal

@Adám is that a general library, or a user supplied one?

@ktye It is installed with Dyalog, and also available online.

@Adám ok, so it's like a standard library, for everything that is not built-in with APL symbols.

@ktye Yes, the closest thing Dyalog has to a standard library right now. However, it is a bit annoying that the library contents isn't available without an explicit import, and even then it is only available in the namespace it was imported into. This ⌂ syntax addresses the issue by being universally available.

@Adám that more says to me that Dyalog doesn't have a good way to manage imports rather than a need to special-case dfns. what if i want to use another library globally?

@dzaima Right. I'm working on addressing this, but meanwhile for Extended… Actually, my real proposal is adding ⎕X (for extensions) as a new root namespace containing imports. I personally use ⎕SE.X as a model for this. Adding more modules is as easy as dropping folders into C:\X

@Adám radical idea: dfns.morse automatically imports dfns.dws as #.dfns and evaluates to the morse function from it

as long as there is no #.dfns name already present

maybe use ⌂ instead of . if that's too radical, and make 'dfns' the default for the part before ⌂/.

@ngn Uh, that;s basically what ⌂ does. It literally means (namespace with dfns copied in). ← note the trailing dot

problem with Dyalog is the many places code can be written in and them not being directly associated with scopes. for :namespaces, i'd be okay with having :import dfns but that doesn't translate well to dfns & lone tradfns, requires a fancy IDE to allow quick imports and doesn't seem very APLy

@Adám yeah, my idea is to generalize that for any workspace, not just dfns

@ngn wsname⌂item would be a new syntax, but 'wsname'.item is a consistent extension of . but a pain to model. I could do it with my high dot cover for . though. However, we really want to move away from workspaces as delivery format.

@dzaima Right, so in 17.1 you can drop files and folders containing files into specific locations and they will be imported when APL starts. You can also set one or two env vars to use custom locations.

@Adám are the library functions gonna be available right from the startup or is some code-wise import still needed?

@dzaima Right from startup, even if you load a workspace from the commandline.

@Adám right, that's what i don't like. maybe that's because i'm too used to java/C(++) though

@dzaima What's the problem? You already have lots of stuff in ⎕SE when you start.

@Adám though i have no idea what's in ⎕SE, I'd assume it isn't mission-critical, and if it is, i don't like it either

@Adám also i really don't like the idea of having a global library folder. i've heard tales of how annoying pythons setup is and i heard you saying before that the package management wasn't going to be global

@dzaima No it isn't critical. You can safely erase it all or use an empty or no session. However, things in ⎕SE survive switching workspace, as it is the right location for utilities. That was the original intention of ⎕SE. Note that you still have to prefix the names with ⎕SE., so it won't interfere with what you do.

@dzaima Morten is working on a workspace setup file that can part of a project. It will define which libraries to load for that project.

@Adám ah okay that sounds better

@dzaima It is for utilities you as a developer want to have at hand when you work, not for modules you want to include when you distribute your application to the end user.

@Adám libraries however are project-specific and so shouldn't be global

@dzaima OK, I shouldn't have answered your question then, as it was leading. I originally didn't say anything about libraries. I said you can drop files and folders…

@dzaima Also, things will only be in ⎕SE (or #). If you want to use stuff without giving the full address, you can set ⎕PATH←'⎕SE.mystuff ⎕SE.myutils'. ⎕PATH can be local to a function too.

@dzaima ok thinking about it more it's probably that. somewhere in the workspace defining what libraries to globally import (relative paths, global files, names, doesn't really matter) is probably okay

so how exactly would using e.g. base64 from dfns look?

@dzaima Where, in Extended, or using actual planned new functionality?

@Adám functionality that you're proposing to Dyalog (excluding specific to dfns)

@dzaima For now, dfns is a workspace, but I was pushing for it to be converted to a collection of text files. Assuming that part had been done, you'd set DYALOGSTARTUPSE=/path/to/folder_containing_dfns_folder. This would cause all of dfns to appear in ⎕SE.dfns upon startup. Now you can do use ⎕SE.dfns.base64. If you want to use dfns directly without ⎕SE.dfns. you set ⎕PATH←'⎕SE.dfns'. Now you can simply call base64 as long as you don't have anything called that where you are.

@Adám ah okay. using ⎕SE for what isn't really related to the session is a bit strange though

@dzaima How is it not related to the session?

@dzaima Btw, you can put it in # instead by setting DYALOGSTARTUPWS.

@Adám ⎕SE (afaik) can be saved & used for multiple workspaces and is preserved between )loads. libraries imo are workspace/project specific, so shouldn't bleed into other places

@dzaima Forget workspaces. In the new world, you shouldn't ever use )load.

@Adám still, the same session file can be used across multiple codebases, no? or is the whole idea of a session getting repurposed?

@dzaima Sure, it can be saved, which is nice if you want a specific development environment setup (or even several to choose between), but by default, changes to ⎕SE are not saved. So if you want to put project specific stuff into ⎕SE, don't use the env var, but rather the new Link tool: ⎕SE.Link.Import '⎕SE.mylib' '/path/to/mylib'

so ⎕SE isn't really the session but just an alternate namespace for things that should be globally accessible

@dzaima Yes, and not interfere with your main stuff in #. However, it is your "programming session", your act of sitting down to write stuff.

@dzaima One of the things that should be globally accessible and not disappear on )clear is the IDE GUI.

@Adám yes, that's a thing that should stay available throughout the IDE usage. Libraries, their versions and files, however, imo, shouldn't.

@dzaima Then just put them in #

@Adám yeah, that's probably what I'd do. Makes using them harder inside namespaces though, which would either require a builtin for the global namespace (which'd be strange) or importing to the current # everywhere (which is pretty much what java does). my personal solution would be to have another quad specifically for global things per-project

@dzaima I'm not sure what you mean by *a builtin for the global namespace. Isn't that #` as in #.mylib.myfn?

@dzaima Importing to the current #: You could obviously designate #.Libs for that and make sure you don't use that name for anything else.

@Adám oh by some reason i thought that # always referred to the current namespace, not the global one :|

@dzaima No, it always refers to the root of the current workspace, even if you are in ⎕SE. It is completely analogue to ⎕SE in that way. The current namespace is ⎕THIS.