@dzaima some operations would have to be limited, but as you said, the challenge is not sacrificing usability significantly for better type predictability (or whatever the term is)
@user41805 There's some conflict, or inefficiency, in that arrays already provide a lot of the benefits of static typing. They're static in terms of length and fast implementations optimize for element type as well. I discussed this some in my Outer Product talk.
Personally I think that dependent typing has a very valuable interaction with array programming because the definition of an array is basically that its axes are independent. But as far as I know, practical dependently-typed languages just don't exist yet.
There are also some newer projects mainly targetting machine learning, that focus mainly on flat homogeneous arrays. Arguably TensorFlow fits here but Dex and Futhark are closer to APL. Work on these is ongoing.
@user41805 By the way, the "typed" circle in that diagram is for typed functional programming, which is different from just having static types and first-class functions. I don't think there's a good concensus definition for this, but I used support for ADTs as the criterion and some other common features are typeclasses and monads. I think every statically-typed language should support ADTs but I don't know if you'd want all the other machinery in a typed array language.
@Marshall how so? yeah i'm not thinking of 'practical', just experimental being curious how such an apl (if it can still be called so) would look like and work
I've implemented the foundations of specialised array support doing a summarion or product over an array specialised on integers resulted in a speedup of between 10 and 15 times.
In concrete numbers, that meant that a +/ over 1 billion numbers now takes 0.5 seconds instead of 5 seconds.
The code is still generic, in the sense that I don't have special optimised loops for certain common functions. The speedup is purely from not boxing the numbers.
@user41805 It's hard to define what is and isn't practical. To explain some, most dependently-typed languages (Coq, Agda) are designed for writing proofs and the fact that they can be used for programming is incidental. Idris is for programming but is still working out usability issues in the language design and has a very slow compiler, even after a ~10x speedup in Idris 2, which is not fully released.
@ngn I used "static" as a metaphor there, to highlight that arrays must be rectangular but can be detected as homogeneous. I'm obviously aware that APL doesn't have static types.
Looking back at the talk, the telltale sign that something is like static typing instead of dynamic typing is that you know the type (which can be any metadata) even if there are no values. Array shape is like that, although Mix/Merge and the Rank operator can break that property.
@dzaima it's meaningless to compare your own impl against itself. it's like those n% discounts in the holidays season - "30% off" after having 40% above-market prices in the first place :)
@ngn it is meaningful if the impls aren't comparable (KAP has lazy evaluation which changes things a lot), or you don't indend one to be competitive with the other
@ngn It's valuable for other implementers to know, because if their implementation boxes every value like KAP did before then they can expect a similar speedup. It's not useful to someone choosing languages.
@ngn a generic object, but it doesn't appear to have any other overhead over a Double (e.g. shape is a function)
@dzaima actually i'm not sure - this specifies vals, but interfaces can't have fields. i'm assuming kotlin auto-generates getters and just uses functions
@Marshall actually, i think it was reading leanprover.github.io/about that led me thinking of this, particularly, "Lean is a functional programming language [...] You can also use Lean as an interactive theorem prover"
i found myself !aplwiki'ing, perhaps this should be suggested as a ddg bang?
If "reasonably" doesn't include performance, then you could use the smaller set from the runtime specification (everything up to "Commentary on other primitives").
@DyalogAPL Laziness doesn't make it instantaneous because it still has to perform the computation. Of course the specific case of +/⍳X can be computed with a formula, but I don't see any point in that since it's not an operation one might do ordinarily.
@dzaima Searching gives me some indication that abstract class calls at least were faster at some point in the past.
May be worth testing. There really isn't a good reason for it to be an interface, other than flexibility. And I haven't actually made use of that flexibility.
I think at some point I had an idea that I could create a subclass of some existing Java class and also implement the APLValue interface.
@ngn that's my primary complaint about c - it's ugly :)
that hypothetical language of mine (that i still intend to make one day) would look pretty much like java (except there's proper structs), but be able to be transpiled down to C or something (and probably allow for most C programs to be written in it semi-equivalently, though with uglier syntax for things i'd want to be used less, i.e. pointers)
Call for suggestions: I'll be making a presentation to uni-level maths students and I want to talk about APL. It will be over Zoom and I want people to interact with me. I also want them to be able to reproduce live whatever what I am doing, perhaps on TryAPL or on their own machines, provided they installed Dyalog APL ahead of time.
I want to showcase the affinity APL has for maths and also showcase its array-oriented capabilities.
Because for their hobbies I wouldn't be able to guess. Also, there'll be students from the whole country so I can't assume very specific knowledge about a specific domain.
@rak1507 APL would work great for numerical methods and related things.
Yeah, but AltGr+Shift+(asrw) is usually followed by a letter so I don't think anyone would try to use that to actually type APL chars like ⍥, which is just easier as AG+Shift+o
↑ (in the case that we are using AG+Shift+(asrw) for an accent)
Hi Adám. I'm reading about J now. There's an Android app, so I can play with it in free time. But it'd be nice to learn APL later on. I heard about April, do you think it's a good enough dialect?
@skovorodkin OK, I quickly read a bit about April, and it seems to follow Dyalog APL quite closely. If you later need help with learning APL in general, don't hesitate to ask. I can also help with pointing out main differences from J.
Thanks! I'm a slow learner, so don't expect any interesting questions too soon :) But in general, if you know J, it's not that hard to understand APL, right? I assume there's a lot of overlap in concepts between these two languages.
@user41805 aaron hsu says he did some experimentation with a typed apl. He gave up on it because the types had to be ~4x longer than the code itself to be at all usable. But maybe you can email him for more details on it
@Adám When coding and when thesis-writing are entirely different states. Note that about 1200 lines of Co-dfns source (that is, all but 17) are not covered by that thesis!