Frege: yet another JVM language
Ingo Wechsung
Frege is a non-strict, pure functional programming language in the spirit of Haskell.
Frege programs are compiled to Java and run in a JVM. Existing Java Classes and Methods can be used seamlessly from Frege.
Frege is not a Haskell dialect, though I put some effort to make it look and feel like so.
The project is in a very early stage, but at least the compiler compiles itself.
What is missing most is more/complete docs and first and foremost, broad Java API support.
John Cowan
<ingo.w...@googlemail.com> wrote:
> Frege is not a Haskell dialect, though I put some effort to make it look and
> feel like so.
It looks very much like a Haskell dialect to me, just judging from the
number of "Incompatibility with Haskell" notes in the manual (very few
and quite small).
--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures
Ingo W.
On 15 Sep., 19:47, John Cowan <johnwco...@gmail.com> wrote:
> On Thu, Sep 15, 2011 at 10:43 AM, Ingo Wechsung
>
> > Frege is not a Haskell dialect, though I put some effort to make it look and
> > feel like so.
>
> It looks very much like a Haskell dialect to me, just judging from the
> number of "Incompatibility with Haskell" notes in the manual (very few
> and quite small).
Most criticism I received so far is that it is not enough like
Haskell.
The point is:
- there is not one line of code borrowed from any existing Haskell
compiler (the major part of the standard base library - aka Prelude -
of course has been adopted from Haskell - or at least it provides a
well knwon interface. Often, the implementation of a function or class
operation is some method from the Java API)
- besides the differences, there are also things that are not part of
Haskell 2010: higher rank polymorphism, functions scoped to namespaces
associated with types (think field labels) to name two.
- I'd never dare to claim compatibility with Haskell, nor is this my
objective. It is just most often so that when you have a design
decision, you choose to not re-invent the wheel. Ang given that the
base paragdigm - non-strict, pure functional - is the same, the
Haskell way is often the most natural.