Friday, October 26, 2007

A simple functional structure in Java

I have progressed a little bit in creating a functional language on top of Java, code name FLOJ (Functional Language On Java (-:). For the moment I'm only working on single files (I have a working parser), on the simple language constructs.
It's really interesting, because looking at very simple things make you think in depth about some issues that you may not really consider in Java proper. For example, this is the definition of a very simple structure:


public class Simple(String data,int port){


So you can see that the package system is Java's and class definition are very similar. There are no constructor, so. Since null are not allowed (nulls are a huge source of bugs, I'll provide a Maybe object or something like that later),
the structure must have all its data filled in. If you want different operations to be done, you just create static functions that take parameters and create what you need, no need for several constructors. So the list of fields is entered straight after the name of the class.
Simple is a structure with a string and an int. It's easy enough to generate the constructor in Java:


public class Simple{
public final String data;

public final int port;

public Simple(final String _data, final int _port){
if(_data==null){throw new NullPointerException("_data");};

The fields are immutable of course, so we don't bother with a getXXX() method, we just expose the field.
And you can then add setters that return a new object :

... public Simple setData(final String _data){
if(_data==null){throw new NullPointerException("_data");}
if (_data.equals(data)){return this;}
return new,port);

public Simple setPort(final int _port){
if (_port==port){return this;}
return new,_port);

Note the null handling is not ideal, left for later. Note also we avoid superfluous creations if the data will not change.

So far, so good.

Then I decided to implement equals, so that equals is based on the data and not pointer equality:

public boolean equals(final java.lang.Object o){
if (this==o){return true;}
if (o instanceof{ co=(;
if (!{return false;}
if (this.port!=co.port){return false;}
return true;
return false;

And with this of course the problem of overloaded equals method raises its head. If I want to allow subclasses to add more fields, my equals method won't work for subclasses.
If I check the exact class name in equals, subclasses that only add/overload methods will not be equals to superclasses.
So what can I do? I haven't decided. I could forbid subclasses to define more data fields (that's I think what you have in Haskell: you inherit functions from your type classes but no data).
I could also make the equals method final and not generate it for subclasses, but equality would then ignore the additional fields.
Another option would be to check the class name in that equals method and generate the proper equals method for all subclasses, but that may cause problems if we then extends the FLOJ class by a Java Class (which will be possible since we generate Java code).
But maybe it should be so, that a class is never equals to its subclasses? Returning equals between two instances that have the same data but different behavior (one instance has an overloaded method) is probably an error in the OO world...

Anyway, creating your own language is fun, I'm learning a lot and maybe I'll even end up with something usable!! I'll keep you posted on my progress.

Thursday, October 11, 2007

Generator (with yield) in Java

For some reason I was thinking about generators and the yield function (as found in Python). All this functional talk about infinite lists and such I suppose... So I had a go at implementing one in Java, which tied in nicely with my current reflexions about a java-based functional language and the need to provide concurrency out of the box. And another occasion to dabble with wait and notify in Java! After I've written it I found a similar looking implementation (but without the standard Iterator/Iterable interface support) and something on Google code that use bytecode intrumentation (why oh why). But still I like mine, that you can find here (and the unit test is here).
Basically the work is done in another thread and we call wait() when we do a yield. We conform to the Iterator and the Iterable interfaces, and we provide a stop method to actually stop the thread (say for infinite generators). Otherwise if the generator has not finished the thread goes on waiting forever. I've thought about trying to stop the thread when the generator is not used, but I don't know if it even possible with things like SoftReferences (The thread having a pointer to its runnable...).

Tuesday, October 09, 2007

My own Java-based functional language

I've been toying for a while with the idea of creating my own Java based functional language, if only to be able to see first hand the challenges in creating a functional language. The language I envision has the following characteristics:
- syntax close to Java: contrary to JHaskell or CAL, I want something that looks like Java, not something totally different
- Java type system: use the normal Java OO type system: classes with at most one superclass, interfaces. Maybe I'll run into issues but for the moment...
- pure functional and monadic: what I love in Haskell is the clear delimitation between what's purely functional and what's subject to side effects (IO, etc...). I'd like to have that in my language. I know about Scala, but Scala lets you mix functional and imperative code, I want something pure (and I don't like to add new very un-Java like keywords like def)!
- Java integration: there is no point of being implemented in Java if we can't reuse the wealth of Java code and libraries out there. Probably I'll need a way to distinguish somehow functional Java code (like the String methods) and not functional code, and wrap access to non functional code in a monad.

Now that's an ambitious program!! I've started some parsing and conversion to Java source files (hey, if Java can do some of the type checking for me...), but it's going to be a long road...
Of course, if such a language already exists, I'd be delighted to hear about it!