Why am I stopping? Not for a very specific reason, though seeing that I had to adapt BuildWrapper to GHC 7.10 didn't exactly fill me with joy, but more generally I got tired of being the single maintainer for this project. I got a few pull requests over the years and some people have at some stage participated (thanks to you, you know who you are!), but not enough, and the biggest part of the work has been always on my shoulders. Let's say I got tired of getting an endless stream of issues reports and enhancement requests with nobody stepping up to actually address them.
Also, I don't think on the Haskell side it makes sense for me to keep on working on a GHC API wrapper like BuildWrapper. There are other alternatives, and with the release of ide-backend, backed up by FPComplete, a real company staffed by competent people who seem to have more that 24 hours per day to hack on Haskell tools, it makes more sense to have consolidation there.
The goal of EclipseFP was to make it easy for Java developers or other Eclipse users to move to Haskell, and I think this has been a failure, mainly due to the inherent complexity of the setup (the Haskell stack and the Java stack) and the technical challenges of integrating GHC and Cabal in a complex IDE like Eclipse. Of course we could have done better with the constraints we were operating under, but if more eyes had looked at the code and more hands had worked on deck we could have succeeded.
Personally I would now be interested in maybe getting the Atom editor to use ide-backend-client, or maybe work on a web based (but local) Haskell IDE. Some of my dabblings can be found at https://github.com/JPMoresmau/dbIDE. But I would much prefer to not work on my own, so if you have an open source project you think could do with my help, I'll be happy to hear about it!
I still think Haskell is a great language that would deserve a top-notch IDE, for newbies and experts alike, and I hope one day we'll get there.
For you EclipseFP users, you can of course keep using it as long as it works, but if no other maintainers step up, down the line you'll have to look for other options, as compatibility with the Haskell ecosystem will not be assured. Good luck!
Happy Haskell Hacking!
Someone solved it, both in the comments and on the IRC channel. Thanks for the help, everyone!
I am working on this project here: https://github.com/pharpend/louse. When I try to compile the program with cabal install, I get this bizarre error with ldResolving dependencies... In order, the following will be installed: louse-0.1.0.0 +dev (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway... Configuring louse-0.1.0.0... Building louse-0.1.0.0... Failed to install louse-0.1.0.0 Build log ( /home/pete/.cabal/logs/louse-0.1.0.0.log ): Configuring louse-0.1.0.0... Building louse-0.1.0.0... Preprocessing library louse-0.1.0.0... In-place registering louse-0.1.0.0... Preprocessing executable 'louse' for louse-0.1.0.0... [2 of 2] Compiling Main ( bin/louse.hs, dist/build/louse/louse-tmp/Main.o ) [Data.Louse.Bugs changed] Linking dist/build/louse/louse ... /home/pete/src/louse/dist/build/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.text+0x536e): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_info' /home/pete/src/louse/dist/build/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.text+0x65d2): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_info' /home/pete/src/louse/dist/build/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.data+0x8a0): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_closure' collect2: error: ld returned 1 exit status cabal: Error: some packages failed to install: louse-0.1.0.0 failed during the building phase. The exception was: ExitFailure 1
If I compile only the library, and try to compile the executable with plain ghc, the same thing happens:Linking louse ... /home/pete/.cabal/lib/x86_64-linux-ghc-7.10.1/louse_0flN1wT55XYAdEZ4du8MhO/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.text+0x536e): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_info' /home/pete/.cabal/lib/x86_64-linux-ghc-7.10.1/louse_0flN1wT55XYAdEZ4du8MhO/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.text+0x65d2): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_info' /home/pete/.cabal/lib/x86_64-linux-ghc-7.10.1/louse_0flN1wT55XYAdEZ4du8MhO/libHSlouse-0.1.0.0-0flN1wT55XYAdEZ4du8MhO.a(Bugs.o):(.data+0x8a0): undefined reference to `lousezu0flN1wT55XYAdEZZ4du8MhO_DataziLouseziConfig_readLouseConfig1_closure' collect2: error: ld returned 1 exit status
The function that ld is complaining about: https://github.com/pharpend/louse/blob/master/Data/Louse/Config.hs#L38readLouseConfig :: IO (Maybe LouseConfig) readLouseConfig = do configPath <- _config_path configPathExists <- doesFileExist configPath if configPathExists then do configBytes <- B.readFile configPath pure (decodeStrict configBytes) else pure Nothing
If I comment out the do-block, and replace the definition with pure Nothing, then everything compiles just fine-and-dandy. It's weird because the library compiles just fine, so it's not a type error. There's some weird undefined symbol in the generated code.submitted by pharpend
[link] [11 comments]
There is little public about Eve so far, no precise design documents, but the development team has a public monthly Development Diary that I found fairly interesting. It displays an interesting form of research culture, with in particular recurrent reference to academic works that are coming from outside the programming-language-research community: database queries, Datalog evaluation, distributed systems, version-control systems. This diary might be a good opportunity to have a look at the internals of a language design process (or really programming environment design) that is neither academic nor really industrial in nature. It sounds more representative (I hope!) of the well-educated parts of startup culture.
Eve is a functional-relational language. Every input to an Eve program is stored in one of a few insert-only tables. The program itself consists of a series of views written in a relational query language. Some of these views represent internal state. Others represent IO that needs to be performed. Either way there is no hidden or forgotten state - the contents of these views can always be calculated from the input tables.
Eve is designed for live programming. As the user makes changes, the compiler is constantly re-compiling code and incrementally updating the views. The compiler is designed to be resilient and will compile and run as much of the code as possible in the face of errors. The structural editor restricts partially edited code to small sections, rather than rendering entire files unparseable. The pointer-free relational data model and the timeless views make it feasible to incrementally compute the state of the program, rather than starting from scratch on each edit.
The public/target for the language is described as "non-programmers", but in fact it looks like their control group has some previous experience of Excel. (I would guess that experimenting with children with no experience of programming at all, including no Excel work, could have resulted in very different results.)
Posts so far, by Jamie Brandon:
- Eve so far (October 2014): a summary of the work from January to September 2014. The general vision; a move from a functional pidgin to a datalog-like language motivated by non-programmers testing; discussions of algorithms for incremental Datalog evaluation (ending with a poor-man solution).
- October: bootstrap editor, experiments, aggregates: the team picks five concrete use-cases and draws lessons for their language needs
- November: more experiments, better performance, integrity constraints, zztrees
- December: more zzjoin, communication, process spawning
- January / February: GUIs, time, joins and aggregates
- Version control, collaborative editing and undo
Some random quotes.
Retrospective:Excited, we presented our prototype to a small number of non-programmers and sat back to watch the magic. To our horror, not a single one of them could figure out what the simple example program did or how it worked, nor could they produce any useful programs themselves. The sticking points were lexical scope and data structures. Every single person we talked to just wanted to put data in an Excel-like grid and drag direct references. Abstraction via symbol binding was not an intuitive or well-liked idea.
Our main data-structure was now a tree of tables. Rather than one big top-level function, we switched to a pipeline of functions. Each function pulled data out of the global store using a datalog query, ran some computation and wrote data back. Having less nesting reduced the impact of lexical scope and cursor passing. Using datalog allowed normalising the data store, avoiding all the issues that came from hierarchical models.
At this point we realised we weren't building a functional language anymore. Most of the programs were just datalog queries on normalised tables with a little scalar computation in the middle. We were familiar with Bloom and realised that it fit our needs much better than the functional pidgin we had built so far - no lexical scoping, no data-structures, no explicit ordering. In late March we began work on a Bloom interpreter.
Where most languages express state as a series of changes ('when I click this button add 1 to the counter'), Eve is built around views over input logs ('the value of the counter is the number of button clicks in the log'). Thinking in terms of views makes the current language simple and powerful. It removes the need for explicit control flow, since views can be calculated in any order that is consistent with the dependency graph, and allows arbitrary composition of data without requiring the cooperation of the component that owns that data.
Whenever we have tried to introduce explicit change we immediately run into problems with ordering and composing those changes and we lose the ability to directly explain the state of the program without reference to data that no longer exists.
[...]In a traditional imperative language, [context] is provided by access to dynamic scoping (or global variables - the poor mans dynamic scope) or by function parameters. In purely functional languages it can only be provided by function parameters, which is a problem when a deeply buried function wants to access some high up data and it has to be manually threaded through the entire callstack.
December:Eve processes can now spawn subprocesses and inject code into them. Together with the new communication API this allowed much of the IDE architecture to be lifted into Eve. When running in the browser only the UI manager lives on the main thread - the editor, the compiler and the user's program all live in separate web-workers. The editor uses the process API to spawn both the compiler and the user's program and then subscribes to the views it needs for the debugging interface. Both the editor and the user's program send graphics data to the UI manager and receiving UI events in return.
About a year ago I announced open internship positions at Hoppinger for building a CMS with Haskell. The resulted in the proud announcement of LambdaCms here on Reddit about eight months later. An interesting remark: one of the interns managed to score an 9.5/10 for the project resulting in a cum laude.
We have decided to commit to another internship project in order to improve it further. Currently one intern, student at the Rotterdam University of Applied Sciences, has committed to work on the project from September '15 to January '16. By this message we want to announce that, in the second half of 2015, we still have one or two positions open on this project.submitted by cies010
[link] [4 comments]