- Haskell-Cafe - Haskell.org

RE: MArray and newSTUArray
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

Excellent idea. This does indeed seem to be the cleanest way to explain the necessary type constraints. I think we (Simon M) may add it to the library. Simon | -----Original Message----- | From: Dean Herington [mailto:heringto@cs.unc.edu] | Sent: 13 February 2003 15:21 | To: haskell-cafe(a)haskell.org | Subject: MArray and newSTUArray | | The MArray class in Data.Array.MArray is a very nice abstraction. | However, when creating an array whose type partakes of MArray, say | STUArray, I find myself defining and using a type-specific creation | function, such as: | | newSTUArray :: (MArray (STUArray s) e (ST s), Ix i) | => (i, i) -> e -> ST s (STUArray s i e) | newSTUArray = newArray | | so that I don't have to give a complicated type declaration for each use | of `newArray` that creates an STUArray. | | 1. Is there a better (more concise/convenient) way to provide the | necessary type information? | 2. If not, should functions such as `newSTUArray` be provided in the | libraries? | | -- Dean | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: Pattern matching, implict par. question
by Simon Peyton-Jones 14 Feb '03

14 Feb '03

Well the definition clearly falls under the monomorphism restriction as laid down by the Report, because you haven't given a signature for us,n,j. I suggest ctPar :: (?ctPar::CTPar) => CTPar ctPar = ?ctPar (us,n,j) = ctPar That should work Simon | -----Original Message----- | From: Jorge Adriano [mailto:jadrian@mat.uc.pt] | Sent: 13 February 2003 14:36 | To: Haskell Cafe; glasgow-haskell-users(a)haskell.org | Subject: Pattern matching, implict par. question | | Hello, When trying | | type CTPar = ([Double],Int,Int) | ctPar ::(?ctPar::CTPar)=>CTPar | ctPar@(us,n,j) = ?ctPar | | I got this error message in ghci is: | " Illegal overloaded type signature(s) | in a binding group for ctPar, us, n, j | that falls under the monomorphism restriction | When generalising the type(s) for ctPar, us, n, j | Failed, modules loaded: CrossTypeOps." | | Should the monomorphis restriction really apply here? | The values of us,j,n do depend on the context, but not their types (right?). | | J.A. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

How to read an initialization file.
by Thaddeus L. Olczyk 14 Feb '03

14 Feb '03

I'm stuck on a problem in a program and I suspect one that I will keep encountering. I need to be able to read from an initialization file a set of values, as a simple example let us take three variables: base_dir, user_name, log_file. I need to be able to access these values effieiently and from virtually anywhere in the program. It would be nice to "at some point" open the file and read all these variables, all at once. Can anyone help?

1 0

ANNOUNCE: 0th International Obfuscated Haskell Code Contest
by shae＠webwitches.com 14 Feb '03

14 Feb '03

In the spirit of http://ioccc.org/ .... Bring us your poor, weary, downtrodden, and unreadable source code. Come to the 0th INTERNATIONAL OBFUSCATED HASKELL CODE CONTEST! This contest is meant to be fun, short, and not terribly serious. Also, then we'll know if a 1st IOHCC is a good idea. * submission deadline: March 1st, 2003 * send your code (and/or complaints/comments) to: mailto:iohc-jury@mgoetze.net * winners and possible rules updates at http://iohc.mgoetze.net/ Submission must have source and some sort of description file so that the jurors won't be totally mystified. Rules: * LICENSE: your code must an original work, all submitted programs are thereby put in the public domain. All explicitly copyrighted programs will be rejected. (see the IOCCC rules) * max source size: 5k * entry must include shell script or makefile to perform the build * build must not require human intervention * doing something interesting and/or useful is a plus * we particularly like games * limited abuse of the rules is acceptable if the specific abuses are documented, and the judges think it's cool Portability: * latest public release versions of hugs, ghc, nhc, hbc, helium acceptable (any we missed?) * may use common Haskell tools such as hmake, happy etc. * program need not be portable across Haskell implementations * must be relatively portable across platforms (i.e. no Linux-specificisms) * use of ANSI/VTxxx codes which are not limited to a specific brand of terminal and work in a standard xterm are portable * FFI is discouraged, we want real Haskell source. Five person jury: * Richard Braakman (dark) * Shae Erisson (shapr) * Ian Lynagh (Igloo) * Andrew Bromage (Pseudonym) * Manuel Chakravarty (Chilli) We expect judging to take two to three weeks, but this is the 0th IOHCC, could be shorter or longer. Awards will depend on the specific entries, but may include: * best one-liner - less than 80 chars not counting imports * best .signature sized - 4x80 or 4x76 or whatever * best game * best H98-only program * best exploit of a compiler bug * most useful program * most creative layout * best abuse of implementation-specific extensions * best abuse of the type system * best abuse of category theory * worst abuse of the rules Spirit, point, reason: * to seek out new lifeforms and new civilizations * to boldly go where no Haskell programmer has ever wanted to be! Semi-seriously, obfuscated code shows neat and unusual ways of structuring a program, cool tricks, dark nooks and crannies you've never thought of, and is generally a good way to shake off all that software discipline and stomp around in the muddy world of spaghetti code for a quick vacation. -- Shae Matijs Erisson - 2 days older than RFC0226 #haskell on irc.freenode.net - We Put the Funk in Funktion

1 0

Bracketless branch if, sugar to taste...
by Alex Ferguson 13 Feb '03

13 Feb '03

Yes indeed, one can further "sugar" Keith's suggestion to eliminate the need for brackets around the branches. Though as this means using an infix operator then and else, with corresponding mangling of the lexical appearance of same, this becomes increasingly a matter of taste (or perhaps, in need of sound dental advice). Example: ifM (return (1==1)) `then_` print (2+3) `else_` print (3+4) Of course, the type errors are going to start looking more and more mysterious if you get 'em in the wrong place... Cheers, Alex. ________ infix 4 `then_` infix 5 `else_` data Branches a = Branches a a then_ :: (a->a->a) -> Branches a -> a then_ sel (Branches t e) = sel t e else_ :: a->a->Branches a else_ t e = Branches t e iff b t e = if b then t else e ifM b t e = do test <- b if test then t else e

1 0

MArray and newSTUArray
by Dean Herington 13 Feb '03

13 Feb '03

The MArray class in Data.Array.MArray is a very nice abstraction. However, when creating an array whose type partakes of MArray, say STUArray, I find myself defining and using a type-specific creation function, such as: newSTUArray :: (MArray (STUArray s) e (ST s), Ix i) => (i, i) -> e -> ST s (STUArray s i e) newSTUArray = newArray so that I don't have to give a complicated type declaration for each use of `newArray` that creates an STUArray. 1. Is there a better (more concise/convenient) way to provide the necessary type information? 2. If not, should functions such as `newSTUArray` be provided in the libraries? -- Dean

1 0

RE: a monadic if or case?
by Kevin Millikin 13 Feb '03

13 Feb '03

On Thursday, February 13, 2003 8:33 AM, Arjan van IJzendoorn [SMTP:afie@cs.uu.nl] wrote: > Not with the syntactic sugar of 'if'. > But you can write [warning: untested code ahead] > > ifM :: IO Bool -> IO a -> IO a -> IO a > ifM test yes no = do > b <- test > if b then yes else no I had ifM :: Monad m => m Bool -> m a -> m a -> m a ifM tst thn els = do b <- tst if b then thn else els And I just tested it. ---- Kevin S. Millikin Architecture Technology Corporation Research Scientist Specialists in Computer Architecture kmillikin(a)atcorp.com http://www.atcorp.com

1 0

Re: Learning Haskell moved
by Matthew Donadio 13 Feb '03

13 Feb '03

>> I would add some significant papers, such as John Hughes' >> "Why functional programming matters", etc. > >I've added that paper to the introduction. Other suggestions are welcome. "Conception, Evolution, and Application of Functional Programming Languages", Paul Hudak, ACM Computing Surveys, Volume 21, Number 3, pp.359-411, 1989 This would probably be good, too. --Matthew Donadio (m.p.donadio(a)ieee.org)

1 0

Pattern matching, implict par. question
by Jorge Adriano 13 Feb '03

13 Feb '03

Hello, When trying type CTPar = ([Double],Int,Int) ctPar ::(?ctPar::CTPar)=>CTPar ctPar@(us,n,j) = ?ctPar I got this error message in ghci is: " Illegal overloaded type signature(s) in a binding group for ctPar, us, n, j that falls under the monomorphism restriction When generalising the type(s) for ctPar, us, n, j Failed, modules loaded: CrossTypeOps." Should the monomorphis restriction really apply here? The values of us,j,n do depend on the context, but not their types (right?). J.A.

1 0

ANNOUNCE: Learning Haskell portal, version 0.1
by Arjan van IJzendoorn 13 Feb '03

13 Feb '03

Hello all, Often we see messages from people who want to learn Haskell (something we applaud), but don't know where to begin. The Haskell homepage offers a lot of information, links and papers, but there is no page aimed specifically at beginning programmers. That's why I started to collect some links and put them on one single webpage. I thought about what the target audience would be interested in: getting an implementation, buying a book, reading course material, looking up functions in references and so on. The page I have now is a first start and I will work on it more. I've probably overseen many good tutorials, maybe a book here or there, listed an incorrect pro or con of an implementation and what not. Please tell me about it. If you have useful contributions ( nice slides, exercises with(out) solutions, some handout you give to your students which everyone could benefit from ) tell me about it, too. Enough talk: http://www.cs.uu.nl/~afie/haskell/LearningHaskell.html Cheers, Arjan PS: As one of the people in the Helium team I would not recommend beginners to use Helium yet. The absence of classes which leads to simpler types and messages is just not compatible with the text books and other teaching materials. Our plan is to add enough support for classes so that you can use the books without modification. This can be expected this summer. From that moment on, I will definitely recommend Helium to beginners since the feedback from the system is really great.

2 2

RE: SPECIALIZE pragma
by Simon Peyton-Jones 13 Feb '03

13 Feb '03

If 'g' is defined in the same module, yes. Simon | -----Original Message----- | From: Sengan.Baring-Gould(a)nsc.com [mailto:Sengan.Baring-Gould@nsc.com] | Sent: 12 February 2003 23:45 | To: haskell-cafe(a)haskell.org | Subject: SPECIALIZE pragma | | Hi, | | If I have {-# SPECIALIZE f ... #-}, | and I have f x y = ... (g x) ..., | will g also be specialized? | | Thanks, | | Sengan | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Good Tutorial to start with?
by Daniel Jian 13 Feb '03

13 Feb '03

Dear All, I use a lot of C++, a little bit of Java, and some other programming languages. But none of them is a functional language. I would like to learn Haskell as my first introduction to FP. Do any of you know a good tutorial for me to start with? FYI, it is easier for me to learn a new language by looking at the source code first, and then the explanation of that code. I browsed through the internet for quite a while, but still I could not find any tutorial that is not tediously long in discussion. Thanks! best regards, Daniel Jian __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com

2 2

SPECIALIZE pragma
by Sengan.Baring-Gould＠nsc.com 13 Feb '03

13 Feb '03

Hi, If I have {-# SPECIALIZE f ... #-}, and I have f x y = ... (g x) ..., will g also be specialized? Thanks, Sengan

1 0

Beginner help
by JJ 12 Feb '03

12 Feb '03

(My apologies if this is off topic) Functional programming is completely new to me. I've been doing imperative programming for quite a while. >From my perspective, the learning curve for Haskell seems to be near vertical. I've read several things on the web, and am working my way through The Haskell School of Expression. Any words of wisdom? ADVthanksANCE, JJ Be Kind, Be Careful, Be Yourself

5 5

Very simple question
by Jorge Adriano 11 Feb '03

11 Feb '03

On style, yes. A concrete example of what I asked before. The following doesn't type check for obvious reasons. In your opinion what is the most elegant way to fix it? Like I said, I'm starting to feel like defining my own operators is the way to go. On the other hand, this kind of situation seems quite common and there are no such operators in the standard libraries, so I might be wrong here. Opinions anyone? J.A. ------------------ Source Code: ------------------ module TypeCheck where import Data.Array import Data.Ix bigR :: Double bigR = sum[a!(i,j)*(r!i - n*b!i)*(r!j-n*b!j) | (i,j)<-range(bounds a)]/n a :: Array (Int,Int) Double b :: Array Int Double r :: Array Int Int n :: Int a=undefined b=undefined r=undefined n=undefined

1 0

cant find module PrelPtr
by Chris Moline 10 Feb '03

10 Feb '03

hi i am learning to use green card. when i try to compile the preprocessed haskell file i get the error message ghc-5.04.2: chasing modules from: main.hs ghc-5.04.2: can't find module `PrelPtr' (while processing "/usr/local/lib/green-card/StdDIS.hs") i am using green-card 2.05 and ghc 5.04.2 on freebsd 4.7. what can i do to fix this? chris

1 0

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

10 Feb '03

> SM> TimeDiff has a perfectly well-defined meaning for Eq > and Ord: one > SM> TimeDiff is equal to another iff all the fields are > respectively equal. > > Yes, sure, Eq and Ord are defined by > deriving (Eq, Ord, ...) > but this does not make much sense if the representation for a > particular duration is not unique. All I'm asking for is a unique > representation for a duration and I do not see how you can do this > using not uniquely defined terms like "month" and "year". TimeDiff isn't a "duration", it's a way of specifying time offsets whose duration depends on the base to which the offset is being added. If we only had constant-duration offsets, then there would be no way to say "give me a ClockTime for this time next Wednesday". The problem is really that all the different kinds of offset are lumped into one type: there ought to be a TimeDiffSeconds, TimeDiffMonths, and so on. TimeDiffSeconds is a constant-duration offset, but TimeDiffMonths isn't. The problem with lumping them into one type is that if multiple components are non-zero, you don't know in which order to add them. The TimeExts library gives you separate differences like these, BTW. [snip] > SM> This isn't a problem with the spec, I think. A > TimeDiff of "1 month" is > SM> precisely a difference, which, when added to a given > ClockTime, produces > SM> a ClockTime which is one month later (with respect to > some timezone, > SM> presumably UTC since it isn't specified otherwise). > That is, January > SM> 12th 12:00 UTC becomes February 12th 12:00 UTC, and > so on. Adding one > SM> month to certain ClockTimes is meaningless: eg. > adding one month to > SM> January 31st doesn't work. > > Unfortunately, with UTC, this goes on to make adding *anything* except > seconds to certain ClockTimes (namely the instants of leap seconds, > eg, what happens if you add 1 minute to 23:59:60 ? This is a perfectly > legal UTC time on a day with a leap second) meaningless. That's right, and here I'm not sure whether the right behaviour is to raise an exception or to "roll over" to the next nearest date/time. I believe TimeExts does some kind of rolling over, but I'm not sure of the exact semantics (George?). > My take would > be to look at an established standard for expressing time durations > (eg, ISO8601) and just adhere to that (but not the POSIX standard, > please!). Personally, I think that it is unacceptable to make > something like addToClockTime a partial function. Ok, ISO8601 seems to specify only constant-duration time intervals, but allows them to be given in terms of years, months, days etc., where a month is specified to be 30 days, it seems, and similar approximations are made for the other units. This seems very odd to me, but if that's what you want... (it's possible I'm misreading the standard, or maybe I got hold of an old version though). > SM> At least, that's how I believe it is supposed to work. GHC's > SM> implementation *is* completely wrong (which is > perhaps where some of the > SM> confusion comes from), but the TimeExts library can > be used instead of > SM> TimeDiffs. > > Well, so you agree that the behavior of the Time module is > unspecified! Of course, I'm not blaming GHC's implementation which > cannot be right under these circumstances. Yes, it's unspecified, but I also think many people misinterpret it to be more broken than it actually is. > SM> This is a perfectly reasonable definition of absolute > time, we don't > SM> need to talk about TAI at all, except to define what > the epoch means. > > Agreed! So what is epoch? Is it > "Seconds since 00:00:00 on 1 Jan 1970 [TAI]"? I guess so... GHC's implementation will be whatever the C library uses, which I assume is the one you specified above (at least on a decent implementation). Cheers, Simon

2 1

Error in Haskell 98 Report 'lex' function
by Simon Peyton-Jones 10 Feb '03

10 Feb '03

Ah yes, this is a genuine bug. Haskell 98 changed at some point to allow identifiers and field labels with a leading '_', but the library didn't keep pace. I'll fix GHC. HOWEVER, the sad thing is that the same bug is in the Haskell 98 Report itself, now begin printed. The definition of lex is wrong. Ah well, I knew this would happen. I'd better start keeping a new bug list! Simon -----Original Message----- From: Jong Keun Na [mailto:jongkn@microsoft.com] Sent: 10 February 2003 02:48 To: Simon Peyton-Jones; haskell-cafe(a)haskell.org Subject: RE: Auto generated instance codes through 'deriving' The following code snippet not works correctly. >data Obj = Obj {_id, p1, p2::Int} deriving (Show, Read) >showObj :: Obj -> String >showObj o = show o >main = do print (showObj (read "Obj {_id=1,p1=10,p2=20}")) > return () The reason is because I used the property name with underscore char like "_id". Looking into auto generated class codes and seeing they show it should encompass identifiers with special characters with parenthesis, so I tried "Obj {(_id)=1,p1=10,p2=20}" as argument of read func. But, the result is same, parse error. Is this problem by-design or bug? Or Am I missing any point? Thanks, /JongKeun -----Original Message----- From: Simon Peyton-Jones Sent: Friday, February 07, 2003 5:41 PM To: Jong Keun Na; haskell-cafe(a)haskell.org Subject: RE: Auto generated instance codes through 'deriving' 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

3 2

RE: Auto generated instance codes through 'deriving'
by Jong Keun Na 10 Feb '03

10 Feb '03

The following code snippet not works correctly. >data Obj = Obj {_id, p1, p2::Int} deriving (Show, Read) >showObj :: Obj -> String >showObj o = show o >main = do print (showObj (read "Obj {_id=1,p1=10,p2=20}")) > return () The reason is because I used the property name with underscore char like "_id". Looking into auto generated class codes and seeing they show it should encompass identifiers with special characters with parenthesis, so I tried "Obj {(_id)=1,p1=10,p2=20}" as argument of read func. But, the result is same, parse error. Is this problem by-design or bug? Or Am I missing any point? Thanks, /JongKeun -----Original Message----- From: Simon Peyton-Jones Sent: Friday, February 07, 2003 5:41 PM To: Jong Keun Na; haskell-cafe(a)haskell.org Subject: RE: Auto generated instance codes through 'deriving' 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

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

09 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

Re: arrays and lamda terms
by oleg＠pobox.com 05 Feb '03

05 Feb '03

Cagdas Ozgenc wrote: > Is it possible to encode an array using lamda terms only, and recover > the term specified by an index term in O(1) time? I'd like to go on a limb and argue that there is generally no such thing as O(1) array access operation. On the conventional hardware, the fastest access to the i-th element of an array 'ar' is expressed by the following formula, which underlies C "arrays": ar[i] = *(ar + i) The formula involves the addition of two numbers -- which is, generally, a O(log(n)) operation. Granted, if we operate in the restricted domain of mod 2^32 integers, addition can be considered O(1). If we stay in this domain however, the size of all our arrays is limited to M (which is 2^32, often less). If we implement our arrays as linked lists, the cost of accessing one element will not exceed M*2*cost(dereference), which is constant, which is O(1). Thus pedantically speaking, within the restricted integral domain, any terminating array access method is O(1). The choice of "hardware" may greatly affect the apparent complexity. For example, associative memory access is difficult on conventional architectures and fast for holographic memory. > Or is it possible in any rewriting system? If all your arrays are limited in size to 2^32, and if your re-writing system offers projection operators pi_0, pi_1, ... pi_4294967295 (i.e., the right "hardware"), well, then it is possible.

2 1

Stacking up state transformers
by Guest, Simon 05 Feb '03

05 Feb '03

Thanks to Andrew, I'm now backtracking my state correctly. Now what I want to do is have two elements of state, an element that gets backtracked, and an element that doesn't. My monad now looks like this: type NondetState bs ns a = StateT bs (NondetT (StateT ns Maybe)) a where bs is my backtracked state, and ns my non-backtracked state. I can still access my backtracked state using Control.Monad.State.{get,put}, but I can't access my non-backtracked state. How do I burrow through the stack of monad transformers to get and put the 'ns' state? Supplementary question: What documentation should I be reading? cheers, Simon

3 2

arrays and lamda terms
by Cagdas Ozgenc 04 Feb '03

04 Feb '03

Greetings. My question is not directly related to Haskell. Is it possible to encode an array using lamda terms only, and recover the term specified by an index term in O(1) time (in other words in one step reduction, without cheating using several steps behind the scenes)? Or is it possible in any rewriting system? I might not be making any sense, but I am sure there are people out there who can read my mind, and possibly put my question into better terminology. Thanks

2 1

RE: Concurrent-Haskell in GHC
by Simon Marlow 04 Feb '03

04 Feb '03

> | I've started looking into the docs on GHC's > | implementation of Concurrent-Haskell, and I got > | confused about the architecture. Different sources > | seem to indicate that it either: > | - Uses one OS thread, and blocking IO calls will > | therefore block all the Haskell-threads, or > | - Uses one OS thread, occasionaly (50 times a second?) > | calling select() to simulate blocking IO calls without > | blocking other Haskell-threads, or > | - Uses a pool of OS threads so that when a blocking IO > | call is made, another thread takes over execution. > > Basically the last of these. (At least in the most recent > GHC.) Simon > Marlow implemented a web server using Concurrent Haskell, and has a > paper about it too. http://www.haskell.org/~simonmar/bib.html But we should really point out that you get the second method by default; the "pool of OS threads" method is currently experimental and not enabled unless you rebuild GHC's RTS with the right flags. The default single-threaded IO multiplexing works pretty well, although it doesn't scale to multiple processors of course. Cheers, Simon

1 0

Re: GHC and C++ (was RE: Creating COM objects and passing out pointers to them via a COM interface)
by Sarah Thompson 04 Feb '03

04 Feb '03

I'm replying to two threads at the same time and cross posting my reply, because they are very relevant to each other. I'm sorry if anyone here ends up seeing this more than once as a consequence. [s] ------ > Sarah > > Did you get this problem sorted out? Not directly. I ended up building an 'outer' COM component in C++ that mapped an MSXML-like interface onto a simpler, internal COM component that wraps up the Haskell code. This approach seems to work well - I might have been able to build the necessary wrapper directly in Haskell using HDirect, but I was becoming aware that I was probably starting to take up an unreasonable amount of Sigbjorn's time with increasingly detailed questions and I didn't have time to figure out the necessary intricacies from scratch. HDirect seems very good, but I don't think it's currently in quite as stable a state as the main GHC release. The problems I had in building a version that works with the current GHC are an example of this. I'm not complaining - it worked well in the end, but I do think it might be a 'good thing' to consider rolling HDirect into the main GHC release at some point. The other thing that bit me was exception handling, or rather the default behaviour when an uncaught exception 'falls out' and reaches the top level of the runtime system. Currently, the functionality appears to be to abort the current process. Whilst this is probably desirable for a typical application executable (be that console or GUI based), it is a problem if it happens inside a COM component. My thinking is quite straightforward on this. Preferred behaviour should really be for a call to a COM component to fail returning an error code, rather than abort the calling process. 'Server-style' applications are usually expected to keep running when minor faults occur, rather than terminate. HDirect/GHC's current behaviour makes this difficult to achieve - I managed to successfully catch exceptions, but the price was needing to use some code based on DeepSeq to force deep strict evaluation for all state updates. This (seemingly) was the only way I could stop exceptions from happening in the context of the automatically generated COM wrapper - passing it a fully evaluated data structure was apparently the only solution available. However, this does break the advantages of laziness as applied to the current state of the object - it would be pretty neat, for example, to be able to define a view of a database as the result of an expression involving relational algebra combinators, with the query evaluated one record at a time as the data is pulled back by the client application. The need for DeepSeq forces strict evaluation, so this benefit is lost. This is actually more of an issue than it might immediately seem - many queries don't actually need to retrieve all of a record set before useful things can be done. A particular example is updating a GUI, where a list box reflects the results of a query. Lazy evaluation will allow the screen to start updating more or less immediately even on a query that returns thousands of records - strict evaluation might incur a delay of a few seconds (for a very complex query or a large database) before updates can start happening. In an ideal world, what I'd dearly love to see would be an HDirect option that allows a choice between existing functionality and having calls return a failure code, or better still allowing a user-supplied handler function to determine the correct course of action. So, to sum up my wish list: 1. A facility to replace the default uncaught exception behaviour for COM objects and similar shared library code 2. HDirect rolled into the main GHC tree 3. A facility within HDirect to create COM objects based on existing (Haskell) data structures, returning an interface pointer as a return parameter on a call to an existing COM object. (This was the question Simon asked if I'd had an answer to - I've attached a copy below for reference). Sarah PS: I've not yet looked closely at the .NET integration in GHC yet, but I can imagine myself having a very similar wish list in that case too. -------- Hi again, A slightly harder problem this time. I want to implement something that looks something like the Microsoft XML parser. This is a very COM heavy contraption that provides an interface that looks to client applications like a tree of COM objects that reflects the internal structure of an XML document. The idea is, you start with the document object, make a method call requesting the root node, and have a COM object that wraps that node returned to you. You can then request the children of that node, and their children and siblings, all which involves being passed back interface pointers to COM objects. Effectively, there is one COM object per syntactic item in the XML document. I already have my document object working nicely. This is where the actual database resides. I want to be able to spawn views of this database as COM objects. When I've done this in the past (using ATL mostly, euuuugh), I've used an IDL definition something like HRESULT CreateView([in,string] BSTR query, [out,retval] IDbView **); What's the correct way to implement the necessary Haskell code to create the coclass and return a pointer to it? I fiddled around for ages, but either couldn't get GHC to like the types I was using, or when I finally got it to compile, I found that my test harness was being passed an invalid COM object. This should be simple stuff, so I'm sure someone will have done it! Secondly, it is a nasty, though fairly common trick, if you know your objects are going to be created in the same process space, to allow them some 'behind the scenes' communication. In my case, I'd like to avoid needing to serialise and deserialise the data in a view during creation of these child objects (of which there may be a great many, and which may be created on the fly rather often). Ideally, I'd like to be able to do something like: newView :: String -> State -> IO State newView db (State st) = do db <- readIORef st r <- newIORef db -- Insert some kind of COM magic here return (State r) so the database content gets copied within the Haskell environment (lazily, I'd hope), without needing to be serialised and deserialised. Is this feasible? One (messy) approach might be to create a bunch of extra interfaces on the main database object, then create 'thin wrapper' child objects that simply make calls back into the parent object. I'm not so keen on that for various reasons, however. Sarah

1 0

RE: Concurrent-Haskell in GHC
by Simon Peyton-Jones 04 Feb '03

04 Feb '03

| I've started looking into the docs on GHC's | implementation of Concurrent-Haskell, and I got | confused about the architecture. Different sources | seem to indicate that it either: | - Uses one OS thread, and blocking IO calls will | therefore block all the Haskell-threads, or | - Uses one OS thread, occasionaly (50 times a second?) | calling select() to simulate blocking IO calls without | blocking other Haskell-threads, or | - Uses a pool of OS threads so that when a blocking IO | call is made, another thread takes over execution. Basically the last of these. (At least in the most recent GHC.) Simon Marlow implemented a web server using Concurrent Haskell, and has a paper about it too. http://www.haskell.org/~simonmar/bib.html Simon

1 0

Re: Global variables?
by oleg＠pobox.com 04 Feb '03

04 Feb '03

Richard Uhtenwoldt wrote: > (2) the global variable has a lexical scope that extends over > the bulk of the program. > It strikes me as a simple and obvious application of lexical > scope, and I am surprised that it received no mention in the > discussions on this list and in Hughes's paper. Something like that has been mentioned before: http://www.haskell.org/pipermail/haskell-cafe/2002-September/003423.html If the global variables are used to store parameters that are read from configuration files at the beginning and are not changed since, it's possible to make such "global variables" _ordinary_ top-level variables scoped through the entire program. No unsafe operations, no pragmas, no implicit variables, and no reliance on the IO monad for variable access are needed. The previous article said the approach was ugly. I'd like to take it back. The approach relies on an ability to dynamically compile and link in a program -- something that we all do and something that is specifically emphasized in the GHCi documentation. The following code is snipped from the previous article and adjusted for GHC. The latter is used as a meta-evaluator/dynamic linker of sorts. Suppose file '/tmp/a.hs' contains the following user program. Suppose the program needs a global, configurational variable named Config.config_item. >>> File "/tmp/a.hs" > import Config (config_item) > > foo = "foo shows: " ++ (show config_item) > > bar = "bar shows: " ++ (show config_item) > > main = do > print foo > print bar > print foo Realistically a user program would do something more with the global variables than just showing them. We specifically illustrate multiple access to the global variable, to indicate that such access poses no trouble (in contrast to the unsafePerformIO approach). We also note that user computations 'foo' and 'bar' do not have to be annotated with the type and the name of the global variable -- in contrast to the implicit variable approach. Furthermore, foo and bar are pure functions rather than IO actions. The value of the global variable Config.config_item is computed by reading it from the configuration file. The computation occurs before running of the main function of the user program. The following code accomplishes the trick *>>> File "/tmp/b.lhs" *>>> To run this code, do *>>> ghci -package posix b.lhs *>>> Be sure /tmp/config exists and contains an integer value > import System (system, ExitCode(ExitSuccess)) > import Posix(executeFile) > > myconfig_file = "/tmp/config" > > phaseII_var = "/tmp/Config.hs" > phaseII_const = "/tmp/a.hs" > phaseII_eval = "ghc --make " > phaseII_result = "/tmp/a.out" > > nl = "\n" > > writeConfig :: Int -> IO () > writeConfig num = > do > writeFile phaseII_var $ > concat > ["module Config (config_item) where", nl, > "config_item =", show num, nl] > > > runSuperIO () = system (phaseII_eval ++ > phaseII_const ++ " -o " ++ phaseII_result) > >>= \ExitSuccess -> > executeFile phaseII_result False [] Nothing > > main = readFile myconfig_file >>= writeConfig . read >>= runSuperIO We can indeed be sure that the configurational variable is set before the first attempt to access it.

1 0

Concurrent-Haskell in GHC
by Jonathan Holt 04 Feb '03

04 Feb '03

Hi guys! I'm considering doing a server project in Haskell, using GHC, and I'm having the old dilema of trying to figure out the best way of handling multiple concurrent connections: multiplexing or multithreading. I've started looking into the docs on GHC's implementation of Concurrent-Haskell, and I got confused about the architecture. Different sources seem to indicate that it either: - Uses one OS thread, and blocking IO calls will therefore block all the Haskell-threads, or - Uses one OS thread, occasionaly (50 times a second?) calling select() to simulate blocking IO calls without blocking other Haskell-threads, or - Uses a pool of OS threads so that when a blocking IO call is made, another thread takes over execution. So which is right for the current stable GHC? And how efficient/scalable is it? Thanks, -Jony __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

1 0

Global variables?
by pavel＠joker.botik.ru 03 Feb '03

03 Feb '03

Hello, Is it even possible to make a "global variable" in Haskell? If yes, how? Thanks. -- Zhbanov Pavel

8 7

Re: Global variables?
by Jon Cast 03 Feb '03

03 Feb '03

Fergus Henderson <fjh(a)cs.mu.OZ.AU> wrote: > On 02-Feb-2003, Jon Cast <jcast(a)ou.edu> wrote: > > Claus Reinke <claus.reinke(a)talk21.com> wrote: > > > It is the programmer's responsibility to verify that none of these > > > problems matter in the particular case of usage. Since many > > > advances in compiler technology tend to invalidate those > > > verifications, it is almost impossible to guarantee safety in such > > > cases > > Even with sufficiently liberal use of {-# NOINLINE #-}? > Haskell Report, Appendix E (Compiler Pragmas): "An implementation is > not required to respect any pragma". Right. So perhaps the Haskell Report should take more notice of global variables. But considering that it doesn't, and there is no completely portable mechanism for getting global mutables, it seems to me that bashing any alternative as non-portable is missing the point :) > > > There you went.. into one of the many available traps in this > > > mine-field: > > > You argue that unallocated IORefs don't matter as long as "the" > > > IORef is allocated before it is dereferenced. But that's just part > > > of the problem - what about inlining globalVar, creating multiple > > > IORefs? > > {-# NOINLINE globalVar #-} :) > What about creating two copies of globalVar, neither of them inlined? > A compiler could do that to improve performance on some architectures, > e.g. by allowing the function to be called via a short jump > instruction rather than a long jump instruction. See above. > -- > Fergus Henderson <fjh(a)cs.mu.oz.au> | "I have always known that the pursuit > The University of Melbourne | of excellence is a lethal habit" > WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

1 0

Re: Global variables?
by Jon Cast 03 Feb '03

03 Feb '03

Claus Reinke <claus.reinke(a)talk21.com> wrote: > > > > import IORef > > > > import IOExts > > > > > > > > globalVar :: IORef Int > > > > globalVar = unsafePerformIO $ newIORef 0 > > > John Hughes wrote a nice pearl on the subject, see > > > http://www.math.chalmers.se/~rjmh/Globals.ps > > This paper claims ``unsafePerformIO is unsafe''. That's not > > actually true in the sense meant; unsafePerformIO merely has safety > > pre-conditions that the compiler can't check. > Which is the main sense in which the 'unsafe' prefix is usually meant > to be interpreted, and that is bad enough (see below, then re-read > John's quote of Simon PJ's description of unsafePerformIO;-). In > particular, the 'unsafe'-prefix is not a hint for the implementation > to treat something with extra care, but a hint for the programmer that > the implementation may shake unsafe expressions around like any other > ones (inlining, cse, ..), even though that is bound to lead to > problems with the hidden side-effects. So you have to be careful. If that weren't what I said, I'd disagree with you :) > It is the programmer's responsibility to verify that none of these > problems matter in the particular case of usage. Since many advances > in compiler technology tend to invalidate those verifications, it is > almost impossible to guarantee safety in such cases Even with sufficiently liberal use of {-# NOINLINE #-}? > - about the best one can hope for is to identify and document > precisely which assumptions need to be made to "guarantee" > safety. Unfortunately, this leaves it to users to figure out whether > the assumptions made by 'unsafe' authors (e.g., no inlining) are still > valid at the point of use.. > Btw, when talking about unsafety in that paper, John also happens to > point out the other little problem with unsafePerformIO: it permits to > break type safety (many a good spirit has stumbled over that > "polymorphic references" problem in other functional languages). > > The precondition (proof obligation) of unsafePerformIO is that the > > order in which unsafePerformIOs are performed cannot affect the > > outcome of the program. However, in this case, ordering doesn't > > matter: the only side effect is allocation of a new IORef, and > > IORefs are sufficiently opaque we don't care (or really know) about > > un-allocated IORefs while the only case we care about the > > now-allocated IORef is when we de-reference it. But, that forces > > the IORef, which executes the unsafePerformIO. So, whenever we > > access the variable, it is allocated. Therefore, the outcome of the > > program (regardless of the order of evaluation) is the same as if > > all such global variable declarations are executed before main > > begins executing. So, the outcome is independent of the order of > > evaluation. > > There you go: the precondition of unsafePerformIO is satisfied, so > > the usage is safe. > There you went.. into one of the many available traps in this > mine-field: > You argue that unallocated IORefs don't matter as long as "the" IORef > is allocated before it is dereferenced. But that's just part of the > problem - what about inlining globalVar, creating multiple IORefs? {-# NOINLINE globalVar #-} :) > Remember that, by using unsafePerformIO, you've given the compiler the > license to treat globalVar as an expression without side-effects, and > for those inlining is a common first step to enable further > optimisations (last time I checked, the language report didn't even > guarantee the sharing on which the globalVar trick depends)! Now there > are multiple side-effects instead of a single one, and read-and > write-accesses are spread out over the multiple copies of your IORef, > none of which is likely to hold the value you'd like it to have.. > Cheers, > Claus Jon Cast

2 1

Re: Global variables?
by Jon Cast 03 Feb '03

03 Feb '03

Andrew J Bromage <ajb(a)spamcop.net> wrote: > G'day all. > On Fri, Jan 31, 2003 at 01:54:26PM -0600, Jon Cast wrote: > > Otherwise, though, see my other post on this subject: > > unsafePerformIO will perform its action when the variable is > > accessed, so you can't write a Haskell program which differentiates > > between what any compiler actually does and running the variable > > allocations before main. > As has been pointed out, there is no language requirement for a > Haskell implementation to be "fully lazy". In particular, it is > technically possible for an implementation to garbage collect > globalVar and re-evaluate it on the next call. So, the technique is implementation-dependent. Since Hughes' recommendation is equally non-portable, I don't see this as a serious problem in this case. > Haskell 2 should probably have a pragma controlling this. IMO, that would be a good idea :) > Cheers, > Andrew Bromage

1 0

Re: Global variables?
by Jon Cast 03 Feb '03

03 Feb '03

Patrik Jansson <patrikj(a)cs.chalmers.se> wrote: > On Fri, 31 Jan 2003, Jon Cast wrote: > > Otherwise, though, see my other post on this subject: > > unsafePerformIO will perform its action when the variable is > > accessed, so you can't write a Haskell program which differentiates > > between what any compiler actually does and running the variable > > allocations before main. > If you initialize this "global variable" with a value from a file > which is changed by main (or over time) then order does matter. 1. Why would you do this? In any case, the solution adopted in C (initialize the global statically with ``no value'' (0, NULL, Nothing, etc.) and overwrite it at a fixed point in main or elsewhere) should be good enough. 2. In any case, my claim is actually: If a :: IO alpha, for monomorphic alpha, and a's only interaction with the state consists of either creating new IORefs or accessing IORefs created by a, then unsafePerformIO's result is unaffected by the order of evaluation. > I claim unsafePerformIO is very often unsafe It's always potentially unsafe. However, it is always possible to prove that a particular application is safe (under sufficiently stringent conditions, of course). > - the question is more like if the "level of unsafety" is acceptable > for a particular application. There is no "level of unsafety". There is only the level of trust you put in your proof of satisfaction of unsafePerformIO's proof obligation and your view of the acceptability of the portability restrictions of your proof. > /Patrik Jon Cast

1 0

RE: Problem with backtracking monad transformer
by Guest, Simon 03 Feb '03

03 Feb '03

Hi, > On Thu, Jan 30, 2003 at 01:55:50PM -0000, Guest, Simon wrote: > > > I'm trying to make a backtracking state monad using Ralf Hinze's > > backtracking monad transformer. My problem is that it > > won't backtrack very far. > > > > Suppose I try ( a >> b ) `mplus` c. > > > > If b fails, it should try c, but it doesn't rewind past a. Andrew Bromage wrote: > > I've compared it with my own > well-tested implementation and it seems identical modulo renamings. The similarity is explained by the fact that I looked at your example on the Haskell Wiki as well as Ralf's paper, so thanks for that useful page. > > In case you want to compare: > > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/hfl/hfl/mtl/ I will have a look at try to see what I am doing wrong. > > I didn't follow the rest of the code, so I suspect the problem is > elsewhere. One place to look is here: > > > -- backtracking state monad > > -- > > type NDSM st a = BACKTR (SM st) a > > You may have meant to stack the monad transformers in a different > order. This bit I don't understand. I only have one monad transformer, which I use to transform my SM monad. I have an uneasy feeling that my observe is in the wrong place (passed to runSM), but again, I can't see what else I should have done. Thanks for the assurance, but I'm still head scratching for now. cheers, Simon

2 1

Re: Global variables?
by Jon Cast 03 Feb '03

03 Feb '03

Nick Name <nick.name(a)inwind.it> wrote: > On Fri, 31 Jan 2003 07:47:43 +0000 > Glynn Clements <glynn.clements(a)virgin.net> wrote: > > The usual fudge is: > > import IORef > > import IOExts > > globalVar :: IORef Int > > globalVar = unsafePerformIO $ newIORef 0 > I see in the documentation of unsafePerformIO that no one makes > guarantees about the order in wich unsafePerformIO arguments are > performed (especially they don't have to be executed BEFORE main), so > this trick should not be adviced as a general practice; it should be > pointed out that it works in GHC but could not work in other > compilers. English nit: I think you mean ``could fail in other compilers'': it's not really impossible for the trick to work in other compilers than GHC. Otherwise, though, see my other post on this subject: unsafePerformIO will perform its action when the variable is accessed, so you can't write a Haskell program which differentiates between what any compiler actually does and running the variable allocations before main. > Vincenzo > -- > Fedeli alla linea, anche quando non c' Quando l'imperatore > malato, quando muore,o dubbioso, o perplesso. Fedeli alla linea > la linea non c'. [CCCP] Jon Cast

3 2

Re: Global variables?
by Jon Cast 02 Feb '03

02 Feb '03

Ralf Hinze <ralf(a)informatik.uni-bonn.de> wrote: > > Pavel G. Zhbanov wrote: > > > Is it even possible to make a "global variable" in Haskell? If > > > yes, how? > > The usual fudge is: > > import IORef > > import IOExts > > > > globalVar :: IORef Int > > globalVar = unsafePerformIO $ newIORef 0 > > However, beware of creating more than one "global variable" of the > > same type. If you enable optimisation, common subexpression > > elimination may result in both names referring to the same IORef. > John Hughes wrote a nice pearl on the subject, see > http://www.math.chalmers.se/~rjmh/Globals.ps This paper claims ``unsafePerformIO is unsafe''. That's not actually true in the sense meant; unsafePerformIO merely has safety pre-conditions that the compiler can't check. However, there's nothing wrong with using it (or wrapping it) as long as the preconditions are checked. In fact, IMO, it's /better/ to use unsafePerformIO in a common case like this, because exactly when the preconditions are satisfied will be much better understood. The precondition (proof obligation) of unsafePerformIO is that the order in which unsafePerformIOs are performed cannot affect the outcome of the program. However, in this case, ordering doesn't matter: the only side effect is allocation of a new IORef, and IORefs are sufficiently opaque we don't care (or really know) about un-allocated IORefs while the only case we care about the now-allocated IORef is when we de-reference it. But, that forces the IORef, which executes the unsafePerformIO. So, whenever we access the variable, it is allocated. Therefore, the outcome of the program (regardless of the order of evaluation) is the same as if all such global variable declarations are executed before main begins executing. So, the outcome is independent of the order of evaluation. There you go: the precondition of unsafePerformIO is satisfied, so the usage is safe. > Cheers, Ralf Jon Cast

2 1

how to open a file descriptor
by David Roundy 02 Feb '03

02 Feb '03

Hello. I'm in the process of interfacing with some C code (libcurl), and I thought that the easiest way to transfer the data in (which is a file transfered over the network) would be to open a pipe and write it into the pipe, and then to pass the pipe over to haskell where I could read it with the IO monad normally. Is there any nice way to open up a file descriptor? I was looking at the ghc internal code, which has an openFd function that would do what I want, but it doesn't seem to be exported. :( Any ideas? -- David Roundy http://civet.berkeley.edu/droundy/

2 2

Re: Global variables?
by Jon Cast 31 Jan '03

31 Jan '03

Glynn Clements <glynn.clements(a)virgin.net> wrote: > Pavel G. Zhbanov wrote: > > Is it even possible to make a "global variable" in Haskell? If yes, > > how? > The usual fudge is: > import IORef > import IOExts > globalVar :: IORef Int > globalVar = unsafePerformIO $ newIORef 0 > However, beware of creating more than one "global variable" of the > same type. If you enable optimisation, common subexpression > elimination may result in both names referring to the same IORef. Is this true? It seems wrong---I don't think expressions involving unsafePerformIO should be combined, for precisely this reason. Even if it is true, though, the following kludge should work: > {-# NOINLINE mkGlobalVar #-} > mkGlobalVar :: String -> alpha -> IORef alpha > mkGlobalVar name value = usafePerformIO (newIORef value) > globalVar = mkGlobalVar "globalVar" 0 This ensures that no common sub-expression elimination will be performed. > -- > Glynn Clements <glynn.clements(a)virgin.net> Jon Cast

1 0

Now solved [was RE: Problem with backtracking monad transformer]
by Guest, Simon 31 Jan '03

31 Jan '03

Andrew Bromage wrote: > > You may have meant to stack the monad transformers in a different > > order. I finally understand. This was exactly my problem. I had to discard my state monad, and use a state monad transformer on the simple backtracking monad (not the backtracking monad transformer on the state monad). Now it works fine (of course). Thanks for the help. cheers, Simon

1 0

Nine open CSE positions at Chalmers
by Patrik Jansson 31 Jan '03

31 Jan '03

The School of Computer Science and Engineering (at Chalmers Univ. in Gotheburg, Sweden) announces 9 open positions (teaching+research): http://www.cse.chalmers.se/doit/doiteng/vacancies/positions.html Apply or spread the word! (List relevance: Many of us use Haskell both in teaching and in research.) /Patrik PS. From my point of view, Haskellers with a background in Software Engineering / Information systems / Human Computer Interaction etc. are extra welcome!

1 0

``Cannot instantiate a type variable with a forall-type''
by Jon Cast 31 Jan '03

31 Jan '03

Why does GHC place this constraint? I would expect forall to be predicative, and a type variable to range over all types, but obviously I'm missing something. Jon Cast

1 0