WikiTalk

WikiTalk is the new FlexWiki behavior language. WikiTalk is a simple object-oriented language that advanced users can use to add dynamic behavior to their FlexWiki topics. Additionally, administrators can use WikiTalk to customize the web user-interface for FlexWiki.

A Wiki DSL for FlexWiki (now shared source). What a lovely idea...

But see here for comments from people who are not in love with DSLs as I am...

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Blech

Okay, there are DSLs in the sense of "languages that, thanks to primitives (or default libraries) suited to a particular domain, make programming that domain significantly easier than a GPL", and then there are unholy children of C# and Smalltalk bolted onto what was once a simple markup language. Do the '@'-signs around it make this "domain-specific"? ;)

@@
federation.Namespaces.Collect
{ e |
[
	["!!!", e.Name, Newline].ToOneString,
	"	* Namespace exists? '''", e.Exists, "'''", Newline,
	"	* Title: '''", e.Title, "'''", Newline,
	"	* Description: '''", e.Description, "'''", Newline,
	"	* Image URL: '''", e.ImageURL, "'''", Newline
].ToOneString
}
@@ 

For another interesting, and more mature, entry in the "bolt a general programming language onto a wiki" category, see EmacsWiki, which lets you escape to elisp. Personally, I'm not sold on the value of user-specified dynamic content on a wiki, since although it seems useful, it provides such incredible room for fine-grained misuse and deception.

is there anything in this language specific to wiki needs?

And what are wiki dsl needs?

DSL via OOP

I wrote here in the past about this approach. You provide an object model, and use conventional OOP constructs instead of designing a "real" DSL.

This approach has its advantages, though personally I prefer real language design...

One Microsoft Way

Having done quite a lot of programming using the automation interfaces of various Microsoft products, I'm very familiar with this approach. Everything from Excel to ASP exposes a collection of domain specific objects for the client programmer to "script". There are real language design issues involved, too, as evidenced by the fact that Excel's object model is pretty tolerable to work with while Word's is an unmitigated pain-in-the-behind.

I went through a phase of creating libraries of DSOs and writing a top layer of scripting code in Javascript, using an MS component that allowed you to expose the interfaces of your own COM objects to their JScript engine. This worked pretty well - it was particularly nice to be able to use Javascript's exception-handling constructs instead of VB6's.

It's a good approach if you have basically two "layers": a layer of agents that respond to messages and perform actions, and a scripting layer that contains the basic logic and sequencing of the messages to be sent to the various agents. You get a feel for this immediately in Squeak Smalltalk, for instance. My guess is that it works best for application-sized domains with fairly simple boundaries and fairly straightforward combinations of actions that you're likely to want to perform.

AppleScript, too

Having done quite a lot of programming using the automation interfaces of various Microsoft products, I'm very familiar with this approach. Everything from Excel to ASP exposes a collection of domain specific objects for the client programmer to "script".

That's essentially how Apple's Open Script Architecture works. There are some legitimate complaints about the syntax of AppleScript itself, but the underlying architecture is flexible and powerful.

Several years ago Luke Gorrie

Several years ago Luke Gorrie coded a wiki that could run code users wrote in Scheme, but nobody seemed to notice it at the time. I'd be surprised if WikiTalk is as pleasant as Scheme, though it's bound to have a lot more hooks into the wiki engine. We were using it to make a kind of literate-programming gallery with example programs editable and runnable in place by anyone.

Tidbits

I don't like this idea. Wiki was meant to be quick and simple to write. Coding isn't fast. I have a feeling it will become another XML... :))

(now shared source)

It's under the CPL, and i guess that makes it far more than just "shared source" M$ crap. Although you're required to assign copyright on your contribution back to Microsoft. Well, while the Free Software Foundation does require you to do the same for GPLed software, at least you should rest assured GPLed code will always be open to everyone, while God only knows what Microsoft could do with your contribution...

Luke Gorrie coded a wiki that could run code users wrote in Scheme, but nobody seemed to notice it at the time.

That's really nice! Should feel somewhat as if your could interspect html with Scheme, rather than Javascript... :)

script/scheme

That's not terribly implausible. I added some sugar to javascript by writing a script that used DOM to search for other scripts on a page and then translated them. Javascript is sufficiently powerful that you could probably write either a Scheme interpreter or Scheme-to-Javascript translator (they're pretty similar). You could embed Scheme in your HTML and have pretty much any modern browser run it without requiring a plugin.

javascript scheme interpreter

put
"javascript scheme interpreter" in your search engine
and you'll see that several implementations allready exist