Okay, I think that I’ve gotten through enough of the backlog and perhaps laid enough groundwork for the idea that’s really been bouncing around in my head. It got derailed about three weeks ago, but in spite that situation’s best (and worst) efforts, I’ve been thinking about a wiki language again.
My inspiration is TWiki. I suppose I really ought to make a survey of the other wikis, but if any others are supporting what the TWiki people call structured wikis, they aren’t calling it by that name. Still, it might be a good exercise for comparing special command syntax.
Anyway, TWiki syntax is a problem. Single variables are fine; %TOPIC%. Simple functions are workable; %INCLUDE{“FetaCheese”}%. But try doing anything nested and you’ll swiftly find yourself in a sea of $percnt and $quot, all of which has be compressed into a single line because of the way the parser works. In short, it stinks. You can smell it five miles off. I’ll spare you the example; this is a family program, we try not to show that kind of thing here.
And of course, like most things of late, the thoughts about how to solve this problem are colored by all my programming language reading. In the words of SCIP, metalinguistic abstraction – making a language perfectly suited to the problem. Or maybe a stack of languages; these ideas are still coalescing, and I may be making some of this up on the fly. In this case, I’ve only had one language in mind so far.
There are of course, all kinds of languages. Being as I’ve thus far not implemented one before, it might be good to start with something that has a very simple core. The obvious choice, at least based on my recent influences, is Lips. This also means it’s doomed to irrelevancy, but this is as much a mental exercise as anything.
The important thing is to choose core concepts relevant to the domain. The domain of interest here is WikiWiki. Plain text blobs with a few extensions, accessible by urls. So now we have our core concepts: text resources, named by urls. Command sequences should operate within these terms as much as possible – text addressed by urls.
The basic operation is textual include. My current syntax thought is that curly braces will form the command sequences; doubled to avoid messing up normal use (i.e., in C code) So {{FetaCheese}} will look find the text of that page include it in place. If the page happens to include more escape sequences, they will be expanded. Nested sequences can use single brackets; {{Crumble?what={FetaCheese} }}
I don’t know to what extent is possible, but my intent is to have as much of the system as possible defined within itself; this may require a cache to be practical. Many pages, especially system operations, will only consist of command sequences; perhaps the documentation of the operation could be exist in some sort of ‘no include’ text. Of course at some point, you have to have primitives. Typically, they will accessed by normal pages, which only include a reference to the primitive – this make is possible to do before, after, and around operations by modifying the text So if Crumble is a primitive, the the wiki page Crumble will normally contain only {{/primitives/Crumble}}, or something to that effect. These ‘same name’ pages should be the only ones to directly reference the primitives namespace.
Choosing urls as a core concept tends towards parameter passing in CGI style; whether this is practical is a matter for further thought. It does have the attractive option of being able to easily define substitutions in the page. Just have the parameters mapped to pseudo pages (probably overwriting system wiki pages – a version of the Lisp dynamic environment (sometimes, ‘funarg’) problem. So:
{{Salad?topping=FetaCheese}}, where Salad contains
A nice salad topped with {{topping}}
One of the issues with cgi style parameters is being restricted by url-encoding. But the ability to type in that same sequence into a browser and get the same result would be pretty nifty.
The ability to pick up url parameters is one thing TWiki did right. They use a function, %URLPARAM{}%, and I might need something comparable. Idea: retrieving url parameters is available as a primitive operation; a standard part of the rendering sequence uses that API to install the URL parameters as ‘local variables’ as it were. If this not desired, the behavior can be changed by editing the appropriate wiki pages that contain the rendering code.
Of course, when core operations are wiki pages, you might need some form of security model. Or sufficiently high-level primitives to be able to restore any damage done.
On a related other thing TWiki did right was fully expose the page save scripts. So you can target your form to /twiki/bin/edit to be able edit a page, say with some URL parameters substituted. But if the operation is completely specified by the html form? /twiki/bin/save/dinner/salad?status=eaten. (Where ‘status’ is a TWiki form field.) Done. Use a html form to set the parameters if you need variable values.
Conceptual schizophrenia?
Lisp is based on list processing. Thus far, what I’ve been calling Wisp (Wiki Lisp) is based on text. Perhaps some sort of auto-parsing text into lists on demand? Of course that’s a type split – you have text and you have lists. (Before long we’ll have a type for cheese, and off down the slippery slope we go.) With automatic type conversion no less, which may be asking for trouble. The other options would be to totally throw out the list processing example and embrace the text paradigm, which would be a pretty major mental exercise.
I’m pretty sure there’s more but I’m starting to feel a bit tired. Hopefully the brain-dump hasn’t been too disconnected to defeat all attempts at comprehension.
