I want to write a Haskell function (module) of type: String -> String to call in Android. The easiest method seems to use JHC to generate C code, then use Android NDK to generate a shared library, but I could not find any documentation for JHC. Does JHC also use Cabal to build? Is JHC stable enough to use Parsec or Attoparsec library?
Back in 2011 I had limited success using JHC in a similar way, but targeting iOS instead of Android. Initial results were good in just getting the thing running, but we ended up discarding JHC in favor of GHC precisely because we started getting weird compile-time errors on programs that used Parsec. Bear in mind, this was in 2011 so JHC might have improved by a lot since.
If you want to give GHC a chance, I'd recommend looking at this example which uses GHC 7.8 to compile a game for Android. I haven't used it in anger yet, but I did manage to get it working on Docker, getting as far as rebuilding the game from scratch and installing it on a real Android device, so the approach definitely has merit.
UPDATE as of August 2017: Moritz Angermann has posted detailed instructions on targeting Android with a GHC cross-compiler.
Well a compiler called eta maybe the most convenient way now.it targets jvm and it will produce a jar file so you can directly put it in your project
Related
By accident I knew that the compiler of Haskell is written in Haskell. It sounds strange to me. How is this possible, I mean, to compile itself? Who is to compile the compiler then? What is the ultimate code accepted by machine?
Consider the programming language who is the first to have a compiler. What is the language of its compiler? Going back even farther in time, how did people program before the era of compiler?
Broadly speaking, I am often confused about the border between software (e.g. programming written by people) and hardware (e.g. something executable on a physical machine).
P.S.: I have basic knowledge about compiler such as lexical analysis, parsing, and code optimization. However, I know little about hardware (the machine).
It seems that the answer to a related post Implementing a compiler in “itself” does not go deeply into the border between software and hardware.
And I would like to see some concrete examples.
EDIT: Some comments mentioned the term "bootstrapping". It seems that there is some minimum core part of a language (like axioms/basic theorems in mathematics) which must be compiled in a lower-level way (instead of by itself). What are they? Are they basically the same in different languages? Again, I would like to see some concrete examples.
As you can read in A history of Haskell page 28, the first haskell compiler was written in Lazy ML in June 1989. It implemented essentially all of Haskell 1.0.
Now that this compiler existed, it can then be used to compile the Haskell version of GHC. The first beta of GHC written in Haskell was release on 1 April 1991. The full release came in December 1992.
Because the Lazy ML-based compiler wasn't developed further, today you use a previous version of GHC to compile GHC. So if you want to build GHC 7.8, you use GHC 7.6 to build it (in practice, it's a bit more complicated, because there are multiple stages and only the first stage, which doesn't support GHCi or TemplateHaskell is built with GHC 7.6)
That means that if you don't have a working haskell compiler today, you have two options:
Try to install a LML compiler and compile the first version of GHC written in Lazy ML. Then use this compiler to compile the next version which is written in Haskell. Then again use that compiler to build the next version, and repeat until you have a reasonably recent compiler. It may be possible to skip a few versions, but I don't know how many. As you can imagine, this could take a lot of time.
(Much easier) Download pre-built GHC binaries.
Um... I have not tried this, but another route would be simply compiling to c and using a c compiler to compile latest ghc...ghc is itself built in stages, so you don't really even need to convert the whole code base to c, just the first stage, which then can compile the rest. Certainly no need to dig up Lazy ML.
Edit: Note the resulting compiler will not build binaries targeting the new platform, it would simply run on that platform and be a cross-platform compiler for targets that ghc already has backends for. Another note is that i actually intended this in response to bennofs answer, not as stand alone answer to the OP.
I have the Haskell Platform 2012.4 installed on Windows. I would like to try the new extensions in GHC 7.6.2. It looks like the GHC 7.6.2 x86_64 download does not include an installer and is just the binaries. What is the proper way to get the latest version installed and set as the default for building Haskell projects? Thanks.
If you download GHC itself, you just get GHC and a tiny handful of libraries. If you download the Haskell Platform, you get GHC plus a much bigger collection of libraries. However, the Haskell Platform is updated infrequently, so you'll get an older version of GHC.
If you're asking "how do I install the Haskell Platform and then make it work with a newer GHC?", then the answer is "you don't". Haskell libraries have to be compiled for the specific version of GHC you're using.
You basically have two options:
Use the Haskell Platform, together with the version of GHC that it supplies.
Use the latest GHC, and compile whatever libraries you want manually.
On Linux it's not too bad, but Haskell libraries that bind to external C code tend to be fiddly to build on Windows. (Stuff like OpenGL, zlib, etc.) Packages that are 100% vanilla Haskell code are drop-dead easy to compile on any system.
I haven't done this and I'm at work so I can't test it out, but looking at the GHC docs I would think you can use the --with-compiler=path flag to select which version of GHC to use?
See also this question, related to using cabal with multiple versions of ghc installed. I would guess that you probably want to use cabal-dev or something to sandbox this, otherwise your package database may become a mess.
EDIT: As far as a default, I think you can set that in a cabal configuration file. See the comments to the accepted answer in that question I linked.
The other answers here are great, and I wanted to add that the current best way to get the latest version of GHC installed is to look at haskell.org's installation instructions. I bounced between lots of different options before I landed there, and I think it's the best source of truth from what I can tell.
To summarize the current instructions: if you already have chocolately set up, "at an elevated command prompt, run choco install haskell-dev, followed by refreshenv."
In the Haskell docs here http://www.haskell.org/haskellwiki/Debugging it mentions Hat to do offline debug traces, but that page is online. I found it via Google but it seems outdated; what is the best way to do offline Haskell traces?
Hat isn't outdated -- olaf chitil revived it and is actively maintaining it: http://olafchitil.github.com/hat/
The latest version on hackage is tested to build with ghc 7.6.
It does, however, still only work on Haskell 98, with a few extensions. So programs that use more advanced GHC extensions (particularly regarding fancy type tricks) won't work with it. To my knowledge, there's nothing similar to hat that's been extended to handle a wider range of extensions to Haskell.
I would like to be able to run code written in F# on a linux system (Debian) but it's unlikely that I'll be able to install Mono on it. Is there any way to compile the F# to be fully static and have absolutely no dependencies on Mono? Basically just end up with an executable binary that I could run just like any other linux binary?
Even on a stripped down account you can compile your own version of Mono - it is not particularly hard, see http://www.mono-project.com/Compiling_Mono. There are a few dependencies, but they aren't hard to find. You will need to prefix most of your run calls with mono though, like mono myapp.exe rather than ./myapp.exe
Try AOT. But be ware of it's limitations.
Update:
I think I've jumped for an answer a bit too fast and haven't dive deep enough to turn it into something useful. AOT will pre-compile code into shared libraries, under the right conditions this may increase performance.
Still, if you have a requirement to not install the mono runtime in the client machine at all (why?), I think you should try mkbundle / mkbundle2. This will produce a huge self contained executable (C# Hello World + deps generated a file around 2.5MB for my machine... With -z I got around 900k). You can try to combine it with Linker to further strip out unused portions of libraries that your application depends on.
As for your second question F# compiler will generate CIL as any other .NET compiler. So, it should not matter. Still, if your application contains either IL instructions that are not yet supported by mono AOT compiler (e.g., you need mkbundle2 to handle generics) or dependencies to external linked libraries that you can't install in your Debian box you are out of lucky. Guess you will have to do a bit of trial and error operations by yourself.
I've been using omniCppComplete + ctags for a while, and want to make a further improvement on the code completion.
According to the suggestion in here [1], gccsense and clang_complete seems to be alternatives. However, I am not sure which one is better. Any idea on their performance?
Thanks!
Update: After I tried clang_complete, I found the completion speed extremely unacceptable.
I then tried it using libclang.dylib, which speeds up a lot but still make one feels lagging.
I think I should stick to ctags for now.
You should probably use clang_complete, not gccsense.
The main point here is the architecture of the two. The idea behind both solutions is very similar: you can't get normal C++ completion without access to internal compiler (gcc) information (Abstract Syntax Tree) while gcc doesn't provide you with sufficient interfaces for that. The implementation part of accessing this info though is quite different here: gccsense is a kind of "hack" - it's a custom build of gcc capable for storing the neccessary info for futher providing it to plugin, while clang_complete goes the other way by using alternative compiler: clang, one of the main goals of creation of which was exactly making AST easily accessible by external tools.
So, in case of using gccsense you'll need to compile your code with a kind of custom gcc compiler, which is already a little bit outdated (gccsense is using gcc 4.4) now and will constantly need developer's support in feature. On the contrary, clang_complete doesn't depend so much on clang compiler, it uses it as external tool.
As for performance: again clang was designed to be faster than gcc and it is. Clang_complete can be slightly slower on Windows than on MacOS/Linux, however gccsense can't even be compiled for Windows at the time.
GCCsense can be built on Windows.
See my patch on gcc 4.5.2 here:
http://forums.codeblocks.org/index.php/topic,13812.msg94824.html#msg94824
I admit that gccsense is just a hack to gcc, but clang has much better design from its beginning.
I hope anyone could improve gcc/gccsense.