- Haskell-Cafe - Haskell.org

Ints as ints and floats - Question on style
by Jorge Adriano 08 Feb '03

08 Feb '03

Hello, Lately I've been coding functions where I have to use Int elements, both as Ints (e.g. as an array or list index) and Doubles/Floats (e.g. when performing arithmetic operations with Doubles/Floats). How do you usually deal with this? Some options I can think of are, 1. using "fromIntegral" when needed (some formulas become unredable). 2. duplicating all those ints to float elements. (not very readable either, you end up with two distinct elements that mean the same thing). 3. creating new operators perform arithmetic operations with Ints/Integers and Float/Doubles. Cheers, J.A.

1 0

libDB
by Sengan.Baring-Gould＠nsc.com 08 Feb '03

08 Feb '03

Has anyone written a binding to the BSD libdb ? Sengan ----------------------- There's a limit to all things, and everything that passes its limit destroys itself.

1 0

RE: time since the epoch
by Simon Marlow 07 Feb '03

07 Feb '03

> Ha! After playing with this, I discovered that only the seconds were > set and all other fields remained untouched. At least in ghc's > implementation. Interestingly, TimeDiff derives Eq and Ord, but I'd > better not ask for their implementation... TimeDiff has a perfectly well-defined meaning for Eq and Ord: one TimeDiff is equal to another iff all the fields are respectively equal. See http://www.haskell.org/pipermail/haskell-cafe/2002-December/003758.html > There is also a more fundamental problem with the TimeDiff data > type. While seconds, minutes, hours, and days are clearly specified > amounts of time, the duration of a month or a year may vary depending > on the reference point where the time difference is applied. This isn't a problem with the spec, I think. A TimeDiff of "1 month" is precisely a difference, which, when added to a given ClockTime, produces a ClockTime which is one month later (with respect to some timezone, presumably UTC since it isn't specified otherwise). That is, January 12th 12:00 UTC becomes February 12th 12:00 UTC, and so on. Adding one month to certain ClockTimes is meaningless: eg. adding one month to January 31st doesn't work. At least, that's how I believe it is supposed to work. GHC's implementation *is* completely wrong (which is perhaps where some of the confusion comes from), but the TimeExts library can be used instead of TimeDiffs. > My conclusion is that time differences really should be measured in > seconds and picoseconds. > > type TimeDiff = (Integer, Integer) We already have this kind of TimeDiff: just don't use anything except the seconds and picoseconds fields. I agree with John Meacham in that it ought to be possible to get a raw time in terms of seconds/picoseconds since the epoch, and indeed GHC lets you do that: importing System.Time lets you get at the representation of ClockTime: data ClockTime = TOD Integer -- Seconds since 00:00:00 on 1 Jan 1970 Integer -- Picoseconds with the specified second This is a perfectly reasonable definition of absolute time, we don't need to talk about TAI at all, except to define what the epoch means. Cheers, Simon

2 1

RE: Auto generated instance codes through 'deriving'
by Simon Peyton-Jones 07 Feb '03

07 Feb '03

Try -ddump-deriv http://haskell.cs.yale.edu/ghc/docs/latest/html/users_guide/options-debu gging.html#DUMPING-OUTPUT Simon -----Original Message----- From: Jong Keun Na [mailto:jongkn@microsoft.com] Sent: 07 February 2003 06:15 To: haskell-cafe(a)haskell.org Subject: Auto generated instance codes through 'deriving' Hello folks, Is there any method with which I can see instance's codes generated automatically by using 'deriving' keyword in GHC? I'm curious in how GHC generates 'Read' class's instance code for user-defined data type. Any help will be great appreciated. /JongKeun

1 0

Auto generated instance codes through 'deriving'
by Jong Keun Na 07 Feb '03

07 Feb '03

Hello folks, Is there any method with which I can see instance's codes generated automatically by using 'deriving' keyword in GHC? I'm curious in how GHC generates 'Read' class's instance code for user-defined data type. Any help will be great appreciated. /JongKeun

1 0

Re: arrays and lamda terms
by Claus Reinke 06 Feb '03

06 Feb '03

>Right, I mean constant-steps, rather than single steps. Could you give an example to what you are describing? Sure. Just thought you'd like to play with the idea yourself first:-) If you limit beta-reduction to deal only with unary abstractions, there's little chance of deconstructing an expression involving n separate subterms with less than n steps. Otherwise, it is just the old idea of representing data structures by their folds. A selector then returns one of its n parameters, which usual implementations deal with in a single step. You could even compute the selectors for each combination of array-size and position if Haskell's type system didn't get in the way (a job for template Haskell, or some type class hackery). Cheers, Claus -- representing arrays as their folds, -- here for m=5 arr5 a1 a2 a3 a4 a5 s = s a1 a2 a3 a4 a5 show_arr5 a = show $ a (,,,,) list2arr5 [a1,a2,a3,a4,a5] = arr5 a1 a2 a3 a4 a5 -- selectors -- sm_n =~= (ignore^(n-1)) (keep^(m-n)) -- where {- const by any other name -} -- ignore f x = f -- keep x y = x s5_1 a1 a2 a3 a4 a5 = a1 s5_2 a1 a2 a3 a4 a5 = a2 s5_3 a1 a2 a3 a4 a5 = a3 s5_4 a1 a2 a3 a4 a5 = a4 s5_5 a1 a2 a3 a4 a5 = a5 -- updates -- for illustration only; whole-array ops preferable u5_1 a1 a2 a3 a4 a5 f = arr5 (f a1) a2 a3 a4 a5 u5_2 a1 a2 a3 a4 a5 f = arr5 a1 (f a2) a3 a4 a5 u5_3 a1 a2 a3 a4 a5 f = arr5 a1 a2 (f a3) a4 a5 u5_4 a1 a2 a3 a4 a5 f = arr5 a1 a2 a3 (f a4) a5 u5_5 a1 a2 a3 a4 a5 f = arr5 a1 a2 a3 a4 (f a5) -- example uses main = do let a = list2arr5 [1..5::Int] putStrLn $ "a="++show_arr5 a putStrLn $ "a[4]="++show (a s5_4) let b = a u5_4 (const 0) putStrLn $ "b="++show_arr5 b putStrLn $ "b[4]="++show (b s5_4) mapM_ (print . b) [s5_1,s5_2,s5_3,s5_4,s5_5] let c = b u5_1 (+1) u5_3 (+1) u5_5 (*2) putStrLn $ "c="++show_arr5 c

2 2

Re: separate compilation [was Re: Global variables?]
by Jon Cast 06 Feb '03

06 Feb '03

Andrew J Bromage <ajb(a)spamcop.net> wrote: > G'day all. > On Wed, Feb 05, 2003 at 08:05:56PM -0600, Jon Cast wrote: > > I'm not sure I follow this. If you change the type of a value exported > > from a given module, that's a public change, no? And if you don't, why > > should re-compilation be needed? > Consider this: > << > module A where > import B > {- use B.b -} > >> > << > module B (b) where > import C > b = C.c > >> > << > module C (c) where > c :: Int > >> > Changing the type of c requires recompiling module A. > You would expect that changing c's type forces a recompilation of B, > since you changed C's public interface. However, this also changes > B's public interface even though you did not touch the text of module > B. The reason is that B's public interface is partly based on modules > which it _privately_ imports, even if it does not re-export any > symbols from those modules. I think I see what you're saying. I still maintain, however, that, since you've changed the type of B.b (admittedly implicitly), and B.b is exported from B, that you've changed B's interface. There is a reason make is designed to re-build B /and/ (potentially) A when C changes, after all. > One fix is to require all exported symbols to have explicit type > declarations. Since this is good practice anyway, I would be in > favour of making it a language requirement in Haskell 2. > Cheers, > Andrew Bromage Jon Cast

2 1

Re: separate compilation [was Re: Global variables?]
by Jon Cast 06 Feb '03

06 Feb '03

Andrew J Bromage <ajb(a)spamcop.net> wrote: > G'day all. > On Wed, Feb 05, 2003 at 04:16:33PM -0800, Iavor S. Diatchki wrote: > > why do you think separate compilation is difficult to achieve in > > Haskell 98? > Because of type inference over recursive module imports. Determining > the type of a function may, in general, require inferring types from an > arbitrary number of other modules, and may require inference to occur > at the level of granularity of a clique in the import graph, rather than > at the level of a single module. > Requiring an implementation to perform static analysis a clique at a > time is not "separate compilation", because changing something which > is private to one module may in general require an unbounded number of > other modules to be recompiled, even if inter-module optimisation is > turned off. I'm not sure I follow this. If you change the type of a value exported from a given module, that's a public change, no? And if you don't, why should re-compilation be needed? <snip> > Cheers, > Andrew Bromage Jon Cast

2 1

RE: Global variables?
by Simon Peyton-Jones 06 Feb '03

06 Feb '03

| Haskell 98 has never supported separate compilation. That's why we | have hi-boot files (or something similar). | | So, yes, I'd like to know how the language designers intend to support | separate compilation in the next version. H98 has nothing to say about the separate compilation; it's an issue for the implementation. GHC does separate compilation for Haskell, and always has done. It requires the programmer to supply an auxiliary hi-boot file for one module in each mutually recursive group (and, of course, none if there is no recursion between modules). Simon

4 5

RE: Looking for large Haskell programs
by Simon Marlow 05 Feb '03

05 Feb '03

> PS: Approximately how many lines of code is GHC these days? ~78k lines of code, ~63k lines of comments in the compiler itself. The runtime has a further ~50k lines of C. Cheers, Simon

1 0