- Glasgow-haskell-users

hierarchical module names
by Serge D. Mechveliani 23 Jun '05

23 Jun '05

Who knows, please, where there are explained hierarchical module names? Is this a matter of Haskell-98 or of GHC ? I looked into both of them (and also a bit into libraries(a)haskell.org) but could not find a basic explanation of the point, somehow missed. Suppose that my user package called dumatel exports a module of kind --------------------------- module List (union) where import Data.List import qualified List union xs ys = f (Data.List.union xs (List.union ys ys)) f = ... --------------------------- First, the module name List conflicts with such of the base package of GHC. So, I change this to --------------------------- module Dumatel.List (union) where where import Data.List import qualified List union xs ys = f (Data.List.union xs (List.union ys ys)) f = ... --------------------------- Second, -v key in ghc --make shows that GHC decides to search for the module Dumatel.List only in the files ./Dumatel/*.hs and ./Dumatel/*.lhs So, I create a directory and put the above module to the file ./Dumatel/List.hs Does this all mean "to use hierarchical module names"? Does the module name "Dumatel.List" agree with Haskell-98 ? What is the currently most convenient way to resolve module name clashes between the packages? Is this the above arrangement with subdirectories and module names with dots (and with "qualified-as" import) ? Thank you in advance for explanation. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

RE: Bignums in Haskell
by Simon Peyton-Jones 23 Jun '05

23 Jun '05

| >> Do any of you have insight into why GHC uses GMP as opposed to | >> another library for arbitrary precision numbers? | > ... | | Right - that's three reasons to use it. Some reasons *not* to use it | are: it has an awkward license, it's big, it needs updating, and we run | into problems when the Haskell program wants to use GMP itself via the | FFI (it's possible by essentially renaming everything in our local copy | of GMP so it doesn't conflict, but we haven't done that). In fact, we have long wanted to replace GMP with another library for exactly these reasons. It's a nice, well-specified, self-contained project, which is just waiting for someone to step up and do it. Of course, we'd only want to replace GMP if the alternative was also fast and reliable. If anyone is interested in tackling this, let us know! Simon

4 5

bignum libraries
by Serge D. Mechveliani 22 Jun '05

22 Jun '05

People, When intending to write a library for large numbers, it worths to keep in mind the following. 1. Efficient multiplication, division and gcd methods may occur rather involved mathematically. 2. It is natural for `arithmetics' to include factorization. Suppose, GHC would like to include such ... 3. It is natural to extend further the library to algebraic numbers. (2) and (3) are definitely very involved mathematically. (2) and (3) are supported by existing libraries (by Lenstra or other experts), -- as I recall, written in C, -- with various wise methods for (1),(2),(3), so that efficient arithmetics for integers is extended to algebraic numbers. (I never looked into all this, only have seen the announcements). Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

comparing 5.02.3 and 6-4-branch
by Serge D. Mechveliani 22 Jun '05

22 Jun '05

I have installed ghc-5.02.3 and ghc-cvs-6-4-branch-June-15 on the same Linux machine, ported DoCon to 6-4-branch, and compared DoCon-2.06 - ghc-5.02.3 to DoCon-2.09 - ghc-cvs-6-4-branch-June-15 on computer algebra (the CA algorithms are the same). 1. They work correct. 2. The performance and memory eagerness difference is within about 5 %. ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

RE: Bignums in Haskell
by Simon Marlow 22 Jun '05

22 Jun '05

On 21 June 2005 22:52, John Meacham wrote: > On Tue, Jun 21, 2005 at 03:48:44PM +0100, Simon Peyton-Jones wrote: >> >>>>> Do any of you have insight into why GHC uses GMP as opposed to >>>>> another library for arbitrary precision numbers? >>>> >> ... >>> >>> Right - that's three reasons to use it. Some reasons *not* to use >>> it are: it has an awkward license, it's big, it needs updating, and >>> we run into problems when the Haskell program wants to use GMP >>> itself via the FFI (it's possible by essentially renaming >>> everything in our local copy of GMP so it doesn't conflict, but we >>> haven't done that). >> >> In fact, we have long wanted to replace GMP with another library for >> exactly these reasons. It's a nice, well-specified, self-contained >> project, which is just waiting for someone to step up and do it. Of >> course, we'd only want to replace GMP if the alternative was also >> fast and reliable. >> >> If anyone is interested in tackling this, let us know! > > I wonder if it would be feasable to implement arbitrary precision > integers in pure haskell. unboxed values would probably want to be > used in some places for speed and it would be very motivating to > improve ghc's optimizer. There should be no reason manually unboxed > haskell code should compile slower than C. GHC currently lacks some of the primitives that you'd need to build an efficient bignum library (eg. add with carry), but you could add these. Also, the fact that GMP contains hand-tuned assembly versions of several operations makes me skeptical that you could get the same performance from GHC-compiled Haskell. However, getting close might be good enough. Cheers, Simon

1 0

RE: Bignums in Haskell
by Simon Peyton-Jones 22 Jun '05

22 Jun '05

There's nothing inherently imperative about bignums. The current algorithms may have an imperative flavour, but that may be partly because that's what suits the implementation language. If the algorithms are divide-and-conquer, perhaps a tree representation would work very nicely. And even in the imperative case there is no reason in principle why a runST-encapsulated imperative algorithm should be slower than C --- although at the moment GHC does not do a consistently good job of compiling imperative code. So I rather agree with John: implementing bignums in Haskell, and trying to make an efficient implementation based on the state of the art on the numerical side (as opposed to just writing the first code that comes into your head), would be an interesting project for someone to try. It might also expose useful optimisations that are missing in GHC or jhc. It's essential to optimise the 'small bignum' case. In practice, most "bignums" easily fit in 32 bits. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Marco Morazan | Sent: 22 June 2005 00:39 | To: karczma(a)info.unicaen.fr | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re: Bignums in Haskell | | This is a rather interesting question. Most "efficient" | implementations use array-based representations for bignums that are | mutable. The use of mutable arrays appears to be justified, because of | divide-and-conquer multiplication and division algorithms (e.g. | Karatsuba) that perform these operations in place. The problem, | however, is not this straighforward. Array-based implementations | require copying bigits into the array. A list-based implementation | simply points to the rest of the bignum avoiding any copying. | | If bignums are immutable structures (as in a true functional data | structure), then we should not be surprised if list-based | representations are as good or better than array-based | implementations. In this case, arrays are forced to copy bigits to new | memory locations while lists can continue to point to pieces of a | bignum. To avoid excessive memory allocation for pure bignums | real-time garbage collection on bignum operations can be used. | | It is certainly a rich and interesting line of research. It also | appears to me that having native support for bignums is desirable. It | would certainly make using bignum libraries seamless. | | Best wishes, | | Marco | | On 6/21/05, karczma(a)info.unicaen.fr <karczma(a)info.unicaen.fr> wrote: | > John Meacham writes: | > | > > I wonder if it would be feasable to implement arbitrary precision | > > integers in pure haskell. unboxed values would probably want to be used | > > in some places for speed and it would be very motivating to improve | > > ghc's optimizer. There should be no reason manually unboxed haskell code | > > should compile slower than C. | > | > Of course, bignums (integers) can be quite nicely implemented in Haskell, | > this is btw. a known student exercise. The implementation is nice, elegant, | > etc., but the efficiency... This is not only having unboxed chunks, but | > also the global policy of memory allocation. Putting number chunks in lazy | > lists involves a substantial overhead. I am not sure how slow it will be, | > since our pedagogic games didn't care at all, but we can try to benchmark | > it one day... | > | > | > Jerzy Karczmarczuk | > | > | > _______________________________________________ | > Glasgow-haskell-users mailing list | > Glasgow-haskell-users(a)haskell.org | > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users | > | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: Bignums in Haskell
by Simon Marlow 21 Jun '05

21 Jun '05

On 21 June 2005 12:47, Ketil Malde wrote: > Marco Morazan <morazanm(a)gmail.com> writes: > >> Do any of you have insight into why GHC uses GMP as opposed to >> another library for arbitrary precision numbers? > > Did you have any particular other library in mind? I'm not too > well-versed in this, but I think GMP is fairly efficient, well tested > and portable. So why not? Right - that's three reasons to use it. Some reasons *not* to use it are: it has an awkward license, it's big, it needs updating, and we run into problems when the Haskell program wants to use GMP itself via the FFI (it's possible by essentially renaming everything in our local copy of GMP so it doesn't conflict, but we haven't done that). There are other good bignum libraries out there: the one that comes with OpenSSL springs to mind. Cheers, Simon

1 0

Bignums in Haskell
by Marco Morazan 21 Jun '05

21 Jun '05

Hello all, Do any of you have insight into why GHC uses GMP as opposed to another library for arbitrary precision numbers? Also, why would bignums not be directly implemented for the GHC or other implementations of Haskell? Best wishes, Marco

4 3

Error building GHC from darwin ports
by David Menendez 17 Jun '05

17 Jun '05

I currently have GHC installed using darwin ports, and I've been trying to upgrade from 6.4_0 to 6.4_8, but I keep hitting a file-not-found error. Looking at the paths in question, I'm guessing the problem has to do with the path segment "/var/db/dports/build/file._opt_local_var_db_dports_sources_rsync.rsync. opendarwin.org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/" appearing twice. Unfortunately, I don't understand the makefiles well enough to track down where this is happening. I'm running Mac OS X 10.4 with XCode 2.0 and darwinports 1.001. Here are the relevant errors: ----------------------------- /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc -M -optdep-f -optdep.depend -osuf o -H16m -O -I/usr/include -I/opt/local/include -L/usr/lib -L/opt/local/lib -cpp -fglasgow-exts -O AbsSyn.lhs First.lhs GenUtils.lhs GetOpt.lhs Grammar.lhs Info.lhs LALR.lhs Lexer.lhs Main.lhs ParseMonad.lhs Parser.hs ProduceCode.lhs ProduceGLRCode.lhs Set.lhs Target.lhs Version.hs /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc: line 5: /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/var/db/dports/build/file ._opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.4/ghc-6.4: No such file or directory /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/bin/ghc: line 5: exec: /opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/var/db/dports/build/file ._opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-bootstrap/lib/ghc-6.4/ghc-6.4: cannot execute: No such file or directory gmake[2]: *** [depend] Error 126 gmake[1]: *** [boot] Error 1 gmake[1]: Leaving directory `/opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-6.4/happy' gmake: *** [/opt/local/var/db/dports/build/file. _opt_local_var_db_dports_sources_rsync.rsync.opendarwin. org_dpupdate_dports_lang_ghc/work/ghc-6.4/happy/src/happy-inplace] Error 2 Warning: the following items did not execute (for ghc): com.apple.destroot com.apple.build Error: Unable to upgrade port: 1 -- David Menendez <zednenem(a)psualum.com> | "In this house, we obey the laws <http://www.eyrie.org/~zednenem> | of thermodynamics!"

2 3

(no subject)
by Amit rohatgi 17 Jun '05

17 Jun '05

hello all, I am new to using ghc . I want to install DARSC and for that i need GHC .. I dont have any old version of Ghc already on the comp so i need the *.hc files from any version 6-?-? to compile ghc. till now i havent been able to locate those files. Please help me to find these files. Hoping for a positive reply Regards Amit --

2 1