Haha I appreciate the sleuthing, and thanks for the links! <3
Some of those might be the bugs I experienced, but then again, some of them claim to be fixed years ago, and I was running a fully up-to-date NixOS unstable (rolling release) system.
Reporting an issue in an OSS project is a great freedom that users have, but it involves so many steps, especially in these complex environments, that it's often not worth the effort. Even if you manage to figure out which component is misbehaving, to search if there's an already open bug report, and take the time to create one if not, there's a chance of running into hostility and WONTFIX responses.
> Impressive list to hit in only 5 minutes!
All it took was logging in, launching Firefox and playing a video. If these issues were so obvious in 5 minutes, I couldn't imagine how many there would be had I used the system for longer. Switching back to Xorg was the quickest fix to my workflow. Besides, I figured that since these issues were so obvious that they were already known. I was just befuddled as to why they remain so prominent given that Wayland is already 15 years old, and there are mainstream distros offering it as an alternative, or switching altogether to it.
I wish any of these projects(obsidian, logseq, Roam) supported WikiWord autolinks alongside [[Mediawiki]] ones. See also: https://apenwarr.ca/log/20100901
I believe GP is referring to government legal action against Parler for "helping" organize lynch mobs. Extralegal retribution from oligopolistic service providers is of course also allowed by law, that just doesn't make it fine.
I've always been curious one decision pervading various APL: what are the relative merits of right to left evaluation order, vs more conventional left-to-right method chains? The core principles are incredibly elegant, but I must admit hitting "expressions are executed right to left, except if you hit a {} lambda, wherein separate statements are ordered left to right, but are themselves expressions going right to left again" is always kind of jarring.
For left-to-right execution, the dissonance between execution and statement separators (including functions and list notation) is very bad as you note.[0] For right-to-left execution, assignment has a similar problem: the name really needs to be on the left to allow easily scanning definitions, but this conflicts with the evaluation order. Particularly statements with multiple assignments in them don't work at all. Right-to-left is usually framed as a more "declarative" or "functional" style (and note that application and composition of mathematical functions follows this order) while left-to-right is considered "imperative".
In my first major language, I,[1] I did change to a left-to-right order. For BQN, which is intended to stick much closer to traditional APL, I didn't want to make such a large break from the methods that have worked in the past. I do think I'll introduce some mechanism like a "pipe" that goes in statement order so that longer chains of functions and operators can be built up without such a discontinuous reading order.
> Parentheses may be used to specify the order, but there's a (usually) better way as well: whitespace! Fewer spaces means the function will be executed earlier.
Oh man, that is a fascinating idea I've played around with some, glad someone's put it more seriously into practice.
Re: assignments, Aaron sure seems to sprinkle them liberally inside lines - though not generally ones referenced in subsequent ones, to be fair. (I suppose another notable attribute of the co-dfns codebase is extensive use of ⊣ as a leftwards statement separator)
Mathematical functions are prefix, which imo is much harder to follow than either infix (OO/APL) or suffix (RPN/Forth), though this may be more of an english-speaking intuition than some manner of universal truth. I do at least observe a trend towards "imperative but functionally pure / side-effect isolated" in recent language design.
Ah, I see ILang deals with the issue by… not having a name binding primitive, making you SKI-calculus your arguments into place. (Compare the piles of roll-swap-dup you get in varless forth dialects, though not as bad due to there being two directions args are passed in from.)
I suspect there is room here for an unprincipled "preceding word/pattern is defined by the following line/s" loose-binding operator, to restore skimability, and a separate inline destructuring let form that cannot leak out of lexical scope. Which I suppose would warrant lambdas - perhaps with ⍺ ⍺⍺ ⍺⍺⍺ to denote enclosing function input, rather than argument/operand/hyperand, though nonconcrete functions would stress the type system as is
It does have : for assignment, although there's no scoping, and you have to assign to symbols that are surrounded in single quotes. You can see some examples at https://github.com/mlochbaum/ILanguage/blob/master/examples/... . They need extra parens, since : is an ordinary function and has the symbol on the left. Your overall point is right; I didn't really try to address any issues with assignment. And of course there are lots of things to try, and I hope some of them make it into some other language I design!
I think it's history: in the 1960's, machines were strongly card (or at least line) oriented, so pure right to left intracard yields a very small "parser" compatible with traditional mathematical notation, and the unavoidable intercard transitions become top to bottom on a teletype.
(FWIW in my array noodling, the equivalent of dfns are given in the haskell style of "expr where defs" instead of the strictly temporal "let defs in expr", which does result in a consistent right to left for those who wish to read bottom-up.)
> there will doubtless need to be some alternative channel for events that need to preventDefault, most notably clicking on links that should route instead, and form submit; I’m not sure how that will work.
Naively I would expect that to be part of the rendered DOM("<a prevent-default='click'>"), or otherwise in a declarative datastructure available to the UI thread. Are there many events that need conditional preventDefault, such that the JS handling code would grow nontrivial?
I thought about it a bit longer after I wrote it and decided that what you need is some sort of pure function that takes the event target DOM element only, and decides whether the default should be prevented. For example, in FastMail we use a function to intercept links that will essentially check whether the href is routable (fiddlier than you might guess, unfortunately) and not target=_blank; that could be reduced to such a pure function, though various routes would now need to be specified in two places. Either that, or just always pipe generated <a href> elements through some function in the worker that annotates them—I like your idea, thanks for the thoughts!
Either way, I can’t think of anything where you need fully conditional preventDefault. Definitely something closer to declarative than imperative is good for these sorts of things.
When writing these examples I use to test in one simple file. Then, for the sake of clarity, I copy and paste pieces of code in the blog post. Some typos come from there.
(these are not necessarily the same issues, but at least similar-sounding ones I found by googling)
• widgets opening in wrong place: https://bugs.kde.org/show_bug.cgi?id=459188
• ignoring icon size configurations: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/i..., closed as wontfix
• on touchscreen menus open wherever you left the cursor: https://bugs.kde.org/show_bug.cgi?id=406025, more info in https://github.com/PeterCxy/evdev-right-click-emulation/issu...
• cursor framerate issues: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1827 maybe, it's in the gnome issue tracker but described as wayland-specific, so might also be happening on KDE
• firefox using wrong screen's DPI: https://bugzilla.mozilla.org/show_bug.cgi?id=1632829, resolved by original reporter but last comment is a repro from someone else. also reported in https://github.com/flatpak/flatpak/issues/5300 but closed as "wrong bug tracker"
• fullscreening a video rotates it from portrait to landscape: https://bugzilla.mozilla.org/show_bug.cgi?id=1600962 possibly, https://bugs.launchpad.net/ubuntu/+source/mutter/+bug/190522... possibly
In general wayland seems too buggy for major software like firefox to use it by default, per https://askubuntu.com/questions/1409389/why-doesnt-firefox-r...
Impressive list to hit in only 5 minutes!