[Haskell-cafe] symbol type?
Is there an implementation of a symbol type in Haskell i.e. a string which has a constant-time comparison operation? Mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] symbol type?
On Tue, Oct 09, 2007 at 11:28:08PM -0700, Michael Vanier wrote: Is there an implementation of a symbol type in Haskell i.e. a string which has a constant-time comparison operation? Yes, I beleive GHC uses one (utils/FastString.lhs iirs) Stefan signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] symbol type?
I'm thinking of a symbol type that can be used for a compiler, so a simple algebraic data type wouldn't work. Unfortunately the GHC datatype isn't part of the GHC haskell libraries AFAICT. Mike Yitzchak Gale wrote: Michael Vanier wrote: Is there an implementation of a symbol type in Haskell i.e. a string which has a constant-time comparison operation? Stefan O'Rear wrote: Yes, I beleive GHC uses one (utils/FastString.lhs iirs) In some cases where you would need that in other languages, you would use an algebraic data type in Haskell, e.g.: data Color = Red | Orange | Yellow | Green | Blue | Purple deriving (Eq, Show) -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] symbol type?
Michael Vanier wrote: Is there an implementation of a symbol type in Haskell i.e. a string which has a constant-time comparison operation? Stefan O'Rear wrote: Yes, I beleive GHC uses one (utils/FastString.lhs iirs) In some cases where you would need that in other languages, you would use an algebraic data type in Haskell, e.g.: data Color = Red | Orange | Yellow | Green | Blue | Purple deriving (Eq, Show) -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
Dan Piponi wrote: The reusability of Num varies inversely with how many assumptions you make about it. A default implementation of pi would only increase usability, not decrease it. If you need a specialized definition of pi in your instance, you would provide it, just as you do now. If pi makes no sense in your instance and you need it to be an error, you would define pi = error pi in your face, just as you do now. And in the most common case, you would do nothing, instead of redifining pi in the obvious way, as you need to do now. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] symbol type?
Michael Vanier wrote: I'm thinking of a symbol type that can be used for a compiler... Ah. Perhaps Data.HashTable is what you are looking for then? -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
Yitzchak Gale writes: Dan Piponi wrote: The reusability of Num varies inversely with how many assumptions you make about it. A default implementation of pi would only increase usability, not decrease it. Suppose I believe you. (Actually, I am afraid, I have doubts.) Can you provide some examples of this increased usability? If possible, with a *relevant* context, which shows that PI should belong by default to the class Floating (whatever we mean by that...) Somehow I do not only think that the default implementation would be good for nothing, but that putting PI into Floating as a class member, serves nobody. I would be happy to learn that I am mistaken, but if it is just to save 5 seconds of a person who wants to pass smoothly between floating numbers of single and double precision... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] symbol type?
Hmm, I was hoping for something that didn't involve side effects. Mike Yitzchak Gale wrote: Michael Vanier wrote: I'm thinking of a symbol type that can be used for a compiler... Ah. Perhaps Data.HashTable is what you are looking for then? -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: symbol type?
Michael Vanier wrote:
Yitzchak Gale wrote:
Ah. Perhaps Data.HashTable is what you are looking
for then?
Hmm, I was hoping for something that didn't involve side effects.
There's always Data.Map
newtype Symbol = S { unS :: Integer } deriving (Eq, Ord)
type SymbolTable = Data.Map Symbol String
Regards,
apfelmus
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] symbol type?
Michael Vanier, before Yitzchak Gale and himself: I'm thinking of a symbol type that can be used for a compiler... Ah. Perhaps Data.HashTable is what you are looking for then? Hmm, I was hoping for something that didn't involve side effects. Some popular Haskell libraries suffer from acute Monaditis. The hash tables, the random numbers, etc., all is embedded in IO or something similar. But the essential algorithms are independent of this structuration. You *can* make streams of random numbers, using the same generation algorithms, without monads. You *can* make your hashed sequences of strings using lists, without monads. You will be simply obliged to carry with you all that stuff, as *explicit* world state. So, go ahead, extract from Data.Hash what you need, and structure the access and the eventual insertions/deletions in a way you wish. The basic idea of constant-time access strings is usually based on hashing. But you may wish to be more elegant... So, why not try tries? http://en.wikipedia.org/wiki/Trie http://www.eecs.harvard.edu/~ellard/Q-97/HTML/root/node22.html http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/Trie/ They have been implemented in Haskell as well, probably many, many times. But beware, Google on Haskell tries will offer you this: http://www.muskogeephoenix.com/highschoolsports/local_story_281003617.html Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pi
[EMAIL PROTECTED] wrote: Yitzchak Gale writes: Dan Piponi wrote: The reusability of Num varies inversely with how many assumptions you make about it. A default implementation of pi would only increase usability, not decrease it. Suppose I believe you. (Actually, I am afraid, I have doubts.) Can you provide some examples of this increased usability? If possible, with a *relevant* context, which shows that PI should belong by default to the class Floating (whatever we mean by that...) Somehow I do not only think that the default implementation would be good for nothing, but that putting PI into Floating as a class member, serves nobody. Putting 'pi' in the same class as the trigonometric functions is good design. I would be happy to learn that I am mistaken, but if it is just to save 5 seconds of a person who wants to pass smoothly between floating numbers of single and double precision... Jerzy Karczmarczuk Moving smoothly from single to double precision was much of the motivation to invent a mechanism like type classes in the first place. There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. And I would bet that some of the custom mathematical prelude replacements do this. If you do not want 'pi' in a class named Floating then you have to move all the transcendental stuff with it. If you do not want 'pi' in any class, then you cannot reasonably put any of the transcendental functions in a class. This would really degrade the API. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On Wed, 10 Oct 2007, Yitzchak Gale wrote: Dan Piponi wrote: The reusability of Num varies inversely with how many assumptions you make about it. A default implementation of pi would only increase usability, not decrease it. As the others have shown, you can compute PI in many ways. Which one is appropriate for the general case? Do you have so much types that you want to make instances of Floating, that manually defining 'pi' annoys you? Not giving a default implementation can even improve code because people have to think about a good implementation rather than relying on the default one. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pi
ChrisK writes: Putting 'pi' in the same class as the trigonometric functions is good design. If you wish so... But: Look, this is just a numeric constant. Would you like to have e, the Euler's constant, etc., as well, polluting the name space? What for? Moving smoothly from single to double precision was much of the motivation to invent a mechanism like type classes in the first place. Pardon? I think I remember the time when type classes have been introduced. The motivation you mention is not very visible, if at all... Actually, the numerical hierarchy was - as the French would say - bricolée with plenty of common sense, but without a decent methodology... The type classes is a splendid invention, much beyond any numerics. Besides, most people who *really* need FlP numerics use only the most precise available, the single precision stuff is becoming obsolete. There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... If you do not want 'pi' in a class named Floating then you have to move all the transcendental stuff with it. I would survive without moving anything anywhere, I assure you. If you do not want 'pi' in any class, then you cannot reasonably put any of the transcendental functions in a class. This would really degrade the API. What?? But it is just a numerical constant, no need to put it into a class, and nothing to do with the type_classing of related functions. e is not std. defined, and it doesn't kill people who use exponentials. Jerzy Karczmarczuk PS. One of the US Army folklore slogans say: if it's ain't broken, don't fix it. I would say: if what you need is one good exemplar, don't overload it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pi
On 2007-10-10, [EMAIL PROTECTED] wrote: ChrisK writes: Putting 'pi' in the same class as the trigonometric functions is good design. If you wish so... But: Look, this is just a numeric constant. Would you like to have e, the Euler's constant, etc., as well, polluting the name space? What for? It's there in the form (exp 1), after all. Yeah, you can get pi from (log i), but the multi-valuedness is annoying. Not an issue with exp. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... Yes, this is an issue. I wish there were a serious plan for reworking the numeric hierarchy for Haskell', but no one seems to interested. I've thought about writing something up, but with it not entirely clear what subset of MPTCs, FunDeps, and ATs will be in, that makes a design a bit trickier. class Exponential a where (^) :: (Integral b) = a - b - a What?? But it is just a numerical constant, no need to put it into a class, and nothing to do with the type_classing of related functions. e is not std. defined, and it doesn't kill people who use exponentials. As I said above, it effectively is. And, after all, 1, 2, 3, are constants of the typeclass Integral a = a, and 0.0, 1.348, 2.579, 3.7, etc. are in Floating a = a. So why not pi? -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: symbol type?
I wrote: Perhaps Data.HashTable is what you are looking for then? Jerzy Karczmarczuk wrote: extract from Data.Hash what you need... why not try tries? apfelmus wrote: There's always Data.Map Those are log n. I would personally use those for almost every application, but Mike says he wants constant time, for a compiler. Apparantly he wants to do some really serious optimization. HashTable is highly optimized. Of course, any memory access is really no better than log n, but HashTable uses the built-in parallelization available on most hardware that makes it look like constant time up to the size of system memory. (Otherwise known as accessing memory locations by address.) So yes, using this hardware has side effects and needs to be in IO. You could do it in the ST monad instead of the IO monad if you want, if that is any consolation. -Yitzchak -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: symbol type?
On Wed, 10 Oct 2007, Yitzchak Gale wrote: I wrote: Perhaps Data.HashTable is what you are looking for then? Jerzy Karczmarczuk wrote: extract from Data.Hash what you need... why not try tries? apfelmus wrote: There's always Data.Map Those are log n. I would personally use those for almost every application, but Mike says he wants constant time, for a compiler. However, I'm guessing he can use key comparison rather than value comparison - that changes things somewhat. -- [EMAIL PROTECTED] My religion says so explains your beliefs. But it doesn't explain why I should hold them as well, let alone be restricted by them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
Jules Bean writes: jerzy.karczmarczuk: Somehow I do not only think that the default implementation would be good for nothing, but that putting PI into Floating as a class member, serves nobody. Are you aware that it already is in the Floating class? A very interesting question. What do you think: do I know it or not, in view of the preceding discussion? This discussion is not about adding it, but about whether or not it should have a default. Are you suggesting pi should be removed from the Floating class? Then, what type would you give pi? First, I don't care whether it is there or not. When I use it, I define a particular instance (double, a constant formal series, a constant element of some differential algebra I enjoy personally, etc. No default would help me anyway). And then, I give it the type it deserves. Given that pi is often used with sin, as in sin (t * pi) it would seem very odd if pi forced that to be monomorphic: Oh yes, everybody in the world uses in ONE program several overloaded versions of pi, of the sine function, etc. Well, perhaps not everybody, for example I don't. And I use numerics quite often. How often *you* needed simultaneously overloaded pi and trigs in such a way that a default could help you? Answer sincerely (if you wish to answer at all...) Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
[EMAIL PROTECTED] wrote: Somehow I do not only think that the default implementation would be good for nothing, but that putting PI into Floating as a class member, serves nobody. Are you aware that it already is in the Floating class? This discussion is not about adding it, but about whether or not it should have a default. Are you suggesting pi should be removed from the Floating class? Then, what type would you give pi? Given that pi is often used with sin, as in sin (t * pi) it would seem very odd if pi forced that to be monomorphic: \t - sin t -- polymorphic \t - sin (t*pi) -- monomorphic ? Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
[EMAIL PROTECTED] wrote: This discussion is not about adding it, but about whether or not it should have a default. Are you suggesting pi should be removed from the Floating class? Then, what type would you give pi? First, I don't care whether it is there or not. When I use it, I define a particular instance (double, a constant formal series, a constant element of some differential algebra I enjoy personally, etc. No default would help me anyway). And then, I give it the type it deserves. Evidently you use pi in more 'serious' programs than I do. I use pi simply for geometric reasons, when I wish to specify circular or elliptic paths or similar constructions. For this I am pleased that the language libraries give me pi, because they save me the work of defining it. Given that pi is often used with sin, as in sin (t * pi) it would seem very odd if pi forced that to be monomorphic: Oh yes, everybody in the world uses in ONE program several overloaded versions of pi, of the sine function, etc. Well, perhaps not everybody, for example I don't. And I use numerics quite often. I like to write a complex function which might use multiple trig functions and pi, to describe the kind of thing about. I might want to use that function at Double, or GLdouble, or GLfloat, for various reasons. I don't particularly want to have to think about that kind of thing more than I have to. How often *you* needed simultaneously overloaded pi and trigs in such a way that a default could help you? Answer sincerely (if you wish to answer at all...) The default wouldn't help me at all. The default would help a (putative) designer of a new Floating instance, and I have never been one of those. If it is true of many Floating instances that (atan 1 * 4) is an accurate way to calculate pi (and it appears to be 'accurate enough' for Float and Double, on my computer) then adding it as a default doesn't appear to do any harm. I can't say I think it's very important either. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
Jules Bean said: If it is true of many Floating instances that (atan 1 * 4) is an accurate way to calculate pi (and it appears to be 'accurate enough' for Float and Double, on my computer) then adding it as a default doesn't appear to do any harm. Maybe this is the wrong point of view, but I think of defaults as impementations that are meant to be correct, but not necessarily the best way of doing things, leaving you the option to provide something better. For the case of power series as an instance of Num, using 4*atan 1 gives me the wrong thing as it triggers an infinite summation, whereas I'd want pi to simply equal the constant power series. Now you could counter that by saying that power series are an esoteric case. But apart from code in the libraries, most code I've seen that provides an instance of Num is doing something mildly esoteric. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hosting of Haskell project
I recently had reason to do some encoding-related coding and noticed that Haskell was somewhat lacking (I could only find code for base64, on the other hand there are two implementations of it :-). I've almost reached a state where I wouldn't be ashamed of sharing the code so I looked into my options of free hosting. It seems I only have one option for publishing the code: - Request a project on code.haskell.org. I could only find one option for a homepage for the project: - Create a page on the Wiki. There seems to be no option when it comes to tracking bugs. :-( I could also not locate any option for publishing haddock pages. :-( Have I missed anything? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus．therning＠gmail．com http://therning.org/magnus The British have the perfect temperament to be hackers--technically skilled, slightly disrespectful of authority, and just a touch of criminal behavior. -- Mary Ann Davidson, Oracle's Security Chief pgptL6w9sPYwH.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
On Wednesday 10 October 2007 11:05:28 Magnus Therning wrote: I recently had reason to do some encoding-related coding and noticed that Haskell was somewhat lacking (I could only find code for base64, on the other hand there are two implementations of it :-). I've almost reached a state where I wouldn't be ashamed of sharing the code so I looked into my options of free hosting. It seems I only have one option for publishing the code: - Request a project on code.haskell.org. I could only find one option for a homepage for the project: - Create a page on the Wiki. You could perhaps use code.haskell.org for this? I'm not sure if that's kosher. There seems to be no option when it comes to tracking bugs. :-( Xmonad uses Google Code's bug tracker, which has worked quite nicely. I could also not locate any option for publishing haddock pages. :-( Haddock documentation is automatically generated for released packages on hackage.haskell.org. Have I missed anything? /M Cheers, Spencer Janssen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PI and series
Dan Piponi writes: Jules Bean said: If it is true of many Floating instances that (atan 1 * 4) is an accurate way to calculate pi (and it appears to be 'accurate enough' for Float and Double, on my computer) then adding it as a default doesn't appear to do any harm. ... For the case of power series as an instance of Num, using 4*atan 1 gives me the wrong thing as it triggers an infinite summation, whereas I'd want pi to simply equal the constant power series. Now you could counter that by saying that power series are an esoteric case. But apart from code in the libraries, most code I've seen that provides an instance of Num is doing something mildly esoteric. For me series are not esoteric. But they can be implemented in a more cautious way, my own package behaves rationally: Prelude :l Series [1 of 1] Compiling Series ( Series.hs, interpreted ) -- nasty messages omitted. Ok, modules loaded: Series. *Series 4*atan 1 3.141592653589793 *Series 4*atan 1 :: Series Double Loading package haskell98 ... linking ... done. [3.141592653589793,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0, ...] *Series pi 3.141592653589793 *Series pi :: Series Double [3.141592653589793,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0, ...] *Series The implementation is, with (:-) as the cons-series operator, colon-dash for those whose browsers will convert it to some nice smiley...: zeros = 0:-zeros ... instance Floating a = Floating (Series a) where pi = pi:-zeros ... atan u@(u0:-_) = sInt (atan u0) (sDif u / (1+u*u)) etc. Of course, sDif differentiates and sInt integrates the series, see 2nd volume of Knuth for the algorithms, and papers, either a nice tutorial of Doug McIlroy, or my old paper for the implementation. The instance does it all. Default *could* help, and would give the same answer, but it would be much slower, so I would override it anyway. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hosting of Haskell project
magnus: I recently had reason to do some encoding-related coding and noticed that Haskell was somewhat lacking (I could only find code for base64, on the other hand there are two implementations of it :-). I've almost reached a state where I wouldn't be ashamed of sharing the code so I looked into my options of free hosting. It seems I only have one option for publishing the code: - Request a project on code.haskell.org. I could only find one option for a homepage for the project: - Create a page on the Wiki. There seems to be no option when it comes to tracking bugs. :-( I could also not locate any option for publishing haddock pages. :-( Have I missed anything? Publishing a code repository: code.haskell.org A homepage may be hosted on: code.haskell.org / community.haskell.org or the Haskell wiki Tracking bugs: Google's bug tracker is good Haddock pages: code.haskell.org or hackage.haskell.org (they'll be automatically generated) Check the http://haskell.org/haskellwiki/How_to_write_a_Haskell_program guide, which I think should be up to date regarding these options. Feedback on how to make this process clearer is welcomed! -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Adding GLUT package to WinHugs
The precompiled WinHugs Sep 2006 does not seem to come with the GLUT package. Although I'm able to add packages to GHC (using Cabal), I failed doing the same for WinHugs. How can I add the GLUT package to WinHugs? I tried starting MSYS, typed configure, which worked fine, but then make fails. Also typing runhugs Setup.hs configure fails with runhugs: Error occurred ERROR c:\program files\winhugs\packages\base\Text\ParserCombinators\ReadP.hs:156 - Syntax error in type expression (unexpected `.') Thanks for any help, Peter Verswyvelen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Adding GLUT package to WinHugs
Hi Peter, Also typing runhugs Setup.hs configure fails with runhugs: Error occurred ERROR c:\program files\winhugs\packages\base\Text\ParserCombinators\ReadP.hs:156 - Syntax error in type expression (unexpected `.') This is because Cabal gets it wrong. You need to type runhugs -98 Setup configure. There is an easy fix, which is for the Cabal developers to always use the bundled ReadP rather than the library one. I talked to Duncan about this in Germany, and he said he'd fix it :-) Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pi
On 2007-10-10, [EMAIL PROTECTED] wrote: Oh yes, everybody in the world uses in ONE program several overloaded versions of pi, of the sine function, etc. They don't have to be in the same program for overloaded versions to be semantically useful. They're not strictly necessary, but so? Having different programs use compatible conventions really is a win. How often *you* needed simultaneously overloaded pi and trigs in such a way that a default could help you? Answer sincerely (if you wish to answer at all...) Oh, just about never. But the defaults are the issue, not the simultaneously overloaded pi and trig functions. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On Wed, Oct 10, 2007 at 08:49:56AM -0700, Dan Piponi wrote: Jules Bean said: If it is true of many Floating instances that (atan 1 * 4) is an accurate way to calculate pi (and it appears to be 'accurate enough' for Float and Double, on my computer) then adding it as a default doesn't appear to do any harm. Maybe this is the wrong point of view, but I think of defaults as impementations that are meant to be correct, but not necessarily the best way of doing things, leaving you the option to provide something better. For the case of power series as an instance of Num, using 4*atan 1 gives me the wrong thing as it triggers an infinite summation, whereas I'd want pi to simply equal the constant power series. Now you could counter that by saying that power series are an esoteric case. But apart from code in the libraries, most code I've seen that provides an instance of Num is doing something mildly esoteric. It sounds like what you're actually saying is atan is buggy in these cases, since it leads to an infinite summation. Programmers who define a buggy atan would certainly be punished by this default for pi, but those who recognize that there is no reason to define a buggy atan at all and leave it undefined would have the same result as when there is no default for pi. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, Oct 10, 2007 at 12:29:07PM +0200, [EMAIL PROTECTED] wrote: ChrisK writes: There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... I suppose you're unfamiliar with the (^) operator, which does what you describe? It seems that you're arguing that (**) is placed in the correct class, since it's with the transcendental functions, and is implemented in terms of those transcendental functions. Where is the abomination here? -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
David Roundy wrote: On Wed, Oct 10, 2007 at 12:29:07PM +0200, [EMAIL PROTECTED] wrote: ChrisK writes: There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... I suppose you're unfamiliar with the (^) operator, which does what you describe? and (^^) which allows even negative integer exponents (at the price of requiring it to be possible to take the reciprocal of the base type) Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hosting of Haskell project
Haskell developers who want their own wiki with a simple issue tracker[1] and email integration[2] are also welcome to set one up at http://zwiki.org/FreeHosting . Cheers - Simon [1] http://zwiki.org/IssueTracker [2] http://zwiki.org/Mail ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, 10 Oct 2007, David Roundy wrote: On Wed, Oct 10, 2007 at 12:29:07PM +0200, [EMAIL PROTECTED] wrote: ChrisK writes: There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... I suppose you're unfamiliar with the (^) operator, which does what you describe? It seems that you're arguing that (**) is placed in the correct class, since it's with the transcendental functions, and is implemented in terms of those transcendental functions. Where is the abomination here? (**) should not exist, because there is no sensible definition for many operands for real numbers, and it becomes even worse for complex numbers. The more general the exponent, the more restricted is the basis and vice versa in order to get sound definitions. http://www.haskell.org/pipermail/haskell-cafe/2006-April/015329.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On Tue, 9 Oct 2007, Seth Gordon wrote: Henning Thielemann wrote: In my experience only the other way round works: Let people use C, Perl and Python until they find their programs unmaintainable. Then they will become interested in style and discipline and programming languages which _support_ good style. Perhaps this could be the kernel of a slogan: If you're having trouble maintaining your code because ..., perhaps you should try Haskell. Nervous? Anxious? You found an irreproducable bug in your program and have to fix it until tomorrow? You feel that your code needs essential cleanup, but you postponed it for long in order to not introduce new bugs? You can hardly maintain the code as it grows and grows? Pause a minute! Maybe we can help. Try Haskell. Its effect is immediate and long-lasting. There are warrantedly no side effects. It's scientifically approved. Available without prescription. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, 10 Oct 2007, Henning Thielemann wrote: (**) should not exist, because there is no sensible definition for many operands for real numbers, and it becomes even worse for complex numbers. The more general the exponent, the more restricted is the basis and vice versa in order to get sound definitions. http://www.haskell.org/pipermail/haskell-cafe/2006-April/015329.html I've put it on the Wiki: http://www.haskell.org/haskellwiki/Power_function ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] New slogan for haskell.org
Henning Thielemann wrote: There are warrantedly no side effects. It's scientifically approved. Available without prescription. :) Yes, but doctor, my space is leaking! ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, Oct 10, 2007 at 08:53:22PM +0200, Henning Thielemann wrote: On Wed, 10 Oct 2007, David Roundy wrote: It seems that you're arguing that (**) is placed in the correct class, since it's with the transcendental functions, and is implemented in terms of those transcendental functions. Where is the abomination here? (**) should not exist, because there is no sensible definition for many operands for real numbers, and it becomes even worse for complex numbers. The more general the exponent, the more restricted is the basis and vice versa in order to get sound definitions. Would you also prefer to eliminate sqrt and log? We've been using these functions for years (in other languages) without difficulty, and I don't see why this has changed. I think it's quite sensible, for instance, that passing a negative number as the first argument of (**) with the second argument non-integer leads to a NaN. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs, dotnet, C#...
On 10/3/07, Peter Verswyvelen [EMAIL PROTECTED] wrote:
I needed to type at least 3 times the amount of code, much
of which was boilerplate code, and the code is not elegant.
Reflection is your friend here.
Example. Code before reflection:
MyConfig
{
// some properties here
public MyConfig()
{
XmlDocument dom = XmlHelper.Loadxml(config.xml);
somevalue1 = getIntValue( dom, value1);
somevalue2 = getStringValue( dom, value2);
// blah, blah, blah...
}
}
With reflection:
MyConfig
{
// some properties here
public MyConfig()
{
ReflectionHelper.LoadMe( this, config.xml );
}
}
Just typed this in off the top of my head, so it might have errors in,
but you get the idea.
Of course, in this case you could just use Microsoft XmlSerializer,
but I quite like the flexibility of using my own serializer (it's not
that hard to write, just a hundred lines or so).
... but then, you can do something similar to display arbitrary
objects to html... or write to sql... or write to a proprietary
protocol... or ... many things!
I kindof know what you mean though. Declaring variable types is
kindof a pain, and of course anything to do with lists is insanely
easier to write in Haskell (/Erlang).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
Henning Thielemann wrote: It's scientifically approved. Available without prescription. Doctor doctor, can you curry me? Okay, I'm gonna stop now :-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs, dotnet, C#...
Thanks for the C# advise, but I was actually just comparing my C# code
with similar Haskell code. Yes, I also like aspect oriented programming,
dynamic code generation, and LINQ to avoid boilerplate code in C#, but
this is a Haskell group, and I want to be curried ;-)
But, for my students I'm actually building a small website, webservice,
database with some rich client applications, in C# 3.0... I would really
love to do that in Haskell, but I haven't got a clue how to start. I
would need a replacement for ASP.NET (e.g. generating HTML on the
server, similar to the PHP stuff), LINQ (translating Haskell to SQL),
webservice wrapper generators, webservice security, etc... Any hints on
useful Haskell packages would be very welcome. LINQ takes its ideas from
FP, so maybe Haskell already had something similar for decades? :)
Hugh Perkins wrote:
On 10/3/07, Peter Verswyvelen [EMAIL PROTECTED] wrote:
I needed to type at least 3 times the amount of code, much
of which was boilerplate code, and the code is not elegant.
Reflection is your friend here.
Example. Code before reflection:
MyConfig
{
// some properties here
public MyConfig()
{
XmlDocument dom = XmlHelper.Loadxml(config.xml);
somevalue1 = getIntValue( dom, value1);
somevalue2 = getStringValue( dom, value2);
// blah, blah, blah...
}
}
With reflection:
MyConfig
{
// some properties here
public MyConfig()
{
ReflectionHelper.LoadMe( this, config.xml );
}
}
Just typed this in off the top of my head, so it might have errors in,
but you get the idea.
Of course, in this case you could just use Microsoft XmlSerializer,
but I quite like the flexibility of using my own serializer (it's not
that hard to write, just a hundred lines or so).
... but then, you can do something similar to display arbitrary
objects to html... or write to sql... or write to a proprietary
protocol... or ... many things!
I kindof know what you mean though. Declaring variable types is
kindof a pain, and of course anything to do with lists is insanely
easier to write in Haskell (/Erlang).
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Adding GLUT package to WinHugs
Okay, I got one step further now, great! But when doing runhugs -98 Setup.hs build it complains about not having CPPHS, and the Windows binary link is broken :( *404: Not Found* *The file you have requested (http://www.cs.york.ac.uk/fp/cpphs-1.5-win32.zip) could not be found on this server.* I could try to build CPPHS from source, but I guess this should not happen? Thanks, Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
Claus Reinke wrote: since this doesn't seem to want to go away:-) 1. reverse psychology approach ... 2. mantra approach ... 3. secret cult approach ... 4. reach for the moon approach ... 5. The fun approach: Haskell: we put the Fun in Functor. I'm only half-joking, because for me personally, the number one reason I program in Haskell is that's it's just more fun than other languages I've tried. -cs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, 10 Oct 2007, David Roundy wrote: On Wed, Oct 10, 2007 at 08:53:22PM +0200, Henning Thielemann wrote: On Wed, 10 Oct 2007, David Roundy wrote: It seems that you're arguing that (**) is placed in the correct class, since it's with the transcendental functions, and is implemented in terms of those transcendental functions. Where is the abomination here? (**) should not exist, because there is no sensible definition for many operands for real numbers, and it becomes even worse for complex numbers. The more general the exponent, the more restricted is the basis and vice versa in order to get sound definitions. Would you also prefer to eliminate sqrt and log? No, why? We've been using these functions for years (in other languages) without difficulty, and I don't see why this has changed. You mentioned these functions - not me. I think it's quite sensible, for instance, that passing a negative number as the first argument of (**) with the second argument non-integer leads to a NaN. It would better to disallow negative bases completely for (**), because integers should be explicitly typed as integers and then (^^) can be used. I have already seen (x**2) and (e ** x) with (e = exp 1) in a Haskell library. Even better would be support for statically checked non-negative numbers. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
Henning Thielemann wrote: It would better to disallow negative bases completely for (**), because integers should be explicitly typed as integers and then (^^) can be used. I have already seen (x**2) and (e ** x) with (e = exp 1) in a Haskell library. Even better would be support for statically checked non-negative numbers. Um... Data.Word? (Now if you'd said strictly positive, that's harder...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: pi
David Roundy: jerzy.karczmarczuk: The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... I suppose you're unfamiliar with the (^) operator, which does what you describe? Sorry for being imprecise. I know (^), certainly, I wanted to suggest that the power should THEN belong to Num; if a multiplication is defined, surely the integer power as well, although this is somewhat delicate, since (*) defines a semi-group. That's why (^) for negative exponent, yells. And that's why we have also (^^) for Fractionals, which calls recip for the negative exponent. ... Where is the abomination here? Having THREE different power operators, one as a class member, others as normal functions. Do you think this is methodologically sane? === Other message: Would you also prefer to eliminate sqrt and log? We've been using these functions for years (in other languages)... I think it's quite sensible, for instance, that passing a negative number as the first argument of (**) with the second argument non-integer leads to a NaN. As you wish. But, since this is an overloaded class member, making it sensitive to the exponent being integer or not, is awkward. And perhaps I would *like* to see the result being complex, non NaN? Oh, you will say that it would break the typing. NaN also does it, in a sense. And this suggests that the type a-a-a is perhaps a wrong choice. Of course, this implies a similar criticism of log and sqrt... (One of my friends embeds the results of his functions in a generalization of Maybe [with different Nothings for different disasters], and a numerical result, if available, is always sound.) I am not sure whether Henning's ideas convince me entirely, and his statement In mathematical notation we don't respect types seems to be perhaps too strong (unless 'notation' means just the notation, which doesn't respect anything), but the relation between mathematical domains and the type system should one day be sanitized. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs, dotnet, C#...
Have you tried F#? I mean, I havent ;-) but maybe it's an interesting half-way house? Presumably you can use all the standard .Net libraries (maybe good enough for getting asp.net working etc?), and you can still use FP constructs? I understand F# is not pure (I think?), and doesnt have monads, but hey, life's full of compromises ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, Oct 10, 2007 at 10:32:55PM +0200, Henning Thielemann wrote: On Wed, 10 Oct 2007, David Roundy wrote: I think it's quite sensible, for instance, that passing a negative number as the first argument of (**) with the second argument non-integer leads to a NaN. It would better to disallow negative bases completely for (**), because integers should be explicitly typed as integers and then (^^) can be used. I have already seen (x**2) and (e ** x) with (e = exp 1) in a Haskell library. Even better would be support for statically checked non-negative numbers. I agree. -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
Nervous? Anxious? You found an irreproducable bug in your program and have to fix it until tomorrow? You feel that your code needs essential cleanup, but you postponed it for long in order to not introduce new bugs? You can hardly maintain the code as it grows and grows? Pause a minute! Maybe we can help. Try Haskell. Its effect is immediate and long-lasting. There are warrantedly no side effects. It's scientifically approved. Available without prescription. Aha! Instead of the lambda surrounded by mathematical stuff as the haskell.org logo, we need a picture of a medicine bottle. Haskell. Fewer headaches. No side effects. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, Oct 10, 2007 at 10:52:36PM +0200, [EMAIL PROTECTED] wrote: ... Where is the abomination here? Having THREE different power operators, one as a class member, others as normal functions. Do you think this is methodologically sane? It's a bit odd, but I prefer it to having one hyper-overloaded power operator that you hope will be efficient for small integer arguments. I suppose if I designed the hierarchy I'd probably have two power operators, both as class members. But then again, this would slow down some code, and it'd be nice to avoid that. Would you also prefer to eliminate sqrt and log? We've been using these functions for years (in other languages)... I think it's quite sensible, for instance, that passing a negative number as the first argument of (**) with the second argument non-integer leads to a NaN. As you wish. But, since this is an overloaded class member, making it sensitive to the exponent being integer or not, is awkward. And perhaps I would *like* to see the result being complex, non NaN? Oh, you will say that it would break the typing. NaN also does it, in a sense. And this suggests that the type a-a-a is perhaps a wrong choice. Of course, this implies a similar criticism of log and sqrt... (One of my friends embeds the results of his functions in a generalization of Maybe [with different Nothings for different disasters], and a numerical result, if available, is always sound.) There are certainly other options, but the only fast option that I'm aware of is to use IEEE floating point arithmetic (or rather, the approximation thereof which is provided by modern CPUs). It's awkward treating things specially based on whether the argument is an integer, but also provides a rather dramatic optimization for those who don't know it's better to use (^) or (^^). -- David Roundy Department of Physics Oregon State University ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
Aha! Instead of the lambda surrounded by mathematical stuff as the haskell.org logo, we need a picture of a medicine bottle. Haskell. Fewer headaches. No side effects. Alternatively, a picture of a red pill with an embossed lambda... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
Seth Gordon wrote: Aha! Instead of the lambda surrounded by mathematical stuff as the haskell.org logo, we need a picture of a medicine bottle. Haskell. Fewer headaches. No side effects. Alternatively, a picture of a red pill with an embossed lambda... I can hear millions of CS students across the globe yelling why oh why didn't I take the BLUE pill! ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
Henning Thielemann wrote: On Mon, 8 Oct 2007, Alistair Bayley wrote: On 08/10/2007, Henning Thielemann [EMAIL PROTECTED] wrote: You cannot turn any programmer into a disciplined programmer just by giving him a well designed language. I you try so, they will not like to use that language, will leave that language as soon as possible or they try to adapt the language to their style of programming. Well, I wasn't suggesting you'll create great programmers overnight, but you might expect that their appreciation of good design might improve after some Haskell exposure. Also, Haskell simply doesn't support some of the things that are common causes of errors in the enterprisey-language world. I recall reading something about one of the most common causes of errors in novice programs being type errors (presumably, once they'd got the program to compile i.e. there were no syntactic errors). And I'm under the (possibly mistaken) impression that some of the common errors non-novice programmers make are aliasing bugs, and/or use of global variables. Does anyone have references to studies confirming (or refuting) this? Thus, what happens today? People ask Haskell-Cafe how to implement global variables and they are advised to use IORefs and unsafePerformIO, although the better answer is: Why do you want to do this? Even Tackling the awkward squad considers unsafePerformIO an acceptable tool for handling global configuration files. I know of lots of people who proclaim that Linux sux because it isn't Windoze. I can well imagine hords of impatient Java programmers decrying Haskell because it isn't Java. (It's not even OO, man!) Haskell is many things, but few would seriously claim it to be the silver bullet to effortlessly writing bug-free code. (Indeed, the number of times my Haskell programs have locked up due to me accidentally writing let x = foo x...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
Derek Elkins wrote: On Mon, 2007-10-08 at 20:54 +1000, Thomas Conway wrote: I must say, I get that! but at the same time, of course, the high level abstraction is exactly what *we* love about Haskell. Then they should teach assembly not Python. In fact, I'd recommend assembly anyway. Ah yes, I remember my days of learning assembly at uni. That particular subject was taught by Mr Apathy. His attitude of well I'm supposed to tell you all this because it's in the exam, but you don't *really* need to know any of this stuff, modern compilers will do it all for you anyway really inspired me to learn. Not. But then, his attitude to *everything* seemed to follow a similar pattern. (E.g., the rebuilding of Colossus was pointless and it'll never be the original, etc.) Personally, I think knowing at least what assembly is *about* is very important for understanding what really happens deep down inside the machine. (I'm less sold on whether you really need to learn a particular dialect well enough to *program* in it...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
How about we just steal the BBC's slogan? Where different works ;-) Say what you like about Haskell, but it is undeniably very different to mainstream programming languages. This in itself is a potential advantage (and problem). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hugs, dotnet, C#...
On 10/10/07, Peter Verswyvelen [EMAIL PROTECTED] wrote: A noble goal and I wish you luck. I'd love to see if you get .NET working with Haskell - I have tried to figure it out from that old build of Hugs and never had any luck. Tantalizingly, the GHC source has some Dotnet stuff in it but it doesn't seem to be in use anywhere ( http://darcs.haskell.org/libraries/base/GHC/Dotnet.hs). Anyways, to answer your questions: * ASP.net - I think you want to look at HAps here - http://happs.org/ * LINQ, etc. - I don't know but there are several database libraries available on hackage ( http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Database) * webServices - Unknown but I have been using HXT lately (a haskell XML parser). It was a nightmare to figure out how to use it, but by reading the thesis about building an RDF parser I was able to make some decent progress. Maybe hackage has a webservice library? If you make some progress please share! Justin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan... (A long speculation)
On 10 Oct 2007, at 12:49 pm, [EMAIL PROTECTED] wrote: No, I am sorry, I know a little bit R. This is not a functional language. There is some laziness (which looks a bit like macro-processing), sure. There is no macro processing in R (or S). The manual speaks about promises and about forcing them. But, at the same time we read that the call by value IS the protocol. That is a misreading. Paragraph 2 of 4.3.3 says The semantics of invoking a function in R argument are call-by-value. ... But that is NOT to be read as strict, but as contrasting with call-by-reference. The very next paragraph makes this clear: R has a form of lazy evaluation of function arguments. Arguments are not evaluated until needed. It is important to realise that i some cases the argument will never be evaluated. ... A promise is forced when its value is needed. Promises in R are part of the underlying implementation; they are not (as in Scheme) a data type that the programmer can ever see or deal with. They are, in fact, just the same as unevaluated arguments in Haskell. And the language is impure, with reassignments. You were happy enough with Scheme. And you didn't say that there were no *pure* lazy dynamically typed languages, only that there were no lazy dynamically typed languages. If you think of R as a lazy and somewhat purer Scheme with lots of number-crunching support and C-like syntax, you won't go far wrong. I don't see how to make co-inductive constructions, infinite streams, etc. (Perhaps I didn't hard enough?...) I don't know what co-inductive constructions are. At first sight it looks to be very easy to make infinite streams in R, but it isn't, for an interesting reason. R doesn't evaluate function *arguments*, but it does fully evaluate function *results*, so that returning something that hasn't been fully evaluated requires you to return a function. Fortunately, R is a higher order language (S isn't) so any stream implementation in Scheme has a natural analogue in R. Can we agree that the existence of R shows that a practically useful programming language with dynamic typing and lazy argument evaluation is possible, and that it isn't quite what you had in mind because it evaluates function results in full? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On Wed, 10 Oct 2007, Andrew Coppin wrote: (I'm less sold on whether you really need to learn a particular dialect well enough to *program* in it...) If you don't then you won't be able to see how complicated things actually get done. It's also an important exercise in abstracting things and keeping something understandable when the system you're building is fighting back against it. -- [EMAIL PROTECTED] My religion says so explains your beliefs. But it doesn't explain why I should hold them as well, let alone be restricted by them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
Let's be clear what we are talking about, because I for one am
getting very confused by talk about putting PI into FLoating as
a class member serves nobody when it already IS there.
From the report:
class (Fractional a) = Floating a where
pi :: a
exp, log, sqrt :: a - a
(**), logBase :: a - a - a
sin, cos, tan :: a - a
asin, acos, atan :: a - a
sinh, cosh, tanh :: a - a
asinh, acosh, atanh :: a - a
-- Minimal complete definition:
-- pi, exp, log, sin, cos, sinh, cosh
-- asin, acos, atan
-- asinh, acosh, atanh
x ** y = exp (log x * y)
logBase x y = log y / log x
sqrt x = x ** 0.5
tan x = sin x / cos x
tanh x = sinh x / cosh x
(1) Mathematically,
sinh x = (exp x - exp (negate x)) / 2
cosh x = (exp x + exp (negate x)) / 2
tanh x = sinh x / cosh x
for all types where exp is defined. It is most peculiar that
one of these definitions is provided as a default rule but the
other two not. Does anyone know why there are no default
definitions for sinh and cosh? Do not cite numerical accuracy
as a reason. sinh 1000 = cosh 1000 = +Infinity in IEEE
arithmetic, so the default definition gives tanh 1000 = NaN,
when for abs x = {- about -} 41, tanh x = 1.0 (in IEEE 64-bit).
Is it something to do with branch cuts? Then Complex is the
right place to put overriding defaults that get them right.
(2) Other omissions can mostly be understood by thinking about
Complex. I find it deeply regrettable that atan2 isn't there,
because asin, acos, and atan are almost always the wrong
functions to use. But atan2 doesn't make sense for Complex.
(If someone could prove me wrong I would be delighted.)
(3) The question before us is whether there should be a default
definition for pi, and if so, what it should be.
I note that in at least one version of Hugs, there *is* a
default definition, namely
pi = 4 * atan 1
So we have evidence that one *can* have a default definition in
Floating without a plague of boils striking the blasphemers.
Unlike a numeric literal, this automatically adapts to the size
of the numbers. It may well not be as precise as a numeric
literal could be, but then, the report is explicit that defaults
can be overridden with more accurate versions.
None of the reasons for omitting other defaults seem to apply,
and providing a default for pi would not seem to do any harm.
So why not provide a default for pi?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On Wed, 2007-10-10 at 23:48 +0100, Philippa Cowderoy wrote: On Wed, 10 Oct 2007, Andrew Coppin wrote: (I'm less sold on whether you really need to learn a particular dialect well enough to *program* in it...) If you don't then you won't be able to see how complicated things actually get done. It's also an important exercise in abstracting things and keeping something understandable when the system you're building is fighting back against it. As you might imagine, I agree with Philippa. You can certainly be a competent programmer without being able to program in assembly, but there is a definite step in understanding between having an idea of what is happening in assembly and being confident in your ability to write non-trivial programs in it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
Someone wrote about pi: | But it is just a numerical constant, no need to put it into a class, and nothing to do with the type_classing of related functions. e is not std. defined, and it doesn't kill people who use exponentials. But it *isn't* A numerical constant. It is a *different* constant for each instance of Floating. In this respect, it's not unlike floatRange, which is just a constant (a pair of integers), but is different for each RealFloat instance. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On 11 Oct 2007, at 4:49 am, Dan Piponi wrote: Maybe this is the wrong point of view, but I think of defaults as impementations that are meant to be correct, but not necessarily the best way of doing things, leaving you the option to provide something better. The example of tanh in the report (page 106) shows that this view cannot be sustained. As an algorithm for computing tanh, it cannot be defended, producing NaN in a vast range of cases where 1.0 is the easily obtained correct answer. For the case of power series as an instance of Num, using 4*atan 1 gives me the wrong thing as it triggers an infinite summation, whereas I'd want pi to simply equal the constant power series. So if you have a default for pi in Float, you still have to provide your own definition for power series. Without a default for pi, you have to provide your own definition for power series. It doesn't sound as though providing a default makes anything worse. One alternative would of course be to simply provide a definition with say 64 digits, to be rounded as appropriate by the compiler. That would be as accurate as 4*atan 1 for Float, Double, and Complex based on them, even for 128-bit floats. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan for haskell.org
On 2007-10-10, Andrew Coppin [EMAIL PROTECTED] wrote: (Indeed, the number of times my Haskell programs have locked up due to me accidentally writing let x = foo x...) For me, that's small. I have seen useful program not lock up that depend on let x = foo x though. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On Wed, 2007-10-10 at 10:40 +0200, [EMAIL PROTECTED] wrote: Yitzchak Gale writes: Dan Piponi wrote: The reusability of Num varies inversely with how many assumptions you make about it. A default implementation of pi would only increase usability, not decrease it. Suppose I believe you. (Actually, I am afraid, I have doubts.) Can you provide some examples of this increased usability? If possible, with a *relevant* context, which shows that PI should belong by default to the class Floating (whatever we mean by that...) pi /is/ a method of class Floating. It just doesn't have a default implementation. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On Wed, 2007-10-10 at 12:29 +0200, [EMAIL PROTECTED] wrote: ChrisK writes: Putting 'pi' in the same class as the trigonometric functions is good design. If you wish so... But: Look, this is just a numeric constant. Would you like to have e, the Euler's constant, etc., as well, polluting the name space? What for? Moving smoothly from single to double precision was much of the motivation to invent a mechanism like type classes in the first place. Pardon? I think I remember the time when type classes have been introduced. The motivation you mention is not very visible, if at all... Actually, the numerical hierarchy was - as the French would say - bricolée with plenty of common sense, but without a decent methodology... The type classes is a splendid invention, much beyond any numerics. Besides, most people who *really* need FlP numerics use only the most precise available, the single precision stuff is becoming obsolete. There are two things in Floating, the power function (**) [ and sqrt ] and the transcendental functions (trig functions,exp and log, and constant pi). Floating could be spit into two classes, one for the power and one for the transcendental functions. The power is an abomination for a mathematician. With rational exponent it may generate algebraic numbers, with any real - transcendental... The splitting should be more aggressive. It would be good to have *integer* powers, whose existence is subsumed by the multiplicative s.group structure. But the Haskell standard insists that the exponent must belong to the same type as the base... Check out the type of (^). It's a different operator, but they exist... jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: New slogan... (A long speculation)
An anonymous called ok writes: jerzy.karczmarczuk wrote [about R]: ... This is not a functional language. There is some laziness (which looks a bit like macro-processing), sure. There is no macro processing in R (or S). I know I've been superficial, but, please, *try* to understand my point. There is a cheap (not always) way of making everything lazy, by rewriting. If an expression is the argument of a function, what is passed is the representation of this expression. This gets evaluated in the context of the caller function, although perhaps in the environment of the argument itself, if there are external references. It is something *similar* to macros, and it is more or less what I understood from my - admittedly weak - knowledge of R, S, etc. (Frankly, I do not know them enough to make the difference). But this is not the same as the laziness - realization of the normal order of evaluation, call by name (need), etc. The manual speaks about promises and about forcing them. But, at the same time we read that the call by value IS the protocol. That is a misreading. Paragraph 2 of 4.3.3 says The semantics of invoking a function in R argument are call-by-value. ... But that is NOT to be read as strict, but as contrasting with call-by-reference. There is a difference between call by name, and by reference. ... you didn't say that there were no *pure* lazy dynamically typed languages, only that there were no lazy dynamically typed languages. Right. But then, laziness *AND* side effects may put you in a nice mess... Near your favourite 4.3.3 there are warnings against using functions with side effects, since the arguments may not be evaluated. Now, the discussion began with ideas how to advertize *functional* languages, not packages with dangerous, non-formalizable semantics, I thought we would agree on this point. OF COURSE, there are untyped languages with suspended evaluation. Snobol had unevaluated expressions, Icon has co-expressions, etc. But if the merits of FL include some protection against errors, issued from enforcing a concrete programming discipline, R doesn't seem to me a good example. But you are right in principle, there are languages with a form of lazy evaluation, as the R manual delicately says... I don't see how to make co-inductive constructions, infinite streams, etc. I don't know what co-inductive constructions are. OK, try to code in R the list [0,1,2,3, ...] using a co-recursive data definition, in Haskell: integs = 0 : (ones + integs) where ones = 1 : ones and where (+) acts on lists element-wise. This may be esoteric for most of readers here, but I happen to use such constructions, or worse... Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
Jonathan Cast adds 'something' to a discussion about pi. I commented the statement of Yitzchak Gale, who answered some point of Dan Piponi: A default implementation of pi would only increase usability, not decrease it. I said: Can you provide some examples of this increased usability? If possible, with a *relevant* context, which shows that PI should belong by default to the class Floating (whatever we mean by that...) pi /is/ a method of class Floating. It just doesn't have a default implementation. Now, do you have anything to propose, or you just want to criticise my wording? If I ask why should I be a nice fellow, and you say that I am a nice fellow, this makes me happy, but doesn't answer my question... Mind you, we are discussing possible solutions, not just the status quo. Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
I haven't been following this discussion closely, but here's an idea: use reverse psychology. Haskell -- You're probably not smart enough to understand it. Nothing like appealing to people's machismo to get them interested. Mike Seth Gordon wrote: Aha! Instead of the lambda surrounded by mathematical stuff as the haskell.org logo, we need a picture of a medicine bottle. Haskell. Fewer headaches. No side effects. Alternatively, a picture of a red pill with an embossed lambda... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pi
On Thu, 2007-10-11 at 02:11 +0200, [EMAIL PROTECTED] wrote: Jonathan Cast adds 'something' to a discussion about pi. I commented the statement of Yitzchak Gale, who answered some point of Dan Piponi: A default implementation of pi would only increase usability, not decrease it. I said: Can you provide some examples of this increased usability? If possible, with a *relevant* context, which shows that PI should belong by default to the class Floating (whatever we mean by that...) pi /is/ a method of class Floating. It just doesn't have a default implementation. Now, do you have anything to propose, or you just want to criticise my wording? Yes. I am very eager to criticize your wording. To wit, I'm still failing to understand what your position is. Is it fair to say that your answer to my question, why pi has no default implementation, is `in fact, pi shouldn't be a method of Floating anyway'? If not, I can only beg for a precise, careful statement of exactly what it is you are arguing for. Btw: I am arguing that I (still) don't understand why the line pi = acos (-1) or something like it doesn't appear at an appropriate point in the Standard Prelude, given that the line pi :: a appears nearby said point. I am eager to be enlightened. But I haven't been, yet. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
What we really need is a sort of stress-strain curve for each of the major languages. Since Haskell is a typed language, we can have one curve for types and one for values: VARIABLE TYPEVALUE --- stress | effort to learn language | coding effort/time required ---|---| strain | ability to solve problems | marginal rate that problem | | is being solved ---|---| yield | knowledge needed to write | boilerplate code needed strength | Hello World program | ---|---| modulus of | semantic power of | productivity once boring elasticity | language syntax | stuff has been written ---|---| ultimate | expressive power | NONE strain | of the language | ---|---| ultimate | NONE | point at which code strength | | is getting beyond you ---|---| failure| NONE | point at which code is point | | broken and indecipherable Each language will be strong in one part of the curve. Haskell is superior in those parts of the curve where it matters most in real tasks, at the high strain end of the graph, both in type (there's always something more to learn, so no programmer burn-out) and in value (one person can manage more complexity with less effort). The PR problem is that newcomers to Haskell are being asked either to: 1) Trust me (but President Bush has strained that argument past failure) 2) Sample the curve at the low end (benchmarks, toy problems) and extrapolate the higher end, giving a very false impression The only answer is to provide a positive marginal interest at each point in the language acquisition process to entice the learner to keep sampling as (s)he progresses individually up the curve. This is the real benefit (and most noble purpose) of haskell-cafe. And of course the justification for this strained material science metaphor! :) Dan Weston Philippa Cowderoy wrote: On Wed, 10 Oct 2007, Andrew Coppin wrote: (I'm less sold on whether you really need to learn a particular dialect well enough to *program* in it...) If you don't then you won't be able to see how complicated things actually get done. It's also an important exercise in abstracting things and keeping something understandable when the system you're building is fighting back against it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
David Benbennick wrote: On 10/10/07, Dan Weston [EMAIL PROTECTED] wrote: Actually, it is a constant: piDecimalExpansion :: String. Where is this constant defined? A translation from piDecimalExpansion :: String to pi :: Floating a = a is already well defined via read :: Read a = String - a Any definition of pi in the Floating class that differs from (read piDecimalExpansion) is erroneous. I propose the above as the default definition of pi. piDecimalExpansion, if defined, would be an infinite length string. It would need to be added. The fact that it has infinite length is no problem. It is countable infinite, and algorithms exist to compute this lazily. The expression read $ 0. ++ repeat '1' :: Double is Bottom. So even if you had piDecimalExpansion, it isn't clear how to use that to define pi. Ouch. Why is that bottom? Any finite dense numeric type can depend on only a finite number of digits. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On 10/10/07, Dan Weston [EMAIL PROTECTED] wrote: Actually, it is a constant: piDecimalExpansion :: String. Where is this constant defined? A translation from piDecimalExpansion :: String to pi :: Floating a = a is already well defined via read :: Read a = String - a Any definition of pi in the Floating class that differs from (read piDecimalExpansion) is erroneous. I propose the above as the default definition of pi. piDecimalExpansion, if defined, would be an infinite length string. The expression read $ 0. ++ repeat '1' :: Double is Bottom. So even if you had piDecimalExpansion, it isn't clear how to use that to define pi. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
On Oct 10, 2007, at 20:14 , Michael Vanier wrote: I haven't been following this discussion closely, but here's an idea: use reverse psychology. Haskell -- You're probably not smart enough to understand it. Nothing like appealing to people's machismo to get them interested. Haskell already has that reputation, and so far as I've seen most programmers conclude they shouldn't waste time on it when any half- trained monkey can write Java/Perl/Python. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
On 11 Oct 2007, at 1:34 pm, Dan Weston wrote: Actually, [pi] is a constant: piDecimalExpansion :: String. No, that's another constant. A translation from piDecimalExpansion :: String to pi :: Floating a = a is already well defined via read :: Read a = String - a Wrong. piDecimalExpansion would be infinite. pi is, after all, a transcendental number. It can be computed incrementally by a finite algorithm, true. The problem is that read has to read *all the way to the end*, and there is no end. (More precisely, either to the end of the string or to the first character that is not part of a floating point literal.) Any definition of pi in the Floating class that differs from (read piDecimalExpansion) is erroneous. In effect, you are proposing that the only non-erroneous definition of pi is bottom. I don't think that is very helpful. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: pi
Come on people! This discussion is absurd. The numeric classes in Haskell have a lot of choices that are somewhat arbitrary. Just live with it. If pi has a default or not has no practical consequences. -- Lennart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type Synonyms
Newbie question: I was wondering the other day if type synonyms might be more useful if they were more restricted, that is, with the definitions: type Foo = String type Bar = String foo :: Foo foo = a foo bar :: Bar bar = a bar x :: Foo - ... x f b = ...only valid for Foo Strings... both 'x foo' and 'x bar' type check correctly. Wouldn't it be useful if Foo and Bar were both equivalent to String, but Foo and Bar were not equivalent themselves? For instance, if you are using Strings as properties of something and want to associate the type of the property with its value, without wrapping the String. Would this break a transitivity property of the type system? Am I just suffering from laziness? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type Synonyms
If you change your type declarations to 'newtype' declarations, I believe you would get the effect that you want, depending on what you mean by 'equivalent'. In that case, Foo and Bar would essentially be strings, but you could not use either of them in a place where the other is expected, nor where a String is expected. See http://haskell.org/haskellwiki/Newtype for more information. Hope this helps! On 10/10/07, Tom Davies [EMAIL PROTECTED] wrote: Newbie question: I was wondering the other day if type synonyms might be more useful if they were more restricted, that is, with the definitions: type Foo = String type Bar = String foo :: Foo foo = a foo bar :: Bar bar = a bar x :: Foo - ... x f b = ...only valid for Foo Strings... both 'x foo' and 'x bar' type check correctly. Wouldn't it be useful if Foo and Bar were both equivalent to String, but Foo and Bar were not equivalent themselves? For instance, if you are using Strings as properties of something and want to associate the type of the property with its value, without wrapping the String. Would this break a transitivity property of the type system? Am I just suffering from laziness? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type Synonyms
Andrew Wagner wagner.andrew at gmail.com writes: If you change your type declarations to 'newtype' declarations, I believe you would get the effect that you want, depending on what you mean by 'equivalent'. In that case, Foo and Bar would essentially be strings, but you could not use either of them in a place where the other is expected, nor where a String is expected. See http://haskell.org/haskellwiki/Newtype for more information. Hope this helps! I wanted to avoid wrapping the string with a constructor. I suppose what I'm really asking for is for each type to implicitly define a 'type class with no methods', and to be able to create new instances of that type class which simply behave as the underlying type. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] latest hdbc-odbc
Hello, When building the latest hdbc-odbc (1.1.2.0) on a linux box with ghc6.6.1, I get the following warnings: [7 of 7] Compiling Database.HDBC.ODBC ( Database/HDBC/ODBC.hs, dist/build/Database/HDBC/ODBC.o ) hdbc-odbc-helper.c: In function â: hdbc-odbc-helper.c:131:0: warning: pointer targets in passing argument 6 of â differ in signedness hdbc-odbc-helper.c:131:0: warning: pointer targets in passing argument 8 of â differ in signedness hdbc-odbc-helper.c: In function â: hdbc-odbc-helper.c:136:0: warning: pointer targets in passing argument 8 of â differ in signedness /usr/bin/ar: creating dist/build/libHSHDBC-odbc-1.1.2.0.a then, after installing the package I get the following error/strange behavior: Prelude :t Database.HDBC.ODBC.connectODBC /usr/local/lib/HDBC-odbc-1.1.2.0/ghc-6.6.1/Database/HDBC/ODBC/Connection.hi Declaration for connectODBC: Failed to load interface for `Database.HDBC.ODBC.ConnectionImpl': Use -v to see a list of the files searched for. Cannot continue after interface file error Can anyone shed light on what is going wrong? Is it something I can fix, or is the distribution buggy? thanks, Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
