HOpenGL mailing list (?)
Is there any interest out there in creating a HOpenGL mailing list? Thanks, Andre W B Furtado
FranTk with ghc 5.00
Hi I'm trying to run the patched version of FranTk for ghc-4.06 with ghc-5.00. I used the fixes provided by Jan Kort for getting FranTk to work with ghc-4.08. This allows 'make boot' to succeed but produces errors at 'make all'. Are there any current fixes for running FranTk with ghc-5.00. Thanks Tuong ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
"S. Alexander Jacobson" wrote: > Great. So that is something that goes into some library conventions > document. Java has a convention that libraries should have reverse domain > name structure. Is that how we should use _? Yes, I think that could be the way. And in addition there should be some language libraries (just like Java has java.*). -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
Great. So that is something that goes into some library conventions document. Java has a convention that libraries should have reverse domain name structure. Is that how we should use _? -Alex- On Wed, 26 Sep 2001, Lennart Augustsson wrote: > "S. Alexander Jacobson" wrote: > > > On Wed, 26 Sep 2001, Manuel M. T. Chakravarty wrote: > > > > Given that Haskell98 is not ready for libraries anyway, why are you so > > > > concerned about it? > > > > > > It isn't? Why? Because of the lack of hierachical name > > > spaces? Then, C isn't ready for libraries either. > > > > As I posted in a prior thread: > > * Library namespace is broken > > So is C's, however it relies MUCH more strongly on build tools like > > Make. All popular languages that have been created in the last 20 years > > appear to have saner systems (Java, Perl, Python, etc). The problem is > > worse in Haskell because the number of built in libraries is very small > > and the code reuse goals are much more ambitious. > > Yes, the Library namespace is not ideal, and there has been a suggestion > to add `.' to module names to solve this. If we don't want to do that, just > use `_' as a name separator instead of `.'. This way you can build hierarchies. > > -- Lennart > > ___ S. Alexander Jacobson Shop.Com 1-646-638-2300 voiceThe Easiest Way To Shop (sm) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
"S. Alexander Jacobson" wrote: > On Wed, 26 Sep 2001, Manuel M. T. Chakravarty wrote: > > > Given that Haskell98 is not ready for libraries anyway, why are you so > > > concerned about it? > > > > It isn't? Why? Because of the lack of hierachical name > > spaces? Then, C isn't ready for libraries either. > > As I posted in a prior thread: > * Library namespace is broken > So is C's, however it relies MUCH more strongly on build tools like > Make. All popular languages that have been created in the last 20 years > appear to have saner systems (Java, Perl, Python, etc). The problem is > worse in Haskell because the number of built in libraries is very small > and the code reuse goals are much more ambitious. Yes, the Library namespace is not ideal, and there has been a suggestion to add `.' to module names to solve this. If we don't want to do that, just use `_' as a name separator instead of `.'. This way you can build hierarchies. -- Lennart ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Joy and Concatenative Programming
> [...] > SAJ> Joy differs from Haskell in that it has no variables. Instead, all > SAJ> functions are postfix, taking a stack as their argument and returning > SAJ> a stack as a result. > No, this is just a good old Forth programming language. It's a pity > that author of Joy even didn't mentioned Forth in his writings... SAJ told that Joy is functional. If I unterstood him correctly, he said functional languages eliminated state and Joy IN ADDITION TO THIS eliminated variables and environments. So there must be a important difference to Forth because AFAIK Forth didn't eliminate state. Of course the particular idea of transforming stacks is not new. > [...] Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: GUI Library Task Force
"S. Alexander Jacobson" wrote: > Haskell will not be production quality without concurrency. If concurreny > allows for a cleaner API and easier to use library, then use it. BeOS had > deep concurrency throughout and was a much better OS as a result. Its > 2001, there is no reason I shouldn't be able to have two threads drawing > things on the screen simultaneously. > > If the issue is that we still don't know how to do concurrency in > Hasskell, that seems like a MUCH higher priority than sorting out GUIs. May I add my vote of agreement. The concurrency abstractions in the GHC libraries are very fine indeed. However, a GHC thread calling into the non-Haskell world blocks all other threads until it returns, and experiment suggests that non-Haskell threads calling into the GHC world are unable to interact freely with other GHC threads. Forging a peer relationship between Haskell and non-Haskell threads would enable whole new classes of applications. For example, a Haskell thread could call into the OS and wait for the next GUI event, and a Haskell IO action could be registered with the OS for callback when certain GUI events occur. -- Tim Sauerwein / Galois Connections Inc. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: GUI Library Task Force
On Wed, 26 Sep 2001, Manuel M. T. Chakravarty wrote: > > Given that Haskell98 is not ready for libraries anyway, why are you so > > concerned about it? > > It isn't? Why? Because of the lack of hierachical name > spaces? Then, C isn't ready for libraries either. As I posted in a prior thread: * Library namespace is broken So is C's, however it relies MUCH more strongly on build tools like Make. All popular languages that have been created in the last 20 years appear to have saner systems (Java, Perl, Python, etc). The problem is worse in Haskell because the number of built in libraries is very small and the code reuse goals are much more ambitious. * Library Interfaces This is a much bigger issue for Haskell than C. Are they monadic and which monad and should they really be arrows but then they will rely on non-standard syntax, etc. > > A GUI system without concurrency is still incomplete. > > There are loads of large GUI-based applications out there > that don't use concurrency. > > BTW, my point was not to say that we rule out concurrency. > I said, we do not demand it. (Same as in many GUI libraries > for the most widespread imperative languages.) Haskell will not be production quality without concurrency. If concurreny allows for a cleaner API and easier to use library, then use it. BeOS had deep concurrency throughout and was a much better OS as a result. Its 2001, there is no reason I shouldn't be able to have two threads drawing things on the screen simultaneously. If the issue is that we still don't know how to do concurrency in Hasskell, that seems like a MUCH higher priority than sorting out GUIs. > > The haskell library interface story is still pretty weak because there is > > no consensus about what monad they should expose (and whether they should > > really expose arrows or something else). Why not focus on rolling from > > H98 into a production quality Haskell system and make the best GUI for > > that system? > > Currently, there doesn't seem to be much interest in going > for a completely new version of Haskell. The idea of adding > addenda to H98 and so slowly and in incremental steps move > to more functionality seems to be more popular. Thats great. I don't disagree. Its just a matter of priority. So how about this agenda? Addendum .5?: Parametrized Libraries Addendum 1: Hierarchical Library Namespace Addendum 2: Concurrency Addendum 3: FFI Addendum 4: Exceptions Addendum 4.5?: Proc Syntax for Arrows Addendum 5: Library Interface Compatibility Guidelines Addendum 6: Enumeration of standard Haskell libraries (GUI etc) If we could focus on converging these addenda rapidly and in a particular order, then Haskell could reach a much better place much more quickly. Many of these things are individually small changes from H98, but together they make it a much stronger language. -Alex- PS I don't know if this agenda is in the right order. I do think that everyone randomly thrashing about with different language features will make everything take much longer. ___ S. Alexander Jacobson Shop.Com 1-646-638-2300 voiceThe Easiest Way To Shop (sm) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: More GHC 5.02 binaries available
"Julian Seward (Intl Vendor)" <[EMAIL PROTECTED]> wrote, > The web site (http://www.haskell.org/ghc) now has final > binary builds for > >x86-Linux >sparc-solaris >Windows NT/2K/XP and allegedly 95/98/ME > > Additionally, the final source tarball is now on the web > page. I claim (and earnestly hope) it is suitable for > building other binary builds of 5.02. > >$ md5sum -b ghc-5.02-src-2.tar.bz2 >0bf8b670759240032c317fec6b02f59d *ghc-5.02-src-2.tar.bz2 Moreover, there are now binary RPM packages for x86/Linux built with RedHat 7.1 (for glibc 2.2): ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-5.02-1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-prof-5.02-1.i386.rpm ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/i386/ghc-doc-5.02-1.i386.rpm Note that a binary distribution now consist of *three* rpm packages. I decided to split off all pre-formatted documentation into the `ghc-doc' package. The preformatted documentation is also available online from the GHC Web page, so some people may decide not to install the documentation locally if they are short on disk space. The matching source RPM is at ftp://ftp.cse.unsw.edu.au/pub/users/chak/jibunmaki/src/ghc-5.02-1.src.rpm Cheers, Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: ANNOUNCE: Happy version 1.11
> ANNOUNCING Happy 1.11 - The LALR(1) Parser Generator for Haskell > - Owing to a rather embarrassing bug related to precedence parsing in the 1.11 release, I've uploaded new versions of the packages with the bug fixed. My apologies to anyone who already downloaded/installed 1.11 - please re-install with the updated packages. Cheers, Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
