Thursday, July 20, 2006

Slipwave Javascript libraries

I came across slipwave today which has a number of interesting Javascript libraries. Of interest to me is js.lang.Recompiler which does a CPS transform of Javascript code, similar it seems to Narrative Javascript. On top of this is built a thread library including thread groups and semaphores. Other libraries include a Javascript interpreter written in Javascript.

Categories:

Wednesday, July 19, 2006

Scala, futures and lazy evaluation

On the Scala wiki there is an implementation of futures, promises and lazy evaluation modelled after the same features in the Alice programming language. Implemented as a library, without changes to the Scala implementation, it seems quite seamless.

After importing the library you can create futures, etc quite easily. The examples below use this definition of the fibonacci function:
object FibTest {
def fib(n: int): int = n match {
case 0 => 0
case 1 => 1
case _ => fib(n-1)+fib(n-2)
}
}

Lazy evaluation is done using the 'lazy' function on the Future object in scalax.futures:
/* Import the future names */
import Future._

/* Lazily compute the 42nd fibonacci number. The computation will
not start running until the value of 'a' is actually requested. */
var a = lazy({ FibTest.fib(42) })

/* This does not attempt to get the value of 'a' so does not start
the computation */
Console.println(a)
=> Lazy(?)

/* This will start the computation, and add 1 to the value. There is
a delay as it computes the 42nd fibonacci number. */
a+1
=> 267914297

/* No delay to compute the following as it has already been calculated */
a+2
=> 267914298

Futures are different in that they immediately start computing the value in a background thread. When the value is retrieved it will block, waiting for the computation to complete, and then return the value, or return it immediately if it is available.
/* Compute the 42nd fibonacci number in a background thread. */
var a = spawn({ FibTest.fib(42) })

/* This will block, waiting for the computation to complete, and add 1 to the value. If it
has already completed there is no delay as it is returned immediately. */
a+1
=> 267914297

The Alice programming language gives an example of an 'enum' function that returns a lazy list of incrementing integers:
fun enum n = lazy n :: enum (n+1)

I translated this to the following Scala code:

/* A LazyList type that has a head and a tail. The tail being a
lazily computed lazy list itself */
case class LazyList[a](head: a,tail: Future[LazyList[a]])

/* Given a number, return a lazy list that where succesive
elements are that number incremented */
def enum(n: int): Future[LazyList[int]] = {
lazy(LazyList(n, enum(n+1)))
}

/* Notice that 'a' is a Lazy value which has not yet been computed */
var a = enum(10)
=> Lazy(?)

/* Computes the lazy value and returns the head */
a.head
=> 10

/* Display 'a' now shows that it has been partially calculated */
a
=> Lazy(LazyList(10,Lazy(?)))

/* Go further down the list... */
a.tail.tail.tail.head
=> 13

/* Again we can see how much has been computed */
a
=> Lazy(LazyList(10,Lazy(LazyList(11,Lazy(LazyList(12,Lazy(LazyList(13,Lazy(?)))))))))

Promises are variables with no initial value. When a thread attempts to retrieve the value they block. Some other thread can set the value of it and the original thread will then resume with that value.
/* Create two promises to hold integer types */
var a = promise[int]
=> Promise(?)

var b = promise[int]
=> Promise(?)

/* A future computation that uses them */
var c = spawn({ Console.println("Result is: " + (a + b)) } )
=> Spawn(?)

/* The future computation completes when 'a' and 'b' get their values */
a.set(1)
b.set(2)

/* Future completes now that it has the values it needs */
Result is: 3
What is nice about the library, and that Scala allows it, is that the future values are be used exactly as if they were normal values. There is no need to call a 'get' or 'compute' to get at the value stored by the future.

A post on the Scala mailing list demonstrates how Cells style computation (automatic updating of variables when others change) can be done with the library.

Categories:

Javascript continuation based webserver

Tony Garnock-Jones has taken the server-side Javascript example I did and built a continuation based web server framework around it. His blog posting demonstrates the Seaside counter example in Javascript.

To test it out, get it from Tony's darcs repository:
darcs get http://www.lshift.net/~tonyg/javascript-server/

Fire up the Rhino interpreter with the jar's in the classpath:
java -classpath jetty.jar:jetty-util.jar:servlet-api-2.5.jar:xbean.jar:js.jar org.mozilla.javascript.tools.shell.Main

Load 'savannahside.js':
js> load("savannahside.js")

You can then test out the following urls:
  • http://localhost:8080/bean
  • http://localhost:8080/count
  • http://localhost:8080/


Categories: ,

Trapexit is back

Trapexit, one of the best Erlang resource websites is back in action. The forum on trapexit mirrors the Erlang mailing list and has a much better search mechanism it's a great resource and I missed it while Trapexit was down. Announcement of Trapexit coming back is here.

Categories:

Tuesday, July 18, 2006

Scala and Actors

The Scala programming language has been getting a bit of attention on Lambda the Ultimate lately. One paper in particular interested me, covering the implementation of a lightweight concurrency model in Scala.

Scala compiles to JVM bytecode (and apparently there is a version that compiles to .NET as well). The paper describes implementing an Erlang style concurrency system within the JVM that doesn't use native threads. This allows large number of 'actors' to exist, communicating with each other. An interesting aspect of what they've done is how they've gone about mapping the actors to native threads so that long blocking operations can get their own thread as well as utilising threads to run some of the lightweight processes.

All of this is implemented as a library rather than extending the Scala language itself.

Categories: ,

Wednesday, July 05, 2006

Python implemented in Common Lisp

CLPython is an implementation of the Python programming language in Common Lisp. From the page:
A large part of the Python language features is implemented by CLPython (basic data types, functions, classes, metaclasses, generators, closures, ...). Many recently introduced features are still missing (e.g. "y = yield x"); the intention is of course to add these features to CLPython.

(Link from Stephan Scholl's weblog).

Categories: ,

Saturday, July 01, 2006

Lightweight Erlang with Package Management

A post on the Erlang mailing points to a lightweight distribution of Erlang with package management facilities to enable installing extra functionality.

The first install is a 1.4MB file which expands to 3MB. This is compares favourably to a full Erlang installation of 35MB (for the windows download).

Functions are included to list, install, remove and upgrade packages.

Categories: