mine doesn't (didn't) intentionally at least. I don't particularly like it (now a name can also be a function-returning function, function-returning operator (monadic and dyadic), along the old list of an array, regular function, monadic operator and dyadic operator), but haven't disabled it
@RGS That (tradfns returning functions) should be on the APL humour page - I am pretty sure that feature started its life as a bug. Now we cannot remove it.
@xpqz Why should I? No one told me explicitly, and all my attempts at functional programming never worked out very well because functions are not first class citizens...
@MortenKromberg Maybe the humour page could contain a section devoted to bugs that people started to rely on, and now can't be fixed or caused mayhem when fixed
@Adám I don't know that I can easily compute my best guess at the number of APL'ers, but I would feel very comfortable claiming to DDG that the number is greater than 500.
@MartinJaniczek BTW, would you be interested in checking out the very latest version of Link, currently known as 2.1 but about to be renumbered as 3.0? This is the version that we plan to ship with Dyalog 18.1 and I think it has passed the point of being a better and more stable version than the old 2.0.3?
I can try this specific issue with a different version of Link if you want to (only used it because the instructions in aplcart said so); but I havent yet gotten around to using Link otherwise :)
@MortenKromberg After installing the Link from master, running ]udebug on results in * Command Execution Failed: cannot find the file "/NASBuild/jenkins/nodes/docker-build/workspace/Dyalog_18.0_Linux_Nightly/SALT-/spice/Spice.dyalog". Unsure what that's about. Maybe I overwrote a directory instead of merging or something.
I'll try to reinstall Dyalog and install the master Link more carefully :)
@Razetime Oops... Ahem... well, I know we have been doing work on our CI framework recently. I will leave you in Adam's hands for further debugging - thanks for your patience!
@MartinJaniczek Interesting to say the least ! Adam has just asked me to take a look at this. I wouldn't reinstall just yet as I have a strong suspicion that you'll get exactly the same outcome ! I'll take a look in the near future ..
@AndyS I've just tried the same set of actions to copy items into a directory with a mix of already existing folders / items (on an unrelated filesystem tree), and that confirmed my suspicion that I've overwrote the folders instead of merging. Hence, if old SALT folder had files a.txt and b.txt and the link-master SALT folder had b.txt, after my overwriting the a.txt would be gone.
Which makes me think it's my error, but anyways I'll leave the installation in its current state if you want to try something on it.
@Razetime Better than 100 words. So that's the white window you were walking about; the status window. Right, are you sure your code is syntactically correct? No stray ∇s?
@Adám That is insane, IMO. People should always use dfns, no matter what the cost. Using one's judgement is a preposterous thing to ask of people. Everyone should blindly follow the dfns cult. Long live the dfns.
@Razetime Dfns can too. A common thing is running an inner function in a loop, with the inner function adding to an accumulator in the outer function. Dfns can only do that if the inner function is defined inside the outer function.
You can use )ed path/to/file.ext but apparently there's a bug where RIDE will ask you a meaningless question. Everything should still work, though, if you just ignore the question and click OK or whatever the default button is.
On Windows, we have a stand-alone APL editor too, which doesn't care what your content is (though it will attempt to make sense of it).
It should also work to create a file (by whatever means) that contains multiple APL items, and then 2⎕FIX and edit that.
Just note that the editor runs in multiple separate modes, so you cannot, e.g. edit a function and insert :namespace foo at the top and :endnamespace at the bottom.
@MartinJaniczek When you get the time, can you download and install/upgrade to the latest 18.0 from www.dyalog.com. Indeed, for anyone who's using 18.0 and isn't running 18.0.39712 (for non-Windows platforms), and 18.0.39659 (for Windows) we would recommend that you update to the latest revision. I can't find anything directly related to this issue, but the number of references to /NASBuild in an installation image drops significantly between early October and mid-November last year ..
@AndyS I will, thanks. BTW would it be costly for Dyalog to upgrade the upload speed of the servers with the binaries? It's topping at around 300 kBps for me, which means the download takes 10min
I don't know the specifics of the server (is it on some Amazon farm for example?) All I know is - I had this problem when downloading Dyalog APL initially, and my ISP's download speed most likely isn't the problem (I can download many MB per second from elsewhere)
@rak1507 We regularly commit fixes to all our supported versions (the last three versions), so in general it's always a good idea to grab the most recent revision. In the case of 18.0 we recommend updating to what we called Issue 3 as earlier revisions of 18.0 include a problem where ⍳ can give the wrong result where the left argument contains 4-byte integers, and the right argument contains floats.
"relative notions" - wtf "the chain of function calls that are currently being interpreted" - i.e. the stack? "global for the called function" - there's no such thing. you could say they are "visible/modifiable in the called function", but they are not "global". "global" means there's only one instance of it and you can use it in _any_ function.
"when a tradfn calls another function". i had to make some experiments to refresh my memory - i think it's the other way round: when another function calls a tradfn
yes, the chain refers to the stack. Both the "relative notions" bit and the "global for the called function" may not be strictly correct, they are an attempt to get the reader -- who may have never programmed in their life -- to understand what is going on. And for someone who has never programmed, I think by that point in the book they can better understand what we are talking about by thinking that there's 2 types of variables: the ones defined in the function and that only exist there (the locals), and the others that the function can get to but were defined elsewhere (the "globals")
@rak1507 I think there are two distinct target audiences for APL training materials today: functional array oriented folks like most of the people who inhabit the orchard, and your traditional domain expert who is looking for something to use for modelling. The latter kind of user probably things of his or her variables as some kind of in-memory database, and finds dynamic scope much easier to understand and work with.
On my mission to read Hui's old papers, I found his introduction to APL to highschool kids ... jsoftware.com/papers/APL_exercises -- judging by that, I've just about reached Roger's idea of an adequate highschool student. I managed the whole Rank section :)
@MortenKromberg but, but.. even experienced apl-ers struggle to understand how dynamic scoping works; and tradfns punish the user disproportionately for forgetting to declare a local
@rak1507 I'd argue that it's easier to believe you understand it. So in that sense dyanmic scoping is quite dangerous, because you never know when it'll bite you in the rear.
@ngn The fact that people forget to localise things doesn't mean that they don't understand it. Clearly, dynamic scope gives you more power to get yourself into an awful mess if you are not disciplined. Lexical scope requires you to plan things ahead of time, which is better in the long term, but also therefore more work in a simple system. And more complex, IMHO.
@MortenKromberg I think it's more work going 'oh I'll just store that in a variable' and then realising that variable name was used 4 functions ago and suddenly your entire system is ruined
Lexical scope is what anyone who's progammed in another language expects. But I guess that's the point @MortenKromberg is making -- those aren't the traditional APLers. I even find Python's half-assed 'functional' scope annoying.
It is hard to for me to explain, or even be confident about given that I have used Dynamic scope for decades. But somehow I feel more able to reason about code in isolation with Dynamic scope. I don't need to read any other code to understand what THIS function does. I know exactly how it will interact with the rest of the environment. Of course, without knowing how other parts of the code use the same semi-global data I cannot know how the whole system works, and I know that I should use such data with great care, but the model still feels simpler. Anyway, I don't expect folks in this roo…
@xpqz i made one important mistake though.. a←1 ⋄ {a←2}0 ⋄ a was 2, i.e. variables belong to the outermost scope in which they are mentioned. it should have been the innermost for plain ← assignment, and the next outer for modified +← assignment.
@MortenKromberg It seems strange that you're saying dynamic scope makes things easier to reason about in isolation when it is completely impossible to reason about anything that makes external function calls as there is zero way of knowing whether or not they modify the current functions scope
The only way to have any sort of idea of what a function is doing is to know exactly what every function it calls is doing
Unless you are completely reliant on none of them changing your scope (like with sensible scoping rules), in which case dynamic scope has no impact on how easy it is to reason about
{a←⍵ ⋄ _←bar ⋄ a} please tell me what this dfn returns :)
@MortenKromberg if you insert your dynamic-scoped functions inside the function from where they are called, you get lexical scope behavior. (or the other way around, extracting functions from callsites goes from lexical to dynamic). That's pretty much the whole difference between lexical and dynamic scope (ignoring when a function is called from multiple places, but oh god do i hope that your scope mutating functions are called from only one function). All dynamic scope does is lose information.
@EliasMårtenson tradfns in pretty much all use dynamic. dfns usually are lexical (though GNU probably does dynamic because dfns are syntax sugar for tradfns or something)
mine used a "cactus stack" - every env (i.e. stack frame) has a pointer to its parent env. a "procedure" is represented as a pair of lambda (ast, and maybe bytecode) and env. a child procedure can outlast the evaluation of the procedure in which it was created, so the "stack" is actually a tree, if that makes any sense.
@user41805 Okay, I have responded to @Adam 's request to address some questions about typed APL, but I'm kind of trying to figure out what the real questions are. I've read through some of the history of the conversation, but I'm still not sure what the salient question about types and APL is?
@ngn What I actually said in my talk on that topic was, "Yes, but stop doing it wrong."
And, in case anyone is curious why the other 1200 lines of my Co-dfns code hasn't received a doctoral thesis on the work yet, it's because the majority of those lines are slated for deletion.
I think @AviFS was wondering about types for purely the expressive joy of the task, but I confess to a bit of confusion in that respect. IME, explicit static typing is always, by definition, a restriction of expressivity, not an addition. I'm curious as to what the definition of expressivity is in this context, and how @AviFS imagines something might be more expressive. ⊃
The best i've seen is in language implementations that do automatic code generation based on types, but I'm not sure that this is something inherent to types or if it is more the result of an implementation leveraging types to generate code, which is, IMO, possibly better understood as an orthogonal component separate from the types themselves.
As I mentioned in my talk, as a type system becomes more powerful, you progressively need to write less and less of the underlying implementation code/language. You write more types, and more of the underlying code is generated for you automatically. A sufficiently expressive type system would be powerful enough for you to no longer need to write any code in the underlying implementation language, at which point, you have a dynamically typed programming language.
@dzaima What confuses me though is what expressive actually means. It's used a lot, but I am not sure that people are very clear and precise on what they mean when they use the word.
