@Adám I have another question, sorry to keep bugging you. from inside a dfn, I want to call ⎕NR¨#.⎕NL¯3, but once inside that function, it reports dfns that are lexically declared from within the function as part of the root namespace
How can I ⎕NR¨#.⎕NL¯3 and return ONLY THOSE FUNCTIONS actually declared in the # namespace?
before I ran clear and relinked, even dfns from within other dfns not related to this one in any way were being reported
by reordering the call so that the expression above is the first line in the dfn, it doesn't report the dfns that are defined below it. But that assumes I won't need to call it another time on another namespace
Where in the Dyalog documentation can I find a description of how ∘ works? I was reading the trains documentation, and they just introduce the use of ∘ in the middle of a description and never explains what it does: help.dyalog.com/latest/Content/Language/Introduction/Trains.htm
Oh, now I think I get it. "bind" is a separate form, and it's always bind or compose, not both.
I can see how compose can be useful.
I need to find a different symbol to use for it though, since my parser would need a pretty ugly hack to handle both outer-join and compose for the same symbol.
Now, maths use ∘ for function composition, which is an argument in favour of dropping the ∘.FN syntax for outer join.
But then again, the traditional outer join syntax is very established.
@user41805 Yes, they have a dedicated operater for outer product. I actually also have that (written as FN⌺), and the ∘.FN syntax is just there fore APL compatibility.
At least that was the original thought. However, the traditional form is so common that ∘.FN becomes the natural form.
@nathanrogers If you have the latest Link then ]add ⎕IO should work. Otherwise you can hand-create an ⎕IO.apla file that just contains 0
@nathanrogers That's why I wrote my code the way I did. Best is maybe to put the utility function in a different namespace. (Also, for completeness, function declared in a function in # also live in #. Namespace scope ≠ function scope.)
@EliasMårtenson But that form is so anomalous. You may be interested in how Iverson rationalised it, namely that ∘.FN is an archaic spelling of 0 .FN i.e. . is a normal dyadic operator which can take either an array or a function left argument. If you make . prefer being an operator over being a decimal point (or alternatively disallow 1. for 1.0) so one isn't forced to insert a space; 0.FN
Then the only "bad" thing is that you'll often have to parenthesise x(0.+)y since x 0.+y will parse as as (x 0).+y
Which symbol would be appropriate for outer product then? As I mentioned, I currently use ⌺ but that's just because it looked like something enclosing something else. Very poor analogy, I know.
Actually, this makes the implementation simpler. ∘ is actually a real function in Kap (called NullFunction). Calling it raises an exception. The . operator explicitly checks if the left function is the NullFunction and if so delegates to the implementation of outer product.
It's really ugly, and if I get rid of ∘.FN then I can remove that code too.
:) I see. I should get used to the fact that APL cart is extending beyond its "how do I...?" credo. Although I don't think I would have thought to search like that.
Anyway, that's a nice feature of tradfns, being able to see from the header which things are optional,.
@xpqz Yes, and similarly, you can see if they are shy or not. Dfns can be both shy and not shy (confident?) at the same time.
Tradfns can also require a vector right argument with a fixed number of elements (a.k.a. a fixed number of "arguments") so you can let the APL system do that check instead of having to code it as (,N)≢⍴⍵:⎕SIGNAL⊂('EN'5)('Message' 'Right argument must be a vector of correct length')
@rak1507 Got this down to 33 in BQN. In Dyalog the 1↓(…)¨⟜» would just be 2(…)/¨ so this might actually come out shorter. Also the ⍟× wouldn't be needed, since 0|n is n instead of NaN. But you can't use an array right operand like ↕1+𝕩 for Power so that part would be worse.
@ngn right, you have an acceptable solution for dynamic scoping in tradfns. That doesn't mean it works for everyone as you yourself said, and for those eating the small inconvenience of the occasional misuse of tradfns is easier to deal with than creating a new language for themselves
@ngn if there was an actual initial element, the direction would probably be much more important (i'm saying this as BQN has rtl reduction with an initial element...), but as-is, reduce already just sucks for non-commutative things.
(imo the right-associativity of functions doesn't at all deserve to be related to reduction direction. even the simple fact that ⍵ is the accumulator is more useful to me)
@dzaima maybe the indices should be thought of as a different axis from the left-right line of syntax, and then the fact that the initial-value is on the left wouldn't matter
@dzaima (that is to say that / being RTL is pretty much pointless. I do think LTR would be better, but it's still a very very tiny problem (compared to scans or dynamic scoping); anyways gtg)
@xpqz I did a lot more on it. Too much to TIO comfortably. I'll get you a link once I've set it up in github, with working examples in a project structure.
@rak1507 Geoff wanted that, but the others wouldn't have it. Though, how would that work when accessing a non-array from a namespace? Also, you know about ⍎?
@rak1507 I disagree. He wants to make it {(⊂⍋⍵)⌷⍺} a.k.a. ⌷⍨∘⊂∘⍋ or with sane indexing ⊇⍨∘⍋ or with sane indexing and reverse-compose ⍋⍛⊇⍨ so not a whole lot of benefit for the cost.
I can't tell if you're being pedantic or if it actually doesn't read well. "they" as in "they who may or may not have built a non-trivial application in one of the 'copy-ks'"
@nathanrogers i said the non-trivial (according to your definition) application would have to be built with one of the proper ks (read: whitney's). i actually don't know if kona is used in a way you'd find non-trivial. i presume it's not.
@nathanrogers so if they∊{kx,shakti}, i'm sure they are telling someone about the applications, but they are not telling everyone
@Marshall Hm, realized a reader might think m is just setting f globally. Not so: the assignment to f is entirely contained in m. Actually, f is passed by name, and to apply it the name is reevaluated in whatever scope it happens to be in at the time. This is known and not considered to be a bug. To fix it, you have to apply Fix before calling an operator to expand all the names (because tacit functions can also contain them).
@nathanrogers Been all right. BQN's doing pretty well, and I'm starting to use it on some stuff that isn't just its own implementation. Been learning classical piano too, actually.
@nathanrogers Helps that I'm not too concerned about playing things to performance standards. I play guitar and piano for about an hour a day each, and clarinet off and on.
@nathanrogers Everything significant is on Github. Right now I'm working on synthesized music and Singeli, which is a low-level language for to use in implementation.
I also need to see if I can parse NOAA's weather data to get it on my desktop in a format I like. I had something working with Google's weather API a long time ago, but they killed it and NOAA is more complicated.
The Singeli implementation is interesting because I'm using OOP for a few things including AST nodes, so I get to see how good BQN's namespaces are for that. All right overall. No support for inheritance but composition is pretty easy to use instead.
@nathanrogers It's sort of Go-ish, maybe? Except that generics are basically the main feature so that part is not much like Go. But you should be able to declare operators, so you could add all the APL operators and put them at the same precedence and get something readable to an APLer.
