eta
eta copied to clipboard
The Eta Programming Language, a dialect of Haskell on the JVM
Laziness is a particularly tricky topic, but once you get a handle on it, it's just as easy to fix laziness bugs as it is to fix memory leak issues...
Java arrays are currently mutable by default but it makes them awkward to work with. As suggested by @GordonBGood, it makes sense to adopt an interface similar to the `array`...
A list field that can store paths to folders or jar files. Will be sent straight to `javac` and also be used for verification purposes.
`etlas update --patches-only` Will update *just* the patches for cases where you don't want to query the package repository.
I'm (now) using JDK8 (x64) on Windows 7 (x64) and etlas seems to feel ... it's not a valid environment? I've attached the results of running the usual diagnostic commands...
Internal "native" `ByteBuffer`'s use `BIG_ENDIAN` `ByteOrder`; should use `nativeOrder` for speed...
## Description It seems that Java's default is to consider everything to be stored as `BIG_ENDIAN` internally (most significant bytes at lower memory addresses); however, the actual machine interface works...
When you have really large source files (2K+ lines), there's a chance that the generated class will be so huge that the constant pool size will exceed the 65,535 size...
While I think it's valuable to have an FFI mechanism in Eta, I think it might be immensely beneficial to support direct Java interop in some way by default, similar...
Java 9+ introduced the module system by specifying `module-info.java` or `module-info.class`. Implementing this requires: - Adding support for `Module` and `Package` constants in `codec-jvm` - Adding support for `Module` attribute...
## Description One of the standard things I do when discovering a new language is to try an optimized bit-packed Sieve of Eratosthenes benchmark using only the CPU L1 cache...