- Haskell-Cafe - Haskell.org

Unit testing in Haskell
by Dmitri Pissarenko 12 Jan '05

12 Jan '05

Hello! When programming in an imperative language like Java, unit tests are a very important development tool IMHO. I want to try out unit testing in Haskell and wonder what experienced Haskellers think about unit testing in Haskell in general and the hUnit testing framework (see URL below) in particular? http://hunit.sourceforge.net/ What other unit testing frameworks for Haskell do you use? TIA dap -- Dmitri Pissarenko Software Engineer http://dapissarenko.com

2 1

RE: [Haskell-cafe] Re: Hugs vs GHC (again) was: Re: Somerandomnewbiequestions
by Simon Marlow 11 Jan '05

11 Jan '05

On 11 January 2005 11:39, Marcin 'Qrczak' Kowalczyk wrote: > Ben Rudiak-Gould <Benjamin.Rudiak-Gould(a)cl.cam.ac.uk> writes: > >> http://www.haskell.org/~simonmar/io/System.IO.html > > "fileRead :: File -> FileOffset -> Integer -> Buffer -> IO ()" > > This is unimplementable safely if the descriptor is read concurrently > by different processes. The current position is shared. There's a big lock on File. If you want to do truly concurrent reading, you can make multiple FileInputStreams, each of which has its own file descriptor (the Unix implementation uses dup(2)). Cheers, Simon

2 1

RE: [Haskell-cafe] Re: Hugs vs GHC (again) was: Re: Some randomnewbiequestions
by Simon Marlow 11 Jan '05

11 Jan '05

On 11 January 2005 06:52, Andre Pang wrote: > Is there a Wiki page or URL with the steram proposal? There is now: http://www.haskell.org/hawiki/HaskellStreamIO Simon

2 1

Re: Hugs vs GHC (again)
by Dimitry Golubovsky 11 Jan '05

11 Jan '05

Ketil, Ketil Malde wrote: > Dimitry Golubovsky <golubovsky(a)gmail.com> writes: > > (Did you intend this for the list?) Yes, and I re-posted similar message on the list. > > >>>I think perhaps the answer is all of the above. The functions could >>>be defined in multiple modules, so that 'ASCII.isSpace' would match >>>the "normal" space character only, while 'Unicode.isSpace' could match >>>all the weird and wonderful stuff in the standard. >> > >>And then there might be a bunch of (perhaps autogenerated) >>locale-matching modules like ISO8859_1, KOI_8 etc. > > > Well - maybe. Another option is for these to require conversion from > to Unicode. > Right, because input of "encoding-specific" functions will be Unicode anyway. And AFAIK conversion from/to unicode may be also contained in localedef files (or for instance in Java CharToXXXX, XXXToChar classes) - I mean that there must be enough information around to build those modules automatically. Except for Unicode itself which would be autogenerated from the Unicode database files like multiple examples of doing this (including mine) that were posted on this list. Dimitry Golubovsky Middletown, CT

2 1

RE: [Haskell-cafe] Hugs vs GHC (again) was: Re: Somerandomnewbiequestions
by Simon Marlow 11 Jan '05

11 Jan '05

On 07 January 2005 17:10, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: >>>> - Can the Char type hold the full range of Unicode characters? >>>> This has been true in GHC for some time, and is now true in >>>> Hugs. I don't think it's true in nhc98 (please correct me if >>>> I'm wrong). >>> >>> You're wrong :-). nhc98 has always had 32-bit characters >>> internally. >> >> I checked the nhc98 sources, and it seems that maxBound::Char is >> '\255'. > > Yes, but nothing prevents you from creating a larger character by e.g. > (toEnum 0x12345678) :: Char Then I respectfully submit a bug report :-) It shouldn't be possible to create a value of Char outside minBound..maxBound. It's possible the report doesn't say this explicitly, but see for example section 6.3.4. Cheers, Simon

1 0

RE: [Haskell-cafe] Re: Hugs vs GHC (again) was: Re: Some randomnewbiequestions
by Simon Marlow 11 Jan '05

11 Jan '05

On 11 January 2005 09:00, Sebastian Sylvan wrote: > On Mon, 10 Jan 2005 17:12:44 -0000, Simon Marlow > <simonmar(a)microsoft.com> wrote: > >> Not a problem. Have you looked at the streams proposal? >> > > I've missed most of the discussion on this, so if someone could just > clarify the reasons for a few things I find peculiar: > > * Prefixing function names with their types, not necessary with > qualified imports. I agree with this. > * Why not put isEOS in the InputStream class since it doesn't make > sense for OutputStreams? I think so, and there's a comment to that effect in the prototype code. > * Why not introduce an additional class BufferedStream containing the > the Buffering-functions (instead of having them in Stream and > resorting to weird failure-patterns for non-buffered streams): > setBufferMode :: s -> BufferMode -> IO () > getBufferMode :: s -> IO BufferMode > flush :: s -> IO () > sync :: s -> IO Bool > Where setBufferMode is not allowed to "fail" (by returning False). If > for some reason it does fail an exception is thrown. Same thing with > getBufferMode. It will return a Buffering or throw an exception (not > return "NoBuffering" instead of a failure). The prototype code has a separate Buffered class, with TextOutputStream an instance of it. I've been wondering whether having a generic buffering layer might be possible/desirable too, so you could do buffered binary I/O. Anyway, it would be good to record comments and suggestions like this on the wiki page (http://www.haskell.org/hawiki/HaskellStreamIO) Cheers, Simon

1 0

Re: [Haskell-cafe] The Implementation of Functional Programming Languages
by Graham Klyne 11 Jan '05

11 Jan '05

I think this is most welcome... I have the original printed version and have found it to be of great inspiration at various times. #g -- At 18:04 07/01/05 +0000, you wrote: >I'm happy to announce that my out-of-print 1987 book, > > The Implementation of Functional Programming Languages > >is now available online at > > >http://research.microsoft.com/%7Esimonpj/papers/slpj-book-1987/index.htm > >Very many thanks to Marnie Montgomery, who did all the work. > >Happy reading > >Simon >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe(a)haskell.org >http://www.haskell.org/mailman/listinfo/haskell-cafe ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact

1 0

Typing question
by Dmitri Pissarenko 11 Jan '05

11 Jan '05

Hello! I want to create two data types: a) Purchase, which represents purchase by a customer (two attributes - amount of the purchase and rebate, both Double's) b) Customer, which represents a customer and his/her purchases. This tuple has two attributes - customer ID and a list of all purchases. Customer ID is Int, list of all purchases is a list of instances of Purchase (see above item a)). So, I wrote this code: <code-snippet> data Purchase (price :: Double) (rebate :: Double) = -- error occurs here Purchase price rebate deriving (Show, Eq) data Customer (id :: Int) (purchases :: [Purchase]) = Participant id purchases deriving (Show, Eq) </code-snippet> When I try to load it into GHCi, I'm getting this error message: <error-message> Prelude> :reload Compiling Gs ( Gs.hs, interpreted ) Gs.hs:15: parse error on input `Double' Failed, modules loaded: none. </error-message> Line 15 is the first line of the code snippet above. I have three questions: a) How should I define the types of the attributes correctly? b) Is it possible to impose a constraint on the "constructor" of tuple Purchase, so that the compiler throws an error, if one tries to create a purchase where rebate is greater than price (rebate and price are given in absolute numbers; rebate is NOT a fraction of price) ? c) What is a correct name for "attributes" of tuples (such as price and rebate in Purchase) and "constructors" of tuples? Many thanks in advance Dmitri Pissarenko

2 1

RE: [Haskell-cafe] Re: Some random newbie questions
by Simon Peyton-Jones 11 Jan '05

11 Jan '05

| -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of John | Hughes | Sent: 10 January 2005 09:16 | To: haskell-cafe(a)haskell.org | Subject: [Haskell-cafe] Re: Some random newbie questions | | I seriously considered switching frlom Hugs to GHC for my introductory | programming class this year, but in the end stayed with Hugs because of | a single feature. | | I'm teaching beginning programmers, and for them at least, there is an | overwhelming volume of names to learn -- "what's that function?" is a | question they ask themselves often, as is "what's that type?". I teach | them that, whenever they see a name they don't recognise, they can find | out more about it using the :i command. This is a simple trick to learn, | that helps them understand points they've missed and catches | misapprehensions. | | My students also see type classes very early. I'll bet yours will too. | Even if one is very careful to restrict the examples in lectures so as | to avoid them (which is a bind), as soon as students try out Hugs for | themselves, they will make mistakes that generate error messages | referring to type classes. No problem: the question "what's that class?" | can ALSO be answered by :i. | | Now, at the beginning students have only a very rudimentary | understanding of classes. A class is a collection of types to them, | nothing more. In particular, the class definition itself is of little | use to them, since it often contains a very subtly chosen collection of | methods (just type :i Show, for example, which students do very early). | What IS useful, right from the beginning, is the list of instances. What | are Num types? Oh, integers and reals. What are Show types? Oh, pretty | much everything. Particularly when debugging "missing instance" errors, | this is just the information you need. | | Unfortunately, while Hugs prints the list of instances of a class in | response to :i, GHCi does not. It only prints the class definition -- | which, for my students, contains no useful information. For that reason | alone, I stuck with Hugs last year. | How about changing the behaviour of :i, Simon, so I can use GHCi | throughout next year? Done, some while ago. You want GHC 6.4! See below Simon Prelude> :i Show class Show a where showsPrec :: Int -> a -> String -> String show :: a -> String showList :: [a] -> String -> String -- Imported from `GHC.Show' instance Show IOMode -- Imported from `GHC.IOBase' instance Show IOException -- Imported from `GHC.IOBase' instance Show IOErrorType -- Imported from `GHC.IOBase' instance Show HandleType -- Imported from `GHC.IOBase' instance Show Handle -- Imported from `GHC.IOBase' instance Show ExitCode -- Imported from `GHC.IOBase' instance Show Exception -- Imported from `GHC.IOBase' instance Show BufferMode -- Imported from `GHC.IOBase' instance Show AsyncException -- Imported from `GHC.IOBase' instance Show ArrayException -- Imported from `GHC.IOBase' instance Show ArithException -- Imported from `GHC.IOBase' instance Show SeekMode -- Imported from `GHC.Handle' instance Show HandlePosn -- Imported from `GHC.Handle' instance Show CWchar -- Imported from `Foreign.C.Types' instance Show CUShort -- Imported from `Foreign.C.Types' instance Show CULong -- Imported from `Foreign.C.Types' instance Show CULLong -- Imported from `Foreign.C.Types' instance Show CUInt -- Imported from `Foreign.C.Types' instance Show CUChar -- Imported from `Foreign.C.Types' instance Show CTime -- Imported from `Foreign.C.Types' instance Show CSize -- Imported from `Foreign.C.Types' instance Show CSigAtomic -- Imported from `Foreign.C.Types' instance Show CShort -- Imported from `Foreign.C.Types' instance Show CSChar -- Imported from `Foreign.C.Types' instance Show CPtrdiff -- Imported from `Foreign.C.Types' instance Show CLong -- Imported from `Foreign.C.Types' instance Show CLLong -- Imported from `Foreign.C.Types' instance Show CLDouble -- Imported from `Foreign.C.Types' instance Show CInt -- Imported from `Foreign.C.Types' instance Show CFloat -- Imported from `Foreign.C.Types' instance Show CDouble -- Imported from `Foreign.C.Types' instance Show CClock -- Imported from `Foreign.C.Types' instance Show CChar -- Imported from `Foreign.C.Types' instance Show (GHC.Ptr.Ptr a) -- Imported from `Foreign.Ptr' instance Show (GHC.Ptr.FunPtr a) -- Imported from `Foreign.Ptr' instance Show Float -- Imported from `GHC.Float' instance Show Double -- Imported from `GHC.Float' instance Show Int8 -- Imported from `GHC.Int' instance Show Int64 -- Imported from `GHC.Int' instance Show Int32 -- Imported from `GHC.Int' instance Show Int16 -- Imported from `GHC.Int' instance Show Word8 -- Imported from `GHC.Word' instance Show Word64 -- Imported from `GHC.Word' instance Show Word32 -- Imported from `GHC.Word' instance Show Word16 -- Imported from `GHC.Word' instance Show Word -- Imported from `GHC.Word' instance Show [a] -- Imported from `GHC.Show' instance Show (a, b, c, d, e) -- Imported from `GHC.Show' instance Show (a, b, c, d) -- Imported from `GHC.Show' instance Show (a, b, c) -- Imported from `GHC.Show' instance Show (a, b) -- Imported from `GHC.Show' instance Show () -- Imported from `GHC.Show' instance Show Ordering -- Imported from `GHC.Show' instance Show (Maybe a) -- Imported from `GHC.Show' instance Show Int -- Imported from `GHC.Show' instance Show (Either a b) -- Imported from `GHC.Show' instance Show Char -- Imported from `GHC.Show' instance Show Bool -- Imported from `GHC.Show' Prelude>

2 1

RE: [Haskell-cafe] Hugs vs GHC (again) was: Re: Some random newbiequestions
by Simon Marlow 11 Jan '05

11 Jan '05

Here's a summary of the state of Unicode support in GHC and other compilers. There are several aspects: - Can the Char type hold the full range of Unicode characters? This has been true in GHC for some time, and is now true in Hugs. I don't think it's true in nhc98 (please correct me if I'm wrong). - Do the character class functions (isUpper, isAlpha etc.) work correctly on the full range of Unicode characters? This is true in Hugs. It's true with GHC on some systems (basically we were lazy and used the underlying C library's support here, which is patchy). - Can you use (some encoding of) Unicode for your Haskell source files? I don't think this is true in any Haskell compiler right now. - Can you do String I/O in some encoding of Unicode? No Haskell compiler has support for this yet, and there are design decisions to be made. Some progress has been made on an experimental prototype (see recent discussion on this list). - What about Unicode FilePaths? This was discussed a few months ago on the haskell(-cafe) list, no support yet in any compiler. Cheers, Simon On 07 January 2005 00:52, Dimitry Golubovsky wrote: > Hi, > > Looks like Hugs and GHC are being compared again ;) > > I am just interested to know, what is the current status of Unicode > support in GHC? Hugs has had it for about a year (or more, in CVS) at > least at the level of recognizing character categories and simple case > conversions based on the Unicode database files. Also UTF-8 or > locale-based I/O encoding conversion to internal Unicode is available. > Does GHC has similar support? > > Some time ago (about 1.5 years) I tried to play with Unicode I/O in > GHC, and it looked like it did not have much Unicode support back > then (at least on I/O level). Has anything progressed in this regard > since then? > > Most of this list subscribers seem to be GHC users, so can anybody > answer? > > BTW when answering the original post (brief quote below) different > aspects were mentioned, but not internationalization ones. Is it > really not that important? > > Dimitry Golubovsky > Middletown, CT > > Benjamin Pierce wrote: > > >> * What are the relative advantages of Hugs and GHC, beyond the >> obvious (Hugs is smaller and easier for people not named Simon to >> modify, while GHC is a real compiler and has the most up-to-date >> hacks to the type checker)? Do people generally use one or the >> other for everything, or are they similar enough to use Hugs at >> some moments and GHC at others? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

9 9