All Queen fans are adviced to check out the new Queen Search Engine and Site Directory. Or at least try to remember the url: www.queenfind.com.

Dave Winer is acting out the thanksgiving ritual. Thanksgiving is generally not celebrated here in the Netherlands. But I like the idea, because people quickly forget the positive things and only remember the negative things. (which results in Murphy's law btw.) It's not in my nature to spontaneously thank people, so I thought it would be a good idea to practice here on my weblog. The first 10 minutes I couldn't think of anything for which I had a real heartfelt need to say thank you. Then I realized something:

I want to thank my colleagues, friends and family for being such nice people to be around with (and to instant message with). I'm thoroughly enjoying every day of my life because of that. Thank you! I specifically want to thank my mother, because she asked for it, literally :)

Today I remembered a type checking idea I had a while ago, which is perfect for Loell. It is dynamic type checking based on prototyping. There's no need to store type information anywhere. When setting a property, o.p=v the simple rules are:

• If o.proto.p is undefined, all values are allowed.
• If v isA o.proto.p.proto, the set is allowed.
• Else throw a type error

It's rather basic type checking, but it fits the small core (currently 150 lines of javascript) of the language. It's hard to be sure if this checking is helpful, or just a pain. I'll just have to actually program something with it, but for that I first need to build proper access to the browser DOM.

I've updated Loell to better support functional programming. In Javascript you can do functional programming, but you cannot do it in an object oriented way. You can hardly ever use a method, because for this to have a value, the method has to be a property of an object. In Loell, a method call looks like this:

expr method expr

The value of the left-hand expression is assigned to this and the value of the right-hand expression is assigned to that. So 1 {this+that} 2 evaluates to 3. On the Loell page I've added an example that implements lists and adds foldr and foldl, in a proper object oriented way (I think).

Hixie is showing how browsers handle tag soup. The way IE does it, is a serious problem for Xopus. Xopus allows pasting of HTML. Unfortunately tools like Outlook paste HTML like this:

<P>text<FONT COLOR=#0000FF><P>text<P>text</FONT>

Xopus then walks the DOM tree. The parent element has 3 <P> elements. The first <P> element has 2 childnodes, a textnode and a <FONT> element. But then when you ask IE's DOM the childnodes of the <FONT> element, it gives the last 2 <P> elements, again. Xopus can validate this, to get proper XHTML, but rule no.1 of the validation routine is to never throw away content. The result: pasting from Outlook sometimes gives you part of the text twice. Those are the bugs you just don't want to fix...

Robert O'Callahan brought this good news to the contentEditable bug page. A colleague at Q42 did some testing. It's not true contentEditable yet, you can only make an IFrame editable (the designMode feature from IE). But execCommand and related functions from IE seem to work. So I think the wysiwyg editor from Radio can be made to work in Mozilla 1.3a without much change.

I worked some more on Loell today. It looks like this is going to give me a lot of fun to work on for a long while.

• The default behavior for closure evaluation is now to use static scoping. (syntax: #closure)
• Closures now have syntax for the argument (like Ruby): { |arg| ... }. I'm not going to enable multiple arguments. If you want that you can pass an object. (point moveTo <.x=1;.y=2>)
• Added the Boolean type.

Because Loell is so centered around scope handling, I needed to think about what the scope is actually for. This is what I came up with:

• Temporary storage. In OO languages there's plenty of opportunity to store data, but storing data in the scope can be good for several reasons: 1. You simply don't need the data anymore at the end of the method. 2. You don't know where the data has to be put, f.e. the return value of a method. 3. You might not have the rights to put data anywhere else.
• Shortcuts. The code to lookup data could be cumbersome or slow. Then it's easier, faster and more readable to put a pointer to that data in a variable.
• Labeling. The code becomes more readable if you put data in a variable that has the proper name for how this data is used in the current context.

When Dan Shappir and I were working on Beyond JS we agreed that Javascript is a powerful language. But we couldn't do all the tricks we wanted to do. One problem is the lack of control over the scope. And to keep the story short, I have created a language that gives full controle over scope: Loell.

Traditional languages either have static or dynamic scoping. With Loell you can have both. When a closure is created, the scope it is created in is stored in the scope property of the closure. When you use that scope when evaluating the closure (closure.scope#closure) you have static scoping. But when you use the current scope ($#closure) you get dynamic scoping. But you can use any object as scope.

It turns out that this is powerful enough to implement if, while the language has no actual branching built in. Even while is implementable which I had never anticipated.

I've got the parser running for just 3 days now, so Loell is nowhere near finished. There's no precedence and it's slow, but if you are interested in programming languages I hope you'll like to experiment with Loell already. If you know other languages that have special scope control, or research in scope control, I'd like to hear from you.