Re: [Haskell-cafe] [GSoC] A data parallel physics engine
* Manuel M T Chakravarty [EMAIL PROTECTED] [2008-03-13 12:30:40+1100] Indeed, a matrix library would be really nice. Before getting serious about this, please take a very close look at how PETSc (http://www-unix.mcs.anl.gov/petsc/) handles matrices. The abstraction is very important because most large matrices of interest are sparse or have some symmetry that makes them asymptotically cheaper to apply (like with an FFT, FMM, or tensor product). In my experience, it is a lot harder to get somebody who is motivated to write a general-purpose library than getting somebody who is motivated to write an application, which you can run and show to people at the end. You're absolutely right from my (i.e. student's) point of view :) -- Roman I. Cheplyaka :: http://ro-che.info/ ...being in love is totally punk rock... signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Reflective capabilities of Haskell (cont'd)
Martin Hofmann wrote: Thanks a lot, this helps a bit, but access to function bodies is exactly what I need. Then perhaps you might like the method of reconstructing bodies (of possibly compiled) functions http://okmij.org/ftp/Computation/Generative.html#diff-th in the form of AST -- the template Haskell AST. The reconstructed bodies of functions can be arbitrarily manipulated (e.g., _symbolically_ differentiated or algebraically simplified) and then converted `back' to the compiled code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: An offer to any haskell projects out there.
michael at schmong.org writes: Hello, My name is Michael Litchard. I'm a techie living in silicon valley, and I want to move into tech writing. I've got the background, now I need a portfolio. I figured the best way to go is to attach myself to some open source projects, and haskell has had my heart for a few years now. I am by no means an expert at haskell. My expertise is writing. So I make this offer. If you need documentation written for your haskell project, I'm your man. Whatever it is, I'll write it or edit it. Thanks for your time. P.S If this was the wrong list, or if anyone has other ideas about how to propogate my proposal, please let me know. Michael Michael, that's an awesome offer. As others have already noted there are plenty of areas where you could make a significant contribution. I'd specifically recommend reposting your offer to the HAppS (http://happs.org) list/group. HAppS is a high profile project which seems to be getting quite a bit of interest from outside the Haskell community. If you're unfamiliar with it I recommend taking a look at the BayFP Presentation linked on the site. Unfortunately HAppS has a serious deficit of documentation (including the web site not being up to date) and consequently there is a high barrier to entry. While HAppS could certainly benefit from you help I would imagine that you could also benefit from helping HAppS. The high profile of HAppS should increase the chance of prospective clients being able to relate to your portfolio, and I'd also imagine that comprehensive documentation focused on a specific project is more portfoliable than random pieces scattered around the standard libraries (not that I want to disuade you from contributing there too!). Good luck! -Bjorn (I'm not involved in the HAppS project, nor have I used it.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exception handling when using STUArray
On Wed, Mar 12, 2008 at 4:45 PM, Donn Cave [EMAIL PROTECTED] wrote: Well, the problem inherently requires a certain order of evaluation. But if you will just handle pattern match failure in the IO monad, then you can write a simple functional expression of the problem instead, let (i, s') = decodeInt s in let (v, _) = decodeInt s' in (i, v) ... where I think `i' can be evaluated without forcing unnecessary evaluation of v. It's clearer, and avoids unnecessary strictness! Unless of course you don't have an IO monad handy. The issue is that exception handling semantics do induce an order of evaluation for determinacy: if both functions in a composition throw an exception at some point (say in the 3rd element of a list they're generating), you need to decide which exception ends up being thrown, and to do that based on the lazy evaluation order would break referential transparency. It bugs me a little how good Haskell is with laziness, but how bad it gets when you need laziness with a slightly different structure. I don't see any way it could reasonably be fixed if I were designing my own language, it's just unsettling. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exception handling when using STUArray
On Wed, 12 Mar 2008, Donn Cave wrote: On Mar 12, 2008, at 2:10 PM, Henning Thielemann wrote: On Wed, 12 Mar 2008, Donn Cave wrote: On Mar 12, 2008, at 12:32 PM, Brandon S. Allbery KF8NH wrote: On Mar 12, 2008, at 14:17 , Donn Cave wrote: Sure. It isn't a lot of code, so I subjected it to Either-ization as an experiment, and I did indeed take the monad procedural route. Monad != procedural, unless you insist on do notation. Think of it as composition (it may be easier to use (=) which points the same direction as (.)). Yes, I insist on do notation, because it provides a convenient binding form that works with what I'm doing - the original functional variation wasn't so suited to composition either, and used `let'. But I see that as only syntactic - equally procedural, either way. Expressions are evaluated in a fixed order, Do notation only looks like there are statements that are processed from the beginning to the end. But that's not true, it's still purely lazy and expressions are evaluated in the order that is forced by data dependencies. Let me put it this way: if I write do (i, s') - decodeInt s (v, _) - decodeInt s' return (i, v) ... instead of, to just avoid the monad stuff case (decodeInt s) of Left e - Left e Right (i, s') - case (decodeInt s') of Left e - Left e Right (v, _) - Right (i, v) Since the decision between Left and Right requires all parts to be evaluated, it's Either that might too strict for your application. What about a writer monad, where exceptions, or better say warnings, are written to the writer stream? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating point operations and representation
On Wed, 12 Mar 2008, Don Stewart wrote: I am under the restriction that I need to write Haskell programs using Double which mimic existing C/C++ programs or generated data sets, and get the same answers. (It's silly, but take it as a given requirement.) If the C programs are using log2, then I need log2 in the Haskell, or else I run the risk of not producing the same answers. Hey Jacob, Just to make life super simple, I packaged up a binding to the basic math.h library for Doubles. You can find the library here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cmath For example, Prelude Foreign.C.Math.Double.log10 5 0.6989700043360189 Prelude log 5 / log 10 0.6989700043360187 You may want to write a RULES pragma which replaces occurences of 'logBase 2' and 'logBase 10' by their specialised counterparts. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
[EMAIL PROTECTED] wrote: G'day all. Adrian Hey wrote: This might be a reasonable thing to say about *sortBy*, but not sort as the ordering of equal elements should not be observable (for any correct instance of Ord). It should be impossible to implement a function which can discriminate between [a,a],[a,b],[b,a],[b,b] if compare a b = EQ. Nonsense. Consider a Schwartzian transform wrapper: data OrdWrap k v = OrdWrap k v instance (Ord k) = Ord (OrdWrap k v) where compare (OrdWrap k1 v1) (OrdWrap k2 v2) = OrdWrap k1 k2 I take it you mean something like .. instance Ord k = Ord (OrdWrap k v) where compare (OrdWrap k1 v1) (OrdWrap k2 v2) = compare k1 k2 Where's the Eq instance for OrdWrap? This may or may not satisfy the law: (compare a b) = EQ implies (a == b) = True. I think everbody agrees about that, but I can't tell from the code you've posted if it does in this case. What's disputed is whether or not this law should hold: (a == b) = True implies a = b Again, I can't tell if it does or not in this case, but I assume the point of your post is that it doesn't. AFAICT the report is ambiguous about this, or at least the non-intutive equality semantics are not at all clear to me from what I can see in the Eq class definition (para 6.3.1). I think an the absence of any clear and *explicit* statement to the contrary people are entitled to assume this law is mandatory for all (correct) Eq instances. It would be incorrect (and not sane) for sort [a,b] to return [a,a] in this case, though a case could be made that either [a,b] or [b,a] make sense. Quoting Jules Bean [EMAIL PROTECTED]: Stability is a nice property. I don't understand why you are arguing against this so aggressiviely. Stability is an occasionally very useful property. However, if there is a tradeoff between stability and performance, I'd prefer it if the library didn't choose for me. Well I hope you or anyone else hasn't used Data.Map or with OrdWrap keys because if so it's likely that the code has either been broken in the past, or is broken now (not sure which). But the equality semantics some people seem to want seem to me like a very good way to guarantee that similar bugs and ambiguities will occur all over the place, now and forever. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An offer to any haskell projects out there.
I am also interested in helping out in this manner, particularly with HaskellWiki. I work as a patent translator in Tokyo, and my specialty is technical translation. In particular, I could help write English-language documentation on Haskell and also translate such documentation into Japanese for Japanese readers in my spare time. Although I took a course in formal semantics in college (under Paul Hudak at Yale, actually) many years ago and studied some beginning Haskell at that time, I haven't had much time to study Haskell since then, and am still a beginner at the language. However, I've been able to set aside some time to study Haskell formally recently, and should be able to help out soon. If anybody is interested in setting up a Japanese-language version of HaskellWiki, please let me know. Haskell is starting to become well-known here in Japan, and there are even two Japanese-language textbooks on Haskell sold in Japanese bookstore. What is probably needed is more online Japanese-language documentation. Benjamin L. Russell --- Tim Chevalier [EMAIL PROTECTED] wrote: On 3/12/08, Don Stewart [EMAIL PROTECTED] wrote: One of the best things you could do would be to submit patches against the core library set where documentation is missing. Starting with things in base, array, containers, directory, filepath, pretty, time etc. That would likely help the largest number of users. Patches to these libraries can be submitted to the [EMAIL PROTECTED] list. To elaborate ever so slightly on what Don said: A lot of libraries only have type signatures for functions in the libraries as documentation. What's missing is English descriptions of what the functions really do. You yourself may not know what the functions do, but you can learn by experimenting with the libraries (writing little programs that use the functions) and by asking on this mailing list (and reading old posts in the archive), if necessary. It would be really useful if you decided to put time into this. Thanks in advance! Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt You never have to aspire to difficulty, darling. It arrives, uninvited. Then it stays for dinner.--Sue Miller ___ 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] Template Haskell -- when are things evaluated?
Hello all! Up until yesterday I thought I understood the basics of Template Haskell, but now I'm a little confused. Consider the following code module A where a1 = [| (2::Int) + 2 |] a2 = let x = (2::Int) + 2 in [| x |] a3 = [| y |] where y = (2::Int) + 2 z = (2::Int) + 2 a4 = [| z |] module B where import A a1S = $a1 a2S = $a2 a3S = $a3 a4S = $a4 I'd have thought that in all four cases the addition was evaluated at compile-time, but compiling with -ddump-splices reveals that this is only the case for a2 and a3. Is there a general reliable rule for when things are evaluated? Thanks, / Emil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
On Thu, Mar 13, 2008 at 1:00 AM, Adrian Hey [EMAIL PROTECTED] wrote: AFAICT the report is ambiguous about this, or at least the non-intutive equality semantics are not at all clear to me from what I can see in the Eq class definition (para 6.3.1). I think an the absence of any clear and *explicit* statement to the contrary people are entitled to assume this law is mandatory for all (correct) Eq instances. In mathematics we usually *don't* assume things that aren't stated assumptions. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell -- when are things evaluated?
Hi Emil, Your problem is related to how are things evaluated not when. The short answer is: if you want to make sure an expression is evaluated before you lift it, don't use quasiquotes, call Language.Haskell.TH.lift On Thu, Mar 13, 2008 at 9:00 AM, Emil Axelsson [EMAIL PROTECTED] wrote: a1 = [| (2::Int) + 2 |] You are lifting the expression AST, not its evaluation. a1 = lift ((2::Int) + 2) would work as you want. a2 = let x = (2::Int) + 2 in [| x |] here you are enclosing a local variable in quasiquotes and, thus, [| x |] is equivalent to lift x a3 = [| y |] where y = (2::Int) + 2 Same as in a2, y is local. Therefore [| y |] is equivalent to lift y z = (2::Int) + 2 a4 = [| z |] z is a global variable and [| z |] is lifted to a variable expression (i.e. a4 is equivalent to varE 'z ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Termination of substitution
As Stefan says, System Fw is strongly normalising. This is a remarkable result because (as you observe) it's very non-obvious how to prove it. However GHC goes beyond Fw by adding data types letrec This blows strong normalisation out of the water. (Assuming you have reasonable rules for case and letrec.) But perhaps if you restrict data types a bit, and place draconian restrictions on letrec (e.g. never inline one) you could retain strong normalisation. It depends how much you want your rules to do. GHC's simplifier deals with the letrec problem by cutting each recursive loop -- see the paper Secrets of the GHC inliner. GHC doesn't solve the data type problem at all -- you can make the Simplifier loop if you try. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Mitchell | Sent: 12 March 2008 21:05 | To: Haskell Cafe | Subject: [Haskell-cafe] Termination of substitution | | Hi | | I'm trying to show that a system of rules for manipulating Haskell | expressions is terminating. The rules can be applied in any order, to | any subexpression - and there is a problem if there is any possible | infinite sequence. | | The rule that is giving me particular problems is: | | (\v - x) y = x[v/y] | | (I realise this rule may duplicate the computation of y, but that is | not relevant for this purpose.) | | In particular, given the expression | | (\x - x x) (\x - x x) | | we can keep applying this rule infinitely. | | However, I don't believe this expression is type safe in Haskell. Are | any such expressions that would cause this to non-terminate not type | safe? What are the necessary conditions for this to be safe? Does GHC | perform lambda reduction, probably by introducing a let binding? Does | the combination of reducing lambdas and creating let bindings give | similar problems, particularly if bindings are inlined? | | I'm wondering if this rule is genuinely unsafe in Haskell. If it is, | why isn't it an issue in real simplifiers. If it isn't, what makes it | safe. | | Thanks for any help, | | Neil | ___ | 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] Re: (flawed?) benchmark : sort
On Thu, Mar 13, 2008 at 3:02 AM, Adrian Hey [EMAIL PROTECTED] wrote: The report doesn't state that for all Ints, (x==y = True) implies that x=y. There's no reason to suppose the Int instance is in any way special, so do you really seriously consider the possibility that this might not hold in your Int related code? if (x==y) then f x else g x y might not mean the same as.. if (x==y) then f y else g x y Of course not :-). However, on what grounds am I to assume that these two will be semantically equivalent for instances other than Int? Int *is* special insofar as its implementation of Eq differs from that of other types (of course, all other instances of Eq are special then, too). So it's reasonable that == means observational equivalence for Int but not for other types, since it's possible to implement them that way and there is no (explicitly stated) law which requires it. But I agree that Eq should have some laws, just maybe not observational equivalence because it is very limiting from a user's perspective (that is, if I have a data type, requiring observational equivalence makes it much less likely that I will be able to write an instance of Eq, even if it makes sense in some stretch of the imagination). Saying that it's reasonable for everyone, everywhere to assume that Eq means what you want it to mean is a stretch. I believe every for function I've written which was polymorphic in Eq it would have sufficed for Eq to be any equivalence relation. What reason do I have to restrict the users of my functions to those who can implement observational equivalence? But I'm just blabbering. Here's my position on the issue with an argument for why I think it's a good one: Eq should be allowed to be any equivalence relation, because there are many data types for which it is impossible to satisfy the constraint of observational equivalence, thus reducing the usefulness of data structures written over types with Eq. On the other hand, (and this is anecdotal), no data structures have been unable to cope with Eq not implying observational equivalence. Here's another argument. Since Eq has no stated laws in the report, give Eq no assumptions*, and allow the community to create an empty subclass of Eq (ObsEq, say) which documents the necessary laws. Then a data structure which relies on the observational equivalence property can specify it explicitly. But really the thing that makes me choose this position is that it sucks not to be able to use someone's code only because it is impossible to satisfy instance laws, even though the code would be perfectly reasonable anyway (though it isn't a strong argument, consider the case of the broken ListT, still, it's enough to convince me for the time being). * No assumptions at all would be strange, but also okay with me, as long as functions which rely on Eq specify that they need it to conform to certain laws. But I consider equivalence relation reasonable because (1) everyone here seems to be on common ground that it should *at least* be that, and (2) all the prelude functions on Eq assume that (and note that none assume obs. eq.). Indeed, group is almost meaningless if Eq imples obs. eq. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort)
Hello All, I'm top posting because I'm getting bored and frustrated with this thread and I don't want to respond detail to everything Aaron has said below. Aaron: Where are you getting this equivalence stuff from? Searching the report for the word equivalence the only remotely relevant section seems to be in para. 17.6.. When the “By” function replaces an Eq context by a binary predicate, the predicate is assumed to define an equivalence Which is fair enough, but this is talking about the argument of By functions. The Haskell wiki refers me to wikipedia, which contains the words In Haskell, a class Eq intended to contain types that admit equality would be declared in the following way http://en.wikipedia.org/wiki/Type_class Not that this is necessarily authoritative, but it seems to be contaradicting some peoples interpretation. Also, on page 60 of the report I find the words Even though the equality is taken at the list type.. So I don't know if all this is really is the correct reading of the report, but if so would like to appeal to movers and shakers in the language definition to please decide exactly what the proper interpretation of standard Eq and Ord class laws are and in the next version of the report give an explanation of these in plain English using terms that people without a Mathematics degree are likely to understand. Aaron's interpretation may indeed be very correct and precise, but I fear in reality this is just going to be incomprehensible to many programmers and a terrible source of bugs in real world code. I cite previous left biasing bugs Data.Map as evidence. I would ask for any correct Eq instance something like the law: (x==y) = True implies x=y (and vice-versa) which implies f x = f y for all definable f which implies (f x == f y) = True (for expression types which are instances of Eq). This pretty much requires structural equality for concrete types. For abstract types you can do something different provided functions which can give different answers for two equal arguments are not exposed. Anything else is just wrong (according to the language specification, even if it can be right in some mathematical sense). Before anyone jumps down my throat, I remind you that this is a request, not an assertion! :-) On the subject of ambiguity, bugs and maxima, I see we have in Data.List -- | 'maximum' returns the maximum value from a list, -- which must be non-empty, finite, and of an ordered type. -- It is a special case of 'Data.List.maximumBy', which allows the -- programmer to supply their own comparison function. maximum :: (Ord a) = [a] - a maximum [] = errorEmptyList maximum maximum xs = foldl1 max xs -- | The 'maximumBy' function takes a comparison function and a list -- and returns the greatest element of the list by the comparison function. -- The list must be finite and non-empty. maximumBy :: (a - a - Ordering) - [a] - a maximumBy _ [] = error List.maximumBy: empty list maximumBy cmp xs= foldl1 max xs where max x y = case cmp x y of GT - x _ - y So I believe I'm correct in saying that maximumBy returns the last of several possible maximum elements of the list. This obviously needs specifying in the Haddock. Because maximumBy documentation is ambiguous in this respect, so is the overloaded maximum documentation. At least you can't figure it out from the Haddock. Despite this ambiguity, the statement that maximum is a special case of maximumBy is true *provided* max in the Ord instance is defined the way Aaron says is should be: (x==y = True) implies max x y = y. But it could be be made unconditionally true using.. maximum :: Ord a = [a] - a maximum [] = error List.maximum: empty list maximum xs = maximumBy compare xs AFAICT, the original report authors either did not perceive an ambiguity in maximum, or just failed to notice and resolve it. If there is no ambiguity this could be for 2 reasons. 1 - It doesn't matter which maximum is returned because: (x==y) = True implies x=y 2 - It does matter, and the result is guaranteed to be the last maximum in all cases because: (x==y) = True implies max x y = y But without either of the above, it is unsafe to assume maximum = maximumBy compare Regarding the alleged max law this too is not mentioned in the Haddock for the Ord class, nor is it a law AFAICT from reading the report. The report (page 83) just says that the default methods are reasonable, but presumably not manditory in any semantic sense. This interpretation also seems to be the intent of this from the second para. of Chapter 8: The default method definitions, given with class declarations, constitute a specification only of the default method. They do not constitute a specification of the meaning of the method in all instances. I
Re: [Haskell-cafe] floating point operations and representation
Jacob Schwartz [EMAIL PROTECTED] writes: A test on IEEE computers (x86 and x86-64), shows that for a range of 64-bit double values, the answers in C do differ (in the last bit) if you use log2(x) and log10(x) versus log (x) / log(2) and log(x) / log(10). I think this may also depend on C compiler and optimization level. Perhaps now everybody uses SSE to do math, but earlier Intel FPU architectures did floating point with 80-bit registers, so the accuracy of the result could depend on whether an intermediate result was flushed to memory (by a context switch). Equality on floating point is tricky, if I were you, I'd round the results before comparing. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
Luke Palmer wrote: On Thu, Mar 13, 2008 at 1:00 AM, Adrian Hey [EMAIL PROTECTED] wrote: AFAICT the report is ambiguous about this, or at least the non-intutive equality semantics are not at all clear to me from what I can see in the Eq class definition (para 6.3.1). I think an the absence of any clear and *explicit* statement to the contrary people are entitled to assume this law is mandatory for all (correct) Eq instances. In mathematics we usually *don't* assume things that aren't stated assumptions. But the trouble is the report says practically *nothing* about Eq class or what the (==) operator means. It all seems to be assumed, and even when it does talk about it informally it talks about equality, not equivalence or some other word. The report doesn't state that for all Ints, (x==y = True) implies that x=y. There's no reason to suppose the Int instance is in any way special, so do you really seriously consider the possibility that this might not hold in your Int related code? if (x==y) then f x else g x y might not mean the same as.. if (x==y) then f y else g x y Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: unification
andrea wrote: data Tipo = Var Int | Const String | Tipo :- Tipo deriving (Show, Eq) But now how can I do to make the set of Const fixed?? I want just a few base types, like int and string, how could I define it? your base types could be: Const String :: Tipo Const Int :: Tipo and the polymorphic type of the identity function could be: Var 1 :- Var 1 :: Tipo (and with infixr :-) the type of binary function like (+) Const Int :- Const Int :- Const Int Note: the data type does not support type constructors like List. I recommend from: http://www.haskell.org/haskellwiki/Research_papers/Type_systems Typing Haskell in Haskell The first few pages will be enough (substitution is on page 7) However, the link http://www.cse.ogi.edu/~mpj/pubs/thih.html does not work for me Could someone correct that link? Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] File I/O question
On Wed, Mar 12, 2008 at 10:03 PM, Andrew Coppin [EMAIL PROTECTED] wrote: Don Stewart wrote: Hey Andrew, What are you trying to do? Read and write to the same file (if so, you need to use strict IO), or are you trying something sneakier? I have a long-running Haskell program that writes status information to a log file. I'd like to be able to open and read that log file before the program has actually terminated. I have a similar program written in Tcl that allows me to do this, since apparently the Tcl interpretter doesn't lock output files for exclusive access. Haskell, however, does. (This seems to be the stipulated behaviour as per the Report.) If there's an easy way to change this, it would be useful... How about using appendFile? appendFile :: FilePath - String - IO () The computation appendFile file str function appends the string str, to the file file. See http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#v%3AappendFile /Björn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: Re: Reflective capabilities of Haskell (cont'd)
On Wed, 2008-03-12 at 15:59 -0400, Jeff Polakow wrote: Data.Generics allows you to do this (to a certain extent), i.e. there is a function dataTypeConstrs :: DataType - [Constr] It might be hard, or even impossible, to get Data.Typeable and Data.Generics to play with each other. There seems to be no good way of converting a Data.Typeable.TypeRep to a Data.Generics.Basics.DataType. Another option might be to use Language.Haskell.Parser and Language.Haskell.Syntax, but I have little experience with this and am not sure if you'll be able to do what you want. On Wed, 2008-03-12 at 23:08 -0700, [EMAIL PROTECTED] wrote: Thanks a lot, this helps a bit, but access to function bodies is exactly what I need Then perhaps you might like the method of reconstructing bodies (of possibly compiled) functions http://okmij.org/ftp/Computation/Generative.html#diff-th in the form of AST -- the template Haskell AST. The reconstructed bodies of functions can be arbitrarily manipulated (e.g., _symbolically_ differentiated or algebraically simplified) and then converted `back' to the compiled code. Thanks for the hints, they all seem to be promising, at least for some part of my problem. I'll try it out whether I can put them together. Cheers, Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
Luke Palmer wrote: On Thu, Mar 13, 2008 at 3:02 AM, Adrian Hey [EMAIL PROTECTED] wrote: The report doesn't state that for all Ints, (x==y = True) implies that x=y. There's no reason to suppose the Int instance is in any way special, so do you really seriously consider the possibility that this might not hold in your Int related code? if (x==y) then f x else g x y might not mean the same as.. if (x==y) then f y else g x y Of course not :-). However, on what grounds am I to assume that these two will be semantically equivalent for instances other than Int? Umm..Maybe the fact that you're using the == method from the Eq class, not some Int specific isIntEqual function? :-) Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell -- when are things evaluated?
Aha, I guess I thought for a while that [|x|] and lift x where the same thing. Having thought too much about partial evaluation lately, I forgot that the main purpose of quoting is to get the unevaluated AST. I'll just use lift in the future then (for partial evalutation). Thanks, Alfonso! / Emil On 2008-03-13 09:49, Alfonso Acosta wrote: Hi Emil, Your problem is related to how are things evaluated not when. The short answer is: if you want to make sure an expression is evaluated before you lift it, don't use quasiquotes, call Language.Haskell.TH.lift On Thu, Mar 13, 2008 at 9:00 AM, Emil Axelsson [EMAIL PROTECTED] wrote: a1 = [| (2::Int) + 2 |] You are lifting the expression AST, not its evaluation. a1 = lift ((2::Int) + 2) would work as you want. a2 = let x = (2::Int) + 2 in [| x |] here you are enclosing a local variable in quasiquotes and, thus, [| x |] is equivalent to lift x a3 = [| y |] where y = (2::Int) + 2 Same as in a2, y is local. Therefore [| y |] is equivalent to lift y z = (2::Int) + 2 a4 = [| z |] z is a global variable and [| z |] is lifted to a variable expression (i.e. a4 is equivalent to varE 'z ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: (flawed?) benchmark : sort
On 2008-03-13, Adrian Hey [EMAIL PROTECTED] wrote: But the trouble is the report says practically *nothing* about Eq class or what the (==) operator means. It all seems to be assumed, and even when it does talk about it informally it talks about equality, not equivalence or some other word. The report doesn't state that for all Ints, (x==y = True) implies that x=y. No, it doesn't. However, for Ints, it's the most reasonable natural (and generic) definition. The report should be clarified on this point. There's no reason to suppose the Int instance is in any way special, Well, what do you mean by special? That it has this additional guarantee? I don't see that as unusual for Eq instances, no. In fact, I expect typical Eq instances to satisfy this. However, if all I know is Eq a, I don't think it can be counted on, so it is special in that sense. Just as, say Maybe a, along with many, or even most other common Monads might satisfy more laws than a generic Monad a, doesn't necessarily make it special. But you can't still write generic Monad code assuming these other properties. Instead, you require MonadPlus instances, or similar for whatever additional properties you need. so do you really seriously consider the possibility that this might not hold in your Int related code? if (x==y) then f x else g x y might not mean the same as.. if (x==y) then f y else g x y In Int code, of course not, because I know the types, and I know the behaviour of (==) on Ints. But f is specialized to work on Ints, isn't it, so it's reasonable to know what semantics (==) has for Ints, and depend on them? -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: floating point operations and representation
Jacob Schwartz [EMAIL PROTECTED] schrieb: I have two questions about using the Double data type and the operations in the Floating typeclass on a computer that uses IEEE floating point numbers. I notice that the Floating class only provides log (presumably log base 'e') and logBase (which, in the latest source that I see for GHC is defined as log y / log x). However, in C, the math.h library provides specific log2 and log10 functions, for extra precision. A test on IEEE computers (x86 and x86-64), shows that for a range of 64-bit double values, the answers in C do differ (in the last bit) if you use log2(x) and log10(x) versus log (x) / log(2) and log(x) / log(10). This is to be expected in about 25% of cases, as the GHC definition rounds two times, whereas the implementation provided in the SUN math library (file lib/msun/src/e_log10.c on FreeBSD) uses a representation in two doubles for log(10) to avoid one of the rounding errors: * Return the base 10 logarithm of x * * Method : * Let log10_2hi = leading 40 bits of log10(2) and * log10_2lo = log10(2) - log10_2hi, * ivln10 = 1/log(10) rounded. * Then * n = ilogb(x), * if(n0) n = n+1; * x = scalbn(x,-n); * log10(x) := n*log10_2hi + (n*log10_2lo + ivln10*log(x)) -- Dipl.-Math. Wilhelm Bernhard Kloke Institut fuer Arbeitsphysiologie an der Universitaet Dortmund Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257 PGP: http://vestein.arb-phys.uni-dortmund.de/~wb/mypublic.key ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
Aaron Denney wrote: so do you really seriously consider the possibility that this might not hold in your Int related code? if (x==y) then f x else g x y might not mean the same as.. if (x==y) then f y else g x y In Int code, of course not, because I know the types, and I know the behaviour of (==) on Ints. But f is specialized to work on Ints, isn't it, so it's reasonable to know what semantics (==) has for Ints, and depend on them? Why are Ints special in this way? Couldn't you use say exacly the same about any type (just substitute type X of your choice for Int) IMO if your going to define a type X which is intended to be an Eq instance you should always ensure, one way or another that all exposed primitives that operate on that type respect equality, as defined by == for the instance method. (And hence more complex functions built on those primitives do too). Just MO, the report doesn't make this clear 1 way or another AFAICS. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell -- when are things evaluated?
I'm reading the following rule from your answer: [|exp|] normally returns the unevaluated AST of exp. However, if exp contains local variables, these are lifted using Language.Haskell.TH.lift (i.e. evaluated before lifting). Is that correct? / Emil On 2008-03-13 09:49, Alfonso Acosta wrote: Hi Emil, Your problem is related to how are things evaluated not when. The short answer is: if you want to make sure an expression is evaluated before you lift it, don't use quasiquotes, call Language.Haskell.TH.lift On Thu, Mar 13, 2008 at 9:00 AM, Emil Axelsson [EMAIL PROTECTED] wrote: a1 = [| (2::Int) + 2 |] You are lifting the expression AST, not its evaluation. a1 = lift ((2::Int) + 2) would work as you want. a2 = let x = (2::Int) + 2 in [| x |] here you are enclosing a local variable in quasiquotes and, thus, [| x |] is equivalent to lift x a3 = [| y |] where y = (2::Int) + 2 Same as in a2, y is local. Therefore [| y |] is equivalent to lift y z = (2::Int) + 2 a4 = [| z |] z is a global variable and [| z |] is lifted to a variable expression (i.e. a4 is equivalent to varE 'z ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Some clarity please! (was Re: Re: (flawed?) benchmark : sort)
On 2008-03-13, Adrian Hey [EMAIL PROTECTED] wrote: Hello All, I'm top posting because I'm getting bored and frustrated with this thread and I don't want to respond detail to everything Aaron has said below. Aaron: Where are you getting this equivalence stuff from? Not from the prose in the report, but from what the code in the report seems designed to support. There are several places where the code seems to take a (small -- much usually isn't needed) bit of care to support equivalencies. So I don't know if all this is really is the correct reading of the report, but if so would like to appeal to movers and shakers in the language definition to please decide exactly what the proper interpretation of standard Eq and Ord class laws are and in the next version of the report give an explanation of these in plain English using terms that people without a Mathematics degree are likely to understand. I agree that the prose of the report should be clarified. Luke Palmer's message in haskell-cafe captures why I think that Eq means equivalence, not strict observational equality is a more generally useful notion. It's harder to guarantee observational equality, thus harder to use code that requires it of your types. Almost all the time (in my experience) equivalencies are all that's generically needed. My comments on this particular message are below. Because maximumBy documentation is ambiguous in this respect, so is the overloaded maximum documentation. At least you can't figure it out from the Haddock. True. Despite this ambiguity, the statement that maximum is a special case of maximumBy is true *provided* max in the Ord instance is defined the way Aaron says is should be: (x==y = True) implies max x y = y. Well, the way the report specifies that max's default definition is. I'd actually favor making that not an instance function at all, and instead have max and min be external functions. AFAICT, the original report authors either did not perceive an ambiguity in maximum, or just failed to notice and resolve it. If there is no ambiguity this could be for 2 reasons. 1 - It doesn't matter which maximum is returned because: (x==y) = True implies x=y 2 - It does matter, and the result is guaranteed to be the last maximum in all cases because: (x==y) = True implies max x y = y The second holds, so long as max isn't redefined. I'd be rather surprised at any redefinitino of max, as it's not part of any minimum definition for Ord, and I can't think of an actual optimization case for it. Regarding the alleged max law this too is not mentioned in the Haddock for the Ord class, nor is it a law AFAICT from reading the report. The report (page 83) just says that the default methods are reasonable, but presumably not manditory in any semantic sense. This interpretation also seems to be the intent of this from the second para. of Chapter 8: Agreed. Elevating this to a law in my previous message was a mistake on my part. I still think this default in combination with the comment is very suggestive that (min x y, max x y) should preserve distinctness of elements. If you're unwilling to count on this holding for arbitrary Ord instances, why are you willing to count on (/=) and (==) returning opposite answers for arbitrary Eq instances? I wouldn't dispute that the default definition is reasonable, but it's certainly not clear to me from the report that it's something that I can safely assume for all Ord instances. In fact AFAICS the report quite clearly telling me *not* to assume this. But I have to assume *something* for maximum to make sense, so I guess that must be: (x==y) = True implies x=y IOW I have no idea if it's the first or last maximum that is returned, but who cares? Well, you have to assume something for maximum to do what it says it does, which isn't quite the same thing as making sense... I'm not saying some people are not right to want classes with more mathematically inspired laws, but I see nothing in the report to indicate to me that Eq/Ord are those classes and consequently that the naive programmers interpretation of (==) is incorrect. Rather the contrary in fact. It's not a question of more or less mathematically inspired, it's a question of more or less useful. Yes, it's slightly harder to write code that can handle any equivalency correctly. But code that only handles observational equality correctly is less reuseable. The compilers cannot and do not check if the various laws are obeyed. They are purely social interfaces, in that the community of code writers determines the real meaning, and what can be depended on. The community absolutely should come to a consensus of what these meanings are and document them better than they are currently. Currently, if you write code assuming a stricter meaning of Eq a, the consequences are: (a) it's easier for you to write code (b) it's harder for others to interoperate with your code
[Haskell-cafe] Re: (flawed?) benchmark : sort
On 2008-03-13, Adrian Hey [EMAIL PROTECTED] wrote: Aaron Denney wrote: so do you really seriously consider the possibility that this might not hold in your Int related code? if (x==y) then f x else g x y might not mean the same as.. if (x==y) then f y else g x y In Int code, of course not, because I know the types, and I know the behaviour of (==) on Ints. But f is specialized to work on Ints, isn't it, so it's reasonable to know what semantics (==) has for Ints, and depend on them? Why are Ints special in this way? Couldn't you use say exacly the same about any type (just substitute type X of your choice for Int) About any /type/, yes. When I'm writing code specific to type X, I can be expected to know more about the type than what guarantees a generic type inhabiting the same type classes will have. In fact, I better know more, because I'm calling specialized functions that take X, rather than a, or Eq a = a. If I didn't, I'd be writing a more or less generic function, that could operate on more types than X. But this doesn't hold for any old use of (==), or compare. The function sort (to go back to the beginning of this thread) as a generic function, need not assume /anything/ about observation equality to sort a list. All it needs do is use the comparison function on the elements to reorder them. This makes it /more useful/ than one that gets cute by duplicating elements that compare equal, because it can be used in more situations. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Some clarity please!
Aaron Denney [EMAIL PROTECTED] writes: Well, the way the report specifies that max's default definition is. I'd actually favor making that not an instance function at all, and instead have max and min be external functions. If you permit a naïve question: Prelude :i Ord class (Eq a) = Ord a where compare :: a - a - Ordering () :: a - a - Bool (=) :: a - a - Bool () :: a - a - Bool (=) :: a - a - Bool max :: a - a - a min :: a - a - a ..while all functions could be easily derived from 'compare'. Or from the Eq instance's (==) and (), say. What is the reason for this? Efficiency? (Which couldn't be handled equally well by RULES?) Otherwise, it looks like an invitation for writing inconsistent instances. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An offer to any haskell projects out there.
On Tue, 2008-03-11 at 18:46 -0400, [EMAIL PROTECTED] wrote: Hello, My name is Michael Litchard. I'm a techie living in silicon valley, and I want to move into tech writing. I've got the background, now I need a portfolio. I figured the best way to go is to attach myself to some open source projects, and haskell has had my heart for a few years now. I am by no means an expert at haskell. My expertise is writing. So I make this offer. If you need documentation written for your haskell project, I'm your man. Whatever it is, I'll write it or edit it. Thanks for your time. P.S If this was the wrong list, or if anyone has other ideas about how to propogate my proposal, please let me know. Michael Hello Michael, I agree that improving the docs for (some) standard libraries would be the most helpful. However, specializing in a special project would probably be better, if it's a visible portfolio you want. Have you thought of writing a tutorial on one of the HackageDB libraries, for example,database connectivity, XML processing, or even Cabal itself? That would be useful, and give you a clear cut deliverable too. http://www.gordonandgordon.com/aboutus.html is a web site with some good info on technical writing, and the differences between sdk documentation, white papers and technical marketing. All of which would be useful to the Haskell community, IMO, but that's a personal view. Best Regards, Hans van Thiel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Some clarity please! (was Re: Re: (flawed?) benchmark : sort)
Adrian Hey wrote: 2 - It does matter, and the result is guaranteed to be the last maximum in all cases because: (x==y) = True implies max x y = y This seems to be the case looking into GHC/Base.lhs max x y = if x = y then y else x Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Some clarity please!
On 2008-03-13, Ketil Malde [EMAIL PROTECTED] wrote: Aaron Denney [EMAIL PROTECTED] writes: Well, the way the report specifies that max's default definition is. I'd actually favor making that not an instance function at all, and instead have max and min be external functions. If you permit a naïve question: Prelude :i Ord class (Eq a) = Ord a where compare :: a - a - Ordering () :: a - a - Bool (=) :: a - a - Bool () :: a - a - Bool (=) :: a - a - Bool max :: a - a - a min :: a - a - a ..while all functions could be easily derived from 'compare'. Or from the Eq instance's (==) and (), say. What is the reason for this? Efficiency? (Which couldn't be handled equally well by RULES?) Otherwise, it looks like an invitation for writing inconsistent instances. My impression (which may not be entirely accurate) is not primarily for efficiency (though that is one reason), but for ease of implementation. It may be easier in some cases to think through the various cases of compare, or to just figure out what (=) is. Either of these is sufficient (perhaps in combination with (==) from the superclass). You can write things so that any of (), (=), (), or (=) are sufficient, but for writing the default compare, it's easiest to know ahead of time which you are basing it on, so definitions don't get circular. max and min seem to have neither justification going for them, although I suppose it's technically possible to write compare in terms of them and (==). I don't think GHC's RULES were around when Haskell 98 was being formalized, nor is it clear that one compiler's method should let other efficiency concerns go by the wayside. Of course, it would be nice to be able to write (==) in terms of compare. While doable manually there's no way to default it to that smartly. There are similar issues with Functor and Monad. ISTR some discussion about this on the list previously. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating point operations and representation
Wow, you have a tough mission if you want to replicate the bit level answers for double (btw, hi Jacob). Libraries differ for transcendental function, and even worse, CPUs differ. You may get different answers on an Intel and and AMD. That said, I think your best bet is to import log2 and log10 from C and use those. Haskell sadly lacks an efficient way to go from a Double to its bit pattern. :( -- Lennart On Thu, Mar 13, 2008 at 12:35 AM, Jacob Schwartz [EMAIL PROTECTED] wrote: I have two questions about using the Double data type and the operations in the Floating typeclass on a computer that uses IEEE floating point numbers. I notice that the Floating class only provides log (presumably log base 'e') and logBase (which, in the latest source that I see for GHC is defined as log y / log x). However, in C, the math.h library provides specific log2 and log10 functions, for extra precision. A test on IEEE computers (x86 and x86-64), shows that for a range of 64-bit double values, the answers in C do differ (in the last bit) if you use log2(x) and log10(x) versus log (x) / log(2) and log(x) / log(10). I am under the restriction that I need to write Haskell programs using Double which mimic existing C/C++ programs or generated data sets, and get the same answers. (It's silly, but take it as a given requirement.) If the C programs are using log2, then I need log2 in the Haskell, or else I run the risk of not producing the same answers. My first thought is to import log2 and log10 through the FFI. I was wondering if anyone on Haskell-Cafe has already done this and/or has a better suggestion about how to get specialized log2 and log10 (among the many specialized functions that the math.h library provides, for better precision -- for now, I'm just concerned with log2 and log10). My second question is how to get at the IEEE bit representation for a Double. I am already checking isIEEE n in my source code (and floatRadix n == 2). So I know that I am operating on hardware that implements floating point numbers by the IEEE standard. I would like to get at the 64 bits of a Double. Again, I can convert to a CDouble and use the FFI to wrap a C function which casts the double to a 64-bit number and returns it. But I'm wondering if there's not a better way to do this natively in Haskell/GHC (perhaps some crazy use of the Storable typeclass?). Or if someone has already tackled this problem with FFI, that would be interesting to know. Thanks. Jacob ___ 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] floating point operations and representation
On Mar 12, 2008, at 8:35 PM, Jacob Schwartz wrote: My second question is how to get at the IEEE bit representation for a Double. My (rhetorical) question on this front isn't how do I get the representation, but why is it so hard and non-portable to get the representation sensibly? A candidate for standardization, surely? -Jan-Willem Maessen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO () and IO [()]
I don't think writing (1,) is an option for Haskell, it looks like a section (and should be one). On Wed, Mar 12, 2008 at 9:13 PM, Bryan O'Sullivan [EMAIL PROTECTED] wrote: Lennart Augustsson wrote: Yes, I wish Haskell had a 1-tuple. The obvious syntax is already taken, but I could accept something different, like 'One a'. Python's one-tuple syntax is (1,). The obvious difficulty with adapting this notation to Haskell lies in how one might write the constructor as a section. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] File I/O question
Hello Andrew, Wednesday, March 12, 2008, 10:06:44 PM, you wrote: When I write to a file using System.IO, the file is locked for exclusive access. I gather this is as specified in the Haskell Report. Which is nice, but... I'd actually prefer the file to *not* be locked. Anybody know how to do that? one (and only?) possible way is to use Streams library which happens to not lock files: http://haskell.org/haskellwiki/Library/Streams -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug with GADT in function Patterns?
Submited: http://hackage.haskell.org/trac/ghc/ticket/2151#preview hugo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating point operations and representation
On Thu, 13 Mar 2008, Lennart Augustsson wrote: Wow, you have a tough mission if you want to replicate the bit level answers for double (btw, hi Jacob). Libraries differ for transcendental function, and even worse, CPUs differ. You may get different answers on an Intel and and AMD. That said, I think your best bet is to import log2 and log10 from C and use those. Haskell sadly lacks an efficient way to go from a Double to its bit pattern. :( You can do nasty casting using STArray: http://slavepianos.org/rd/sw/sw-78/Sound/OpenSoundControl/Cast.hs ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem making a program in ghc
Hi, I have a problem when I am trying to use a binary file generated by ghc make in Windows. Ihave writed an application that parses xml files and returns a result(using HaXml), this is published as a service, I implemented a server(withSocketsDo), the server listen the port 5760 in a forever fashion,when a message arrives, then the program creates a new thread (forkIO)for attend the request. This works fine when I run it from ghci, when I make the program and run the binary (in Windows), the requests arrive to the program but I think that the response can´t be sentbecause the front end can´t receive the response (I am calling theservice from a .Net web application), I have a log that confirms that the response arrives correctly. I use make like this: ghc --make -package HaXml Main.hs HermesService.hs . What could be the problem? I am using HaXml 1.13.2 with Ghc 6.6.1, thanks in advance. Alvaro Sejas UMSS Cochabamba - Bolivia __ Enviado desde Correo Yahoo! El buzón de correo sin límite de almacenamiento. http://es.docs.yahoo.com/mail/overview/index.html___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell -- when are things evaluated?
On Thu, Mar 13, 2008 at 11:13 AM, Emil Axelsson [EMAIL PROTECTED] wrote: I'm reading the following rule from your answer: [|exp|] normally returns the unevaluated AST of exp. However, if exp contains local variables, these are lifted using Language.Haskell.TH.lift (i.e. evaluated before lifting). Is that correct? / Emil Yes, that seems to be true. I'm not an expert in the internals of TH though, so I have inferred that rule by extensive use of TH ;). SPJ can confirm if it's right. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating point operations and representation
On Thu, Mar 13, 2008 at 1:35 AM, Jacob Schwartz [EMAIL PROTECTED] wrote:
I have two questions about using the Double data type and the
operations in the Floating typeclass on a computer that uses IEEE
floating point numbers.
I notice that the Floating class only provides log (presumably log
base 'e') and logBase (which, in the latest source that I see for
GHC is defined as log y / log x). However, in C, the math.h
library provides specific log2 and log10 functions, for extra
precision. A test on IEEE computers (x86 and x86-64), shows that for
a range of 64-bit double values, the answers in C do differ (in the
last bit) if you use log2(x) and log10(x) versus log (x) /
log(2) and log(x) / log(10).
I am under the restriction that I need to write Haskell programs using
Double which mimic existing C/C++ programs or generated data sets, and
get the same answers. (It's silly, but take it as a given
requirement.) If the C programs are using log2, then I need log2
in the Haskell, or else I run the risk of not producing the same
answers. My first thought is to import log2 and log10 through the
FFI. I was wondering if anyone on Haskell-Cafe has already done this
and/or has a better suggestion about how to get specialized log2 and
log10 (among the many specialized functions that the math.h
library provides, for better precision -- for now, I'm just concerned
with log2 and log10).
The RULES pragma + FFI solution (as suggested by Henning) seems to be
the most sensible one so far.
My second question is how to get at the IEEE bit representation for a
Double. I am already checking isIEEE n in my source code (and
floatRadix n == 2). So I know that I am operating on hardware that
implements floating point numbers by the IEEE standard. I would like
to get at the 64 bits of a Double. Again, I can convert to a CDouble
and use the FFI to wrap a C function which casts the double to a
64-bit number and returns it. But I'm wondering if there's not a
better way to do this natively in Haskell/GHC (perhaps some crazy use
of the Storable typeclass?).
Posted in a a previous haskell-cafe message [1]
{-# LANGUAGE MagicHash #-}
import Data.Int
import GHC.Exts
foo :: Double - Int64 --ghc only
foo (D# x) = I64# (unsafeCoerce# x)
[1] http://www.haskell.org/pipermail/haskell-cafe/2008-February/04.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating point operations and representation
On Mar 13, 2008, at 5:12 , Ketil Malde wrote: Perhaps now everybody uses SSE to do math, but earlier Intel FPU architectures did floating point with 80-bit registers, so the accuracy of the result could depend on whether an intermediate result was flushed to memory (by a context switch). Double operations in IO, anyone? :/ -- 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] Space leak - help needed
Krzysztof Kościuszkiewicz wrote: I have tried both Poly.StateLazy and Poly.State and they work quite well - at least the space leak is eliminated. Now evaluation of the parser state blows the stack... The code is at http://hpaste.org/6310 Apparently, stUpdate is too lazy. I'd define stUpdate' :: (s - s) - Parser s t () stUpdate' f = stUpdate f stGet = (`seq` return ()) and try using stUpdate' instead of stUpdate in incCount. HTH, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Exception handling when using STUArray
On Mar 12, 2008, at 11:23 PM, Luke Palmer wrote: The issue is that exception handling semantics do induce an order of evaluation for determinacy: if both functions in a composition throw an exception at some point (say in the 3rd element of a list they're generating), you need to decide which exception ends up being thrown, and to do that based on the lazy evaluation order would break referential transparency. OK, that is what I was getting several years ago when I brought this up, but ... check my reasoning on this. Maybe a contrived example of what you're talking about, if I write f _ [] = [] f n (a:x) = (div 3 n, j a):(f (n - 1) x) where j (Just v) = v main = print $ f 2 [Just 1, Just 2, Nothing] Running it, I'll hear about a divide by zero on the 3rd element, and not hear about the Just match failure on the 3rd element. Suppose you model exceptions with an data type X that implicitly describes all expressions in Haskell: data X a = Good a | Bad String such that a partial explicit expansion of the above is f _ [] = [] f n (a:x) = (div 3 n, j a):(f (n - 1) x) where j (Just v) = Good v j Nothing = Bad X.hs:15:0-27: Non-exhaustive patterns in function j div a 0 = Bad divide by zero div a b = Good (div a b) The expanded result of (f 2 [Just 1, Just 2, Nothing]) will be [(Good 1, Good 1), (Good 3, Good 2), (Bad divide by zero, Bad X.hs:15:0-27: Non-exhaustive patterns in function j)] My IO action (print) had to decide to throw divide by zero, but arbitrary decisions like that are common and don't make the underlying principle unsound. Am I missing something, or is that a suitable model for pure, non-strict exceptions that could in principle be caught outside IO? (Of course, I do _not_ propose to write code per the expanded example above - that's only a partial expansion, and already too cumbersome to be useful. It's only a conceptual model.) Donn Cave, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] File I/O question
Bulat Ziganshin wrote: Hello Andrew, one (and only?) possible way is to use Streams library which happens to not lock files: Is that likely to compile on Windows? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about monad laws
Am Mittwoch, 12. März 2008 00:53 schrieb askyle: […] So if floating point (==) doesn't correspond with numeric equality, it's not FP's fault, but ours for expecting it to do! No, I think, it’s the Prelude’s fault to define (==) as “floating point equality”. We should us a different identifier like floatingPointEq. (==) is expected to be an equivalence relation. (I think I already said this.) […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem making a program in ghc
2008/3/13 Maverick [EMAIL PROTECTED]: I have writed an application that parses xml files and returns a result (using HaXml), this is published as a service, I implemented a server (withSocketsDo), the server listen the port 5760 in a forever fashion, when a message arrives, then the program creates a new thread (forkIO) for attend the request. This works fine when I run it from ghci, when I make the program and run the binary (in Windows), the requests arrive to the program but I think that the response can´t be sent because the front end can´t receive the response (I am calling the service from a .Net web application), I have a log that confirms that the response arrives correctly. I hate to see any requests for help go unanswered here, but this one might be tough. I think you need to give some more information, otherwise the suggestions are going to be very general. Can you put the Haskell source code on a website somewhere and link to it. Since it's a network service, an example request and reply might be good to include. In general, you should check that you are correctly flushing your connection. If you are using Handles to interface to the network, they can buffer the response. hFlush[1] may need to be called when you have finished generating it. [1] http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO.html#v%3AhFlush AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A question about monad laws
Not to be picky, but where did you hear that (==) established an equivalence relation? Not I expect from the Haskell98 Report! The only law I can find there is that x /= y iff not (x == y) So, the definition x == y = False x /= y = True would be perfectly legitimate, making x /= x = True, which kind of ruins the equivalence relation thing, no? Dan Wolfgang Jeltsch wrote: Am Mittwoch, 12. März 2008 00:53 schrieb askyle: […] So if floating point (==) doesn't correspond with numeric equality, it's not FP's fault, but ours for expecting it to do! No, I think, it’s the Prelude’s fault to define (==) as “floating point equality”. We should us a different identifier like floatingPointEq. (==) is expected to be an equivalence relation. (I think I already said this.) […] Best wishes, Wolfgang ___ 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: Exception handling when using STUArray
Luke Palmer wrote: On Wed, Mar 12, 2008 at 4:45 PM, Donn Cave [EMAIL PROTECTED] wrote: Well, the problem inherently requires a certain order of evaluation. But if you will just handle pattern match failure in the IO monad, then you can write a simple functional expression of the problem instead, let (i, s') = decodeInt s in let (v, _) = decodeInt s' in (i, v) ... where I think `i' can be evaluated without forcing unnecessary evaluation of v. It's clearer, and avoids unnecessary strictness! Unless of course you don't have an IO monad handy. The issue is that exception handling semantics do induce an order of evaluation for determinacy: if both functions in a composition throw an exception at some point (say in the 3rd element of a list they're generating), you need to decide which exception ends up being thrown, and to do that based on the lazy evaluation order would break referential transparency. It bugs me a little how good Haskell is with laziness, but how bad it gets when you need laziness with a slightly different structure. I don't see any way it could reasonably be fixed if I were designing my own language, it's just unsettling. Isn't this what imprecise exeptions were invented (and implemented in GHC) for? See http://research.microsoft.com/Users/simonpj/Papers/imprecise-exn.htm Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Video / Slides: Type-driven testing in Haskell (Simon Peyton Jones)
I was lucky enough to attend a lecture by SPJ yesterday. You're lucky that I taped it and have put it all online :-) http://www.foomongers.org.uk/videos/spj-typedriventestinginhaskell.html If you're a redditer please vote it up on programming.reddit! http://reddit.com/r/programming/info/6byuy/comments/ -Rob -- - She's flushing me out with dogs and grenades, and a sincere desire to spend time with me --Mark Corrigan That's the way things are these days, let's just put a zip here, a swastika there. Who the hell even knows what these things were used for. Who cares? --Mark Corrigan http://www.robhulme.com/ http://robhu.livejournal.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort)
Hi folks I'm late into this thread, so apologies if I'm being dim. On 13 Mar 2008, at 16:17, [EMAIL PROTECTED] wrote: Adrian Hey [EMAIL PROTECTED] wrote: I would ask for any correct Eq instance something like the law: (x==y) = True implies x=y (and vice-versa) I wish I knew what = meant here. Did somebody say? I don't think it's totally obvious what equational propositions should mean. Nor do I think it's desirable to consider only those propositions expressible in QuickCheck. If = is reflexive and distinguishes undefined from True, then x = y implies (x == y) = True will be tricky to satisfy for quite a lot of types. What about undefined == undefined or repeat 'x' == repeat 'x' ? For some suitable (slightly subtle) definition of finite, you might manage x finite and x = y implies (x == y) = True One rather intensional definition of x = y might be x and y have a common n-step reduct with respect to some suitable operational semantics. I don't think this is what Adrian had in mind, but it certainly falls foul of Wolfram's objection. The easiest counterexample are sets (or finite maps) provided as an abstract data type (i.e., exported without access to the implementation, in particular constructors). Different kinds of balanced trees typically do not produce the same representation for the same set constructed by different construction expressions. This suggests that we should seek to define x = y on a type by type basis, to mean x and y support the same observations, for some suitable notion of observation, which might depend crucially on what operations are exported from the (notional or actual) module which defines the type. If so, it's clearly crucial to allow some observations which rely on waiting for ever, in order to avoid _|_-induced collapse. Something of the sort should allow this... Therefore, (==) on sets will be expected to produce equality of sets, which will only be an equivalence on set representations. ...but this... which implies (f x == f y) = True (for expression types which are instances of Eq). This specifies that (==) is a congurence for f, and is in my opinion the right specification: (==) should be a congurence on all datatypes with respect to all purely defineable functions. ...is more troublesome. Take f = repeat. Define f = f. I'd hope x == y = True would give us x = y, and that x == y would be defined if at least one of x and y is finite. That implies f x = f y, which should guarantee that f x == f y is not False. But at least nowadays people occasionally do export functions that allow access to representation details, [..] I consider this as an argument to remove showTree from the interface of Data.Set, and to either specify toList to produce an ordered list (replacing toAscList), or to remove it from the interface as well. Perhaps that's a little extreme but I agree with the sentiment. How about designating such abstraction- breaking functions nosy, in the same way that functions which might break purity are unsafe. (mapMonotonic should of course be removed, too, or specified to fail (preferably in some MonadZero) if the precondition is violated, which should still be implementable in linear time.) What's wrong with mapMonotonic that isn't wrong with, say, sortBy?, or Eq instances for parametrized types? but if so would like to appeal to movers and shakers in the language definition to please decide exactly what the proper interpretation of standard Eq and Ord class laws are and in the next version of the report give an explanation of these Strongly seconded, inserting ``precise'' before ``explanation'' ;-) (And I'd expect equivalences and congruences to be accessible on the basis of standard first-year math...) Before we can talk about what == should return, can we settle what we mean by = ? I think we need to pragmatic about breaking the rules, given suitable documentation and maybe warnings. We should at least aspire to some principles, which means we should try to know what we're talking about and to know what we're doing, even if we don't always do what we're talking about. I'll shut up now. Potatoes to peel Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
On Wed, Mar 12, 2008 at 4:29 PM, Aaron Denney [EMAIL PROTECTED] wrote: When defining max, yes, you must take care to make sure it useable for cases when Eq is an equivalence relation, rather than equality. If you're writing library code, then it won't generally know whether Eq means true equality rather than equivalence. If this would let you optimize things, you need some other way to communicate this. The common typeclasses are for generic, parameterizable polymorphism. Equivalence is a more generally useful notion than equality, so that's what I want captured by the Eq typeclass. I agree that equivalence is more general than equality, but I think equality makes more sense for Eq. Unfortunately, my reasons are mostly circumstantial. (1) You get at most one instance of Eq per type, and you get at most one equality relation per type. On the other hand, you have at least one equivalence (trivial equivalence) and will usually have several. Type classes don't work well when you have more than one of something per type (consider monoids). (2) Libraries like Data.Set and the Edison have to go through a lot of hoops because they can't assume that an Eq tests equality. (The Edison API, in particular, has to create a distinction between observable and non-observable collections, in order to support, e.g., a bag that doesn't store multiple copies of equivalent elements.) (3) Eq uses (==), which is commonly known as the equality sign, not the equivalence sign. (4) The Prelude already provides alternative functions that support any equivalence (sortBy, nubBy, etc.). If I were creating Haskell right now, I'd use Eq for equality and provide an additional class for equivalences along these lines: data P r class Equivalence r where type EqOver r :: * equiv :: P r - EqOver r - EqOver r - Bool data Equality a instance (Eq a) = Equivalence (Equality a) where type EqOver (Equality a) = a equiv _ = (==) data Trivial a instance Equivalence (Trivial a) where type EqOver (Trivial a) = a equiv _ _ _ = True Similar tricks can be used for orderings. -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
G'day all. Quoting Adrian Hey [EMAIL PROTECTED]: I take it you mean something like .. Err... yes, I did. Where's the Eq instance for OrdWrap? Omitted for brevity. This may or may not satisfy the law: (compare a b) = EQ implies (a == b) = True. I think everbody agrees about that, but I can't tell from the code you've posted if it does in this case. The default implementation of compare says that. One thing that's not explicitly stated in the report is whether or not the instances of typeclasses like Eq or Ord need to do the same thing as[*] the default implementations. Does x /= y do the same thing as not (x == y)? What's disputed is whether or not this law should hold: (a == b) = True implies a = b Apart from possibly your good self, I don't think this is disputed. Quotient types, as noted elsewhere in this thread, are very useful. Their common use predates Miranda, so it's way too late to unbless them now. Well I hope you or anyone else hasn't used Data.Map or with OrdWrap keys because if so it's likely that the code has either been broken in the past, or is broken now (not sure which). For Data.Map, using an OrdWrap-like wrapper for keys is wrong, because it's not necessary. OrdWrap is for situations where you need to associate a value with a key which is, unsurprisingly, what Data.Map also does. As for sort, the behaviour hasn't been broken at any point in the past or present that I'm aware of, and a lot of people would strongly resist it if it ever were proposed that it be broken. Cheers, Andrew Bromage [*] Do the same thing as here means that they mean the same thing, but allows for the possibility that some implementation may be less stack-consuming, lazier or in some way more efficient than its default. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Space leak - help needed
On Thu, Mar 13, 2008 at 05:52:05PM +0100, Bertram Felgenhauer wrote: ... Now evaluation of the parser state blows the stack... The code is at http://hpaste.org/6310 Apparently, stUpdate is too lazy. I'd define stUpdate' :: (s - s) - Parser s t () stUpdate' f = stUpdate f stGet = (`seq` return ()) and try using stUpdate' instead of stUpdate in incCount. Yes, that solves the stack issue. Thanks! -- Krzysztof Kościuszkiewicz Skype: dr.vee, Gadu: 111851, Jabber: [EMAIL PROTECTED] Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
Hi On 13 Mar 2008, at 22:28, [EMAIL PROTECTED] wrote: G'day all. Quoting Adrian Hey [EMAIL PROTECTED]: What's disputed is whether or not this law should hold: (a == b) = True implies a = b Apart from possibly your good self, I don't think this is disputed. Quotient types, as noted elsewhere in this thread, are very useful. For a suitable notion of = on quotients, and with a suitable abstraction barrier at least morally in place, is that really too much to ask? Their common use predates Miranda, so it's way too late to unbless them now. How depressing! Untyped programming also predates Miranda. We can always aspire for better. It's not that we need to get rid of Quotients: it's just that we need to manage information hiding properly, which is perhaps not such a tall order. Meanwhile, the sort/Ord/OrdWrap issue may be a storm in a different teacup: the type of sort is too tight. Ord (total ordering) is way too strong a requirement for sorting. Antisymmetry isn't needed for sorting and isn't possessed by OrdWrap. A bit more structure for order-related classes would surely help here. Isn't there room for hope? All the best Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
[EMAIL PROTECTED] wrote: What's disputed is whether or not this law should hold: (a == b) = True implies a = b Apart from possibly your good self, I don't think this is disputed. If that's supposed it imply you think I'm in a minority of one I don't think you've been following this thread very well. Even the report uses the word equality in the prose. And as I pointed out in another post, even the standard library maximum function appears to ambiguous if the law doesn't hold. It can be disambiguated if Aarons max law holds: (a == b) = True implies max x y = y But this is only true for the *default* max implementation. One of the few explicit things the report does say on these matters is that the default methods should *not* be regarded as definitive. Besides there are good pragmatic safety and performance reasons why Haskell should provide at least one class that offers strong guarantees regarding equality and the (==) operator. If that class isn't Eq, then where is it? The (==) law holds for: 1- All standard Eq instances 2- All wholly derived Eq instances 3- Most hand defined instances I suspect. ..and has almost certainly been implicitly assumed by heaven knows what extant code (some of it in the standard libraries I suspect). So I think that we should recognise that this was the original intent for the Eq class and this should be made official, albeit retrospectively. If there's a need for a similar class where the (==) law doesn't hold that's fine. But please don't insist that class must be Eq. Regards -- Adrian Hey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: (flawed?) benchmark : sort
On 2008-03-13, Conor McBride [EMAIL PROTECTED] wrote: Hi On 13 Mar 2008, at 22:28, [EMAIL PROTECTED] wrote: G'day all. Quoting Adrian Hey [EMAIL PROTECTED]: What's disputed is whether or not this law should hold: (a == b) = True implies a = b Apart from possibly your good self, I don't think this is disputed. Quotient types, as noted elsewhere in this thread, are very useful. For a suitable notion of = on quotients, and with a suitable abstraction barrier at least morally in place, is that really too much to ask? I really think it is. I don't think the case of equivalent for this purpose, but not that purpose can be ignored. Now, it may be the case that fooBy functions are then the right thing, but it's not clear to me at all that this is true. And if the fooBy option works, then why would the foo option fail for equivalence classes? I've seen mention of difficulties with Data.Map, and edison, but not in enough detail to really grasp what the problems are. Until I do, my natural bias (which I'm trying to resist, really) is that it's a matter of lazy coding, not any inherent difficulty. Their common use predates Miranda, so it's way too late to unbless them now. How depressing! Untyped programming also predates Miranda. We can always aspire for better. It's not that we need to get rid of Quotients: it's just that we need to manage information hiding properly, which is perhaps not such a tall order. Meanwhile, the sort/Ord/OrdWrap issue may be a storm in a different teacup: the type of sort is too tight. Ord (total ordering) is way too strong a requirement for sorting. Antisymmetry isn't needed for sorting and isn't possessed by OrdWrap. A bit more structure for order-related classes would surely help here. Say what? If I don't have a total ordering, then it's possible two elements are incomparable -- what should a sort algorithm do in such a situation? -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: (flawed?) benchmark : sort
On 2008-03-13, David Menendez [EMAIL PROTECTED] wrote: On Wed, Mar 12, 2008 at 4:29 PM, Aaron Denney [EMAIL PROTECTED] wrote: When defining max, yes, you must take care to make sure it useable for cases when Eq is an equivalence relation, rather than equality. If you're writing library code, then it won't generally know whether Eq means true equality rather than equivalence. If this would let you optimize things, you need some other way to communicate this. The common typeclasses are for generic, parameterizable polymorphism. Equivalence is a more generally useful notion than equality, so that's what I want captured by the Eq typeclass. I agree that equivalence is more general than equality, but I think equality makes more sense for Eq. Unfortunately, my reasons are mostly circumstantial. Despite the circumstantial nature, still strong though. (1) You get at most one instance of Eq per type, and you get at most one equality relation per type. On the other hand, you have at least one equivalence (trivial equivalence) and will usually have several. Type classes don't work well when you have more than one of something per type (consider monoids). Right. But wrapping in newtypes gets around that somewhat. (2) Libraries like Data.Set and the Edison have to go through a lot of hoops because they can't assume that an Eq tests equality. (The Edison API, in particular, has to create a distinction between observable and non-observable collections, in order to support, e.g., a bag that doesn't store multiple copies of equivalent elements.) Why is this a distinction in the API, rather than just the same API by coalescing and non-coalescing collections? (3) Eq uses (==), which is commonly known as the equality sign, not the equivalence sign. Meh. Having the names be right is important, but choosing the right semantics comes first. Eq should be renamed (to either Equal or Equivalent, depending). (4) The Prelude already provides alternative functions that support any equivalence (sortBy, nubBy, etc.). Consider the old if we have trees with different comparison operators, how do we keep the user from merging them together. Well, phantom types, and different instances provides a way to ensure this statically. If I were creating Haskell right now, I'd use Eq for equality and provide an additional class for equivalences along these lines: Well, Haskell' isn't yet finished... data P r class Equivalence r where type EqOver r :: * equiv :: P r - EqOver r - EqOver r - Bool data Equality a instance (Eq a) = Equivalence (Equality a) where type EqOver (Equality a) = a equiv _ = (==) data Trivial a instance Equivalence (Trivial a) where type EqOver (Trivial a) = a equiv _ _ _ = True Hmm. Pretty nice, but I might prefer an MPTC solution. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Space leak - help needed
On Wed, Mar 12, 2008 at 12:34:38PM -0700, Justin Bailey wrote:
The stack blows up when a bunch of unevaluated thunks build up, and
you try to evaluate them. One way to determine where those thunks are
getting built is to use GHCs retainer profiling. Retainer sets will
show you the call stack that is holding on to memory. That can give
you a clue where these thunks are being created. To get finer-grained
results, annotate your code with {#- SCC ... #-} pragmas. Then you
can filter the retainer profile by those annotations. That will help
you determine where in a given function the thunks are being created.
If you need help with profiling basics, feel free to ask.
I'm not entirely sure if I understand retainer profiling correctly... So
please clarify if you spot any obvious blunders.
Retainers are thunks or objects on stack that keep references to
live objects. All retainers of an object are called the object's
retainer set. Now when one makes a profiling run, say with ./jobname
+RTS -p -hr, the graph refernces retainer sets from jobname.prof. My
understanding is that it is the total size of all objects retained by
retainer sets being plotted, correct?
About decoding the sets from jobname.prof - for example in
SET 2 = {MAIN.SYSTEM}
SET 16 = {Main.CAF, MAIN.SYSTEM}
SET 18 = {MAIN.SYSTEM, Main.many1,Main.list,Main.expr,Main.CAF}
{...} means it's a set, and ccN,...,cc0 is the retainer cost centre
(ccN) and hierarchy of parent cost centres up to the top level (cc0)?
My understanding is that SET 18 above refers to objects that are
retained by exactly two specified cost centres, right?
Finally, what is the MAIN.SYSTEM retainer?
Thanks in advance,
--
Krzysztof Kościuszkiewicz
Skype: dr.vee, Gadu: 111851, Jabber: [EMAIL PROTECTED]
Simplicity is the ultimate sophistication -- Leonardo da Vinci
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
G'day all. Quoting Conor McBride [EMAIL PROTECTED]: How depressing! Sorry, I don't understand that. Quotient types are good, but they're not the whole story. They just happen to be one use case with a solid history behind them. it's just that we need to manage information hiding properly, which is perhaps not such a tall order. It's my opinion (and I know I'm not alone in this) that modularity is probably the one thing that Haskell really hasn't (yet) gotten right. Haskell's implementation of modules/namespaces/whatever is the bare minimum needed to be minimally useful. It's a shame, because abstraction, in Haskell, is extremely cheap. It's often only one line, and you've got a compiler-checked abstraction that can't be accidentally confused with its representation. This should encourage micro-abstractions everywhere, but without submodules, namespaces or whatever you want to call them, these abstractions are easy to break (on purpose, not by accident). If only you could add a couple more lines of code, and instantly have your abstraction unbreakable. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
Hi On 13 Mar 2008, at 23:33, Aaron Denney wrote: On 2008-03-13, Conor McBride [EMAIL PROTECTED] wrote: Hi On 13 Mar 2008, at 22:28, [EMAIL PROTECTED] wrote: G'day all. Quoting Adrian Hey [EMAIL PROTECTED]: What's disputed is whether or not this law should hold: (a == b) = True implies a = b Apart from possibly your good self, I don't think this is disputed. Quotient types, as noted elsewhere in this thread, are very useful. For a suitable notion of = on quotients, and with a suitable abstraction barrier at least morally in place, is that really too much to ask? I really think it is. I don't think the case of equivalent for this purpose, but not that purpose can be ignored. Sure. But use the right tools for the job. Now, it may be the case that fooBy functions are then the right thing, but it's not clear to me at all that this is true. And if the fooBy option works, then why would the foo option fail for equivalence classes? It seems reasonable to construct quotients from arbitrary equivalences: if fooBy works for the carrier, foo should work for the quotient. Of course, if you want to expose the representation for some other legitimate purpose, then it wasn't equality you were interested in, so you should call it something else. A bit more structure for order-related classes would surely help here. Say what? Don't panic! If I don't have a total ordering, then it's possible two elements are incomparable Quite so. -- what should a sort algorithm do in such a situation? Not care. Produce a resulting list where for any [..., x, ..., y, ...] in the result, y = x implies x = y. Vacuously satisfied in the case of incomparable elements. In the case of a total order, that gives you y = x implies x = y (and everything in between), but for a preorder, you put less in, you get less out. Will that do? Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
G'day all. Quoting Adrian Hey [EMAIL PROTECTED]: If that's supposed it imply you think I'm in a minority of one I don't think you've been following this thread very well. Sorry, that was a bit of hyperbole. Even the report uses the word equality in the prose. Indeed, and the only sensible meaning of equality that I can think of is _semantic_ equality. Two values are semantically equal if they mean the same thing. A concrete example of a quotient type that I had in mind is rationals. A rational is implemented as, for the sake of argument, a pair of integers. Two rational numbers, a/b and c/d, are equal iff ad = bc. That's what everyone means by equality for rationals. It's true that rationals have a normal form, and this can be enforced by a smart constructor and an unbreakable abstraction. But if you've got an unbreakable abstraction, then you've also got the mechanism to enforce observational equality. Moreover, not all quotient types have a one true normal form (e.g. regular expressions), and even in cases where there is a sensible normal form, it might be undesirable for reasons of performance or convenience. Besides there are good pragmatic safety and performance reasons why Haskell should provide at least one class that offers strong guarantees regarding equality and the (==) operator. Well, I haven't heard any reasons that have convinced me yet. No arguing over taste, of course. ..and has almost certainly been implicitly assumed by heaven knows what extant code (some of it in the standard libraries I suspect). Nobody has yet gone to the trouble of consulting either heaven or the source code (in whatever order is deemed appropriate) to see if this claim is true. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort)
Hi On 13 Mar 2008, at 23:42, [EMAIL PROTECTED] wrote: Conor McBride [EMAIL PROTECTED] responded to my comment: (mapMonotonic should of course be removed, too, or specified to fail (preferably in some MonadZero) if the precondition is violated, which should still be implementable in linear time.) What's wrong with mapMonotonic that isn't wrong with, say, sortBy?, or Eq instances for parametrized types? Prelude :m + Data.Set Prelude Data.Set toAscList $ mapMonotonic (10 -) (fromList [1 .. 5]) [9,8,7,6,5] Prelude Data.Set 5 `member` mapMonotonic (10 -) (fromList [1 .. 5]) False Something's certainly wrong there! But nothing out of the ordinary: garbage in, garbage out. Happens all the time, even in Haskell. Why pick on mapMonotonic? Prelude Data.List sortBy (\_ _ - GT) [1,3,2,5,4] [4,5,2,3,1] Prelude Data.List sortBy (\_ _ - GT) [4,5,3,2,1] [1,2,3,5,4] I guess there's a question of what we might call toxic waste---junk values other than undefined. I think undefined is bad enough already. So the type system can't express the spec. I don't think we should be casual about that: we should be precise in documentation about the obligations which fall on the programmer. Some dirt is pragmatically necessary: we shouldn't pretend that it ain't so; we shouldn't pretend that dirt is clean. Before we can talk about what == should return, can we settle what we mean by = ? ``='' is not in the Haskell interface! ;-) No, but is is in the human interface! Therefore, I talked only about (==). Ah, but you talked about things. Which things? Is one of the things you talked about the same as (==)? the same as (flip (==))? The best way to include ``='' seems to be the semantic equality of P-logic [Harrison-Kieburtz-2005], which is quite a heavy calibre, and at least in that paper, classes are not yet included. I expect it's hard work. It's hard work in much better behaved systems. My point is that it's worth it, in order to facilitate more meaningful discussions. All the best Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (flawed?) benchmark : sort
On Thursday 13 March 2008 07:33:12 pm Aaron Denney wrote: [snip] I've seen mention of difficulties with Data.Map, and edison, but not in enough detail to really grasp what the problems are. Until I do, my natural bias (which I'm trying to resist, really) is that it's a matter of lazy coding, not any inherent difficulty. For the specific case of Edison, the Haddock documentation for the following two modules tells the whole sordid story: http://hackage.haskell.org/packages/archive/EdisonAPI/1.2.1/doc/html/Data-Edison.html http://hackage.haskell.org/packages/archive/EdisonAPI/1.2.1/doc/html/Data-Edison-Coll.html The Cliff Notes version is that Edison assumes the following things about Eq and Ord instances: * An Eq instance correctly defines an equivalence relation (but not necessarily structural equality); that is, we assume (==) (considered as a relation) is reflexive, symmetric and transitive, but allow that equivalent items may be distinguishable by other means. * An Ord instance correctly defines a total order which is consistent with the Eq instance for that type. It's not explicitly stated, but Edison also assumes that the operations within a class are consistent, i.e., that (not (x == y)) calculates the same function as (x /= y), etc. I suppose that should go in the docs too. Edison makes no particular assumptions about min and max, except that they are consistent with the defined order. Anyway, the end result for Edison is that some operations aren't well-defined, and can't be made well-defined without restrictions. For example, consider the operation of folding in non-decreasing order over the elements of a multi-set. If the function being folded distinguishes between two elements x and y, but (compare x y) = EQ, and x and y are both contained in the multi-set, then the result of the fold depends on internal state that is not supposed to be user-visible (e.g., the exact shape of a balanced tree). Blah, blah, blah, its all in the documentation. The point is that making loose assumptions about the meaning of the operations provided by Eq and Ord complicates things in ways that can't be made to go away. Rob Dockins ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ackermann Function Memoization, GHC Weird Output or Bug?
Hello,
I'm learning Haskell, so I was attempting memoization based upon the
Fibonacci examples but for the Ackermann function. In my tests, I found
what seems to be truncated output. See my comments at the end of the code
for the test cases and output.
### Begin Code ###
module Main where
import Data.Array
main = do
let m = 3
n = 1
a = ackermann_mem m n
putStrLn(Ackermann-mem ++ show m ++ ++ show n ++ = ++ show a)
-- Functions.
-- Based upon examples from:
-- http://reddit.com/r/programming/info/16ofr/comments)
http://reddit.com/r/programming/info/16ofr/comments%29
tabulate bounds f = array bounds [(i, f i) | i - range bounds]
dp bounds f = (memo!) where memo = tabulate bounds (f (memo!))
-- Trying to apply memoization function to Ackermann.
ackermann_mem m n = dp ((0,0), (30, 1000)) ack (m, n)
where
ack rec (0, n) = n + 1
ack rec (m, 0) = rec (m - 1, 1)
ack rec (m, n) = rec (m - 1, rec (m, n - 1))
{-
Test cases:
ackermann_mem 4 1 = 533 -- when using (30, 1000) as upper bound.
ackermann_mem 4 1 = 5533 -- when using (30, 1) as upper bound.
ackermann_mem 4 1 = 65533 -- when using (30, 10) as upper bound.
--- correct answer!
-}
### End Code ###
It seems if I don't choose an upper bound pair for (m,n) that is large
enough I get truncated output for the answer, instead of GHC giving me an
array index exception... This behavior seems very odd to me, can someone
explain? Or is this a bug?
Thank you.
__
Donnie Jones
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Some clarity please! (was Re: [Haskell-cafe] Re: (flawed?) benchmark : sort)
Adrian Hey wrote: I would ask for any correct Eq instance something like the law: (x==y) = True implies x=y (and vice-versa) which implies f x = f y for all definable f which implies (f x == f y) = True (for expression types which are instances of Eq). This pretty much requires structural equality for concrete types. For abstract types you can do something different provided functions which can give different answers for two equal arguments are not exposed. How do you propose something like this to be specified in the language definition? The report doesn't (and shouldn't) know about abstract types. It only talks about things which are exported and things which are not. The distinction between implementation modules and client modules is made by the programmer, not by the language. So you can either require your law to hold everywhere, which IMO isn't a good idea, or you don't require it to hold. From the language definition point of view, I don't see any middle ground here. Also, when you talk about definable functions, do you include things like I/O? What if I want to store things (such as a Set) on a disk? If the same abstract value can have multiple representations, do I have to convert them all to some canonical representation before writing them to a file? This might be rather slow and is, IMO, quite unnecessary. From a more philosophical points of view, I'd say that the appropriate concept of equality depends a lot on the problem domain. Personally, I quite strongly disagree with restricting Eq instances in the way you propose. I have never found much use for strict structural equality (as opposed to domain-specific equality which may or may not coincide with the structural one). On the subject of ambiguity, bugs and maxima, I see we have in Data.List [...] So I believe I'm correct in saying that maximumBy returns the last of several possible maximum elements of the list. This obviously needs specifying in the Haddock. Because maximumBy documentation is ambiguous in this respect, so is the overloaded maximum documentation. At least you can't figure it out from the Haddock. Why not simply say that maximumBy returns some maximum element from the list but it's not specified which one? That's how I always understood the spec. Code which needs a particular maximum element can't use maximumBy but such code is rare. I don't see how this is ambiguous, it just leaves certain things unspecified which is perfectly ok. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem making a program in ghc
This answer may be way off base, but if differences appear between ghci and compiled versions, I've often found its as simple as remembering to compile with the -threaded flag. The ghci runtime is threaded by default, as I understand it, while compiled binaries are not, and IO operations will block in very different fashions (i.e. in their own thread, or stalling the entire app) depending on the runtime. Regards, sterl. On Mar 13, 2008, at 3:47 PM, Adam Langley wrote: web application), I have a log that confirms that the response arrives correctly. I hate to see any requests for help go unanswered here, but this one might be tough. I think you need to give some more information, otherwise the suggestions are going to be very general. Can you put the Haskell source code on a website somewhere and link to it. Since it's a network service, an example request and reply might be good to include. In general, you should check that you are correctly flushing your connection. If you are using Handles to interface to the network, they can buffer the response. hFlush[1] may need to be called when you have finished generating it. [1] http://haskell.org/ghc/docs/latest/html/libraries/base/System- IO.html#v%3AhFlush AGL -- Adam Langley [EMAIL PROTECTED] http://www.imperialviolet.org ___ Haskell-Cafe mailing list ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ackermann Function Memoization, GHC Weird Output or Bug?
On Mar 13, 2008, at 23:47 , Donnie Jones wrote: It seems if I don't choose an upper bound pair for (m,n) that is large enough I get truncated output for the answer, instead of GHC giving me an array index exception... This behavior seems very odd to me, can someone explain? Or is this a bug? Per http://www.haskell.org/ghc/docs/latest/html/libraries/base/ Control-Exception.html: NOTE: GHC currently does not throw ArrayExceptions -- 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
[Haskell-cafe] Naming as infection
All, Here http://biosimilarity.blogspot.com/2008/03/naming-as-dialectic.html is a deliberately provocative posting (with running code and a shameless plug for BNFC) on the process of introducing naming and name management into the design of data structures. Comments greatly appreciated. Best wishes, --greg -- L.G. Meredith Managing Partner Biosimilarity LLC 806 55th St NE Seattle, WA 98105 +1 206.650.3740 http://biosimilarity.blogspot.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
