The term mu is a Discordian answer to a yes or no question: meaning it cannot be answered because it depends on incorrect assumptions. So mu is an ironic reply to questions about language such as: what programming language is best? — or perhaps: how should things be named?
Initially most pages discuss a toy programming language named lathe: a lisp dialect plus smalltalk class system, using þ library under the mu-babel license. Links you see in mu menus amount to little more than an outline of material to come. So toy is devoted to tracking changes in all the other pages: check there when you want to see what's new and where you can find more than just a short introductory blurb on a topic.
The name lathe (introduced in Sep2007) comes from joining lambda for Lisp with thorn for the þ C++ runtime library. It's pronounced with a long a and a voiced th, like 'the', the same as an ancient tool used for machining wood and metal by spinning on a spindle's axis while shaving away excess with — in the case of small watchmaker's lathes — a handheld graver.
When a smalltalk style syntax is later essayed, another page describing scythe will be added, but the semantics of scythe will be the same as lathe with another syntax. Support for other syntaxes might be added in whatever order seems most convenient for subsuming libraries written in other languages. (Implementing other languages might be motivated by nothing but library envy or a chance to find new hosts via translation.)
The target audience for toy language lathe is the author, represented by fictional character Wil who strongly resembles the author but is not the author, because second person dialog and narration makes a few things easier to say. For instance, Wil can indulge in theatrical behavior via poetic license when the author is carefully circumspect and retiring in real life. Wil stands for the fellow using BriarPig as a pseudonym, as a handy puppet.
Wil expects it may confuse you that lathe isn't aimed at you or anyone you know, except coincidentally when you happen to share Wil's tastes and motives, which Wil doesn't care about one way or the other. The value of lathe being useful to others is low in Wil's view. A page describing relative weight of pros and cons is offered, primarily to stave off stupid ideas and deeds of importunate meddlers who mistakenly guess their opinions matter. (They do not.)
The value of publication to Wil is several fold: most importantly it documents lathe exists so no one later can claim it is owned by some other party besides Wil. Almost as big: good docs help add constraints in judging what's worth doing because anything too complex to describe likely isn't worth doing, and tools without minimal manuals are a pain. A close third is practical expectation parts will be cherry picked by Wil and third parties for other uses — without transferring ownership to any third party — making it easier for Wil to apply when he likes without being hassled.
A couple final reasons to value publication have an altruistic flavor, but still modulo what's useful to Wil. First, Wil hopes a simple dynamic language might make a worthwhile tool for teaching his sons to program, without pushing them either into deeply complex practical matters, or into easy-but-impractical acadamic fringes too far from value in real life practice; this will force Wil to describe some parts for beginners eventually. Second, Wil hopes other folks learn to see the same things Wil does, if using easy techniques more often makes life better in tech venues Wil frequents.
Parts of lathe will imitate Scheme — either r4rs or r5rs, or both. Other parts will mimic a no-name vanilla Smalltalk without libraries. But unlike many Lisp and Smalltalk systems aiming to self-host and self-implement, early versions of lathe will use C++ widely where it can be, as a library aiming to be the guts of a C++ server that happens to have an embedded language (or two).
mu « Þ, toy, peg, imm, tag, box, symbol, token, number, bigint, class, method, reader, writer, eval, env, vm, gc, world, pcode, compiler, asm, lathe, lisp, smalltalk, design, weight, jar, card, harp, debug, profile
(thorn, todo, names, iovec, assert, log, run, hex, crc, buf, in, out, quote, escape, compare, file, deck, cow, arc, blob, tree, slice, rand, time, stat, heap, node, primes, page, book, pile, stack, atomic, lock, mutex, thread, map, list, iter, ctype)
Some demos are stubs: todo is a demo guide. See toy for mu updates on language pages; names introduces naming schemes.
Iconic images used in the upper right of pages aim to lend a sense of place to pages, so you can see you've returned to a known spot when you come back later. Otherwise pages are so similar in format you might not see change in location clearly, causing confusion. There needn't be any relation between topic of a page and image used, but making interesting choices was a fun game for Wil on the last day of his August vacation in 2008, when he created forty new images and a dozen muddled rejects over the course of ten hours of surfing and editing.
It's possible some images will be too interesting and distract. And others might be hard to parse to the same effect. Just keep this in mind: the images don't matter — it's not important. Some images will be attributed when Wil thinks it's creator wants attribution, or when Wil likes one enough to comment.
The license for lathe's C++ implementation using þ is the same mu-babel license used by þ C++ sources. That page states license terms clearly — they won't be amended anywhere else including here. But a consequence of the license can be summarized here: you can clone the sources and do whatever you like without fee, provided you change names (specifically: avoid a leading lowercase y at start of all global scope symbols) and give attribution (BriarPig was here) and copyright notice (only if you kept parts verbatim, like comments).
Wil wants you to own your own clone of the sources to do as you like, without you or anyone else being able to constrain others with different terms regarding their clones. The prohibition against using the þ namespace (changing or adding symbols using the global y namespace prefix) aims to stop accidental or intentional embrace-and-extend effects polluting the value of þ and lathe by turning interfaces into a standards nightmare game. Wil's version is the standard under the y namespace. If you want to fight about some other standard, go right ahead as long as your namespace is distinct.
Wil wants no standard to interfere with doing whatever he likes in þ and lathe. Value of use by others isn't worth any amount of hassle bought with coordination. One reason Wil doesn't use some other dynamic language is impossibility of having total independent control over runtime to do as he pleases without likely chaotic growth (even if there was time to learn every nuance of some design-by-committee language where no one person knows it all). So lathe aims to be a one-person sized toy language you can tweak as you like.
Unlike demos under thorn (which tend to be written monolithically in their entirety) pages here under mu will likely all grow and accumulate incrementally over time, with no clear end state at which they are 'done' and ready to present. This ought to be unpleasant for readers who visit frequently, so be forewarned. However, the earliest parts added to each page will tend to be highly general comments likely interesting in themselves, at least a little.
In addition to briefly introducing each page, one purpose of the toy index is to log every change to any page in one place. Please consult toy for update news. At least one section of the page will show a reverse chronological list of changes in pages under mu.
Most likely a period of experimentation will be needed for the right grooves to appear in writing styles, pacing, and order.
