Þ   briarpig  » λσπ

lisp

     The name of this page, λσπ, very nearly spells out Lisp in greek letters, but this is just coincidence (unless my subconscious is even busier than usual) since that's merely the order in which I intend to write implementations of Lisp, Smalltalk, and Python using þ as a common runtime. It's true lisp might be more pervasive than others in some layers — as data — when intermediate code as lists is quite convenient. I expect the virtual machine's assembler to be lisp. But any of the languages would handle lists equally well.

thorns

     I never released my old efforts because they had warts, and I didn't think they were good enough. While this is true (from a perspective of many more years coding experience), I should not have been that particular when no one else seems to be. Today I'd call the warts thorns, but since I sleep in a bed of thorns I no longer mind. You're getting thorns in whatever I publish, no doubt about it.

warnings

     Instead of removing all the thorns — especially those you really don't want to step on — I'll label many of them with warning signs. They'll often be things I'd fix if I was being paid for a result closer to perfection. But then you're not paying me, are you? It's possible you'll find my description of the thorns educational. It might not occur to you a problem was possible, especially if I remove it first.

scaling

     When given a choice of alternatives near one another in cost, I'll choose technique favoring better scaling in servers using as much memory as you would normally try to get in a high end Linux box, because that's where I work for a living. I'm unwilling to make code complex, but I'm happy to waste a bit of space in the small in order to get better results in the large. I'm not aiming for tiny platforms. I certainly won't take complexity to save space in small apps. Don't assume I care about embedded apps.

less

     The first versions of everything might use gross simplifications to get done faster, as long as they don't cripple scaling scenarios. I don't really care exactly how efficient the first virtual machine is, as long as the time and space complexity of þ parts scale to using all available memory. New VMs and better compilers seldom pose a problem. I'm sure I'll focus more on profiling and debugging tools before clever code optimizations. Ability to check whether a system acts as expected always trumps doing unknown things very fast.

value

     The value in this plan comes from my enjoyment of these languages, and from the prospect of using them for paid work in the future. Nowhere in this description is there an opportunity to substitute alternatives to optimize some other payoff. (I decide what's fun to me; no one else does.) A general part of my plan is generating code in any syntax I need (say Javascript) from any starting syntax.

     Choose one of these demos for sample code and related docs, developed together to motivate þ C++ code for this purpose.

     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, meter, list, iter, ctype

     The new mu menu links future toy language pages. Many demos are stubs; see todo for a thorn demo guide, or toy for mu updates. Also see names for an overview of naming schemes.

more

     After that, it seems unlikely it would be hard to do more languages on top of þ, but I don't think I'll have time myself, except for languages used where I work — so that spending time that way actually shortens some critical path. I hope to spend fun coding time instead on server oriented IDEs for creating web sites integrated with other less well defined services. (I've no reason to exclude any given protocol. If you think this means I want more of the pie, you're right.)

codenames

     The official names of λþ, σþ, and πþ for Scheme, Smalltalk, and Python on top of þ will likely have some codename synonyms. I wish they could all be pronounced and be clever at the same time. Only pith for πþ fits the bill, however. I'd always meant to use gab for σþ because it's actually a near synonym for smalltalk which is itself a small word. (Update: 24sep07 lathe changes names.) The cute name gab has been changed to scythe.

     Until just now I thought λþ would be the difficult one. But after looking up the definition of lathe, I see it comes from Old English (how convenient) laþe: a spinning tool that shapes material.

frugality

In the early 90's I wrote software that had at most a couple megabytes of space for a budget, in which I had to scale what I did carefully with pseudo virtual memory. It still serves me today when I do paging systems. I try to make a large amount of memory go as far as I can without special effort. I might aim to use a lot of memory, but I don't plan to waste any.

roadmap

Try to think of this plan as a roadmap, and not a promise or a schedule. I'm like a guy on a motorcycle planning a cross country trip. I might change my itinerary, or stay somewhere longer than I planned; this would throw off arrangements and cost me something, but I could. However, I'm not ditching the bike, so I always need a place to go. (Unlike Briar Pig, who is staying safely in that briar patch.)

steering

The main purpose of this page (and of wyv or gui) is to explain the pattern behind my movements, since you can see where I plan to steer — so you can see my plan is not your plan. It's not to get you excited so you give me something for nothing before I produce. My exit strategy will always be to stop and enjoy whatever I have so far, whenever I want. When I don't go where you would, it's not a mistake on my part; don't try to grab the wheel.

sml

I have a funny feeling I might get sucked into SML though, since it looks even easier than Python. And it would be useful to support SML if the Javascript community does more with SML in reference implementations.