- Haskell-Cafe - Haskell.org

Suggestion for implementation of vector library
by Olex P 17 Jun '08

17 Jun '08

Hi guys, Sorry for a silly questions but I didn't find a proper answer in Google. I've started to learn Haskell and would like to implement a library for work with vectors. I found different implementations of this stuff but all of them made just for fun in a short as possible terms using lists or tuples. I suppose there should be a better way to go. First idea came to my mind was using of classes. Something like this: [code] -- Template Vector class class Vector v where (<+>) :: v -> v -> v (<->) :: v -> v -> v (<*>) :: v -> v -> v (*>) :: v -> Float -> v -- other methods here -- Vector3 instance -- Declare new Vector3 type data Vector3 = Vector3 (Float, Float, Float) instance Vector Vector3 where (<+>) (Vector3 (x1, y1, z1)) (Vector3 (x2, y2, z2)) = Vector3 (x1 + x2, y1 + y2, z1 + z2) (<->) (Vector3 (x1, y1, z1)) (Vector3 (x2, y2, z2)) = Vector3 (x1 - x2, y1 - y2, z1 - z2) (<*>) (Vector3 (x1, y1, z1)) (Vector3 (x2, y2, z2)) = Vector3 (x1 * x2, y1 * y2, z1 * z2) (*>) (Vector3 (x, y, z)) f = Vector3 (x * f, y * f, z * f) length (Vector3 (x, y, z)) = sqrt (x * x + y * y + z * z) -- the rest of methods [/code] What I don't like here is using of data type constructors when even simple expression like v1 + v2 becomes too long (<+>) (Vector3 (1,2,3)) (Vector3 (4,5,6)) Do I really need a data type constructor (in this particular case)? Or better to declare a vector3 type as: type Vector3 = (Float, Float, Float)? Next question is how to make one instance which derives from several classes? For example from Eq, Num and Vector (if I want to overload +, -, <, >, == etc.) Is it good idea to use classes and ad hoc polymorphism or better to use parametric polymorphism? How you would implement such library? (not just for educational purposes but for development of _very_good_extensible_ software) Thank you, Alex.

5 5

1/0
by Evan Laforge 17 Jun '08

17 Jun '08

So, I know this has been discussed before, but: > 1/0 Infinity > 0/0 NaN ... so I see from the archives that Infinity is mandated by ieee754 even though my intuition says both should be NaN. Every other language throws an exception, even C will crash the program, so I'm guessing it's telling the processor / OS to turn these into signals, while GHC is turning that off. Or something. But then what about this note in Control.Exception: (NOTE: GHC currently does not throw ArithExceptions except for DivideByZero) Doesn't this imply GHC should be throwing DivideByZero? Why is it in the stdlib if it's turned off? And why would it be turned off? I suppose I could accept the above since Infinity *is* an exceptional value meant to represent things like 1/0, and it can be nice to see NaNs in your output instead of crashing everything (this is, I assume, why ieee754 has these modes in the first place), but how about this: > round (0/0) :: Integer (huge negative number) Ok, so integral types don't have that exceptional value. Shouldn't trying to convert NaN or Infinity to an Integral throw something? Is it a performance thing? I'd think if you're converting to Integer you don't really need hardware level performance anyway, so a couple of checks wouldn't kill anyone.

10 18

Re: [Haskell-cafe] Re: How to do this in FP way?
by Thomas Davie 17 Jun '08

17 Jun '08

On 16 Jun 2008, at 19:24, Achim Schneider wrote: > Thomas Davie <tom.davie(a)gmail.com> wrote: > >> >> On 16 Jun 2008, at 18:28, Achim Schneider wrote: >> >>> Thomas Davie <tom.davie(a)gmail.com> wrote: >>> >>>>> >>>>> One half of all Haskell coders will tell you that mutable state >>>>> isn't a >>>>> good starting point to learn Haskell, the other half will tell you >>>>> the same because they want to be cool kids, too. >>>> >>>> And the one left over will point out that he asked how to do this >>>> the FP way, not the imperative way? >>>> >>> There's no difference, as you can't do time-accounting non-strict >>> and still expect it to give meaningful results: I'm merely trying >>> to be helpful. None of the other solutions allow for the IO Monad. >> >> Firstly, I'd phrase that differently -- the IO Monad doesn't allow >> for the other solutions -- the other solutions are the truly >> functional ones. Secondly, I'm curious as to why you think that the >> two are incompatible, are you saying that for any meaningful kind of >> computation we need to resort to IORefs? I'd strongly contest that >> idea. >> > We have to resort to IO actions to get the time, and to IORefs because > we need to chain up different calls to getCurrentTime using the IO > Monad. The rest of the program can work with whatever you like best. And in what way is this incompatible with either FRP as pierre suggested, or with generating an infinite list of times at which we call the function, and scanning it to find the differences? Bob

2 1

ANN: Haddock Trac
by David Waern 17 Jun '08

17 Jun '08

Hi everyone, there's now a Haddock bug-tracker and wiki at http://trac.haskell.org/haddock. Please use it to submit bug reports and feature requests! David

2 1

C-program calling Haskell program?
by Taepke, Bob 16 Jun '08

16 Jun '08

Hello, I am very new to Haskell, and I work in Windows XP. Can anyone please point me to a working C / Haskell program pair that does the following: 1) The C routine passes one or more scalars, arrays, or matrices to the Haskell routine. 2) The Haskell routine reads a comma-delimited, ASCII file from the path, C:\my_directory\input_data\. 3) The Haskell routine writes a comma-delimited, ASCII file to the path, C:\my_directory\output_data\. 4) The Haskell routine returns to the C routine one or more scalars, arrays, or matrices. 5) For what it's worth, I'm only using the C-routine as an interface between MATLAB and Haskell, because MATLAB can call C-routines. Has anyone written C / Haskell code that does the above tasks? If so, would you please be willing to pass it along to me? Thank you! Bob [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com

1 0

FunPtr error?
by Galchin, Vasili 16 Jun '08

16 Jun '08

Hello, I am getting what is to me a mysterious error in a test case that I am writing: vigalchin@ubuntu:~/FTP/Haskell/unix-2.2.0.0/tests/timer$ runhaskell Setup.lhs build Preprocessing executables for Test-1.0... Building Test-1.0... [1 of 1] Compiling Main ( ./timer.hs, dist/build/timer/timer-tmp/Main.o ) ./timer.hs:11:45: Not in scope: data constructor `FunPtr' It seems like the compiler is complaining about the lack of FunPtr in it's symbol table but System.Posix is imported: module Main where import System.Posix import Foreign import Foreign.C import Foreign.Ptr main = do let event = Sigevent{sigevFunction=(FunPtr (notifyFunc))} <<<<<< error here timerId <- timerCreate Clock_Realtime Nothing timerDelete timerId return () notifyFunc :: Sigval -> IO () notifyFunc sigval = do putStrLn "timer POP!!!!!!!" return () I am probably looking right at the answer and not seeing it. ?? Thanks, Vasili

5 15

monomorphism restriction
by Rex Page 16 Jun '08

16 Jun '08

Definition of f: f = foldr (+) 0 Types: 0 :: (Num t) => t foldr (+) 0 :: Num a => [a] -> a f :: [Integer] -> Integer Please remind me, again, of the advantages of f being something different from the formula defining it. - Rex Page

5 6

Lazy IO.
by Sebastiaan Visser 16 Jun '08

16 Jun '08

Hi, I've got a question about lazy IO in Haskell. The most well known function to do lazy IO is the `hGetContents', which lazily reads all the contents from a handle and returns this as a regular [Char]. The thing with hGetContents is that is puts the Handle in a semi-closed state, no one can use the handle anymore. This behaviour is understandable from the point of safety; it is not yet determined when the result of hGetContents will actually be computed, using the handle in the meantime is undesirable. The point is, I think I really have a situation in which I want to use the handle again `after' a call to hGetContents. I think I can best explain this using a code example. readHttpMessage :: IO (Headers, Data.ByteString.Lazy.ByteString) readHttpMessage = do myStream <- <accept http connection from client> request <- hGetContents myStream header <- parseHttpHeader request bs <- Data.ByteString.Lazy.hGetContents myStream return (header, body) The Data.ByteString.Lazy.hGetContents in the example above obviously fails because the handle is semi-closed. So, what I am trying to do here is apply a parser (on that consumes Char's) to the input stream until it has succeeded. After this I want to collect the remainings of the stream in a lazy ByteString, or maybe even something else. I tried to open the handler again using some internal handle hackery, but this failed (luckily). In the module GHC.IO there is a function `lazyRead' that more or less seems to do what I want. But I'll guess there is a good reason for not exporting it. Does anyone know a pattern in which I can do this easily? Thanks, -- Sebastiaan

8 13

Design your modules for qualified import
by Johan Tibell 16 Jun '08

16 Jun '08

Hi! The last two weeks I've seen two new packages that add suffixes to identifiers instead of relying on them being imported qualified to distinguish them from identifiers in other modules. This is not a new thing in Haskell community and there are examples of this practice in libraries shipped with GHC. It is also common in papers (for good reasons as we will see later). Atomic channels and variables under Control.Concurrent.* are examples of using a prefix as a namespacing tool. Let me reiterate the arguments [1,2] against this practice and also speculate why this practice is more common in Haskell than in e.g. Python, Java or Ruby. * Cons of including a namespace prefix/suffix in identifiers 1. From experience these prefixes/suffixes tend to be short and non-descriptive, typically just one letter e.g. foldU or elemB. Very frequently used functions that every Haskell programmer is likely to use often can have shorter name as the cost of memorizing them is amortized over all their uses. Examples of short names that most Haskell programmers know by heart is map, fold*, etc. Given that your library won't see the same use as these functions your functions need more descriptive names (or in this case use a qualified import that makes them more descriptive e.g. Array.fold). 2. If your modules are imported qualified the suffix is redundant and thus wastes space. Consider for example foldU imported qualified from the module Data.Array as Array.foldU. Array.fold would have been better in this case. * Pros of using qualified imports 1. Your code will be more robust against additions to modules you depend on. Consider this snippet: import Some.Module -- An utility function that the author of the above module forgot to include. foo = ... Now the author of Some.Module releases a new version of his or her package which include `foo' and your code no longer compiles. If you have no imports on the form import Some.Module your package can specify more relaxed version dependencies on other packages [3]. 2. It's easier to see from where an identifier is imported. Just check the functions module prefix (e.g. Array in Array.foo). If you renamed the import using import Foo as F you might have to check the import list. * Explicit, unqualified imports An alternative to qualified imports that shares some of benefits is to import names unqualified but explicitly enumerate the function names e.g. import Some.Module (foo, bar) It is still not immediately obvious what module a name refers too when using this style (point 2 under pros above) but it is at least easier to find than when implicitly importing all names from a module. This is my current preference for infix operators as they look quite ugly qualified with a module name. It might also make sense if a few functions (e.g. parser combinators) are used a lot in the same module (e.g. an HTTP parser). * Why is this practice common in Haskell Here are some guesses: 1. It's common in papers. However, papers and libraries are quite different. The former usually build up a small vocabulary and having short names is a big win. Papers rarely make use of the module system at all. The latter are included as pieces of large programs and their names need to be adjusted accordingly. 2. It's the default. You have to add "qualified" to all your imports to make them qualified. In most language imports are qualified by default. I think the latter would have been a better choice but we have to live with the current design so bite the bullet and add those qualified keywords to your imports. 3. Lack of common interfaces. An example would be two different set implementations that essentially have the same interface but since there is no explicitly shared interface, defined using a type class, you sometimes end up with different names. The lack of type families might explain why e.g. collection classes don't share interfaces. 4. Haskell is a very expressive language. You can often write a whole function definition on one line! Adding those module qualifications makes your code slightly longer and it might just break your beautiful one liner into two lines. * Summary Whenever you write a library design it so it works well with qualified imports. That means leaving namespacing issues to the module system. Try to think of how code using your functions will look like if it uses them qualified. * References 1. http://www.haskell.org/haskellwiki/Import_modules_properly 2. http://www.haskell.org/haskellwiki/Qualified_names 3. See section 2 Version numbers - http://www.haskell.org/haskellwiki/Library_versioning_policy Cheers, Johan

22 40

Memory profiling
by Pieter Laeremans 16 Jun '08

16 Jun '08

Hi, Which tools do you recommand for memory profiling haskell programs on a *nix system. I'm using haskell to develop a CGI program/script. The application has to be deployed on shared hosting infrastructure. Since I would like to be a good citizen , I would need to meassure the maximum amount of memory allocated to the program during execution. The best I can do now is look at top but that 's not satisfactory. thanks, Pieter -- Pieter Laeremans <pieter(a)laeremans.org>

2 1