Here follows a simple example on how to achieve it:

class DynamicConsole : TextWriter
{
  readonly TextWriter orig;
  readonly TextWriter output;

  public DynamicConsole(string filename)
  {
     orig = Console.Out;
    output = File.AppendText(filename);
    Console.SetOut(output);
  }

  public override System.Text.Encoding Encoding
  {
    get { return output.Encoding; }
  }

  public override void Write(char value)
  {
    output.Write(value);
  }

  protected override void Dispose(bool disposing)
  {
    Console.SetOut(orig);
    output.Dispose();
  }
}

Usage:

Console.WriteLine("Real 1");

using (new DynamicConsole("Foo.txt"))
{
  Console.WriteLine("Moo");

  using (new DynamicConsole("Bar.txt"))
  {
    Console.WriteLine("Ork");
  }

  Console.WriteLine("Bar");
}

Console.WriteLine("Real 2");

When running you get the following:

This will print to the Console:

Real 1
Real 2

It will append to Foo.txt:

Moo
Bar

It will append to Bar.txt:

Ork

I will update the code later to make it generic, so any property, method or field can be used for the dynamic binding. Stay tuned!

Update:

Posted an article on CodeProject last Friday. This is a generic implementation: Dynamic binding in C#

See http://forum.unity3d.com/threads/76266-Facilities-for-script-languages-Scheme-in-particular for details. You can also view the initial discussion @ http://ironscheme.codeplex.com/Thread/View.aspx?ThreadId=243958.

Thanks a lot!

Also, the IronScheme source code is now under a BSD license. The DLR goodies stays on MSPL however, as moving it to the new Apache license DLR would be too much effort. Now for the rest of the post.

So the general feeling is that most ‘dynamic’ languages are pretty poor with number crunching. This is true, as code is mostly generic and have no static typing. The same goes for IronScheme, but you can make code (read hotspots) behave much better with only a little extra effort.

Let’s take the naive Fibonacci algorithm to use for this example.

(define (fib n)
  (if (< n 2)
      n
      (+ (fib (- n 2)) (fib (- n 1)))))

The main problem here is the usage of generic math operators. They are generally slow, as they cover the entire number hierarchy of Scheme. This can be improved by using the fixnum specific procedures.

(define fibf (lambda (n)
  (if (fx<? n 2)
      n
      (fx+ (fibf (fx- n 1)) (fibf (fx- n 2))))))

While the above run significantly faster (about 5 times faster), there is still quite a bit of overhead due to boxing of value types, and overflow checks. This can now be improved by using a statically typed variant of lambda called typed-lambda, and by using some ‘unsafe’ operators provided by IronScheme.

(define fibt (typed-lambda (n) ((Int32) Int32)
  (if ($fx<? n 2)
      n
      ($fx+ (fibt ($fx- n 1)) (fibt ($fx- n 2))))))

The above only requires minor changes again, that could be easily made transparent with a macro or 2. The result is a very fast procedure that runs optimally on .NET (when compared to the same code generated by the C# compiler). My tests show it running almost 13 times faster than the fixnum version and subsequently around 60 times faster than the original generic approach.

Here are timings for all of the above:

isc fibs.sps
Statistics for '(fib 35)':
  Real Time:  8357ms
  CPU Time:   8344ms
  User Time:  8344ms
  GC's:       0
Statistics for '(fibf 35)':
  Real Time:  1826ms
  CPU Time:   1828ms
  User Time:  1828ms
  GC's:       0
Statistics for '(fibt 35)':
  Real Time:  147ms
  CPU Time:   141ms
  User Time:  141ms
  GC's:       0 

Update:

On the same PC, IronPython 2.6 takes 3150ms for a naive fib.

A common request is to have some form of compiled libraries to run a Scheme program, and not relying on source files for the program to run.

This is already provided in IronScheme via precompiled/serialized libraries, but still results in a ‘binary’ format for every library file, which in turn can end up being quite a few with a fixed directory structure.

So yesterday I worked around a serialization bug that hindered my progress on improving this.

I have added the following:
1. Created a container package to shove all precompiled libraries in.
2. Added the ability to use ILMerge to merge all the assemblies into 1 executable.
3. And for bonus points, I added the ability to include the container package into such a merged executable, resulting in 1 fat executable with all the libraries included.

For now, you can go to this IronScheme page and download the result of step 3. A 21MB executable with everything to run IronScheme, including all IronScheme and SRFI and miscellaneous libraries.

Of course your own program may not need all the libraries, so you could chose to only merge the ‘base’ 2.1mb executable with say 1mb of libraries.

I will add some documentation later to explain how to craft these.

Cheers

leppie

I present using IronScheme in C# 4:

class Program
{
  static dynamic Scheme = new SchemeEnvironment();

  static void Main(string[] args)
  {
    var list = Scheme.list;
    var map = Scheme.map;
    var reverse = Scheme.reverse;

    Func<int, int> f = x => x * x;

    var r = map(f, reverse(map(f, list(1, 2, 3))));

    Console.WriteLine(r.car); // prints 81
  }
}

The implementation is straight forward, and can be viewed here. I just involves a simple Linq expression.

Cheers

leppie

After just over 1 year in beta phase, IronScheme has moved into release candidate phase.

Download and release notes for IronScheme 1.0 RC 1.

Cheers

leppie

I have recently checked in code that completely removes the usage (and in fact removes it from existence) of the DLR’s BigInteger implementation and replaces it with the IntX big number implementation.

The new code provides much better performance in terms of multiplication of very big numbers. Although I have not benchmarked it, I suspect the other operations are slightly faster too, given that quality of the implementation.

The ‘port’ was done in-place. First, the C# was modified and recompiled, then the bootfile was disassembled, and patched with the new type, and recompiled. Lastly, the new type was extended to make its interface (aka public methods) was compatible in terms of IL method signatures.

The rest, just involved some testing, and minor bug fixing. It should all work as before, and be completely transparent.

I did however come across a weirdass bug, where a case statement will fail to match. I couldn’t repro it at all, even after days of debugging/trying/crying….

Please notify me of any big number related bugs

Cheers

leppie

Further work will include making direct constructor (if possible), predicate, accessor and mutator references. This should provide a nice little speed boost.

Cheers

leppie

clr-call, clr-field-get and clr-field-set! have been modified to infer the type based on the instance argument. This is good news, as it allows me to apply with-clr-type‘s shorthand syntax fluidly (or recursively).

To utilize this feature, you simply have to pass #f as the type argument in the macros. Note: This only applies to instance members. For static members, you are still required to provide the type.

The method and indexer syntax has been slightly modified to accommodate this.

The new body syntax is as follows (rest denotes continuable syntax):

(obj : id (arg ...) . rest) ; calls method 'id' with args
(obj : (arg ...) = value)   ; sets the indexer with args to a value
(obj : (arg ...) . rest)    ; gets the indexer with args
(obj : id = value)          ; sets a property 'id' to a value
(obj : id . rest)           ; gets a property 'id'
(obj -> id = value)         ; sets a field 'id' to a value
(obj -> id . rest)          ; gets a field 'id'

;
Example (given the class defined in the previous posting):

(let-clr-type ((obj (TestClass "foo"))) 
  (obj : Message : (1))) ; C#: obj.Message[1]
=> #\o

;
Also added to the (ironscheme clr shorthand) library are define-clr-type and lambda-clr-type syntax, that binds and defines procedures with their arguments tagged as CLR types.

As you can see, now the ability to use .NET libraries should be a lot easier.

Usage:

(let-clr-type ((obj (TestClass "foo))) ; same as 'clr-new', but without 'clr-new' identifier
   (obj : Message))