aboutsummaryrefslogtreecommitdiff
path: root/docs/commentary/ltr.html
blob: b7c478a8dea85d3438adb3d51596fab7f9f51463 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
<head>
  <link href="../favicon.ico" rel="shortcut icon" type="image/x-icon"/>
  <link href="../style.css" rel="stylesheet"/>
  <title>BQN: Left to right ordering?</title>
</head>
<div class="nav">(<a href="https://github.com/mlochbaum/BQN">github</a>) / <a href="../index.html">BQN</a> / <a href="index.html">commentary</a></div>
<h1 id="left-to-right-ordering"><a class="header" href="#left-to-right-ordering">Left to right ordering?</a></h1>
<p>APL's right-to-left (RtL) evaluation order is something many programmers ask about, and something I've questioned personally as well. In fact the first significant language I designed, called <a href="https://github.com/mlochbaum/ILanguage">I</a>, used a left to right (LtR) ordering for all code. I hope to work with this ordering again in future languages! And changing BQN's compiler to order things differently wouldn't be too large of a task. But that would be a different language. I'd better stick with BQN for a while instead of building up a pile of partial languages.</p>
<p>I'm still of (at least) two minds about a left-to-right APL, in that I'm fairly sure I prefer writing code from left to right but I'm also worried this won't fit in with other aspects of an APL-family language. In BQN I decided that changing the order relative to APL was simply too radical. Why the cowardice? Well, I hope it's better described as pragmatism. BQN is designed to avoid losing the good parts of APL\360, up to my own interpretation of course. For a big change like LtR, I honestly can't say whether it leads to a better language, and in the worst case it could make the entire thing unusable. BQN makes a lot of changes, with a few candidates like this (trying to unify functions and modifiers would be another example). But the risk profile for these big unknowns isn't acceptable: only one has to go wrong to ruin my work, and as more are added this goes from possible to likely. So I stuck with relatively smaller changes I was more confident in.</p>
<p>I've thought about adding some sort of pipe notation (the <code><span class='Value'>$</span></code> character is open) to BQN, but I'm currently against it. It would be complicated and hard to design, and at the end of the day not all that much better than splitting a statement into a sequence of assignments.</p>
<h2 id="considerations"><a class="header" href="#considerations">Considerations</a></h2>
<p>English text is read left to right. This in itself is not decisive in either direction: many contend that the way to read a function is first to read the function, then its argument. Although I usually read the other way, I do find that order to be useful sometimes.</p>
<ul>
<li>Function application is pronounced &quot;f of x&quot;, following the mathematical convention.</li>
<li>Similarly, composition is pronounced &quot;g of f&quot; or &quot;g compose f&quot;. The alternative &quot;f then g&quot;, however, feels more natural to me.</li>
<li>Transformation is nearly always given with the initial state first followed by the final state: &quot;from rags to riches&quot;. Sometimes programmers use this convention as well: &quot;png2jpg&quot;.</li>
</ul>
<p>Although mathematical functions are usually evaluated right-to-left, infix operations such as basic arithmetic are usually left-to-right. Of note is the fact that infinite series which start at zero and proceed upwards must be thought of as being evaluated in the positive direction, which is universally rendered as rightwards in number lines.</p>
<ul>
<li>Function application is written function-first.</li>
<li>Function composition is ordered right-to-left.</li>
<li>Arrows indicating function types and in diagrams are written left-to-right.</li>
</ul>
<p>See page 147 of <a href="http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-169.pdf">this report</a> for an interesting discussion on ordering in mathematics: function notation and diagrams.</p>
<p>As for programming precedent, stack-based languages such as Forth go from left to right. In Java-style object-oriented programming, methods go from left to right. This style of &quot;method chaining&quot; is particularly prevalent in Javascript.</p>
<h2 id="other-attempts"><a class="header" href="#other-attempts">Other attempts</a></h2>
<ul>
<li>There's an <a href="https://aplwiki.com/wiki/Category:Left_to_right">APL Wiki category</a> that gathers some left-to-right languages. <a href="https://github.com/DennisMitchell/jellylanguage">Jelly</a> is likely the most widely used of these, but being a code golfing language it's explicitly designed for brevity first and usability second.</li>
<li><a href="https://github.com/smabie/xs">xs</a> is a concatenative (or stack-based) array language not yet on APL Wiki.</li>
<li>Milan Lajtoš is working on the Fluent language for his &quot;new kind of paper&quot;. It's left-to-right nature is mentioned in <a href="https://mlajtos.mu/posts/new-kind-of-paper-2">this post</a>.</li>
<li>Adám Brudzewsky and others did some investigation into LtR APL specifically in the <a href="https://topanswers.xyz/apl?q=1660">LPA/NQB thread</a>.</li>
</ul>