@Adám is it possible to make dyalog show you all the windows you have open when you hover over the icon in the taskbar on windows?

@TomCockram - On Windows 10, it does. That's a Windows function, not an application function.

@TomCockram Yeah, I'm not sure what you mean. It does for me:

Hmmm, for me I have one workspace open with 3 trace windows and when I hover over the dyalog icon I only get the workspace showing. Perhaps I need to look at my windows settings then

@TomCockram Are your trace windows docked, by any chance?

@Adám I have the trace window open on the same monitor as my work space. lemme get a test workspace so I can show you

@Adám I'm on Dyalog 17 rather than 17.1 in case that makes a difference

@TomCockram Works the same for me on 17.0. What are your Options>Configure>Trace/Edit settings?

"Classic Dyalog mode"?

@Adám i.imgur.com/nf966YF.png

@Adám I have classic mode ticked

@Adám it appears to be working now. I unticked and ticked 'Classic dyalog mode' option. Although not sure what that setting actually does

@TomCockram I don't know either, but most people seem to prefer it checked.

@Adám ah I believe it's the 'Allow session above edit & trace windows' that needs to be ticked for it to work.

Which I apparently didn't have ticked

@TomCockram I guess that kind of makes sense.

@TomCockram I also have "Allow floating windows" checked, but you have to uncheck Classic mode to check it, then when set right, you can re-check classic (!).

@Adám agreed

/me spocks at @Adám 's pic. Courier Italic?

Philosophical question: What are the advantages and disadvantages of tacits/trains vs dfns vs tradfns?

hm, about the whole "define your own symbols" thing, maybe it wouldn't be that bad to allow it, as long as trying to define one that already exists gives a clear error (i'd even say as far as ignoring non-special-cased error guards), so there's absolutely no chance of accidentally executing a symbol even if it's defined by the language, calling it a "risky to use" feature and giving no guarantee that using it won't break later, and blaming users for using it after things break.

@dzaima - I don't think I disagree; there are languages where you can override built-ins (and maybe some reserved words), even though it's not recommended, and there are explicit warnings in the documentation about "yeah, you can do it, but it might break later and it's your problem if it does".

Most of them also provide ways to "dig down" and call the built-in version if you need to.

@JeffZeitlin i was more thinking the route of not allowing overriding built-ins at all, though fully embracing that is also an option (but much more likely to break things - idiom recognition, compilation, etc)

@dzaima - Yes and no. With a way to "call around the override" and invoke the original behavior, you end up with a way of extending the behavior of the built-in/standard-lib/etc. procedure/function. PowerShell, for example, allows this, and user functions are encouraged to "look like" standard functions.

With a language like APL, though, there would have to be at least one non-overridable glyph to use as a "signal" to use the original definition.

@JeffZeitlin the problem is that you still could completely override the behavior, making static analysis 100% completely pointless pretty much always (possibly even to the tokenization level?), resulting in a lot of lost performance. I don't think PowerShell was made to be very performant, in which case allowing crazy things is perfectly acceptable

@dzaima - No, PowerShell's point was definitely not performance; it was capability. The way I usually describe it to people is that just like VB begat VBScript, and Java begat JScript, C# begat PowerShell.

That said, however, later versions of PowerShell do have somewhat better performance than the earliest versions.

@JeffZeitlin Nope.

@Adám - Hmmm... Actually, that's not too bad as a font. I still think I like APL385 better, but SAX2 definitely has its points.

@JeffZeitlin If you like APL385, you might like APL386.

@Adám - Grabbed for later comparison.

@JeffZeitlin It is mostly just have more APL symbols and accented Latin characters. However, compare aá.