Beruflich Dokumente
Kultur Dokumente
Above all else, though, every decision that goes into Murex is motivated by what I call
the "Five Pillars of Programming", which I'll get to further below. First, let's see the
feature rundown.
Features
Instead of just giving a list of features and letting you work out the implications, I'll first
give a layman's rundown of usefulness. The advantages of polymorphic static typing
with type inference are clear, and type inference keeps code concise. Higher kinds allow
for types to be parameterized by type constructors as well as normal types; higher ranks
allow for all sorts of data abstraction, particularly statically verified region-local effects.
An ML-style module system is still the best-known strategy for achieving modularity (i.e.
abstraction and extension), and I hope to integrate it with Haskell-style ad-hoc
overloading to reduce the syntactic burden. With delimited continuations and winding
protection, we can have all the power of first-class control, but still be able to abstract
and protect resource management. Channel-based concurrency (ala pi-calculus) is
exactly the expressive power of Erlang, but allows for anonymous communication and
makes clear dynamic reconfigurations of processes.
As I am still exploring some of the design space, this list is both incomplete. Since I've
only just started implementation, many of these features don't actually exist yet.
Possible Features
The implications of each directive are usually subtle, but also not meant to be grasped
here. My decisions, as they relate to Murex, will be explained in the definition with
reference to these pillars.
Reliability
Efficiency
Minimize latency.
Maximize throughput.
Minimize resource use (memory, files, sockets).
Concision
Clarity
Rigorous documentation.
Strict coding standards.
Extra-API documentation.
Communication
Implementation Plan
At this point, I have only just begin. There is roughly no implementation whatsoever.
I plan to build Murex roughly according to the stages outlined below. The goal is to
have a working system from the beginning. It's always fun to see a program execute,
especially when it's actually two programs at once.
Stage One
Basic data types (Number, Char, List, IO, finite sums and products)
Interpreter
Parser
Stage Two
Syntactic sugar
Distfixes
Finite sums and products
Stage Three
Multiple files
Basic linker
Scheduled cleanup
Stage Four
Stage Five
Type checking
Reference cells
Stage Six
Module system
Scheduled cleanup
Stage Seven
Macros
Syntax abstraction
Stage Eight
Spawn
Channels
Locking references
Stage Nine
Compiler
REPL
Scheduled cleanup
Further
At this point, I'll have a better understanding of the possible features and may begin
integrating some. The definition should be nearly complete. I'll have a tiny set of
libraries that I will begin to clean and expand on; we'll especially need a good OS
interface. As we gain users, I'll need a package archive. The compiler will need to do
optimizations. We can begin work on foreign function interfaces to C and JavaScript,
among others. Since locking algorithms are not compositional, we'll need software
transactional memory.