« first day (1439 days earlier)      last day (1205 days later) » 
00:00 - 17:0017:00 - 00:00

12:23 AM
The 0+/ thing is a little more obvious if you start by looking at the subvectors directly (not reductions on them). I discussed the BQN version some in this section.
 
 
2 hours later…
1:58 AM
Is there a rank equivalent to M[I;]?
 
Is I a scalar?
 
In this case, yes. And M is a matrix.
 
I⌷M
 
Aha! Thanks @Adám, that gives me a decent starting point. I'm working on converting some of these examples from 1970 to the current hot newness
 
OK, in general, for replacing bracket indexing, there are a few options. To select major cells (e.g. rows of a matrix) Ym[Iv;] you can do (⊂I)⌷Ym or I⍤0 99⊢Ym
If instead you want to select a single column: Is⌷⍤1⊢Ym
 
2:07 AM
@Adám is this ⎕IO dependent?
 
Yes.
For ⎕IO-independence, go with ⊣⌿Is⊖Ym which is like ⎕IO←0 even when ⎕IO←1.
Iv⊣⌿⍤⊖⍤0 99⊢Y for multiple
Oh, right in all of the above Ym should be Y as it can be of any rank.
 
Thanks! :D
 
No problem. Btw, expect performance to suffer with the ⎕IO-agnostic code.
 
2:22 AM
would it still suffer if you used ⎕IO in the expression?
 
No, that'd be fine. But you really should set a local ⎕IO instead, unless you're doing something unusual.
 
Makes sense
 
 
5 hours later…
7:10 AM
Most of the APL docs I read use the term 'defined functions' (or operators) to refer to what we used to call 'user-defined ..'. Does anyone know why that change in terminology was made? Surely any usable function is defined?
 
7:21 AM
<moon-child> @RomillyCocking perhaps builtins are considred axiomatic
 
except they aren't, since they may even be secretly implemented in APL :)
More seriously, which term should I use when writing about APL: 'defined' or 'user-defined'. I'd prefer the latter as to me it's unambiguous.
 
 
1 hour later…
8:45 AM
@RomillyCocking Function style names are a very annoying part of APL. APL Wiki believes "defined function" is a tradfn. (soo we have "defined" for tradfns, and "direct"/"dynamic" for dfns? ಠ_ಠ)
 
@dzaima I'm glad it's not just me that finds this less than perfect.
It does seem that 'user-defined', while not universally used, does make it quite clear what we're talking about. I'll stick with that for now.
 
"A dfn is an alternative way to define a function" :|…
(and then the "Defined function" article uses "user-defined function" for itself which is just stupid)
@dzaima so that's the "a dfn is not really defined" talked about in this talk page. yaaay
 
9:05 AM
Was there ever a successor to the original ISO/ANSII APL standard? I know one was mooted, though by then I'd left the standards committee.
 
@RomillyCocking there is a something-extended-APL standard or something
 
@dzaima I found the answer on the APL wiki
 
:)
 
I like the technical terminology: 'something-extended-APL standard or something'
:)
 
:D
I intentionally wrote "something-extended-APL standard" but the added "or something" was just an instinctive must-add before posting a message about something I don't have 100% certainty about
 
9:13 AM
The new (year 2000) 'standard' apparently covers APL2, but not Dyalog APL :(

That is bad from several points of view, not least because it presumably says nothing about direct definition. (I can't be sure, because It costs 196 CFH, which I am not willing to pay)
@dzaima I respect your anonymity, but I can't help thinking that we have met IRL.
(or elsewhere on-line)
 
<moon-child> @RomillyCocking there is the ‘dyalog apl language reference guide’, which is effectively a reference. (Relevant here is a portion of it that says ‘function may refer to a primitve function, a system function, a defined (canonical, dfn, or assigned) function, or a derived (from an operator) function’)
 
@RomillyCocking I highly doubt both of those (given different country, plus code golf & this being pretty much the only place online where i talk)
@RomillyCocking it definitely doesn't
 
@dzaima Well, I'm glad I met you here :)
@DyalogAPL I guess I'll go with that definition, then, though I would feel much happier if 'defined' has the prefix 'user-'. The OED says that defined means 'having a definite outline or specification; precisely marked or stated', and it seems to me that that applies to all functions and operators in APL.
 
<moon-child> @RomillyCocking well, crucially that definition excludes derived functions. ({+/⍵}) is defined per that definition, but (+/) is not. Even though the latter was still defined by the user
 
+/ kind of doesn't feel very user-defined-ly. trains though - that's a better question, and doesn't seem to be included in any of the reference options
 
9:29 AM
@DyalogAPL IMO it does not exclude that, We must be using words in different ways, and I doubt it's worth more time exploring that. I will go against my preferences and accept 'authority of position' :)
 
<moon-child> @dzaima I think a train can be considered derived (though the dyalog spec does say 'derived (from an operator)')
 
@dzaima Yup. I haven't used trains in the MENACE book but I have been wondering about the issue that you raise.
 
moon-child: right, that was what I was also thinking
either way, given that some Dyalog reference uses "defined function" for both tradfns and dfns makes it sound like there's actual reason to not call tradfns "defined functions"
also @Marshall/@Adám there 3/7 references are for non-existent (at least in 18.0 docs) pages
 
There are *loads* of issues with the current Dyalog docs which I am trying to catologue. Should I make my list a public project on GitHub so that others can add to them?

The biggest problem IMO is that many Google searches lead to *very* out-of-date help, which will at best confuse and at worst put off newcomers.
 
@RomillyCocking i'm kind of surprised google searches even work, so ¯\_(ツ)_/¯
my random search for "dyalog apl natural logarithm" gives a first result to a page with the title "Natural Logarithm - Dyalog APL 18.0 Help" while it links to 12.1 docs. So I see what you mean..
 
9:45 AM
There's also a deeper issue, in that there seems to be a gap between the things that attract potential new users (Code Golf, the Competition etc.) and the things they need to get started. TryAPL is a great step forward but beyond that many will flounder.
@dzaima There are dozens of searches like that.
 
@dzaima at least the APL wiki page is the 2nd result (and first in ddg)
 
I'm currently working on a doc for Morten Kromberg which will highlight these issues and propose some remedies.
@dzaima I hadn't thought of looking at DDG's results. Thanks.
 
@dzaima (and ddg doesn't give any help.dyalog.com links (to specifically) in the first page)
@dzaima (where does google even pull the "18.0" out of‽)
(if it isn't clear, I have long given up using generic search engines for anything APL related)
 
@dzaima You may have but many newcomers will still use them.
 
yeah, true
 
10:54 AM
ty
 
@RomillyCocking I'm 100% with you that the current situation is a mess, and I privately disagree with Dyalog's "official" terminology.
 
@Adám what is the Dyalog official terminology?
 
@Adám Morten is as keen as I am to sort out the mess. I will do all I can to help.
 
@dzaima "Defined functions and operators" only include "tradfns/tradops" and "dfns/dops" while e.g. trains and operator-derived functions/operators are called "derived functions/operators". "Tacit" isn't in the vocabulary at all.
I believe some of the terminology stems from a semi-artificial distinction based on a technical difference that is irrelevant to the normal user.
 
@Adám so the APL wiki terminology conflicts Dyalog's by calling tradfns defined functions?
 
11:01 AM
@dzaima Yes, Marshall decided to do that. I disagree with him, though.
 
(personally I wouldn't want to call derived fns/trains as "defined functions". I'm okay with the only connection between trains and dfns being that they're both "functions")
 
I think his argument includes that all the dialects that don't have any other forms of user-written functions, call their user-written functions "defined functions".
I say: Of course they do, but not to exclude dfns or other types, as those are not in mind at all.
 
@Adám Agreed.
 
unfortunately noone uses "del-functions", otherwise I'd easily go with that
 
@dzaima No. I'll explain.
 
11:04 AM
@Adám that isn't a part of the function definition but a marker of entering a different writing mode?
 
Technically speaking, the interpreter switches from "desktop calculator mode" to "function definition mode when you enter ∇ header, and the reverse on the next (outside any brackets/strings/comments). Meanwhile, the internal (names used in the C code) representation for primitives/operator-bound stuff/trains is called "derv".
So Dyalog ends up calling anything you can define using the "function definition mode" a "defined function", and everything else a "derv", expanded to "derived function".
Now you just have to be aware of something you can do, but practically nobody ever does:
∇foo←{⍵ ⍵}
∇
 
@dzaima Spot on. The ∇ was there to allow users entering, editing and defining functions in APL\360 and APL\1130 to use golfball terminals to edit code as well as submit expressions for immediate execution.
∇ is 1) a 'change mode' signal to the editor and
 
@Adám wat
 
@dzaima Exactly. And hence the messed up terminology.
 
2) a 'change mode' signal to anyone reading a printed session transcript.
 
11:09 AM
y
 
@Glitteringriver Hi there. Interested in APL?
@RomillyCocking Imo, using the same symbol to switch in the other direction was a huge mistake.
 
@Adám I had never thought about that. You're right.
 
If had been used to close definition, then we could have had nested tradfns.
Heck, even inline tradfns.
Anonymous functions would have been an obvious extension.
And then lexical scope would have followed naturally.
 
@Adám like, is that a special-case in ? or is there some convoluted reason that "obviously" has to work?
 
@dzaima No, all does did is throw what you type at ⎕FX which handles dfns just fine.
Now the distinction is becoming more blurred with the multi-line input where pretty much anything goes.
And yes, you guessed it, multi-line input is simply a beefed up editor mode in disguise.
 
11:17 AM
@Adám ah, so the progression is traditional tradfns → ⎕FX giving access to creating tradfns → adding dfns to ⎕FX
 
@dzaima Something like that. I'm not sure what was added first, the ability of ⎕FX to handle dfns or the ability for normal execution to handle dfn assignment, though.
@Deveter Hi. Interested in APL?
 
@Adám I would assume they would be added at the same time (there's no other way to execute dfns, right?)
 
@dzaima I don't understand. What does execution have to do with this?
 
@Adám execute as in ⍎'{…}', not {…} argument
 
@RomillyCocking As I'm sure you know, we do have our own issue tracker which isn't publicly viewable, but if you prefer a public list, that's fine too. Fyi, we've already decided what to do about the links to old versions, and also how to avoid broken links in the future. As always, we're stretched thin on every front at Dyalog. The documentation team person currently has 535 open issues…
@dzaima I still don't see how that's relevant for how functions are defined, but hey: ⋄ (⍎'{⍵ ⍵}')42
 
11:25 AM
@Adám
┌→────┐
│42 42│
└~────┘
 
@Adám Thanks. I can remove the links issue from my note to Morten. He said he'd pass the document on but maybe I should just copy you in when it's ready.
 
@Adám ah, the emphasis in "normal execution to handle dfn assignment" is "assignment", not execution of things like {1+⍵}5 in general?
 
@dzaima Correct.
 
@Adám so that clears the confusion. (and imo it's kind of stupid that it was even possible to add {1+⍵}5 while f←{1+⍵} ⋄ f 5 wouldn't work)
 
I have great respect for the documentation team; I had no idea that it was still a team of 1.
 
11:30 AM
@RomillyCocking I think that gap is very real. The reason is that currently, there is no way forward from "APL as a cool toy" to "let me build an application with APL" while adhering to modern practices. It is very sad indeed, and I'd love to do something about it, but two restrictions make this a rather difficult task: backwards compatibility for existing APL code and maintaining single code base for our APL interpreter.
@dzaima Isn't it kind of stupid that ⊂⍣3⍳4 works and P←⍣ ⋄ ⊂ P 3⍳4 doesn't?
 
@Adám I've complained about that before
@dzaima (and, of course, it works just fine in dzaima/APL)
 
@dzaima That's what happens when design give way to bandages and duct-tape. My colleagues where rather surprised when I presented this:
 
I can't see a *perfect* solution, but I think there are workable ones, and I think my basic assumptions may be different from yours. Or maybe it's just a question of priorities.

In particular, I think one could get to a point where there were enough people with real money to spend (whihc is what Dyalog needs IMO)by introducing APL to people who are trying to build *internal* applications to explore new algorithms rather than build finished apps that are ready for a mass market.
Cases in point: Computer Vision, Neural Networks, doing hard stuff with Big Data.
I have a couple more mini books in the pipeline that address ANNs (not using backprop, which was a terrible mistake) and Big Data.
 
@Adám I somewhat knew about -(∘)÷4 being an error, but ⍎'¨' vs ⍎'∘' is just absurd
 
@RomillyCocking Let's meet and discuss this, but I do have to run right now.
 
11:40 AM
The big data eg uses inverted files to enable me to make better use of Semantic Scholar's open corpus of 189 M records of research papaers.
@Adám Yes please!
 
11:53 AM
@dzaima I also didn't realize f←¨ was allowed. ¯\_(ツ)_/¯
 
12:13 PM
@Dogbert Hello. Looking into APL?
@dzaima You are lucky, not having customers that (ab)use to stop execution!
 
@Adám in assignment‽
 
@dzaima No, but that's the same thing. It would have to be "a value" to be assignable, and then it is also returnable, and then it is a valid statement in a function.
(Although why is O←{⍵⍵} allowed but none of {⍵⍵} or O←∘ are…‽)
 
@Adám ah, as in ∇f \n ∘ \n ∇
 
Yes, exactly.
 
@Adám so that's another row in your class table?
 
12:23 PM
@dzaima That's "dyadic dops" (fourth) vs "other dyadic ops" (fifth).
 
what is this?
 
@dzaima A messy implementation. I think I've seen this before.
 
Hello folks. I'm trying to learn about how/whether does Jarvis parallelize / multithreads. In the source I see calls to the & spawn primitive. That's only "green threads", right? "Threads" page in Dyalog help says that if one thread is running, other are paused. So, I'm inferring that only 1 core is used at any point. Am I reading into it correctly so far?
 
@MartinJaniczek yep
 
@MartinJaniczek ^ however, I do think there's a way to make it use multiple OS threads to handle incoming requests. That's what old TryAPL used to do, and it was based on an old version of MiServer, which was a precursor to JSONServer (the precursor to Jarvis).
 
12:36 PM
@Adám Was that patching the server source, or just some configuration field?
 
@MartinJaniczek It was using a vanilla server. Let me have a look at the configs…
@MartinJaniczek Ah, I see, the TryAPL code was setting that up as part of its constructor for the server instance. Still you or I can ask Brian if it wouldn't be a good option to handle callbacks in separate threads. I can see many good uses for this.
 
@Adám Thanks for checking. I haven't done any benchmarking yet but I suppose it would be handy to be able to use all the machine resources to improve throughput, latency etc. of the server.
 
@dzaima FYI the page name "Defined function" doesn't specify APL Wiki terminology. It's fine to use the name "tradfn" if it makes sense in context (e.g. not on the "APL.SV" page, since dialect pages use that dialect's terminology).
 
@MartinJaniczek This whole question is spawned from one of my colleagues finally getting home from holidays and looking at my prototype and asking questions :)
 
@MartinJaniczek That's a good thing! Do you want to contact brian@ or shall I?
 
12:49 PM
I can. Is the @ - @dyalog.com ?
 
It is. In principle, he can be pinged here, but I doubt he's constantly logged into SE.
 
@Marshall The page name should reflect the most prevalent use, and in my research I found that Dyalog resources are basically the only place you'd find the word "tradfn". Every other language where the creator uses that term (such as ngn/apl) doesn't actually have them.
 
@Adám Alright. I'll write him an e-mail. Thanks!
 
@Marshall I don't mind avoiding the term "tradfn" so much. My problem is that "defined function" is misleading.
fwiw, GNU APL uses "defined functions" as a term covering both "lambdas" (similar to dfns) and "normal user defined functions".
 
@Adám It's better to have a misleading term that people are familiar with that one that will be totally unknown to a lot of readers (the point of the page title is as a navigational aid, while the text actually explains what's going on). In the first case, readers get annoyed at the ambiguity. In the second case, they think they're on the wrong page and start hunting around for the one they really meant.
 
12:57 PM
Maybe something like "Defined function (traditional)" would be better. They sure are the traditional way to define functions.
 
@Adám I'd be okay with that.
 
Question for people with more real-life APL programming experience than me: How often do you declare a custom operator which can take either a function or a value as argument?
 
@EliasMårtenson Very rarely. Also: "operand"
 
Since the roles of functions vs. values are locked down at parse-time in Kap, I would like to have different syntax for each of these cases. However, if both is needed, then the functions needs to be passed as lambda expressions instead.
 
Such a restriction would make it impossible to write covers for things like @ and and
I certainly get the value of static parseability, but much prefer BQN's way to achieving that.
 
ngn
1:18 PM
@Marshall more likely in the second case: the user takes the term at face value, keeps doing user things, builds wrong mental models, and learns about the trap later
 
@ngn That should be corrected by the page text, not the title. But who learns APL directly from the wiki?
 
@Marshall With the state of available documentation, I wouldn't be surprised.
 
@Marshall the wiki is like the only dialect-agnostic APL information source. I assume most would assume the title of the page is the preferred name for a thing.
 
@dzaima It is, which is distinct from it being a bad name.
I added a header to point out that some dialects consider dfns to be defined functions (we'd need this even if the page was called Tradfn, since "defined function" would still redirected there).
 
ngn
if language changes the way you think, shouldn't we hold our jargon to the same standards as our programming languages?
 
1:31 PM
@ngn The purpose of an encyclopedic wiki is to describe existing usage, not specify it.
 
ngn
@Marshall are you talking about wikipedia or the apl wiki?
 
@ngn Both (see edit).
 
ngn
@Marshall it's hard to separate the two - describing vs prescribing. new aplers will read what's described and start using the term as if it's prescribed.
 
@Marshall NARS2000 calls tradfns "user-defined" but never uses the phrase "defined function" as a term.
 
@Adám I think "defined function" was always short for "user-defined function", so NARS2000 just chooses not to abbreviate. The abbreviation's more common historically though.
 
1:39 PM
Also of note is that both NARS2000 and GNU APL seem to not consider the braces as part of the definition, but rather only as a syntax to delimit the definition from surrounding code, and only at definition time. If you edit a dfn in NARS2000 or GNU APL, the braces are gone.
 
ngn
and dfns are not user-defined?
 
and trains are not user-defined?
@ngn That's why I really dislike the term. It is so misleading.
 
everything's user-defined \o/
 
Not primitives.
 
@Adám How does BQN achieve it?
 
1:40 PM
@EliasMårtenson you do 𝕗 to get a value form of the left operand, and 𝔽 to get a function form
 
@EliasMårtenson It allows changing syntactic role of anything simply by changing the capitalisation of the first letter and/or adding/removing leading (and optionally trailing) underscores.
 
@ngn user-defined is an even worse term for just tradfns. if that was the title of the wiki page, I would really protest.
@Adám where do you draw the boundary? + isn't "user-defined". +/ isn't really either. Is +∘÷/? +∘÷/⍤(⍴∘1)?
 
@Adám Thanks. That gives me something to think about.
 
ngn
@dzaima tradfns should be backronymed as tragically defiled functions
4
 
@dzaima I'd claim +/ is user-defined. It isn't inherently in the language (never mind optimisations), and only exists because the user put together two arbitrary atomic building blocks to define something new.
 
1:51 PM
@Adám +/ being "user-defined" is misleading at best. (and such a distinction between built-in and user-defined is extremely pointless anyways)
 
ngn
@Adám what about f←+ ⋄ g←/ and somewhere else: f g ? is it the user or the program putting the train together?
train derv
 
@ngn I'd personally say that f is a user-defined function, in that f was meaningless until the user defined it. I'm not sure if it is useful to distinguish between named and anonymous functions, but it could be done.
 
@Adám so.. everything is user-defined \o/
 
Yes, except raw unnamed primitives. Doesn't that make sense?
 
@Adám i mean, userDefined ← ~builtinToken is a rather pointless definition to have
 
2:00 PM
I never claimed the definition or distinction was useful.
afaict, the only time one should need to care about this distinction is when teaching or discussing how a user can build/define/use/change things they put together themselves.
 
@Adám I would say that it's still very much pointless even then (even misleading as the distinction implies there's a difference, which there is not)
 
In a tutorial, I'd have "How to define your own functions" and not care about what such functions are called (if anything).
 
@Adám I definitely wouldn't describe +/ as "my own function"
 
Why not?
 
@Adám it's just a reduction (n-adic, if you will) variant of +. Literally 0 of anything I put into making it.
 
2:11 PM
So you'd distinguish between Sum←+/ and Sum←{+/⍵}? The latter being a user-defined function, and the former not?
@dzaima How about Sum←+/⍤⊢?
 
@Adám derivations just don't fit under user-defined.
 
And trains? (Mind you that they can defined using compositional operators!)
 
@Adám I'd still not call trains user-defined functions, they're a tree of 1-3 grouped functions. somewhat like a subset of statements in a function isn't a user-defined function
is 1+1+1+1+⊢ 4 user-defined functions?
@Adám That's asking a different question - those are statements (or variables), instead of functions. Taking +/ vs {+/⍵} alone, I would distinguish them.
 
@dzaima So I can conceivably build an entire functioning application, having defined numerous functions, but never having created any "user-defined functions"‽ How is that useful terminology?
 
@Adám this is a question about a subset of non-explicit expressions. Once you start assigning & calling stuff, there are different considerations at hand.
(and i'm fairly certain you can make some full applications with no derivations/trains too)
 
2:25 PM
@dzaima No derivations/trains and no dfns/tradfns‽ I doubt that.
 
@Adám what derivations would you need? Pre-nested APLs went on quite well with /⌿\⍀ and ∘. being like the only operators
 
@dzaima Uh, how do you use those operators without creating derivations?
 
@Adám simple: you don't
i guess without tradfns & dfns the only control flow you have is gotos, but with trains you're also stuck with just
 
@dzaima You don't have gotos outside tradfns.
 
@dzaima you'd be handicapping yourself much more than trains-only, but that's to be expected
@Adám i mean i guess (though i will again blame dyalog not having a proper scripting evaluation mode)
 
2:32 PM
I don't see any reason why f←+/ shouldn't be considered a user-defined function. But that said, I don't think that is a useful category anyway. User-named function would make more sense. +/ isn't user-named by itself, of course. f←+ is user-named, and so is f←{⍵}, but + and {⍵} are not.
 
@Adám again, the question is about +/ alone. The resulting f after f←+/ is a user-defined function, but so would f←+ be
 
Then we agree!
 
@dzaima (if it wasn't clear, i didn't finish reading the message when i replied)
 
2:59 PM
@Marshall I can confirm that this text from 1970 that I'm working through uses 'defined functions'.
 
@ab5tract What does it call {braced ⋄ functions}, direct:condition:definition and thingsLikeThis←+/ (rhetorical question)
 
My point was only that there is historical precedence for shortening 'user-defined' to 'defined'.
 
That doesn't really excuse the practice, as "defined" has a very different feel to it than "user-defined".
"Surely + is a defined function, otherwise I wouldn't be able to use it"
"On the other hand, % isn't a defined function in any APL I know of".
Imo, any source that only recognises a single functional form that one can associate with a name is inherently disqualified from influencing what that form should be called in a world where multiple forms exist.
 
@Adám I didn't intend to offer it as a justification, I was supporting the point that "user-defined" was at one time shortened to "defined" in texts covering APL
I think tradfns, dfns, and trains are all useful names to distinguish between their various constraints and capabilities. I agree that "user defined" is a decent overall heading to cover them. I don't see using that broad of a categorization to be very helpful in most cases, as they have too much to distinguish themselves from each other to be usefully grouped together all that often.
 
Agreed.
 
3:29 PM
@Adám I think this principle privileges Dyalog's worldview more than you realize. If GNU APL decided to add a new kind of control structure written with ;, and for disambiguation called the : kind "tradcntrl" and the ; kind "newcntrl", we'd be pretty justified in keeping "Control structure" as a page title. I don't see any relevant differences between that and the current situation.
"Control structure" even has a similar ambiguity, in that is also a structure you can use for program control, but the name doesn't apply.
So you can argue this case, but I don't think you can claim in general that the language with the most specific terminology wins.
It would be very different if even one other language used "tradfn" in public documents as this would imply some level of community uptake.
 
@Marshall in that case, the page could be about both : and ; (which I wouldn't mind for the dfn/tradfn case)
 
@Marshall I'm not saying that "tradfn" is a good term, but I'm protesting against using a misleading term, when several implementations sport alternative functional forms.
 
@Adám I'm just arguing against "Imo, any source that only recognises a single functional form that one can associate with a name is inherently disqualified from influencing what that form should be called in a world where multiple forms exist." now.
 
@Marshall I don't understand your argument, then.
 
@dzaima That would be Function styles, but del-functions and dfns are clearly distinct, and both significant enough to have their own pages. We definitely shouldn't change the page divisions to get cleaner titles.
@Adám Well, the analogous form would be "Imo, any source that only recognises a single control form that one can associate with a name is inherently disqualified from influencing what that form should be called in a world where multiple forms exist." I don't think that argument would apply in the hypothetical GNU case, so I don't think the same kind of argument should apply to Dyalog either.
 
3:39 PM
I think it should apply there too.
APL2 only recognises a single way for a user to create their own function. This method, which APL2 shares with most historic implementations, and many current ones, needs a name so we can speak about it. The fact that implementations that only have that form call it "defined function" is irrelevant to our needs, as their terminology never was intended to distinguish.
 
@Marshall The current situation would be like there being a page for "control structure" which is about Dyalog's : and GNUs : and explicitly not GNUs ;, which would have a separate page. That feels very wrong, as both : and ; are control structures.
 
You can't keep calling DC "electricity" once "AC" is widely implemented, even if all historic sources called DC "electricity".
 
@dzaima (of course, there's also the fact that some sources (i have no clue which) do use "defined function" only for del-functions (heh, if we add dzaima/APLs : and :←, we get a similar situation :p))
 
@Adám No, I think you can keep using "electricity" and "AC". More importantly, you can't make the switch to "DC" until you expect your readers to have heard of the term.
 
@Marshall I disagree. In that case the wiki should have three pages: AC, DC, and Electricity. The latter should give an overview, but begin with a note saying "For the traditional… see [[DC]]".
 
3:46 PM
I think your viewpoint tends towards the idea that tradfn and dfn are two platonic things that must exist. That's a Dyalog-centric view. dfns are invented; APL never needed to add them (and many other kinds of definition can and have been invented). That doesn't fit with AC and DC, which are the only reasonable ways to transmit energy through electric currents in wires.
 
@Adám something doesn't add up there for me - is "electricity" like a disambiguation page?
 
@dzaima No, an overview page like Function styles.
 
@Adám it makes no sense for that page to start with "For the traditional ∇-functions, see [[tradfns]]". It should describe both with no preference
 
I don't think one dialect should be able to force other APLers to change the way they refer to a concept just to disambiguate from another concept they didn't even want.
 
@dzaima No, it'd be a page called "User-defined functions" or some such.
@Marshall Obviously neither tradfns nor dfns had to exist (evidenced by some APLs having neither), but the current state of the universe is that most APLs have one or the other or both. We need to be able to unambiguously speak about them.
 
3:50 PM
Just done a quick performance spike.
     ⎕io ← 0
      bools ← ?1024 1024⍴2
      cmpx '^⌿bools' '^/bools' '+⌿bools' '+/bools' '⍉bools'
  ^⌿bools → 4.0E¯7 |      0%
  ^/bools → 4.9E¯6 |  +1138% ⎕⎕
* +⌿bools → 4.8E¯5 | +12053% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
* +/bools → 1.2E¯5 |  +2976% ⎕⎕⎕⎕
* ⍉bools  → 1.2E¯4 | +30246% ⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕⎕
Ranking as expected, relative speeds surprised me.
 
@Marshall Neither do I. But Dyalog+ngn+dzaima+GNU+NARS2000 can.
 
@Adám You can use tradfn to speak about them if there's ambiguity; the page title doesn't influence that. The "Defined function" page uses tradfn all over the place!
 
Now, should these things be called "tradfns", that I don't know, but surely we can't go on calling them "defined function" when that'd just wildly misleading the innocent reader.
 
@Adám As I said, if any of ngn, dzaima/APL, GNU, or NARS2000 used "tradfn" in published materials, it would be a very different case.
 
@Marshall I never argued for the term "tradfn". I don't like that term. Come up with something better!
But not "defined function". "Tradfn" is easy to learn. Once you hear that it means that traditional form, you won't forget. But "defined function" or "user-defined function" keeps being confusing, as every time you see it, you have to guess if the author means it as a technical term (=tradfn) or just any function the user has defined in general.
 
3:56 PM
is there any actual APL with both dfns and tradfns that uses "Defined functions" only for tradfns?
 
@dzaima ^ this 100%
> Defined functions and operators (including lambdas) accept an axis argument.
 
@Adám Well, if you want to popularize a name, I like "del-function". But it has to be taken up by the APL community before it goes on the wiki.
 
I've begun learning apl (today ;D) and coded this program: f←{×/⍵~0}
Multiply all non-zero elements in an array
Can it be reduced?
Thanks! ;)
 
@VictorVosMottor as in, golfed?
 
3:58 PM
yeah
 
@VictorVosMottor ×/~∘0
 
@Marshall No, that's a terrible name, since the dels are not part of the syntax, and not necessary to define such functions in any implementation used today, not to mention that dels can be used when defining dfns!
 
@dzaima whooops, how it works?
 
@VictorVosMottor Welcome to the club.
 
@Adám Thanks ;)
 
3:59 PM
@VictorVosMottor See here.
 
thx
I'll check it out
 
I'm beginning to wish I had never asked about terminology. I feel a bit like Dr Frankestein as the monster he created starts to walk towards him.

Since I only use primitive, system and d functions and operators in the MENACE code, I will stick with dfns and dops.
 
@VictorVosMottor for starters, you often need to wrap tacit code in parentheses for it to be callable (exception being in assignment). (~∘0) is currying the right argument of ~, and (f g) (f being ×/ and g being ~∘0) for any arbitrary 2 functions is equivalent to {f g ⍵} when called monadically
 
Sounds tricky lol ;D
 
@dzaima cause the page is explicitly only about tradfns, while, apparently, noone actually uses it as such. It really should just be a disambiguation for dfns and [insert any non-ambiguous name for tradfns]
 
4:02 PM
Just to be clear, currying is something you do to functions, not food :)
I prefer the POP-2 term 'partial application'
 
@RomillyCocking I guess that's more understandable. i was mostly betting on it being heard before
 
Yup, 'currying' is widely used, but partial application needs no prior exposure to the idea. Also POP-2 deserves te be remembered - it's a wonderful language.
 
@dzaima I'm with you. If I understand @Marshall correctly, he's arguing that "defined function" is widely used to mean "only tradfn" ― by those that recognise no other form.
 
@dzaima If you really need an unambiguous title, I think Adam's "Defined function (traditional)" is the only reasonable option I've seen so far.
 
@Marshall yeah, that's acceptable
 
4:07 PM
@Marshall +1
 
I think all can agree that that is in fact APL's traditional form of defined function.
 
I'm moving it then.
 
yay
 
yay
 
4:09 PM
:D
 
@Marshall I'd replace the intro note with a single reference: For other types of defined functions, see [[Function styles]].
 
@Adám the first sentence should be kept though at least
 
Also, with this updated title, the explanatory for "traditional function" becomes unnecessary, and things seem much more consistent.
@dzaima Yeah, sorry, I meant the pointer part.
> with J and K rejecting function definition
 
@Adám The text has to have a full description even without the title.
 
… I think that's taking the term "defined function" a bit far.
You can't do symbolic manipulation on the term.
teapot ≠ pot of tea
 
4:17 PM
@Adám Given that "Defined function" redirects to this page (it's the most common meaning of the term), I think the point about dfns is still needed. I've streamlined it a bit, but I'm done editing for now, so go ahead and make other changes you think are needed.
 
@Marshall Looks good. Thank you.
 
As far as I'm concerned only the page title itself is contentious. Be bold when editing the contents!
 
00:00 - 17:0017:00 - 00:00

« first day (1439 days earlier)      last day (1205 days later) »