Home » forums » LtU Forum

Fan Programming Language

Just came across the Fan object-oriented programming Language, running on the JVM and the CLR. They're shooting for portability across both VMs. Looks like they took an interesting approach language-wise, such as default immutability for concurrency, closures, mixins and exporting namespaces as REST-like URIs. This last feature is one I first encountered in the Waterken capability-secure HTTP application server.

I was disappointed to read that Fan eschews generics/parametric polymorphism however. All told, it seems to lean slightly more towards the dynamic end of the spectrum than C#/Java.

By naasking at 2008-04-15 21:49 | LtU Forum | previous forum topic | next forum topic | other blogs | 7461 reads

Comment viewing options

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

Type prototypes for genericity

In my pet language (dodo) I have prototypes. I can define an object p as a copy of object o with some fields with a different value, and possibly additional fields or methods.

The reason I mention this is that generics can be thought as type prototypes:

class List { static Type T }

class IntList : List<T: Int.type> { }

List<T: String.type> lines;

I tried to stay close to Fan syntax in the example above. The List<T: sometype> are new types prototyped on List.

By Denis Bredelet -jido at Wed, 2008-04-16 10:53 | login or register to post comments

Looks like Fan does have

Looks like Fan does have something like prototypes called dynamic types. There is no specific syntax for them though. And I do not know if they are powerful enough to apply the suggestion above.

By Denis Bredelet -jido at Wed, 2008-04-16 12:07 | login or register to post comments

Whacky scoping?

I've had trouble navigating the site, and I'm a bit disturbed by "default immutability for ... closures ..." Does that mean closures can sometimes be mutated? What does that do to scoping?

By Charles Stewart at Wed, 2008-04-16 14:00 | login or register to post comments

I don't see what you're

I don't see what you're referring to. Their concurrency page doesn't say anything about immutable closures, just that shared state between threads is always immutable.

By naasking at Wed, 2008-04-16 14:06 | login or register to post comments

Source

I was excerpting your text in the story. I gather that you have not heard of mutating closures, and I misunderstood what you wrote.

By Charles Stewart at Wed, 2008-04-16 14:13 | login or register to post comments

If you are asking if

If you are asking if captured variables can be modified, yes they can. From the documentation:

counter := 0
f := |->Int| { return ++counter }
echo(f())
echo(f())
echo(f())
echo(counter)

the output of the code above is to print "1", "2", "3", and "3".

By Denis Bredelet -jido at Wed, 2008-04-16 15:10 | login or register to post comments

Not exactly

This example is consistent with scheme's scoping rules, cf.:

(define c 0)
(define f (lambda () (set c (+ c 1)) c))
...

By mutable closures, I mean that it is possible for code to dynamically change not the values of bound variables, but the binding of names to locations. Tcl allows you to do this, as does newlisp.

It's particularly insidious if the language encourages you to treat namespaces as lexically determined, as in the case of newlisp. It's in this case I call it whacky scoping.

By Charles Stewart at Wed, 2008-04-16 19:00 | login or register to post comments

Yes in newLISP you don't

Yes in newLISP you don't really know what c you will be using. There must be a remedy to this though?

Fan does not have that problem.

By Denis Bredelet -jido at Wed, 2008-04-16 22:07 | login or register to post comments