RE: ghc/HopenGL/cygwin/W2K
Clifford In the next few days we'll release GHC 5.02. The Windows version of that will not require any version of cygwin; it comes complete, and you don't need to install anything else to make it work. (Nor does it mind if you have some version of cygwin installed, a surprisingly difficult criterion to satisfy, given Window's DLL story.) So I suggest you wait a few days. I do mean days and not weeks! (There is a slightly experimental Windows binary download you can try meanwhile; I enclose the message announcing it.) I'm not certain whether HOpen/GL has 'caught up' to GHC 5.02, but I'm sure it will shortly, and any differences will be of the trivial kind. Simon | -Original Message- | From: Clifford Beshers [mailto:[EMAIL PROTECTED]] | Sent: 14 September 2001 04:14 | To: [EMAIL PROTECTED] | Subject: ghc/HopenGL/cygwin/W2K | | | | | I'm trying to get to the point where I can use ghc and OpenGL | under Windows 2000. Unfortunately, I'm lost in a maze of | version numbers. | | I had cygwin-1.3.2 installed, I think, which did not match | the 1.3.1 used in the ghc-4.08 package. I tried to install | cygwin 1.3.1, but got 1.3.3 instead. Nowhere can I find a | course for 1.3.1. Nor can I find 5.00.2 compiled for | Windows, though there is some mention of W2K support in the | documentation. | | Can anyone provide me with a recent road map? I don't mind | compiling everything, if that's what it takes, I just feel | I'm wandering in the wilderness. | | Thanks, | | Clifford Beshers | | | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users | I've updated the test Windows InstallShield of GHCi 5.01 available from http://www.haskell.org/ghc/dist/5.00.2/ghc-5-01.exe (There's no link to it on the web site) In case you missed the previous announcement, this is a test release, but seems fairly stable (I use it all the time). It has the following features: * GHCi: now you can use GHC interpretively under Windows. You can just run the InstallShield, and double-click on GHCi to get going. * Complete install: everything you need to use GHC is included; Cygwin is no longer required; also, unlike recent 4.08.2 releases, it doesn't interfere with any Cygwin installation you may already have Changes from the previous test release, Zarjaz: * Now installs in Program Files by default (supports paths containing spaces). * Installs the profiling libraries and imports (the previous test release included them, but for mysterious reasons they weren't actually installed). Also note that as one user found, the supplied gcc doesn't like identifiers containing top-bit-set characters, so if you want to use them you must use the native code generator. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Confused by profiling
On Thu, Sep 13, 2001 at 06:42:52PM +0100, Ian Lynagh wrote: p_aexp_list Parser 00.0 0.0 0.0 0.3 [...] Now basically my problem is how things under p_aexp_list can be entered 896 times if p_aexp_list is entered 0 times - am I reading it wrong? [...] And the only place p_aexp_list is called from is Aha, I think I might have worked this out. As far as I can tell p_aexp_list is being evaluated once and being brought up the chain with it's single evaluation being attributed to CAF, and subsequent calls do not then need to evaluate it but do need to evaluate it's children. Ian, off to see if I can extract useful information from it now ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
I WILL TEACH YOU TO HAVE SEX - MY CAN IS ON FOR YOU
Below is the result of your feedback form. It was submitted by ANNA ([EMAIL PROTECTED]) on Friday, September 14, 2001 at 18:47:37 --- message: Hello my friend My cam is always on for you.for your sex I cannot forget all the words that you told me last saturday while my wet pussy was open for you. Now you can connect to my CAM directly from my home page http://www.freebox.com/livesex I will teach you how to do. I have a new software for that. You'll find me nude waiting you. Don't leave me alone without you Anna --- ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Application letters at the Haskell workshop: suggestion
Alastair David Reid wrote: | existential types, functional dependencies, other | experimental-but-apparently-crucial features [...] : | I do use the IO monad, IORefs (sparingly), constructor | classes, lots of libraries, the foreign function | interface (lets you call C and C++), parser generators | (happy) and parser combinators, exception handling and | concurrency (even just the lame non-preemptive version | that Hugs provides). One small point here: many libraries use experimental features in their implementation. Many efficient parsing combinator libraries for example rely on some kind of continuation monad, which often needs existential types to be implemented. /Koen. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
Fri, 14 Sep 2001 01:00:06 +0200, Lennart Augustsson [EMAIL PROTECTED] pisze: I have been writing substantial Haskell programs and I use *NO* experimental features. In a 2000-line interpreter I used: - FiniteMap (for environments), - Dynamic Exception (for exceptions in the language being implemented and compile errors), - MonadReader, MonadError (for convenience, in two places), - MVar (could be IORef; for mutable objects in the language being interpreted), - unsafePerformIO (for three global variables: unique supply, loaded modules, search paths), - Readline (for the interactive toplevel). -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
On Friday, 14. September 2001 04:38, you wrote: [...] wxWindows is quite C++ centric and AFAIK nobody has made a serious effort at a C++ FFI yet. One of the big advantages of GTK+ is that it was written with bindings for other languages in mind. Therefore, it is probably the toolkit with the most language bindings. I didn't mean that a Haskell binding to wxWindows should be made. I meant that the strategy of wxWindows should be used also for a Haskell GUI library. This strategy is to define a common GUI interface and provide implementations for different platforms based on different libraries like GTK+ (for GNOME), Qt (for KDE), Win32. By the way a Haskell binding to wxWindows would maybe cause performance problems just because wxWindows isn't native but itself uses other GUI libraries. Wolfgang ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
As such, I would like to see a focus on making Haskell great for web application and web service development. Right. On the server side, this is easy (and people have done it, see the example HTML server, and I've used it to code up a game server, used for a students' programming contest here (*)). I would love to see Haskell used on the client side, that is, I want Haskell applets. This would probably require that the user downloads Hugs as a netscape-plugin? Or ghc emits Java (byte-)code? And in both cases: what GUI should we use? In case you wonder - this application is purely academic: the applets should help my students to understands certain concepts in theoretical computer science. Of course I would then welcome their questions on how did you program this... (for an example, see the PCP Puzzle http://www.informatik.uni-leipzig.de/~pcp/ but that is a Java program. I want to program exactly this kind of applet in Haskell!) (*) the server itself runs fine, but the Java applet to play/display games http://theopc.informatik.uni-leipzig.de/~connect/ currently is broken :-) -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/252 -- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
I would love to see Haskell used on the client side, that is, I want Haskell applets. I know of one Haskell applet running on the internet. This would probably require that the user downloads Hugs as a netscape-plugin? Or ghc emits Java (byte-)code? And in both cases: what GUI should we use? There are proposals for java byte-code backends for ghc. However, there are currently no concrete products implementing such a backend. I know three links to papers in this area, the last one coming with a Haskell applet example. D. Wakeling wrote three papers which are available at http://www.dcs.ex.ac.uk/~david/en/research/previous/java/ Martijn de Vries wrote a paper which is at http://www.i2x.com/~martijn/ Alessandro Vernet wrote an article and a backend, but he mailed me he lost the backend due to a computer crash. http://www.scdi.org/~avernet/projects/jaskell/ Still, he has one haskell-applet (having the algorithm written in Haskell and the GUI written in Java) which survived the crash. It is running at http://www.scdi.org/~avernet/projects/jaskell/queens/ Rijk-Jan ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: The future of Haskell discussion
| wxWindows is quite C++ centric and AFAIK nobody has made a | serious effort at a C++ FFI yet. One of the big advantages | of GTK+ is that it was written with bindings for other | languages in mind. Therefore, it is probably the toolkit | with the most language bindings. The lack of any way to interface to C++ is a problem, IMO. I would love to be able to write Haskell programs using Qt and ultimately the KDE libraries, both of which are C++, but I can't, at the mo. J ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
Fri, 14 Sep 2001 02:09:21 -0700, Julian Seward (Intl Vendor) [EMAIL PROTECTED] pisze: The lack of any way to interface to C++ is a problem, IMO. I would love to be able to write Haskell programs using Qt and ultimately the KDE libraries, both of which are C++, but I can't, at the mo. I think it should be easy to add support for C++, except exceptions. There are two approaches: call C++ functions directly (it requires implementing name mangling by the Haskell compiler; there are several name mangling schemes and gcc changed its scheme in version 3.0) or write C wrappers (this is inconvenient but is doable now without compiler support). An annoyance is that templates can't be called directly but each instance must be imported separately. On Linux it works when main() of a mixed C/C++ program is written in C. AFAIK it doesn't work everywhere. Nevertheless an example I've now made worked. hsc2hs and ghc need to be extended to make it work smoothly. hsc2hs produces a file with extension .c and ghc compiles these files by passing -x c options to the C compiler, so even if a C++ compiler is substituted, it is compiled as C. There should be a switch in hsc2hs to let it produce C++ and ghc should recognize .cc extension, or in some other way ghc should be informed that the .c file is really C++. Option -pgmlg++ causes ghc to link using g++; option -lstdc++ instead also works. And hsc2hs should be taught about extern C. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
As a general question (and forgive my ignorance): are the various ffi's implemented using something like `dlopen' or are they done by actually putting suitable stubs into the Haskell generated C-code which then gets compiled by the C compiler as part of the overall haskell compilation? On 14 Sep 2001, Marcin 'Qrczak' Kowalczyk wrote: I think it should be easy to add support for C++, except exceptions. There are two approaches: call C++ functions directly (it requires implementing name mangling by the Haskell compiler; there are several name mangling schemes and gcc changed its scheme in version 3.0) or write C wrappers (this is inconvenient but is doable now without compiler support). I suspect that there's several different levels of C++ interface; here's mty personal taxonomy (which other people may disagree with :-) ) : (1) Firstly there's calling code where the interface is basically C but compiled with C++; at this level there's the issue of name mangling (accounting for both for argument structure and namespace effects) and any global stuff in the C++ code (e.g., ensuring global objects construction/destruction happens at times that are ok). (2) Then there's being able to invoke the method of an object without caring about moving `inside object' information back in to haskell (e.g., calling the colour_segment() member of an object of the Image class). Here the object is essentially just acting as a `struct with attatched function pointers'. (3) Then there's being able to actually use objects more fully via a Haskell type/type-class wrapper of some sort (so that for example objects of C++-class X_cpp with a member function string show(void) const could be used in, e.g, display :: [X_haskell] - IO() display = sequence (map (putStr.show)) Obviously this throws up issues of the semantics that need to be solved (e.g., can I only use const member functions, or can I use them all providing I embed the object in a monad?) and is (I imagine) a heavy research and implementation project. (4) Finally there's being able to propagate C++ exceptions into Haskell, using either Haskell exceptions or some other representation. (This is clearly incredibly hard, but I belive some package (forget which) manages to propagate C++ exceptions into Python exceptions.) From my limited understanding, the really nice bits about the KDE framework (e.g., embedding application objects inside others) would require at least level (3) and possibly even (4). An annoyance is that templates can't be called directly but each instance must be imported separately. Indeed, with a potential additional problem: many template functions are written as inlines in header files, so that if I try and use a template function I wrote years ago in a .cc file containing a C++ class I defined yesterday I silently get the correct code compiled into the new .o file. If I try to `glue' together a template function and a new C++ type (where they haven't been used together otherwise) where does the new instantiation go; do I have to go around adding explicit instatantiation requests in the C++ source? On Linux it works when main() of a mixed C/C++ program is written in C. AFAIK it doesn't work everywhere. Nevertheless an example I've now made worked. hsc2hs and ghc need to be extended to make it work smoothly. hsc2hs produces a file with extension .c and ghc compiles these files by passing -x c options to the C compiler, so even if a C++ compiler is substituted, it is compiled as C. There should be a switch in hsc2hs to let it produce C++ and ghc should recognize .cc extension, or in some other way ghc should be informed that the .c file is really C++. Option -pgmlg++ causes ghc to link using g++; option -lstdc++ instead also works. And hsc2hs should be taught about extern C. All these are useful things; however I'm just pointing out that there's various degrees of interoperation with C++. My personal position at the moment is that I want to be able to use the level 1 facilities above with minimal effort (and to be able to call in to Haskell from C++, but that's another story) for program development purposes. If there's any coding that better informed people can suggest to make interfacing with C++ easier I can try and help with it, but unfortunately (1) I'm unreliable; (2) I can't justify doing development on interfacing C++-Haskell as part of my job so it'd only be during my very scarce free time; (3) did I mention I'm incredibly unreliable? ___cheers,_dave www.cs.bris.ac.uk/~tweed/pi.htm |tweed's law: however many computers email: [EMAIL PROTECTED] | you have, half your time is spent work tel: (0117) 954-5250 | waiting for compilations to finish. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
JPBernède/Haskell/Question about Sgbd Connexion
Hello, I would like to know how can-I mapping Haskell program with a database (for example Oracle). and How can-I encapsulate the request ina O'Haskell Object ? Thanks for your response. Kind regardsJean-Pierre Bernède (Paris - France).
Re: The future of Haskell discussion
S. Alexander Jacobson [EMAIL PROTECTED] wrote, Out of curiosity, how does GTK+ compare with Fruit? GTK+ has a C API heavily based on call backs and mutable state. Thus, the Haskell transcription of that API heavily relies on the use of the IO monad - as does H98 textual IO. It seems like it would make sense for the standard Haskell GUI also to be functional. A functional GUI would be nice, but standard Haskell text and file I/O is not functional either. Functional GUIs like Fruit are from a research perspective very interesting, but their design is rather far from being a solved problem, which makes them a not very likely candidate for a standard that people seem to like to have sooner rather than later. Cheers, Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
Mark Carroll [EMAIL PROTECTED] wrote, On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote: (snip) wxWindows is quite C++ centric and AFAIK nobody has made a serious effort at a C++ FFI yet. One of the big advantages (snip) Of course, wxPython also exists - I assume that the emphasis on object orientation is the problem? Also, the lack of a static type system makes it easier to embed foreign APIs into Python. Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
At 09:58 14-9-01 +0200, Wolfgang Jeltsch wrote: I didn't mean that a Haskell binding to wxWindows should be made. I meant that the strategy of wxWindows should be used also for a Haskell GUI library. This strategy is to define a common GUI interface and provide implementations for different platforms based on different libraries like GTK+ (for GNOME), Qt (for KDE), Win32. This strategy has been followed by the pilot project that has been described in [1]. In this project we have ported a crucial subset of the Clean Object I/O library to Haskell. The Clean Object I/O library is used for major projects such as the Clean IDE and the Clean theorem prover SPARKLE by Maarten de Mol. The pilot port has been done on a Windows platform, so that we could reuse the primitive implementation layer. To port it to a more Unix friendly environment, I guess Manuel Chakravarty's GTK binding library is very well suited. You can find the results from the pilot project in the GHC CVS repository at fptools/hslibs/object-io The current state of affairs is due to severe lack of time a little unsatisfactory... To make this project manageable, it would be good to have some kind of automatic translator (nothing fancy, just a specialised translator from Clean Object I/O to Haskell Object I/O would do) that will derive the Haskell version from the Clean version that I do maintain. I haven't had time yet to make such a tool. Regards, Peter Achten -- [1] Peter Achten and Simon Peyton Jones, Porting the Clean Object I/O Library to Haskell, in Mohnen, M. and Koopman, P. (eds) Proceedings of 12th International Workshop Implementation of Functional Languages, IFL2000, Aachen, Germany, September 2000, Selected Papers, Springer, LNCS 2011, pp. 194-213. ftp://ftp.cs.kun.nl/pub/Clean/papers/2001/achp2001-HaskellObjectIO.ps.gz ftp://ftp.cs.kun.nl/pub/Clean/papers/2001/achp2001-HaskellObjectIO.pdf ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 14 September 2001 12:52 pm, Marcin 'Qrczak' Kowalczyk wrote: I think it should be easy to add support for C++, except exceptions. There are two approaches: call C++ functions directly (it requires implementing name mangling by the Haskell compiler; there are several name mangling schemes and gcc changed its scheme in version 3.0) or write C wrappers (this is inconvenient but is doable now without compiler support). An annoyance is that templates can't be called directly but each instance must be imported separately. I understand that you ought to deal with name mangling at some stage, but how would the interfaces ultimately look like? Say, for instance virtual functions, classes, sub classes, constructors, destructors? If you can do non-template C++, then it wouldn't be difficult to call template code. Just do an explicit instantiation of the template code in an auto-generated .cxx file. What's the problem there? On Linux it works when main() of a mixed C/C++ program is written in C. AFAIK it doesn't work everywhere. Nevertheless an example I've now made worked. It's about the linker used I guess. You should be able to do that. hsc2hs and ghc need to be extended to make it work smoothly. hsc2hs produces a file with extension .c and ghc compiles these files by passing -x c options to the C compiler, so even if a C++ compiler is substituted, it is compiled as C. There should be a switch in hsc2hs to let it produce C++ and ghc should recognize .cc extension, or in some other way ghc should be informed that the .c file is really C++. Option -pgmlg++ causes ghc to link using g++; option -lstdc++ instead also works. And hsc2hs should be taught about extern C. Writing another such translator would be necessary. After all, C++ is another language. It would be quite tricky to do that. It's halfway writing a C++ front-end, and would require an amount of deep magic. Even a standard conformant parser alone is quite difficult. Anybody give it a shot? :) Thanks, - -- Eray Ozkural (exa) [EMAIL PROTECTED] Comp. Sci. Dept., Bilkent University, Ankara www: http://www.cs.bilkent.edu.tr/~erayo GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE7ohx4fAeuFodNU5wRAlF9AKCnpE7xO3QzI8qeqih9coifE0Td4wCfT+gj aOKIFCV6yu1XEB4oUHmGvI8= =UR1s -END PGP SIGNATURE- ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
Manuel M. T. Chakravarty wrote: Maybe it should be clarified that there are exceptions in H98, but *only* in the IO monad. What the extension is about are exceptions in pure functions. Further clarification: the extension allows you to _raise_ exceptions in pure functions, but you may only catch them in the IO monad. This asymmetry is very important for Haskell, since otherwise evaluation order would be observable. This would break many important equalities and render almost any optimizations unsafe (i.e., GHC would be crippled). ML allows one to catch exceptions in pure functions with impunity, and can do so because evaluation order is fixed. The story is similar for imperative languages. A further extension to this exceptions mechanism allows one to catch asynchronous exceptions (e.g., interrupts or UNIX signals) in the IO monad, and to signal (or raise an asynchronous exception in) other threads. There are also scope-based operators block and unblock which, given a computation, perform it with asynchronous exceptions blocked/unblocked respectively. They may be nested arbitrarily. I believe GHC is the only system with this extension implemented thus far, but there are rumours of Hugs not being far behind (I'm looking at you, Alastair David :-) The exceptions mechanisms would certainly benefit from an addendum. Cheers, Andy -- Andy Moran Ph. (503) 526 3472 Galois Connections Inc. Fax. (503) 350 0833 3875 SW Hall Blvd. http://www.galconn.com Beaverton, OR 97005 [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
On Fri, 14 Sep 2001 [EMAIL PROTECTED] wrote: (snip) Further clarification: the extension allows you to _raise_ exceptions in pure functions, but you may only catch them in the IO monad. This asymmetry is very important for Haskell, since otherwise evaluation order would be observable. This would break many important equalities and render almost any optimizations unsafe (i.e., GHC would be crippled). ML allows one to catch exceptions in pure functions with impunity, and can do so because evaluation order is fixed. The story is similar for imperative languages. (snip) For the sort of exception where the function you're calling either returns successfully or throws an exception, I'm not sure why things can't be done entirely referentially transparently. One would do it in just the same way that something might return a 'Succeeded a' or 'Exception String' or something as aspects of an algebraic data type. The function, whenever it does something that might cause an exception, if it gets a 'Succeeded a' returned it goes ahead and returns something based on the a, or else it returns the Exception String, except if there's a 'catch' which specifies some other value to return if there was an exception. Basically, such simple exceptions can have a 'try', 'catch' construct simply being syntactic sugar around existing Haskell using algebraic types, pattern matching and 'if' statements, so I don't see why monads need to be brought in. Evaluation is done exactly as usual - when you decide to do something predicated on whether or not there was an exception thrown, we evaluate enough to find out if an error condition happened. However, there is a lot I don't know about Haskell! I assume you're talking about some more exciting sort of exception, like things with multiple threads or something, and I'm thinking of something more simplistic (but adequate for my immediate needs, which are currently being served with lots of ifs and Maybes!). -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Fwd: Application letters at the Haskell workshop: suggestion]
[ Meant for this to go to the mailing list ... ] -- Andy Moran Ph. (503) 526 3472 Galois Connections Inc. Fax. (503) 350 0833 3875 SW Hall Blvd. http://www.galconn.com Beaverton, OR 97005 [EMAIL PROTECTED] Mark Carroll wrote: For the sort of exception where the function you're calling either returns successfully or throws an exception, I'm not sure why things can't be done entirely referentially transparently. One would do it in just the same way that something might return a 'Succeeded a' or 'Exception String' or something as aspects of an algebraic data type. The function, whenever it does something that might cause an exception, if it gets a 'Succeeded a' returned it goes ahead and returns something based on the a, or else it returns the Exception String, except if there's a 'catch' which specifies some other value to return if there was an exception. Exceptions can be encoded in this way, and for a while this was the only way to have exceptions in Haskell (modulo monadic presentations, etc.). But what about division by zero? It can easily be encoded in the above style: Exception Division by Zero. But now _every_ function that can raise or wants to handle this exception must be rewritten so that it either wraps correct results with Succeeded, wraps exceptional results with Exception, and passes exceptional results upwards. The point of the exceptions extension is that you don't need to change anything; existing code (even that which may cause a division by zero error) remains as it is. And we can raise exceptions of our own anywhere. The tradeoff is that we can catch these exceptions in the IO monad. But we can extend the extension to handle asychronous exceptions (which don't admit this kind of encoding, AFAIK). Cheers, Andy -- Andy Moran Ph. (503) 526 3472 Galois Connections Inc. Fax. (503) 350 0833 3875 SW Hall Blvd. http://www.galconn.com Beaverton, OR 97005 [EMAIL PROTECTED]
Re: Application letters at the Haskell workshop: suggestion
I may as well send my reply to the list too, then! (-: On Fri, 14 Sep 2001 [EMAIL PROTECTED] wrote: Mark Carroll wrote: (snip) Oh, certainly, but couldn't the compiler do all the rewriting for you, though, so existing code would still work and new code would still look nice? I'm not sure how this would interact with type inference; what's the difference between a function that I mean to be rewritten and one that I don't? Perhaps what you're wanting is that every type implicitly has an exception constructor tacked on. This is in effect what one gets with the exception extension. Yes, I suppose you're correct, although I'd add that I'd expect that the compiler could often do lots of optimisation so that it only needs to check for the exceptional condition when checking the result of a function from which exceptions can arise, and in that case it can go right up to the handler, so in practice I bet that you could implement this without every single calculation being tainted by such overhead even though there's no semantic difference. (Although, the main point of my Succeeded/Exception example is just to show that for much exception stuff monads needn't be necessitated.) I'm not sure what you mean here. For hand-written exception code, monads make the code easier to read in most cases. But I don't think you mean that; it sounds like you mean exceptions can be expressed already, so there's no need for new stuff. I don't buy that in general (since otherwise, why not just use the raw lambda calculus, or Turing machines), or in this specific case, since the encoding is a lot of work, and needs to be done for almost everything you might use (including things one usually doesn't have access to, like the Prelude and library code). But maybe you don't mean that. I sort of do mean that, with the compiler doing the work you mention. There would be new stuff in how the throws/catch stuff the programmer would write would interact with how the compiler would implement the synchronous exceptions, but it would look reasonable to the programmer and not require them to catch such exceptions from within monads. (snip) Well, if you can deal with only catching in the IO monad, then what you want is avilable now, with the extension (GHC only at the moment I think). Otherwise, you're stuck encoding it. Now, you may well be able to structure your code better if you employed an exception monad (not the IO monad, just an ordainary monad), or perhaps a continuation monad. (Aside: it seems as though you're lumping general monads, usable anywhere without affecting the rest of the program, together with the IO monad, which is the top-level put-impure-things-here monad. It's important to see that there's a difference. I apologise if you do; if you don't, feel free to ask probing questions.) (-: Really, I just want to be able to use exceptions that behave more or less as I've suggested without having to catch them from within monads. It would indeed be especially irritating to have to catch them all within the IO monad, as I would now if I wasn't doing the ugly manual encoding that I currently have to that I figure could easily be done behind the scenes with some much nicer syntactic sugar on top. I may not understand monads enough, though. I think of them being inextricably linked with actions, probably sequenced ones, and I'm wanting to use exceptions in purely declarative code where actions shouldn't be relevant concept. Perhaps I should be writing this code in a monadic style, though, and thinking in terms of actions. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
Fri, 14 Sep 2001 18:04:24 +0300, Eray Ozkural [EMAIL PROTECTED] pisze: I understand that you ought to deal with name mangling at some stage, but how would the interfaces ultimately look like? It depends how sophisticated tools we create. The easy step is to wrap everything in functions. They would be C functions for the moment. For example a plain method would be wrapped in a C function with 'this' as one of arguments. With C++ support in the Haskell compiler it can be more convenient for overloaded functions and even non-virtual methods. Unfortunately for calling a virtual method or getting a field out of a struct/class it's not enough to supply what the programmer sees (function name and types involved) to generate the code; the object layout matters. Currently ghc doesn't deal with C/C++ object layout at all, and I imagine it would be very hard for it to do this (how to interpret a C++ header?). OTOH tools like hsc2hs and c-hs can support this; they already can handle C struct fields. I think calling a virtual method requires creating a function wrapper, but tools should cope with this in future. If you can do non-template C++, then it wouldn't be difficult to call template code. Just do an explicit instantiation of the template code in an auto-generated .cxx file. What's the problem there? Usually it should not be a problem, because arbitrary Haskell objects can be represented only as something like StablePtr in C++, so templates working on Haskell objects don't need many instantiations. But a sophisticated cooperation between Haskell and C++ should probably create custom C++ classes for wrapping different kinds of Haskell objects, and then clients of a Haskell interface to a C++ library must instantiate templates themselves. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Application letters at the Haskell workshop: suggestion
Fri, 14 Sep 2001 12:10:27 +1000, Manuel M. T. Chakravarty [EMAIL PROTECTED] pisze: Maybe it should be clarified that there are exceptions in H98, but *only* in the IO monad. What the extension is about are exceptions in pure functions. BTW, Exceptions are useful for something other than Haskell 98 I/O primitives only when combined with Dynamic. Haskell 98 Exceptions are limited like errno in C. -- __( Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
Hello, Probably this question has been brought before. Besides the Preludes, why doesn't Haskell have libraries like Java, Squeak (Smalltalk). I found this: http://www.cit.gu.edu.au/~arock/hlibs/ Please take a look at .pdf files. Also I remember there was a Russian (actually Georgian) guy who wrote a paper and Haskell as a proposal for a computer algebra library. In the insuing discussion did his computer algebra come to nothing? Regards, Bill HalchinGet your FREE download of MSN Explorer at http://explorer.msn.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
On Fri, 2001-09-14 at 15:12, Mark Carroll wrote: On Fri, 14 Sep 2001, Bill Halchin wrote: Probably this question has been brought before. Besides the Preludes, why doesn't Haskell have libraries like Java, Squeak (Smalltalk). I found this: (snip) I'm puzzled - it does! - see http://www.haskell.org/libraries/ for some of them. I think the question is more along the lines of Why doesn't Haskell come bundled with complete, useful and _supported_ libraries? For example, the Edison home page describes the library in this way: in its current state, the library is mostly a framework. That is, I provide signatures, but not yet very many implementations... This is not the type of thing that your standard software engineer wants to hear. Professional software developers need to be highly productive, and are often unwilling to invest time learning libraries that aren't part of the core language environment. However you feel about the design of the Java Collections API, at least it's a supported part of the language. Developers feel comfortable that any time spent learning the how to use these APIs is worthwhile. I felt this very recently when looking for a quality GUI framework for Haskell. There appear to be many(!) libraries available, and all seem to be in various states of completion. Personally, I would like to see someone complete the port of the Clean library that was attempted, as that library seems to have been pretty battle-tested, and there are lots of good, real-world examples. That, I suppose, is the key point. Whatever libraries are chosen for final inclusion in the Haskell environment, they should be treated as integral to the language experience. Extensive documentation and examples should exist, perhaps of book length (I really liked Hudak's text for this reason, and only wish that it had been written with the standard Haskell GUI libs). Finally, any libraries should be beaten upon to such an extent that there is a solid guarantee that they are safe for production use. Thoughts? - j -- Jeffrey Palmer Curious Networks, Inc. http://www.curiousnetworks.com e: [EMAIL PROTECTED] ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
If the GUI is based on the IO monad, then it doesn't seem like there is a lot of advantage to doing it in Haskell. It seems like a better idea to use a more natural language for IO and make RPC/interproc calls to a haskell server to get stuff done. In other words, what is the value of the GTK+ haskell interface? Shouldn't more effort be put into getting Fruit production quality and/or figuring out how to use arrows to manage textual and network IO? -Alex- ___ S. Alexander Jacobson Shop.Com 1-646-638-2300 voiceThe Easiest Way To Shop (sm) On Fri, 14 Sep 2001, Manuel M. T. Chakravarty wrote: S. Alexander Jacobson [EMAIL PROTECTED] wrote, Out of curiosity, how does GTK+ compare with Fruit? GTK+ has a C API heavily based on call backs and mutable state. Thus, the Haskell transcription of that API heavily relies on the use of the IO monad - as does H98 textual IO. It seems like it would make sense for the standard Haskell GUI also to be functional. A functional GUI would be nice, but standard Haskell text and file I/O is not functional either. Functional GUIs like Fruit are from a research perspective very interesting, but their design is rather far from being a solved problem, which makes them a not very likely candidate for a standard that people seem to like to have sooner rather than later. Cheers, Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
If the GUI is based on the IO monad, then it doesn't seem like there is
a lot of advantage to doing it in Haskell. It seems like a better
idea to use a more natural language for IO and make RPC/interproc calls
to a haskell server to get stuff done.
In other words, if you use the IO monad, you're going to have the same
programming experience (only more verbose) as a C/C++/Java programmer?
I don't think that's true.
My graphics library (http://haskell.org/graphics/) uses the IO monad
for manipulating windows and the Draw monad for doing graphics but
both feel quite different from similar code I've written in C (and, I
believe, from C++ or Java code).
In the case of manipulating windows, the different feel comes from
using concurrency to hide the event loop and from using layers of
abstraction to hide the full power (and horror) of the X and Win32
programming models.
In the case of the Draw monad (which is identical to the
IO monad except that it carries a device context around as an
implicit parameter), the different feel comes from aggressive
use of continuations (actually, they're not quite continuations
but I don't have a better word for them). For example, you might
normally write code like this:
do
old_color - selectColor blue
old_font - selectFont helvetica
write_text Hello World
selectFont old_font
selectColor old_color
(Reselecting the old color and font at the end is recommended Win32
programming style.)
In the HGL, you instead write:
setPicture window (withColor blue (withFont helvetica (text Hello World)))
or, equivalently but allegedly easier to read,
setPicture window$
withColor blue $
withFont helvetica $
text Hello World
where withColor and withFont are defined like this:
withColor :: Color - Draw a - Draw a
withColor c m = do{ old - selectColor c; a - m; selectColor old; return a }
withFont :: Font - Draw a - Draw a
withFont f m = do{ old - selectFont f; a - m; selectFont old; return a }
and setPicture exploits the fact that an object of type Draw a is a
first class object which can be stored in the window state and
executed when appropriate (e.g., when the window is uniconified).
What I'm saying is that Haskell's standard abstraction facilities mean
that even in the IO monad your programming experience can
significantly better than that of a C programmer. (Of course your
experience can also be worse if you don't or can't bring Haskell's
strengths to bear on your problem.)
--
Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: The future of Haskell discussion
On 14 Sep 2001, Jeffrey Palmer wrote: (snip) [ good stuff ] Thoughts? A shortage of volunteers? I get the impression that there's a reasonable consensus on what needs to be done; it's just that too few of us have the time and expertise to execute it. -- Mark ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
