mirror of
https://github.com/wren-lang/wren.git
synced 2026-01-11 22:28:45 +01:00
270 lines
13 KiB
HTML
270 lines
13 KiB
HTML
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
|
|
<title>Q & A – Wren</title>
|
|
<script type="application/javascript" src="prism.js" data-manual></script>
|
|
<script type="application/javascript" src="codejar.js"></script>
|
|
<script type="application/javascript" src="wren.js"></script>
|
|
<link rel="stylesheet" type="text/css" href="prism.css" />
|
|
<link rel="stylesheet" type="text/css" href="style.css" />
|
|
<link href='//fonts.googleapis.com/css?family=Source+Sans+Pro:400,700,400italic,700italic|Source+Code+Pro:400|Lato:400|Sanchez:400italic,400' rel='stylesheet' type='text/css'>
|
|
<!-- Tell mobile browsers we're optimized for them and they don't need to crop
|
|
the viewport. -->
|
|
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1"/>
|
|
</head>
|
|
<body id="top">
|
|
<header>
|
|
<div class="page">
|
|
<div class="main-column">
|
|
<h1><a href="./">wren</a></h1>
|
|
<h2>a classy little scripting language</h2>
|
|
</div>
|
|
</div>
|
|
</header>
|
|
<div class="page">
|
|
<nav class="big">
|
|
<a href="./"><img src="./wren.svg" class="logo"></a>
|
|
<ul>
|
|
<li><a href="getting-started.html">Getting Started</a></li>
|
|
<li><a href="contributing.html">Contributing</a></li>
|
|
<li><a href="blog">Blog</a></li>
|
|
<li><a href="try">Try it!</a></li>
|
|
</ul>
|
|
<section>
|
|
<h2>guides</h2>
|
|
<ul>
|
|
<li><a href="syntax.html">Syntax</a></li>
|
|
<li><a href="values.html">Values</a></li>
|
|
<li><a href="lists.html">Lists</a></li>
|
|
<li><a href="maps.html">Maps</a></li>
|
|
<li><a href="method-calls.html">Method Calls</a></li>
|
|
<li><a href="control-flow.html">Control Flow</a></li>
|
|
<li><a href="variables.html">Variables</a></li>
|
|
<li><a href="classes.html">Classes</a></li>
|
|
<li><a href="functions.html">Functions</a></li>
|
|
<li><a href="concurrency.html">Concurrency</a></li>
|
|
<li><a href="error-handling.html">Error Handling</a></li>
|
|
<li><a href="modularity.html">Modularity</a></li>
|
|
</ul>
|
|
</section>
|
|
<section>
|
|
<h2>API docs</h2>
|
|
<ul>
|
|
<li><a href="modules">Modules</a></li>
|
|
</ul>
|
|
</section>
|
|
<section>
|
|
<h2>reference</h2>
|
|
<ul>
|
|
<li><a href="cli">Wren CLI</a></li>
|
|
<li><a href="embedding">Embedding</a></li>
|
|
<li><a href="performance.html">Performance</a></li>
|
|
<li><a href="qa.html">Q & A</a></li>
|
|
</ul>
|
|
</section>
|
|
</nav>
|
|
<nav class="small">
|
|
<table>
|
|
<tr>
|
|
<div><a href="getting-started.html">Getting Started</a></div>
|
|
<div><a href="contributing.html">Contributing</a></div>
|
|
<div><a href="blog">Blog</a></div>
|
|
<div><a href="try">Try it!</a></div>
|
|
</tr>
|
|
<tr>
|
|
<td colspan="2"><h2>guides</h2></td>
|
|
<td><h2>reference</h2></td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
<ul>
|
|
<li><a href="syntax.html">Syntax</a></li>
|
|
<li><a href="values.html">Values</a></li>
|
|
<li><a href="lists.html">Lists</a></li>
|
|
<li><a href="maps.html">Maps</a></li>
|
|
<li><a href="method-calls.html">Method Calls</a></li>
|
|
<li><a href="control-flow.html">Control Flow</a></li>
|
|
</ul>
|
|
</td>
|
|
<td>
|
|
<ul>
|
|
<li><a href="variables.html">Variables</a></li>
|
|
<li><a href="classes.html">Classes</a></li>
|
|
<li><a href="functions.html">Functions</a></li>
|
|
<li><a href="concurrency.html">Concurrency</a></li>
|
|
<li><a href="error-handling.html">Error Handling</a></li>
|
|
<li><a href="modularity.html">Modularity</a></li>
|
|
</ul>
|
|
</td>
|
|
<td>
|
|
<ul>
|
|
<li><a href="modules">API/Modules</a></li>
|
|
<li><a href="embedding">Embedding</a></li>
|
|
<li><a href="performance.html">Performance</a></li>
|
|
<li><a href="qa.html">Q & A</a></li>
|
|
</ul>
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
</nav>
|
|
<main>
|
|
<h2>Q & A</h2>
|
|
<h2>Why did you create Wren? <a href="#why-did-you-create-wren" name="why-did-you-create-wren" class="header-anchor">#</a></h2>
|
|
<p>Other creative endeavors aren’t immediately met with existential crises, but
|
|
for some reason programmers don’t seem to like new languages. Here’s the niche
|
|
I’m trying to fill:</p>
|
|
<p>There are a few scripting languages used for embedding in applications. Lua is
|
|
the main one. TCL used to be. There’s also Guile, increasingly JavaScript, and
|
|
some applications embed Python. I’m an ex-game developer, so when I think
|
|
“scripting”, I tend to think “game scripting”.</p>
|
|
<p>Lua is nice: it’s small, simple, and fast. But—and I don’t mean this as a
|
|
criticism—it’s also weird if you’re used to languages like C++ and Java.
|
|
The syntax is different. The semantics, especially the object model are
|
|
unusual. Anyone can get used to 1-based indexing, but things like metatables
|
|
really show that objects were bolted onto Lua after the fact.</p>
|
|
<p>I think there’s room for a language as simple as Lua, but that feels natural to
|
|
someone with an OOP background. Wren is my attempt at that.</p>
|
|
<h2>Why classes? <a href="#why-classes" name="why-classes" class="header-anchor">#</a></h2>
|
|
<p>Thanks to JavaScript’s popularity, lots of people are discovering prototypes
|
|
right now, and the paradigm is experiencing a popularity boom. I think
|
|
prototypes are interesting, but after <a href="http://finch.stuffwithstuff.com/">several years playing with them</a>,
|
|
I concluded (like many people on the original Self project that invented
|
|
prototypes) that classes are more usable.</p>
|
|
<p>Here’s an example of that kind of object-oriented programming in Lua:</p>
|
|
<pre class="snippet">
|
|
-- account.lua
|
|
|
|
Account = {}
|
|
Account.__index = Account
|
|
|
|
function Account.create(balance)
|
|
local acnt = {} -- our new object
|
|
setmetatable(acnt,Account) -- make Account handle lookup
|
|
acnt.balance = balance -- initialize our object
|
|
return acnt
|
|
end
|
|
|
|
function Account:withdraw(amount)
|
|
self.balance = self.balance - amount
|
|
end
|
|
|
|
-- create and use an Account
|
|
account = Account.create(1000)
|
|
account:withdraw(100)
|
|
</pre>
|
|
|
|
<p>Here’s the same example in Wren:</p>
|
|
<pre class="snippet">
|
|
//account.wren
|
|
|
|
class Account {
|
|
construct new(balance) { _balance = balance }
|
|
withdraw(amount) { _balance = _balance - amount }
|
|
}
|
|
|
|
// create and use an Account
|
|
var account = Account.new(1000)
|
|
account.withdraw(100)
|
|
</pre>
|
|
|
|
<p>Classes have a reputation for complexity because most of the widely used
|
|
languages with them are quite complex: C++, Java, C#, Ruby, and Python. I hope
|
|
to show with Wren that it is those languages that are complex, and not classes
|
|
themselves.</p>
|
|
<p>Smalltalk, the language that inspired most of those languages, is famously
|
|
simple. Its syntax <a href="http://www.jarober.com/blog/blogView?showComments=true&title=Readability+is+Key&entry=3506312690">fits on an index card</a>. My aim is to keep Wren that
|
|
minimal while still having the expressive power of <a href="classes.html">classes</a>.</p>
|
|
<h2>Why compile to bytecode? <a href="#why-compile-to-bytecode" name="why-compile-to-bytecode" class="header-anchor">#</a></h2>
|
|
<p>The <a href="performance.html">performance page</a> has more details, but the short answer
|
|
is that bytecode is a nice trade-off between performance and simplicity. Also:</p>
|
|
<ul>
|
|
<li>
|
|
<p>Many devices like iPhones and game consoles don’t allow executing code
|
|
generated at runtime, which rules out just-in-time compilation.</p>
|
|
</li>
|
|
<li>
|
|
<p>I think <a href="concurrency.html">fibers</a> are a really powerful tool, and implementing them is
|
|
straightforward in a bytecode VM that doesn’t use the native stack.</p>
|
|
</li>
|
|
</ul>
|
|
<h2>Why is the VM stack-based instead of register-based? <a href="#why-is-the-vm-stack-based-instead-of-register-based" name="why-is-the-vm-stack-based-instead-of-register-based" class="header-anchor">#</a></h2>
|
|
<p>Bytecode VMs come in two flavors. Stack-based VMs have short (usually one byte)
|
|
instructions whose operands are implicitly understood to be at the top of the
|
|
stack. That means you often have a couple of instructions to push some stuff on
|
|
the stack and then an instruction to do something.</p>
|
|
<p>Register-based VMs have big instructions (usually 32 bits) that contain both an
|
|
opcode and a couple of numbers indicating where in the stack the operands can
|
|
be found. This is cool because it means, that, for example, this Lua statement:</p>
|
|
<pre class="snippet">
|
|
a = b + c
|
|
</pre>
|
|
|
|
<p>Can be a single bytecode instruction. In a stack-based language, it would be
|
|
four—push <code>b</code>, push <code>c</code>, add, store <code>a</code>. (Though note that in both cases
|
|
you’ve got 32 total bits of code.)</p>
|
|
<p>Lua used to be stack-based and switched to register-based and got a speed
|
|
boost. Why not use registers for Wren?</p>
|
|
<p>I’ve implemented a <a href="http://finch.stuffwithstuff.com/">register-based VM
|
|
before</a>. I think it’s a cool model, but I
|
|
don’t think it would bring much benefit for Wren. It’s more effort to compile,
|
|
and I’m trying to keep Wren’s implementation as simple as possible.</p>
|
|
<p>In return for that complexity, you can generate fewer instructions. However, I
|
|
don’t think Wren would be able to take advantage of that. Wren doesn’t
|
|
currently have any dedicated instructions for arithmetic. Operators are just
|
|
regular method calls and can call user-defined procedures.</p>
|
|
<p>The calling convention for methods requires all of their parameters to be at
|
|
the top of the caller’s stack so that they can become bottom of the callee’s
|
|
stack frame window. To call <code>+</code> in Wren, we still have to push the arguments on
|
|
top of the stack. Likewise, the method calling convention places the return
|
|
value where the first argument was, so we’d have to move it back down to the
|
|
destination slot after the call.</p>
|
|
<p>It may be worth having dedicated instructions for arithmetic that special case
|
|
the built-in types before falling back to user-defined operator methods (which
|
|
I assume is what Lua does since they added operator overloading late in the
|
|
language’s development). If that happens, it may be possible to switch to
|
|
register-based.</p>
|
|
<p>But I’m not convinced it would be an actual performance win. A lot of details
|
|
of the language affect whether a register-based VM is better. For example,
|
|
assignments are statements in Lua but expressions in Wren, which would make
|
|
them harder to compile to efficient register-based code.</p>
|
|
<h2>What about your other languages? <a href="#what-about-your-other-languages" name="what-about-your-other-languages" class="header-anchor">#</a></h2>
|
|
<p>This is a strange question if you don’t happen to know <a href="http://journal.stuffwithstuff.com">who I am</a>. In the
|
|
past, I’ve hacked on and blogged about a couple of other hobby languages like
|
|
<a href="http://finch.stuffwithstuff.com/">Finch</a> and <a href="http://magpie-lang.org/">Magpie</a>.</p>
|
|
<p>I started Finch to learn more about implementing an interpreter and also about
|
|
the prototype paradigm. I learned a ton about both. Critically, I learned that
|
|
I really prefer classes over prototypes. I started retrofitting classes into
|
|
Finch but realized it was too big of a change, and thus Wren was born.</p>
|
|
<p>Wren is a replacement for Finch to me. I gave it a new name mainly so that I
|
|
can keep Finch around in case other people want to take it and do something
|
|
with it. I don’t have any intention to work on it anymore.</p>
|
|
<p>Magpie is a trickier one. I really like the ideas behind Magpie. It’s the
|
|
general-purpose language I wish I had much of the time. I love pattern matching
|
|
and multiple dispatch. I like how it integrates the event-based IO of <a href="https://github.com/joyent/libuv">libuv</a>
|
|
with the simplicity of fibers.</p>
|
|
<p>But it’s also a much more challenging project. As a general-purpose language,
|
|
there’s a ton of library work to do before Magpie is useful for anything. It
|
|
has some unresolved GC issues. And I’m frankly not skilled enough right now to
|
|
implement multiple dispatch efficiently.</p>
|
|
<p>Meanwhile, since I started working on Magpie, <a href="http://julialang.org/">Julia</a>
|
|
appeared and <a href="http://opendylan.org/">Dylan</a> <em>re</em>appeared. I created Magpie
|
|
partially to carry the torch of multiple dispatch, but others are starting to
|
|
spread that light now.</p>
|
|
</main>
|
|
</div>
|
|
<footer>
|
|
<div class="page">
|
|
<div class="main-column">
|
|
<p>Wren lives
|
|
<a href="https://github.com/wren-lang/wren">on GitHub</a>
|
|
— Made with ❤ by
|
|
<a href="http://journal.stuffwithstuff.com/">Bob Nystrom</a> and
|
|
<a href="https://github.com/wren-lang/wren/blob/main/AUTHORS">friends</a>.
|
|
</p>
|
|
<div class="main-column">
|
|
</div>
|
|
</footer>
|
|
</body>
|
|
</html>
|