[null, {"document_url": "http://fregepl.blogspot.com.es/2011/10/", "unformatted_src": "http://3.bp.blogspot.com/--l_gSZs21A8/TqBc5JgCJpI/AAAAAAAAA34/8VuqPXvkxjw/s1600/Functor.PNG", "src": "http://3.bp.blogspot.com/--l_gSZs21A8/TqBc5JgCJpI/AAAAAAAAA34/8VuqPXvkxjw/s1600/Functor.PNG", "formatted_filename": "Functor"}, null, {"document_url": "http://fregepl.blogspot.com.es/2011/10/", "unformatted_src": "http://1.bp.blogspot.com/-wKu1oFDwA9U/TqBu0EbehII/AAAAAAAAA4Y/t481JpGsRZY/s1600/TApp.PNG", "src": "http://1.bp.blogspot.com/-wKu1oFDwA9U/TqBu0EbehII/AAAAAAAAA4Y/t481JpGsRZY/s1600/TApp.PNG", "formatted_filename": "TApp"}, null, {"document_url": "http://fregepl.blogspot.com.es/2011/10/", "unformatted_src": "http://2.bp.blogspot.com/-ltKC_0aewyw/TqBi7PfB9vI/AAAAAAAAA4I/U0Revc0CQKA/s320/Rank2.PNG", "src": "http://2.bp.blogspot.com/-ltKC_0aewyw/TqBi7PfB9vI/AAAAAAAAA4I/U0Revc0CQKA/s320/Rank2.PNG", "formatted_filename": "Rank", "rendered_width": 320, "rendered_height": 29}, null, {"document_url": "http://fregepl.blogspot.com.es/2011/10/", "unformatted_src": "http://1.bp.blogspot.com/-OVHn_--Egiw/TqBl0mWbGoI/AAAAAAAAA4Q/x4VaKB8ph9A/s1600/coerce.PNG", "src": "http://1.bp.blogspot.com/-OVHn_--Egiw/TqBl0mWbGoI/AAAAAAAAA4Q/x4VaKB8ph9A/s1600/coerce.PNG", "formatted_filename": "coerce"}, null, null, null, null, null, null, {"document_url": "http://fregepl.blogspot.com.es/2011/10/", "unformatted_src": "http://faculty.washington.edu/smcohen/453/Frege.jpg", "src": "http://faculty.washington.edu/smcohen/453/Frege.jpg", "formatted_filename": "Frege", "alt_text": "Gottlob Frege", "rendered_width": 195, "rendered_height": 248}, null, null, null, null, null, null, null, null]

Frege and Java Generics

Early on in the development of the Frege compiler, I decided that the compiler would produce Java source code, which would be compiled subsequently by a Java compiler fired up with Runtime.exec().

The reasons for this decision were manyfold:

But it turned out, that I stretched the second point  too far, when my ambition was not only to generate correct Java code, but to generate type safe (in java terms, that is) java code. I had not considered that java generic types are not  powerful enough to reflect higher ranked, higher kinded polymorphic types like they occur in Frege programs.

A first warning came early, when the Java 6 compiler complained about syntax errors. It turned out that this was instead a Java compiler bug. Astonishing, a few years after introduction of generics in the language! Worse, the bug would only get fixed with JDK7. See my stackoverflow post for details.
Fortunately, at this time the JDK7 preview was already available, so I downloaded that and continued with JDK7.

Some days later I discovered that I could not express the type of a class method of a constructor type class, like this: Here, the type variable f stands not for a type, but for a partially applied type, like Maybe or [], and the variables a and b are like the element types.
As I had to learn this way, Java has not the slightest idea of how to apply a type variable to a type. I wasted a week or so trying with something like but other difficulties arose I can't recall exactly, but they were insurmountable.

Not enough that type applications would not work with variables, partially applied types would not work either.  Don't ask what I experienced with higher ranked function types like Yet, my desire to see Frege compiled code run finally, and, when this was achieved, the aversion against throwing everything away and starting anew, seduced me to write one workaround after the other, every time in the hope it would be the last one. For example, I introduced methods like this: that are called at various places to "instantiate" polymorphic functions at the required type just to make javac happy. This made the code even uglier, but finally seemed to work.

Until recently, when one of the committers of the Frege project found a number of bugs, and two or three of them were of the sort where the Java compiler flags type errors. Today, he sent me another error report with the following compiler message:

.\test\Test.java:1051: <?,?>w(test.Test.tMaybe<?>,frege.rt.Lazy<frege.rt.Fun<?,t
est.Test.tMaybe<?>>>) in test.Test.iMonad_Maybe._gt_gt_eq cannot be applied to <
return iMonad_Maybe._gt_gt_eq.<Fun<?, ?>, ?>w(_arg1, _â2805_27)._e();

Yes, it can be applied, I just can't prove it in Java!
Time for a new code generation without generics, but with unavoidable explicit casts in the right places! This will mostly be a matter of stripping the generic overhead of maybe 30% to 40% off the current code generator.

Gepostet von Ingo Wechsung um 21:03 0 Kommentare Labels: Frege, Java, Type system


Improved import declarations, plans for future developent

With Revision 202, the functionality of import declarations has been extended.

Taken together, this will make it possible to create packages that provide an interface to some library consisting of arbitrary many sub-packages, so that implementation details remain hidden and full functionality of many modules can be imported with a single import.
Unfortunately, changes in some module of a library that are not merely additions will continue to break binary backwards compatibility of the client modules that are compiled against an earlier version. This is due to limitations of the JVM, where all classes, methods and so on have only one name.
The new features are documented in chapter 5 of the language reference.

Next steps in development will be:

Gepostet von Ingo Wechsung um 03:47 0 Kommentare Labels: Compatibility, Development, Java, JVM


Bug fixing

As people start playing with Frege some errors in the compiler are exposed. Some of them are merely usability issues, while others are more critical.

For example, somebody tried the following:

fib n = case n of
Integer.zero -> n
Integer.one  -> n
_ -> ....

I had not anticpated this possibility, so the compiler treated this like:

z -> n
o  -> n

and only complained about unreachable case alternatives. Of course, fib degenerated to another identity function this way. The right thing in this case was to refuse the program on the ground that pattern bound variables must not be qualified.

As I strive to correct errors as soon as possible, we had around 7 new versions of the frege*.jar in the last 14 days. I am sorry for that, but I hope error corrections will occur on a slower and slower pace. When one looks at the source code commits one sees also that almost all corrections are but small fixes. Nothing required fundamental changes up to this day.

I appreciate very much your feedback, even if it takes the form of an error report. As mentioned on the project home page there are now the following ways to communicate:

Thank you all for your contributions in finding errors and  for your patience with runtime/compiler downloads that are updated often.

Gepostet von Ingo Wechsung um 11:47 1 Kommentare Labels: Bug, Compiler
