« first day (1704 days earlier)      last day (1170 days later) » 

09:10
@Adám Is there something wrong with the file on github? What does é and ó do?
This can't be right: ø←{á}(áá þ óó)ó ⍝ cover for ⍣ (allows interruption)
it is
yeah, it abuses the fact that Dyalog allows some extra chars as identifiers to squeeze in the custom overrides that won't clash with user-defined things
09:34
Dyalog needs namespaces then :-)
It should be possible to create a custom namespace and assign other things to the local versions of the standard symbols.
Dyalog doesn't allow assigning to symbols
I guess this creates difficulties to idiom recognition for optimizing
and just optimizing in general
@LdBeth I'd be surprised if idioms are recognised based on string matching. You'd parse first, and then identify patterns, just like any compiler.
@EliasMårtenson they are
09:41
Dyalog can't parse.
@rak1507 Really?
idioms are literally search and replace
it's not string matching, but token matching though
ah
but yeah, same thing pretty much
how else is dyalog gonna handle {1 (⍎(?2)⊃'+4') 3}¨⍳100
09:46
@dzaima Handling of ⍎ could very well be handled just like how Lisp does it. Evaluate in a different environment.
Sure, that means that code in ⍎ can't access lexically scoped variables, but Dyalog doesn't have those anyway.
but the result having an unknown type bleeds into the current environment either way
and eval is just the simple example. The worse one is {1 ⍵.field 2} - ⍵.field could be a function, thus dyadically called, or an array, thus making a 3-item strand
and the even worse one is {1 variable 2} where the surrounding code could be constantly switching variable between function/array/operator
and fwiw, namespace.⍳ can be used to execute (or any other builtin) with the ⎕IO/⎕ML/etc of a specific namespace, not the surrounding one, so there's already a sort of meaning for builtins in a namespace
and the way that syntax works is that namespace.(expression) is literally the expression evaluated within the scope of the namespace, so you can't really even define as a key anyways
10:17
@dzaima It seems to me all of these issues comes down to the fact that symbols could be dynamically changed from functions to variables in the middle of the execution of a function. How common is it really that this is needed?
relardless of how needed it is, you still have to at least handle the namespace field reading varying types, otherwise you have a very weird language where the first execution of a function defines what it does or something
and also /⍺⍺/⍵⍵ being arrays/functions
@dzaima I mean, I see two approaches: One is to have a strict separation of what is a function vs variable. BQN does this with casing. Another is to have a way to declare what a certain symbol is. This second approach would work well in APL I think. Simply say that foo is a function, and then it'll be parsed as such. Trying to assign a value to foo would result in an error.
My guess is that very little existing APL code would break with such a restriction.
well, unless your namespaces are statically typed, namespace.foo can't be assigned a type even
@EliasMårtenson most APL implementations (and J) just read in the code as tokens and interpret them, one way would be make a proper compiler.
@dzaima That depends on what you mean by static.
10:22
and there's tons of code relying on ⍺←{⍵ ⋄ ⍺⍺}
and could fallback to interpreter mode if cannot be compiled.
@dzaima that just sets ⍺ to ⍺⍺ doesn't it?
@EliasMårtenson actually, you need everything to be statically typed. otherwise {1 (⍺⊃⍵).field 2} has zero place to store type info
> you have a very weird language where the first execution of a function defines what it does or something < like FORTH
@EliasMårtenson it sets it to a monadic operator if it doesn't exist. (also ⍺←⊢ is the more common thing)
10:26
@dzaima Ah right. But in that case, the {...} would be typed as function. If you have a←functionOrValue, what sensible thing could you ever do with a?
well just restrict the a to be immutable
@EliasMårtenson use it as a left argument that isn't when there isn't one, e.g. {⍺←⊢ ⋄ ⍺-⍵} for a reimplementation of dyadic -
The point I'm trying to make is that there is very little sensible code where you have some expression x y z where the code would do the right thing regardless of whether y is a function or a value (other than some ticks that are more clever than they should be)
@EliasMårtenson yeah, that's not wrong, but there's also very little sensible code where you're indexing out-of-bounds, but some people still decide to not make that break the whole language
a clever enough compiler can produce if ⍺ is bound do so else ... for {⍺←⊢ ⋄ ⍺-⍵}, but the problem is compilers are not yet so good at guessing it
10:30
right, you can duplicate the body for that. Doesn't work for {⍵.a ⍵.b ⍵.c ⍵.d ⍵.e ⍵.f ⍵.g ⍵.h ⍵.i ⍵.j}, which has up to 1024 variations of what it could mean
there's just not really anything a language can do with a "this is mostly the case"
My concerns all stem from the fact that because of these issues, Dyalog is ridiculously slow when executing dfns.
@EliasMårtenson yeah, that's unfortunate, but there's not much Dyalog can do about it
So you have to spend a lot of time trying to work around such issues by ysing things like trains instead of just using dfns.
a new APL, sure, but not an existing impl
@dzaima it is possible to defer the compilation until the dfns is actually executed, and depends on the type information available at runtime
10:35
@dzaima Well, there is extended. So they could extend it even further by imposing limitations on reassignment of functions to values. If so, they can pre-parse a dfn instead of reparsing every invocation.
I like a lot of things about Dyalog, and I'm impressed by the performance in many cases. It's just that when I use dfns (especially in conjunction with ¨) performance just drops like a rock.
it would be rurally for the recursion to be polymorphic
@LdBeth you still end up having to have fallback handling & type checking everywhere
(and Dyalog does have a compiler to bytecode, which just doesn't run if any of the bad discussed things exist in your code)
@EliasMårtenson by that you mean this thing which is actually literally just find&replace?
@dzaima Just give me a way to tell Dyalog that no, I will not redefine anything. Just reuse the bytecode on every invocation.
@dzaima It is? I've never actually used it. I thought it was a variant.
@EliasMårtenson that's still only about variables, and doesn't do anything about a←⎕ns⍬⋄a.f←1 ⋄ b←⎕ns⍬⋄b.f←+ ⋄ {1 ⍵.f 4}¨ a b
@dzaima Give me a way to statically declare those too :-)
10:40
type systems for APL :)
@dzaima A very mild type system, like Common Lisp if you like, that has a DECLARE form that allows you to provide extra information that the compiler may or may not choose to take advantage of.
So I could tell the Dyalog compiler that anything in the following file will always be evaluated with ⎕IO←0
well if you provide wrong information CL code can segfault or what ever
And things like that.
@LdBeth Indeed. Well, in practice, modern compilers will only crash if SAFETY is 0.
huh, CBQNs vm for a random test is only 6x faster than Dyalog's
What does cmpx do?
10:45
execute expressions and do benchmarks
time an expression; 1 cmpx returns seconds of average runtime
So it just calls f 5 1 million times?
Similar to ({f 5}⍣10000000) 0
it calls it until it's ran for a couple seconds or something
So 114 ns for BQN suggests that 1 million iterations would take 114 seconds?
I.e. execution time of my ⍣ version.
1 billion iterations would take 114s. 1 million would take 114ms/0.114s
10:50
Ah of course. That makes a lot more sense.
 
4 hours later…
14:31
@dzaima I just tried my ⍣ version in Dyalog, and it takes rougly 2 seconds to complete 1 million iterations.
Were you measuring something else?
@EliasMårtenson that message has 10M not 1M
I still get around that same time though
870ms vs 2s isn't too far off
14:46
@dzaima Yeah, I changed it to 1 million.
 
5 hours later…
20:15
@hyper-neutrino Can you give chat.stackexchange.com/users/379439/user107162 access?
21:07
@Adám done
Thanks!
@user107162 Welcome to the APL Orchard. Since you're new to Stack Exchange's chat, I highly recommend reading through apl.wiki/APL_Orchard#Features
21:29
@Adám Thanks, I'll do that now.
21:43
@user107162 So, how much experience do you have with APL?
Leo
Leo
I've learned the first few pages of the book mastering dyalog, but I find it difficult learning by myself.
Hi, welcome
Leo
Leo
Hi.
@user107162 I see. Maybe have a look at our list of learning resources to see if there is something else that fits you? Otherwise, people here will surely be happy to help.
xpqz also had a nice tutorial, didn’t they? Perhaps you might find that helpful, lemme find the link
Leo
Leo
21:51
@Adám I'll have a look at that, thanks.

« first day (1704 days earlier)      last day (1170 days later) »