https://xolang.dev/docs/book/Recent content in The Xo book on Xo LanguageHugoen-UShttps://xolang.dev/docs/book/01-effects-and-capabilities/Mon, 01 Jan 0001 00:00:00 +0000https://xolang.dev/docs/book/01-effects-and-capabilities/<p>In most languages any function can open a file, read the clock, or call the network, and you find out by reading its body. In Xo the signature says it. Two ideas work together:</p> <ul> <li>an <strong>effect</strong> is a name in the <code>uses</code> clause (<code>fs.read</code>, <code>clock</code>, <code>stdio</code>);</li> <li>a <strong>capability</strong> is a value (<code>Fs</code>, <code>Clock</code>, <code>Stdio</code>) that grants the permission. <code>main</code> receives them all in <code>os: Os</code>; everything else must be passed one.</li> </ul> <h2 id="pure-and-what-it-costs-to-stop-being-pure">Pure, and what it costs to stop being pure</h2> <p><code>caps-basics/main.xo</code></p>https://xolang.dev/docs/book/02-error-handling/Mon, 01 Jan 0001 00:00:00 +0000https://xolang.dev/docs/book/02-error-handling/<p>Xo has two kinds of failure, and the language keeps them apart:</p> <ul> <li>an <strong>error</strong> is something the caller can reasonably handle (bad input, a missing file). It is a value in the return type after <code>!</code>.</li> <li>a <strong>fault</strong> is a bug (a broken <code>requires</code>, an index out of range). It stops the task, and only an isolation boundary turns it into a value.</li> </ul> <h2 id="layered-errors-with-from">Layered errors with <code>from</code></h2> <p>Each layer has its own error enum. A <code>from</code> variant lets <code>?</code> convert a lower layer&rsquo;s error into the upper one.</p>