Re: 64-bit windows version?
skaller wrote: On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote: Bulat Ziganshin wrote: Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? The main thing standing in the way of this is the lack of a 64-bit port of mingw. Why do you need mingw? What's wrong with MSVC++? We have talked (extensively) about doing a Windows port using the MS tools instead of mingw. Check the archives of cvs-ghc, search for windows native. There's no problem in theory, but it's a lot of work. Peter Tanski has done some work in this direction, he should be able to tell you more. I don't think we'll be able to drop the mingw route either, mainly because while the MS tools are free to download, they're not properly free, and we want to retain the ability to have a completely free distribution with no dependencies. There are people that want a Cygwin port too; personally I think this is heading in the wrong direction, we want to be more native on Windows, using the native object format and interoperating directly with the native Windows tools. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
Bulat Ziganshin wrote: Hello skaller, Tuesday, June 19, 2007, 8:15:19 PM, you wrote: are you plan to implement 64-bit windows GHC version? Why do you need mingw? What's wrong with MSVC++? really! Simon, how about unregisterised build? Unregisterised would still need a C compiler capable of generating 64-bit code. Are you talking about using the MS compiler for that? Certainly possible, but I'm not sure why you'd want to do it - you'd end up with much slower code than running the 32-bit compiler. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to use qualified name ModuleName.(.!.) ?
Marc Weber [EMAIL PROTECTED] wrote: print $ M.(.!.) [1,2] 1 -- (2) The parens must enclose the whole varop: print $ (M..!.) [1,2] 1 -- (2) Regards, Malcolm ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On Wed, 2007-06-20 at 08:49 +0100, Simon Marlow wrote: I don't think we'll be able to drop the mingw route either, mainly because while the MS tools are free to download, they're not properly free, and we want to retain the ability to have a completely free distribution with no dependencies. I'm not sure I understand this. MS tools are free to download by anyone, but not redistributable. The binaries needed by programs *built* by those tools are not only free to download, they're free to redistribute, and they're less encumbered than almost all so-called 'free software' products. Don't forget -- Windows isn't a free operating system. You're juggling some possible problem with a single source vendor withdrawing supply (possible) against open source products which are late to market (definite :) 64 bit Mingw .. will already be years out of date when it turns up, since MS is focusing on .NET platform. MSVC++ tools already support CLR, assemblies and .NET: even if Mingw supported that .. you'd still need Mono (does it work, really?) for a 'free' platform .. but .NET is redistributable and available on most modern Windows platforms already .. I doubt the Open Source community is as reliable a supplier for the Windows market as Microsoft. It's really a boutique market. Cygwin was a major platform in the past, for running Unix software on Windows. But now we're talking about a Windows *native* version of GHC, there's no Unix in it. I see no real reason not to build for the native toolchain .. and plenty of reasons not to bother with others. Hmm .. can't MS be coaxed into supplying some support to the developers? After all, Haskell IS a major lazily evaluated statically typed functional programming language. Why wouldn't MS be interested in bringing GHC on board? They have an Ocaml (called F#) now.. -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
skaller wrote: On Wed, 2007-06-20 at 08:49 +0100, Simon Marlow wrote: I don't think we'll be able to drop the mingw route either, mainly because while the MS tools are free to download, they're not properly free, and we want to retain the ability to have a completely free distribution with no dependencies. I'm not sure I understand this. MS tools are free to download by anyone, but not redistributable. The binaries needed by programs *built* by those tools are not only free to download, they're free to redistribute, and they're less encumbered than almost all so-called 'free software' products. The binaries needed by programs built by these tools..., you're referring to the C runtime DLLs? Why does that matter? Note I said with no dependencies above. A Windows native port of GHC would require you to go to MS and download the assembler and linker separately - we couldn't automate that, there are click-through licenses and stuff. Hmm .. can't MS be coaxed into supplying some support to the developers? After all, Haskell IS a major lazily evaluated statically typed functional programming language. Why wouldn't MS be interested in bringing GHC on board? They have an Ocaml (called F#) now.. MS pays for Ian Lynagh, who works full time on GHC as a contractor. MS puts roughly as much money into GHC as it does into F#, FWIW. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
Hi I'm not sure I understand this. MS tools are free to download by anyone, but not redistributable. The binaries needed by programs *built* by those tools are not only free to download, they're free to redistribute, and they're less encumbered than almost all so-called 'free software' products. The binaries needed by programs built by these tools..., you're referring to the C runtime DLLs? Why does that matter? Note I said with no dependencies above. A Windows native port of GHC would require you to go to MS and download the assembler and linker separately - we couldn't automate that, there are click-through licenses and stuff. I don't compile GHC on Windows, as its kind of annoying to do, and the binaries are usually sufficient for my needs. Typically MS tools are well packaged and even if there is a click through license, it usually involves checking a box and clicking next. I can't believe that anyone is going to have any difficulty installing Visual Studio express. Compare this to Cygwin/Mingw where the packaging is frankly awful, and makes my head hurt every time I have to install it. I'm looking forward to having GHC built with Visual Studio, but I can understand why its not a priority - the advantages are relatively minimal. What I keep hoping is that Microsoft will put some serious thought into debugging Haskell - the MS tools for debugging blow away everything else. (I realise a start is being made in GHCi, and am looking forward to the end results!) Thanks Neil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On Wed, 2007-06-20 at 14:42 +0100, Simon Marlow wrote: The binaries needed by programs built by these tools..., you're referring to the C runtime DLLs? Why does that matter? Note I said with no dependencies above. A Windows native port of GHC would require you to go to MS and download the assembler and linker separately - we couldn't automate that, there are click-through licenses and stuff. So what? Felix requires: (a) C/C++ compiler (b) Python (c) Ocaml you have to download and install these tools on ANY platform, including Ubuntu Linux. gcc isn't installed on a basic system. True, with Debian, this can be automated, so you only have to click on the main package. I need THREE external tools. Is this a pain? YES! [On Windows .. it's a breeze on Ubuntu .. :] Is it too much effort to ask, for someone to use a major advanced programming language like Haskell? Don't forget .. Mingw has to be installed too .. and in fact that is much harder. I tried to install MSYS and gave up. MS pays for Ian Lynagh, who works full time on GHC as a contractor. MS puts roughly as much money into GHC as it does into F#, FWIW. I'm happy to hear that! Now let me turn the argument around. Mingw is a minor bit player. The MS toolchain is the main toolchain to support. C++ can't run on Mingw for example (MS and gcc C++ are incompatible). GHC needs to target *professional windows programmers*. They're going to have VS installed already. Haskell is far too important a language (IMHO) not to have an entry in the commercial programming arena. Commercial programming is in a bad way! It NEEDS stuff like Haskell available. BTW: I don't really like Windows .. but I want to see Haskell succeed. Trying to do Haskell on Windows without MSVC++ toolchain is like trying to work on Linux without binutils... :) -- John Skaller skaller at users dot sf dot net Felix, successor to C++: http://felix.sf.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
Neil Mitchell wrote: Hi I'm not sure I understand this. MS tools are free to download by anyone, but not redistributable. The binaries needed by programs *built* by those tools are not only free to download, they're free to redistribute, and they're less encumbered than almost all so-called 'free software' products. The binaries needed by programs built by these tools..., you're referring to the C runtime DLLs? Why does that matter? Note I said with no dependencies above. A Windows native port of GHC would require you to go to MS and download the assembler and linker separately - we couldn't automate that, there are click-through licenses and stuff. I don't compile GHC on Windows, as its kind of annoying to do, and the binaries are usually sufficient for my needs. Typically MS tools are well packaged and even if there is a click through license, it usually involves checking a box and clicking next. I can't believe that anyone is going to have any difficulty installing Visual Studio express. Compare this to Cygwin/Mingw where the packaging is frankly awful, and makes my head hurt every time I have to install it. Not a fair comparison - I'm talking about *users* of GHC, who currently do not have to download anything except GHC itself. With a Windows native port they'd have to also get VS Express and the MASM package separately. GHC *developers* wouldn't be any better off either. You'd still need either Cygwin or MSYS for the build environment. There's no way I'm using MS build tools, ugh. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
skaller wrote: GHC needs to target *professional windows programmers*. They're going to have VS installed already. Haskell is far too important a language (IMHO) not to have an entry in the commercial programming arena. Commercial programming is in a bad way! It NEEDS stuff like Haskell available. BTW: I don't really like Windows .. but I want to see Haskell succeed. Trying to do Haskell on Windows without MSVC++ toolchain is like trying to work on Linux without binutils... :) This is a fine point, and probably the biggest reason for doing a Windows native port. I'd like to see it happen, but we need help! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Neil Mitchell wrote: Typically MS tools are well packaged and even if there is a click through license, it usually involves checking a box and clicking next. I can't believe that anyone is going to have any difficulty installing Visual Studio express. I would have some difficulty, because I would feel obliged to read the license first and decide whether it felt acceptable for me to agree to. That's the same reason I haven't started up iTunes on my MacBook - reading the general Apple-software license was tiring enough! This is one place GNU/Linux/(other Free systems) really shine, even compared to OS X: you don't have to explicitly accept a click-through license the first time you start everything up (iterated for every new installation and computer, and they don't tell you whether it's the same version of the license that you read earlier). (Copyright doesn't require you to click to agree; I've already read the GPL and a few other Free licenses; and I trust the FSF's judgment in what freedoms the other miscellaneous Free licenses grant.) But I guess that doesn't matter to most Windows users... even if they're developers of FOSS ... ? Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeUihHgcxvIWYTTURAiSmAJ4yy6SinJgfUKARozwcYuxvSoUgdwCgpZD9 JFI0TddUPvYjGogtgjQnVM8= =FInN -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: 64-bit windows version?
I would be more than happy to help. Maybe we need to get a sub-team together and start plowing through this mine-field? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Simon Marlow Sent: Wednesday, June 20, 2007 10:29 AM To: skaller Cc: glasgow-haskell-users@haskell.org; Bulat Ziganshin Subject: Re: 64-bit windows version? skaller wrote: GHC needs to target *professional windows programmers*. They're going to have VS installed already. Haskell is far too important a language (IMHO) not to have an entry in the commercial programming arena. Commercial programming is in a bad way! It NEEDS stuff like Haskell available. BTW: I don't really like Windows .. but I want to see Haskell succeed. Trying to do Haskell on Windows without MSVC++ toolchain is like trying to work on Linux without binutils... :) This is a fine point, and probably the biggest reason for doing a Windows native port. I'd like to see it happen, but we need help! Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users * The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank you. * ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 skaller wrote: (MS and gcc C++ are incompatible). is this still true? GCC has been standardizing its C++ ABI for a while, and I think there actually weren't any ABI changes noted between 4.1 and 4.2 for most platforms (I don't know if MS C++ is compatible with that common ABI though). I could be confused here though. BTW: I don't really like Windows .. but I want to see Haskell succeed. Trying to do Haskell on Windows without MSVC++ toolchain is like trying to work on Linux without binutils... :) yes, binutils written in Haskell! Will never happen! :)) Isaac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGeUpvHgcxvIWYTTURAimNAKClTAkuRU3pr/ASsfSZdGiYoNLsmwCgo4G2 Oh/mK9MQ2vcRLAeaT4bOsdo= =0nHh -END PGP SIGNATURE- ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
skaller wrote: On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote: Bulat Ziganshin wrote: Hello glasgow-haskell-users, are you plan to implement 64-bit windows GHC version? The main thing standing in the way of this is the lack of a 64- bit port of mingw. Why do you need mingw? What's wrong with MSVC++? The largest problem is the build system: GHC uses autoconf with custom makefiles. I have looked into porting the whole thing to a Visual Studio project, using SCons (unreliable), CMake (limited command line abilities--good for a one-shot build but really just a safe lowest-common-denominator version of Make), Waf (another python-based build system that started as a fork of SCons for the KDevelop changeover from Autotools) and Jam. I would prefer to use Jam but I'm afraid I would be the only one who would ever want to support it. Nothing has the auto-configuration abilities you (John) built into the Felix Interscript-based system but I do not porting the build system (at least) to Interscript would go over well with anyone else who wanted to maintain it and the build itself would require heavy customisation. I have tested all of these on a small scale (the replacement-Integer library). The best option seems to be to create a VS project (not trivial--lots of glue) so a user may also call that from Make (if under Mingw) or pure DOS. There is also some gcc-specific code in the RTS (inline assembler, use of extern inline, etc.) By the way, as of gcc-4.2 (I believe; I know it is true for gcc-4.3) the use of 'extern inline' now conforms strictly to the C99 standard so we will have to add the option '- fgnu-89-inline' to get the old behaviour back--'extern inline' is used in some of the headers. Converting those 'extern inline's to 'static inline' or best yet plain 'inline' would also solve the problem. Ian Taylor's message at http://gcc.gnu.org/ml/gcc/2006-11/ msg6.html describes this in greater detail; his proposal was implemented. I don't think we'll be able to drop the mingw route either, mainly because while the MS tools are free to download, they're not properly free, and we want to retain the ability to have a completely free distribution with no dependencies. I don't know of any completely free 64-bit compilers for Windows. The Intel compilers are free for 30-day evaluation but everything else is for Win32. For the base Win32-native port there are many compilers available but I have mostly worked on using CL and Yasm (assembler) as replacement back-end compilers for GHC. There are people that want a Cygwin port too; personally I think this is heading in the wrong direction, we want to be more native on Windows, using the native object format and interoperating directly with the native Windows tools. Cygwin has a real problem with gcc: it is far behind everything else (gcc-3.4.4, though Mingw isn't much better) and it doesn't look like that will change anytime soon. It is also only 32-bit, I believe. Cheers, Pete ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: 64-bit windows version?
| BTW: I don't really like Windows .. but I want to see Haskell | succeed. Trying to do Haskell on Windows without MSVC++ toolchain | is like trying to work on Linux without binutils... :) | | This is a fine point, and probably the biggest reason for doing a | Windows native | port. I'd like to see it happen, but we need help! | I would be more than happy to help. Maybe we need to get a sub-team | together and start plowing through this mine-field? That'd be great! A good way to start might be to start GHC-Trac Wiki page, identify who wants to be involved, and sketch the challenges. thanks! Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
Simon Marlow wrote: GHC *developers* wouldn't be any better off either. You'd still need either Cygwin or MSYS for the build environment. There's no way I'm using MS build tools, ugh. The way I have it set up (so far) is as simple as running configure and make--all from the command line, under DOS or Mingw, although someone with VS tools may open up the VSproject in the IDE. Would that be o.k.? I am not particularly enamored with VS, myself but that may be a consequence of having a small monitor for my Windows machine and constantly comparing it to the Xcode/Emacs combination I normally use. The VS debugger *is* very good and helped me pick out some bugs in Yasm quickly--when I only really know how to use gdb. Cheers, Pete ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: 64-bit windows version?
Hello Simon, Wednesday, June 20, 2007, 11:51:34 AM, you wrote: really! Simon, how about unregisterised build? Unregisterised would still need a C compiler capable of generating 64-bit code. Are you talking about using the MS compiler for that? Certainly possible, but I'm not sure why you'd want to do it - you'd end up with much slower code than running the 32-bit compiler. in *my* program all code that is need to be efficient is written in C++ :) generally speaking, people want to use 64-bit code in order to work with much larger data space, overall speed may be better than using 32-bit version with 2gb limit so, if it is a not big problem - afaiu unregisterized build should be easy? - can you please build such version? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: 64-bit windows version?
On Wed, 2007-06-20 at 11:39 -0400, Peter Tanski wrote: The largest problem is the build system: GHC uses autoconf with custom makefiles. Well, that needs to be fixed. Autoconf and make are rubbish. I have looked into porting the whole thing to a Visual Studio project, using SCons (unreliable), CMake (limited command line abilities--good for a one-shot build but really just a safe lowest-common-denominator version of Make), Waf (another python-based build system that started as a fork of SCons for the KDevelop changeover from Autotools) and Jam. I would prefer to use Jam but I'm afraid I would be the only one who would ever want to support it. Nothing has the auto-configuration abilities you (John) built into the Felix Interscript-based system but I do not porting the build system (at least) to Interscript would go over well with anyone else who wanted to maintain it and the build itself would require heavy customisation. The Felix build system is more or less independent of Interscript. There's NO WAY GHC should be ported to use Interscript. We don't want to touch any of the source files. For information of other readers: Felix uses two pieces of advanced technology for building. 1. Interscript is a general purpose extensible literate programming (LP) tool. The idea of LP is that code is embedded in documents. Interscript documents are *.pak files, which when 'tangled' create the actual sources. Interscript is different to other LP tools in that you can embed arbitrary Python script inside a document and use it to *generate* code (or documentation). This just wipes out rubbish like autotools method of filling in Makefile.am templates because it is (a) programmatic and (b) applies to all sources the same way. I regularly use tables to generate various parts of a program, eg a list of tokens to generate lexing components as well as a pretty printing function. But LP is an invasive technology. You pay for using it: it pervades the whole software base and it typically defeats IDE's and syntax colouring etc. 2. The Felix build system is basically a 'debian like' package manager. Although it hooks interscript, that's just another plugin of the build system. The key thing for the building portability is that the C and C++ compilers are represented by Python classes. There is a pre-programmed class for gcc, and another for MSVC++. The way this works is we have identified build abstractions like: * make an object file for static linking * make an object file for dynamic linking (-fPIC thing) * make a dynamic link library from object files * make a static link library from object files * static link a program * link a program for dynamic loading plus some things peculiar to Felix. Each of these functionalities is represented by a method of the Python class. So the build scripts are portable, provided you use these methods on an object of the appropriate compiler class (gcc or msvc). Similarly, to manage files, scripts say stuff like: fileparts = string.split(filename,/) osfilename = string.join(fileparts,os.sep) which converts a 'unix' filename to your local OS convention. I typically mandate Unix style filename literals even on Windows, but it is tricky to get this right. To build a library a package typically has a meta-description, which is itself an executable Python script which is requires to set some variables, such as a list of source files to be compiled. The build system compiles them using both the static and dynamic methods, and makes both shared and static archive libraries. Clearly GHC will have different requirements to Felix. I'm not suggesting copying the Felix build system verbatim! What I actually recommend is: (a) Pick a portable scripting language which is readily available on all platforms. I chose Python. Perl would also do. I can't recommend Tcl, it's too messy. Scheme may be an excellent choice I'm only just learning it and I'm not sure about availability, but it seems really well suited if you can hack all the brackets :) (b) Write the WHOLE build system using that language. For parts that differ between OS, you use parameters. These parameters can be simple things like EXE_EXT = .exe # Windows EXE_EXT = # Unix etc, or they can be classes encapsulating complex behaviour. Too much abstraction is bad .. environments are too quirky, lots of cases with minor variations is the way to go unless you're REALLY sure what you have is an abstraction. (c) provide 'values' for the parameters for the platform combinations you want to build on (d) write configuration scripts to create a file of these parameters -- if that fails the user can edit it. You can also supply 'prebuilt' configurations for common platforms. BTW: doing all this was more or less mandatory for Felix, since it is a cross-cross-compiler. The Felix build system actually splits building
Re[4]: 64-bit windows version?
Hello skaller, Thursday, June 21, 2007, 7:06:09 AM, you wrote: generally speaking, people want to use 64-bit code in order to work with much larger data space, overall speed may be better than using 32-bit version with 2gb limit With x86_64, 64 bit programs are usually faster than 32 bit ones even for small data, probably because despite the extra stack space etc that is required for double sized pointers, there are also more registers. There may also be a penalty for 32 bit code in other parts of the processing pipeline, eg segmentation (which is not available for 64 bit code). this small speed increase will be easily outweighted by using non-optimizing (un*register*ized means non using registers in optimal way) compiler the whole problem is that GHC has very complex compilation strategy which is fine-tuned for every platform fully supported. it mangles asm code produced by C compiler, it uses registers directly, so on. this is so-called registerized build. and without all these optimizations it just generates plain ANSI C code, this is unregizterized build. the last is much simpler to implement - you need to port only libraries/RTS IMHO the main use of 32 bit machines now is embedded applications, for example mobile phones. but this doesn't apply to 32-bit code. moreover, you say about computers that are now selled but there are lots of old boxes. and not everyone with 64-bit CPU buys 64-bit OS from my POV, main reason for 64-bitness is using more than 2G of memory, and growed amount of memory in typical desktops was the reason why 64-bit systems now becomes popular. in terms of CPU architecture, x86-64 is still CISC while RISC and EPIC architectures proven their efficiency in last 20 years. doubled amount of registers is very small step in this direction -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
