The Jars here reflect ongoing development for 3.25, and may be needed for going forward.
3.25.42 from May 10, 2018
Contains a fix for #357 that changes the Java signatures of some library functions.
After some pause, many bugs of the 3.24alpha releases have been fixed and we have finally a compiler we can work with for future developments.
Note that Java 1.7 is still supported, however, people needing it are kindly asked to build their own. See https://github.com/Frege/frege/wiki/Contributing-to-Frege#recompile-the-compiler-unix
Frege is proud to utilize the jline library in its interpreter. Thank you, https://github.com/jline/jline2
- REPL runs better under Windows now
- compile java source code dependencies in
- The REPL is now included! Just run
java -jar frege3.24.400.jarfrom a command line.
- 31.1 MB frege3.24-7.100.jar
- 31.8 MB frege3.24-7.30.jar
- 31.5 MB frege3.24-7.304.jar
- 30.8 MB frege3.24-7.40.jar
- 30.8 MB frege3.24-7.61.jar
- 30.7 MB frege3.24-7.80.jar
- 7.33 MB frege3.24.100.jar
- 7.45 MB frege3.24.30.jar
- 7.39 MB frege3.24.304.jar
- 7.3 MB frege3.24.40.jar
- 7.3 MB frege3.24.61.jar
- 7.29 MB frege3.24.80.jar
- Source code (zip)
- Source code (tar.gz)
The preliminary jars here are intended for community members who develop tools like REPL, IDEs and Builders.
A public release is planned to appear in a few weeks, but there are still some minor bugs to fix, issues to resolve, documentation to write and cleanup to do.
Note that except for small programs, you'll need a JAVA 9 SDK if you want to target Java8, since the
javac in Java8 is broken.
The JARs with version numbers 3.24-7 are compiled for target 1.7 and allow Frege development with Java7.
It goes without saying that bug reports are welcome.
The JARs offered here should run with JDK9, as they contain the fix for #165
Also, if you want to build "master", you will need to use one of those.
From 3.23.343 on, we use Haskell lambda syntax. There are a few cases where previously valid syntax won't compile any more (in the whole standard codebase, there were 5 corrections to make). So please recompile your sources to make sure you're up to date.
From 3.23.365 on, we use Haskell class/instance syntax.
Unfortunately, this means that most of your non-trivial class and instance declarations will fail the syntax check. Please adapt and recompile.
Version 3.23.370 contains some patches to show instance and class definitions in the new syntax in the eclipse plugin and doc tool.
Because of the radical syntax change in 365, earlier versions have been removed.
Version 3.23.401 includes the change to Haskell variable names due to @danielkroeni . Unfortunately, this results in changed class names in the binaries, as we had to replace heading underscores with $ signs. This means that this version is not binary backwards compatible with earlier ones, so you have to recompile your sources once.
Finally, 3.23.422 fixes a bug in code generation that has gone unnoticed since February.
3.23.888 is (hopefully) the latest 3.23 release before switching to 3.24.
Please read the release notes for more information.
Please Note The JARs here will not run with JDK9. To run Frege with JDK9, use one of the preliminary releases under "Summer 2015".
Also, as of Aug 20, 2015 you can't build the master branch with those releases anymore.
See description in the wiki.
In certain cases it may be that code that compiled previously doesn't with the new compiler. Most of the time the reason is one of the following:
- lexical errors with no longer supported regular expression literal syntax
- lexical errors with operators
- errors that can be traced back to problems with precedence and/or associativity of operators.
You should be able to solve these after having read the aforementioned wiki page. Or just ask on SO or in the news group.
Please report other errors as issues.
There is also a corresponding version of the eclipse plugin ready for upgrade from the upgrade site, see the fregIDE tutorial. Unless indicated otherwise, you can update your frege IDE 3.22 installation by replacing the
fregec.jar with a more recent one from the 3.22.xxx series.
This is the final release of the 3.21 branch, and serves as fallback (just in case ...), it is also the starting point for the 3.22 releases that will result in an overhauled compiler.
The goals are thus:
- Scanner must not load classes. Because of this, precedence and associativity of operators will not be known to the parser.
- Parser will not: desugar do-blocks and list comprehensions, translate expressions to patterns and will not resolve applications with binary operators. A new source expression type will be needed for this.
- Benefit: Desugaring pass and instance derivation does not need to distinguish between expressions and patterns, which should reduce the support code by 50%.
- Desugaring happens only after import pass, together with name resolution. At this point, the symbol tables of the imported modules are known, which contain operator information n the associated symbols. This will solve also the long standing problem that operator names appear "global", i.e. you can't have two operators with the same name but different associativity and precedence in different modules, without the compiler choosing silently one of the associativities/precedences. Also, these properties can be documented/shown in the IDE.
- Every pass will be of type StateT IO Global. Most passes will not do IO, however. (Scanner, Import, and code generation, of course, must be able to do IO, as well as future plug-ins). Error messages are saved in the state and are printed at the end of the pass. (Trace output will use trace/traceLn, not IO)
- The monolithic big source files (like Transform.fr, that contains 4 different passes) will get splitted up.
- A better make facility will do a dependency analysis of the given source files and compile in parallel, if possible. We will cache the global state, not the annotations from the class files. The latter prooved to be buggy in the presence of certain changes: when B depended on A and A was changed, this loaded the old A.class, then compiled A, then tried to compile B. But in B's import pass, the old A class was still there, so compilation terminated with phantom errors: errors that went away by just restarting the compilation (because then, the new A.class could be loaded). This also makes the import independent with regard to the source of the global state of imported modules: if it was compiled or imported before, the available state can be used, and only if it was not imported before and not build in the same session will the class file get loaded and the global state reconstructed. This will make it possible to javac the produced java files in one go, which could again be faster than now.