On 09 May 2005 16:03, Daniel Carrera wrote:
robert dockins wrote:
Perhaps. Nonetheless it is common practice for compilers to be written in the target language and to be compiled via bootstrapping. Ever take a look at the GCC sources? You guessed it: C.
Please don't confuse the compiler being written in the target language with the compiler requiring itself. It should be possible to compile it with a compiler for a /different/ language.
You can compile gcc with Sun's CC. You should be able to compile ghc with nh98.
It is possible to compile GHC without having GHC installed, there are detailed instructions in the Building Guide. Indeed you found the instructions, but gave up because the instructions talked about "porting". So is that all you're complaining about? While it's a bit fiddly to get GHC up for the first time, you only have to do it once. Hence, making this easier is not a top priority. Cheers, Simon
Simon Marlow wrote:
It is possible to compile GHC without having GHC installed, there are detailed instructions in the Building Guide. Indeed you found the instructions, but gave up because the instructions talked about "porting". So is that all you're complaining about?
No, you misunderstood. I was trying to say that "porting" was not the place you'd expect to find out how to compile GHC when you are not doing a port. I /did/ read the instructions (but only after skipping the "porting" link many times).
While it's a bit fiddly to get GHC up for the first time, you only have to do it once. Hence, making this easier is not a top priority.
I think it should be if you want Haskell to grow in acceptance. The first barrier that new potential users hit is the one that causes most people to give up and move on to a different project. That first barrier should be made as low as possible. Best, Daniel.
2005-05-09T16:09:16 Daniel Carrera:
I think it should be if you want Haskell to grow in acceptance. The first barrier that new potential users hit is the one that causes most people to give up and move on to a different project. That first barrier should be made as low as possible.
This is a first barrier only for users on platforms that don't currently have ghc maintainers. Given how tricksy it is getting a working ghc build, even on a "supported" platform, doing so is relegated to the few and devoted; new users are only welcome on the platforms for which pre-built ghc binaries are available. I agree with you, Daniel, that this is a terribly unfortunate state of affairs, but as has already been said, the folks who are doing the actual work (I ain't one of 'em) have decided that making ghc easier to bootstrap onto a supported platform is not a priority for them, they're content that virtually all ghc users should have to download prebuilt binaries, or source packages on platforms where devoted souls have built working automated builds. -Bennett
On May 9, 2005, at 4:55 PM, Bennett Todd wrote:
2005-05-09T16:09:16 Daniel Carrera:
I think it should be if you want Haskell to grow in acceptance. The first barrier that new potential users hit is the one that causes most people to give up and move on to a different project. That first barrier should be made as low as possible.
This is a first barrier only for users on platforms that don't currently have ghc maintainers.
Given how tricksy it is getting a working ghc build, even on a "supported" platform, doing so is relegated to the few and devoted; new users are only welcome on the platforms for which pre-built ghc binaries are available.
I'll echo this. The Darwinports GHC build is the first time I've ever gotten GHC to build out of the box. Previous attempts have required multiple hours of hacking, even with a same-version binary installed on the same platform. Part of that was being burdened with variously non-standard machine configurations. But mostly it's because the fptools build structure was historically pretty fragile, and stuff broke badly if it didn't get built in just the right order with just the right versions of things. On many occasions I just gave up and kept the sources around for reference only (eg to look things up in the library code when the docs were fuzzy...). My perception is that this is improving with time. But it's still a big time investment. Certainly I don't expect to ever have the time to coax GHC to build from source on Solaris nowadays. -Jan-Willem Maessen
I agree with you, Daniel, that this is a terribly unfortunate state of affairs, but as has already been said, the folks who are doing the actual work (I ain't one of 'em) have decided that making ghc easier to bootstrap onto a supported platform is not a priority for them, they're content that virtually all ghc users should have to download prebuilt binaries, or source packages on platforms where devoted souls have built working automated builds.
-Bennett _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I think it should be if you want Haskell to grow in acceptance. The first barrier that new potential users hit is the one that causes most people to give up and move on to a different project. That first barrier should be made as low as possible.
Without commenting on any of the other points raised in this thread, I must agree with this. I am new to Haskell. I consider becoming proficient in Haskell programming a worthy goal in itself. However, making Haskell useful beyond an academic context is difficult because of the limitations you face with the tools, both in terms of installing and using those tools and the fact that some tools simply aren't available. I say this because I have been evaluating Haskell for use in my senior project. I need a stable and usable graphics toolkit for the project. While graphics toolkits for Haskell do exist, they are oftentimes either translations of other bindings that don't quite work, incompatible between platforms, limited in their utility, or in some cases, abandonware that represented the heroic effort of a lone programmer that disappeared when that programmer lost interest or moved on to other projects. I am not saying this to disparage the hard work of those who develop and maintain GHC and other Haskell compilers/runtime environments. That work is very much appreciated. And I can understand that people will become impatient when somebody expresses a sentiment in the form of "well, your product sucks so I'm going to use somebody else's". GHC is a good product. Haskell is not GHC or any particular implementation, although in the end, the utility of the platform can determine the success of the language. Python is easier to use because it has a larger standard API and considerable effort has gone into making it portable across many platforms. This may be a simple issue of resources, I don't know. It is my understanding that those who participated in creating and standardizing Haskell did so with the goal of reducing the proliferation of functional programming languages and creating a functional programming language that would combine "best practice" features and promote the use of this programming model in preference to the older imperative style. But at the end of the day, you have to be able to use it to do "stuff". A devotion to a good concept only goes so far if the second-best concept can get "stuff" done with a fraction of the effort. _________________________________________________________________ Dont just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/
On Mon, 2005-05-09 at 21:26 -0400, Mark Brooks wrote:
I say this because I have been evaluating Haskell for use in my senior project. I need a stable and usable graphics toolkit for the project. While graphics toolkits for Haskell do exist, they are oftentimes either translations of other bindings that don't quite work, incompatible between platforms, limited in their utility, or in some cases, abandonware that represented the heroic effort of a lone programmer that disappeared when that programmer lost interest or moved on to other projects.
May I direct your attention to two working, extensive, portable (with native look), actively developed Haskell GUI library bindings: Gtk2Hs: http://haskell.org/gtk2hs/ wxHaskell: http://wxhaskell.sourceforge.net/ Incidentally, both of these projects are quite mature and are nearing 1.0 releases. If you find any issue with either binding, I'm sure bug reports would be gratefully accepted. Duncan (disclaimer: Gtk2Hs developer)
participants (6)
-
Bennett Todd -
Daniel Carrera -
Duncan Coutts -
Jan-Willem Maessen -
Mark Brooks -
Simon Marlow