Monday, October 09, 2006

Three cheers for C syntax

I found this lovely snippet in a C application which shall remain nameless:
void interpreter( void ) { for(;;) (*(prim *)(intptr_t)*(cell *)(intptr_t)(*++lc))(); }

So, which pairs of brackets correspond to casts, grouped expressions, and function invocations? What is the operator precedence between casts, dereferencing, and pre-increment? I really don't know.

Here is the PowerPC disassembly:
0x00002488 :     mflr    r0
0x0000248c : bcl- 20,4*cr7+so,0x2490 interpreter+8
0x00002490 : stmw r30,-8(r1)
0x00002494 : mflr r31
0x00002498 : stw r0,8(r1)
0x0000249c : stwu r1,-80(r1)
0x000024a0 : addis r2,r31,0
0x000024a4 : lwz r30,23748(r2)
0x000024a8 : lwz r2,0(r30)
0x000024ac : addi r2,r2,8
0x000024b0 : stw r2,0(r30)
0x000024b4 : lwz r9,4(r2)
0x000024b8 : lwz r0,4(r9)
0x000024bc : mr r12,r0
0x000024c0 : mtctr r0
0x000024c4 : bctrl
0x000024c8 : b 0x24a8 interpreter+32

Now if I wanted to figure things out, I could spend 5 minutes going through every instruction and keep track of registers with a paper and pen, but at least its possible. Not so with the C code.

Like watching a puss-filled boil explode in slow motion

Reading this (which is only the latest in a long saga of closure debates on Java sites) makes me glad I don't program in Java anymore. I personally think it is too late to add closures to Java, simply because the existing libraries are not designed for it, but the responses posted in discussions such as these are so comical that I want to see closures added just so that these guys get pissed off.

Come on now enterprise monkeys, make up your mind: are closures simply for newbie "script kiddies" who are not man enough to use a 400$ keyboard macro IDE? Or are they so complex that newbies cannot learn them (nevermind the extremely convoluted anon inner class syntax). Or are they easy to learn but simply unsuitable for serious Enterprise(tm) team development?

This is sort of like watching assembly freaks debate if parameters should be passed in registers or on the stack... or if subroutine calls are any good at all. Those of us in the know have moved on long ago.

Enchilada programming language

The Enchilada language now has a home page.

Saturday, October 07, 2006

Swapping two variable values

I thought this was kind of nifty when I first thought of it:
: swap-vars [ [ get ] 2apply ] 2keep [ set ] 2apply ;
For example:
5 "x" set
7 "y" set
"x" "y" swap-vars
"x" get "y" get 2array .
==> { 7 5 }

Completion and right-click popups in the UI

I've been pretty busy with my mathematics research lately as I've managed to prove some pretty nice results. However things have not all been quiet on the Factor front.

Documentation for the below features is forthcoming, but for now the below is as good as it gets. You can press TAB to get a keyboard-navigatable, automatically updating, buzzword compliant completion popup:

If you press Up/Down to select a word followed by Enter, the word name is inserted in the input area. Instead you can right-click on the word to see a menu of other commands.
Now if you press C+e, you get the same popup, but instead it completes loaded source file names; again pressing Enter opens the file in your editor (if you've previously loaded a module such as contrib/jedit or contrib/emacs) and a right-click offers another option, running the file -- note that this works for loaded contrib modules too, not just core library files, and in the future there will be a more extensive integrated module browsing tool than this:

Finally, you can press C+u to get a vocabulary completer, where the default operation is to USE: the vocabulary and from the popup menu you can also browse it or IN: it -- this screenshot shows the popup menu (yes its ugly):

Some of you will remember that the Factor UI used to have popup menus, then they disappeared, then in the recent darcs release I started using the three mouse buttons to invoke different object operations, and now menus are back again. I have a hard time making my mind up on certain issues, but my code does tend to slowly converge on a preferred approach. In either case, I think its better than picking an approach and religiously sticking with it, despite observations that it may be better to do things differently.

Tuesday, October 03, 2006

bigForth

I didn't realise bigForth had a good compiler until I saw this. It does a lot better in this benchmark that gForth did.

Sunday, October 01, 2006

Single stepping

With a stack language, single stepping has a certain intuitive appeal, and there is no ambiguity when it comes to what will happen next. Single stepping through C, on the other hand, is an exercise in frustration. Suppose you have a piece of code like:
foo(bar(),baz())
If I want to step over the calls to bar() and baz(), but step into foo(), it appears that I'm out of luck, at least in gdb. You can set a breakpoint on foo(), or just step into the nested function calls and then step out, but it wastes time and breaks concentration.
I like having a programmer-visible stack. It seems to shorten the 'round trip time' between my brain and the computer.