In this blog I talk about some of the personal work I do in programming. I mainly do Java and JavaScript, but I'm learning functional programming in Haskell too...

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:

package fr.moresmau.jp.floj.samples;

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:

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.

And there's not even generics yet (-: ... Seriously, apart from the fact that the code show 1 space instead of tabs and in a couple of places doesn't go to a new line to have return false, I don't see what's so horrible about it.

The last sniplet:1. we know what package Object is in, and you defined Simple earlier so no need to type in the full class names.2. There's nothing wrong with indenting with 1/2/3/4/10 spaces or tabs, but you have to put spaces around binary operators (==, =, +, -, etc.).3. no need to declare "o" final. You're not referencing it from inside of an embedded anonymous class.

Sorry, you're not bitchy, it's good to have reactions!! What may not be clear in the post is that the code here is generated by my converter from the functional code to Java. Hence the absence of spaces, the aggressive use of final, etc... But yes since the converter generates source files (I didn't want to dive into .class format right now) I could generate prettier output. Thanks!