- Haskell-Cafe - Haskell.org

Extended functionality for record field accessors
by Henning Thielemann 16 Oct '06

16 Oct '06

Here is some proposal for Haskell 2 1/2 or so: {- | In Haskell 98 the name of a record field is automatically also the name of a function which gets the value of the according field. E.g. if we have @ data Pair a b = Pair {first :: a, second :: b} @ then @ first :: Pair a b -> a second :: Pair a b -> b @ However for setting or modifying a field value we need to use some syntactic sugar, which is often clumsy. @ modifyFirst :: (a -> a) -> (Pair a b -> Pair a b) modifyFirst f r@(Pair {first=a}) = r{first = f a} @ We propose to extend the meaning of the record field names to a function which allows setting, getting and modifying values easily. -} module RecordAccess where import Control.Monad.State (MonadState) import qualified Control.Monad.State as State {- | The access functions we propose, look very similar to those needed for List.mapAccumL (but parameter order is swapped) and State monad. They get the new value of the field and the record and return the old value of the field and the record with the updated field. -} type Accessor r a = a -> r -> (a, r) {- * Access helper functions, these are similar to State methods and should be in Prelude -} {- | Set the value of a field. -} set :: Accessor r a -> a -> r -> r set f x = snd . f x {- | Get the value of a field. -} get :: Accessor r a -> r -> a get f = fst . f undefined {- | Transform the value of a field by a function. -} modify :: Accessor r a -> (a -> a) -> (r -> r) modify f g rOld = let (a,rNew) = f (g a) rOld in rNew {- * Access helper functions in a State monad. -} setState :: MonadState r m => Accessor r a -> a -> m () setState f x = State.modify (set f x) getState :: MonadState r m => Accessor r a -> m a getState f = State.gets (get f) modifyState :: MonadState r m => Accessor r a -> (a -> a) -> m () modifyState f g = State.modify (modify f g) {- * Example accessors for the pair type -} {- | Access to the first value of a pair. -} first :: Accessor (a,b) a first xNew (xOld,y) = (xOld, (xNew,y)) {- | Access to the second value of a pair. -} second :: Accessor (a,b) b second yNew (x,yOld) = (yOld, (x,yNew)) {- * Example accessors for the pair type -} {- | Example of using 'set', 'get', 'modify'. -} example :: Int example = get second $ modify second succ $ set first 'a' $ ('b',7) exampleState :: State.State (Char,Int) Int exampleState = do setState first 'a' modifyState second succ getState second

1 0

Debugging Newton's method for square roots
by Vraj Mohan 16 Oct '06

16 Oct '06

I am new to Haskell and need help in debugging my code. I wrote the following function for calculating square roots using Newton's method: my_sqrt :: Float -> Float my_sqrt x = improve 1 x where improve y x = if abs (y * y - x) < epsilon then y else improve ((y + (x/y))/ 2) x epsilon = 0.00001 This works for several examples that I tried out but goes into an infinite loop for my_sqrt 96. How do I go about debugging this code in GHC or Hugs? (The equivalent code is well-behaved on MIT Scheme)

8 8

Re[4]: [Haskell-cafe] windows file locking
by Bulat Ziganshin 15 Oct '06

15 Oct '06

Hello Stefan, Wednesday, October 11, 2006, 4:53:19 PM, you wrote: > So far the windows API seems to work for me. Currently I'm still struggling to not > write garbage to the file but the shared access works now. Does anyone have an > example how to use it (e.g. the implementation of hPutStr on windows or something, > i did not find it in the ghc source code)? > I tried to use Streams before but without the windows API. sorry, i'm a bit to fool you. there is a way to apply Handle API to HANDLE. you should just 1) open file using win32 API and get HANDLE 2) convert this HANDLE to FD using _open_osfhandle from win32 api 3) open Handle over FD using fdToHandle function from GHC.Handle module alternatively, you can use Streams with the same mechanism: 1) open file using win32 API and get HANDLE 2) convert this HANDLE to FD using _open_osfhandle from win32 api // it's in C language: fd = _open_osfhandle (someHANDLE, _O_TEXT | _O_WRONLY); 3) use bufferBlockStream to make full-featured Stream from this FD: do stream <- bufferBlockStream fd it is from MS docs: SUMMARY There are multiple types of file handles that can be opened using the Win32 API and the C Run-time: Returned Type File Creation API API Set --------------------------------------------- HANDLE CreateFile() Win32 HFILE OpenFile()/_lcreat() Win32 int _creat()/_open() C Run-time FILE * fopen() C Run-time In general, these file I/O "families" are incompatible with each other. On some implementations of the Win32 application programming interfaces (APIs), the OpenFile()/_lcreat() family of file I/O APIs are implemented as "wrappers" around the CreateFile() family of file I/O APIs, meaning that OpenFile(), _lcreat(), and _lopen() end up calling CreateFile(), returning the handle returned by CreateFile(), and do not maintain any state information about the file themselves. However, this is an implementation detail only and is NOT a design feature. NOTE: You cannot count on this being true on other implementations of the Win32 APIs. Win32 file I/O APIs may be written using different methods on other platforms, so reliance on this implementation detail may cause your application to fail. The rule to follow is to use one family of file I/O APIs and stick with them--do not open a file with _lopen() and read from it with ReadFile(), for example. This kind of incorrect use of the file I/O APIs can easily be caught by the compiler, because the file types (HFILE and HANDLE respectively) are incompatible with each other and the compiler will warn you (at warning level /w3 or higher) when you have incorrectly passed one type of file handle to a file I/O API that is expecting another, such as passing an HFILE type to ReadFile(HANDLE, ...) in the above example. MORE INFORMATION Compatibility ------------- The OpenFile() family of file I/O functions is provided only for compatibility with earlier versions of Windows. New Win32-based applications should use the CreateFile() family of file I/O APIs, which provide added functionality that the earlier file I/O APIs do not provide. Each of the two families of C Run-time file I/O APIs are incompatible with any of the other file I/O families. It is incorrect to open a file handle with one of the C Run-time file I/O APIs and operate on that file handle with any other family of file I/O APIs, nor can a C Run-time file I/O family operate on file handles opened by any other file I/O family. _get_osfhandle() ---------------- For the C Run-time unbuffered I/O family of APIs [_open(), and so forth], it is possible to extract the operating system handle that is associated with that C run-time handle via the _get_osfhandle() C Run-time API. The operating system handle is the handle stored in a C Run-time internal structure associated with that C Run-time file handle. This operating system handle is the handle that is returned from an operating system call made by the C Run-time to open a file [CreateFile() in this case] when you call one of the C Run-time unbuffered I/O APIs [_open(), _creat(), _sopen(), and so forth]. The _get_osfhandle() C Run-time call is provided for informational purposes only. Problems may occur if you read or write to the file using the operating system handle returned from _get_osfhandle(); for these reasons we recommend that you do not use the returned handle to read or write to the file. _open_osfhandle() ----------------- It is also possible to construct a C Run-time unbuffered file I/O handle from an operating system handle [a CreateFile() handle] with the _open_osfhandle() C Run-time API. In this case, the C Run-time uses the existing operating system handle that you pass in rather than opening the file itself. It is possible to use the original operating system handle to read or write to the file, but it is very important that you use only the original handle or the returned C Run-time handle to access the file, but not both, because the C Run-time maintains state information that will not be updated if you use the operating system handle to read or write to the file. -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

searching haskell.org
by Tamas K Papp 15 Oct '06

15 Oct '06

Hi, I noticed that searching on Haskell.org (using the Search feature at the bottom) doesn't work as I expected. For example, searching for "memoise" produces no results. http://www.google.com/search?q=memoise+site%3Ahaskell.org produces 18 hits. Is this intentional? Thanks, Tamas

3 3

Haskellers in London (UK)?
by Ben Moseley 15 Oct '06

15 Oct '06

Hi, Just thought I'd send out a quick mail to see if there are any other Haskellers based in London who might be interested in getting together occasionally. Anyway, if you're interested please reply to this. Cheers, --Ben

2 1

[off-topic / administrative] List Reply-to
by Matthias Fischmann 14 Oct '06

14 Oct '06

In my last post, I hit the wrong button again, with the effect of some noise in innocent mailboxes (sorry!). Some lists have the Reply-To: set to the list address. I think you can even configure the From: to be haskell-cafe instead of the poster, making the poster merely identifiable by the Sender: field. Do you have strong opinions on this subject? I would opt for setting Reply-To:; I think most of the follow-ups here are of some public interest, or easily filterable if not. cheers, matthias

10 14

function result caching
by Silviu Gheorghe 14 Oct '06

14 Oct '06

hello,I'm new to Haskell and I'm using it to do some simulations for a game, and I have a some functions that have as argument just one int (the current situation), but they do a lot of computations after that (future evolutions etc) I'd like to know if the results are "cached" by the compiler (there are only a few thousand values i call the functions on, but they are distributed on a fairly large interval (0-1000000), because of the codification. if they are not I'd like to know what is the best way to cache them manually, and where can I read more about this, and the optimizations the compiler does, because I've searched the web before and i found very little on this topic. thank you very much Silviu P.S. sorry for my English :)

10 14

What's going on in our courses?
by Walt Potter 14 Oct '06

14 Oct '06

All, Last Spring my Functional Programming class implemented a Genetic Algorithm with Neural Networks that learned to play Nim. The students had a really good time--they also learned lots about Functional Programming with Haskell. Part of the final exam was a tournament. This Fall in AI we'll be doing GA's again and Genetic Programming. Is there a list or forum that talks about teaching our students about Haskell? Thanks, Walt

4 4

Howto Haskell in PocketPC?
by Iván Pérez Domínguez 14 Oct '06

14 Oct '06

Hi. Here a simple question: Is there any haskell compiler/interpreter or similar for PocketPC?

3 2

Fwd: [GHC] #939: Possible bug building wxhaskell
by Jason Dagit 14 Oct '06

14 Oct '06

I reported the following bug and received the response below. Any wxhaskell hackers up to the challenge? I'd really love to see the makefiles go away and see wxhaskell just use cabal but I don't know if that's possible given the wxhaskell build requirements. Any help is much appreciated. Thanks Jason ---------- Forwarded message ---------- From: GHC <trac(a)galois.com> Date: Oct 13, 2006 5:21 PM Subject: Re: [GHC] #939: Possible bug building wxhaskell To: dagit(a)codersbase.com #939: Possible bug building wxhaskell -------------------------------------+-------------------------------------- Reporter: dagit(a)codersbase.com | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.6 Severity: normal | Resolution: invalid Keywords: | Difficulty: Unknown Architecture: x86 | Os: Unknown -------------------------------------+-------------------------------------- Changes (by duncan): * resolution: => invalid * status: new => closed Comment: It's not a GHC bug. It's a problem with the way wxHaskell is built. Admitidedly this is due to a slight change in the way GHC manages packages but it's not a bug as such, wxHaskell just needs fixing. What needs to happen is that the packages must be registered locally before they get used in other packages. Also, instead of importing the modules from the other package directly from the directory with -i foo/, it must be via -package foo. So you'll need to get in contact with someone who knows enough about wxHaskell's build system to fix it. Try asking on the ghc-users or haskell-cafe mailing lists. ------------------------ The bug report: I appologize if this isn't a GHC bug but since it started happening after a GHC upgrade I suspect it's a GHC bug. After upgrading to ghc6.6 on windows (using the release binary) I tried to install the current wxhaskell release found here: http://wxhaskell.sourceforge.net/download.html (version wxhaskell-src-0.9.4-1.zip) I have used wxhaskell on this machine before with older version of ghc (including ghc6.5, specifically visual haskell) so my environment for building the wxhaskell source was already setup. When I first got the error below I thought maybe my version of wxhaskell was messed up so I redownloaded the above zip file and unzipped a fresh copy. I unziped the source then I typed: configure && make Things went along fairly smoothly for a while then suddenly I got this error message: ghc -c wx/src/Graphics/UI/WX/Types.hs -o out/wx/imports/Graphics/UI/WX/Types.o -iout/wx/imports -odir out/wx/imports -hidir out/wx/imports -fvia-C -package-name wx -iout/wx/imports wx/src/Graphics/UI/WX/Types.hs:94:0: Bad interface file: out/wx/imports/Graphics/UI/WXCore/Types.hi Something is amiss; requested module wx:Graphics.UI.WXCore.Types differs from name found in the interface file wxcore:Graphics.UI.WXCore.Types make: *** [out/wx/imports/Graphics/UI/WX/Types.o] Error 1

3 2