Re: [Haskell-cafe] What *not* to use Haskell for
Don Stewart [EMAIL PROTECTED] writes: Data.ByteString is full of mutation-heavy inner loops. I suspect you are missing Kyle's point, which I interpret to be more like what Paul Graham talks about in ANSI Common Lisp: [OO] provides a structured way to write spaghetti code. [...] For programs that would have ended up as spaghetti anyway, the object oriented model is good: they will at least be structured spaghetti. In my opinion, Haskell is pretty bad at spaghetti. And although it is possible that some programs simply need to be spaghetti-structured, I still think not supporting it is a good thing - Haskell should instead provide the tools for writing an equivalent non-spaghettized program. Bytestrings have mutation-heavy inner loops, but localized, well-structured, and exporting a neat, pure interface, so they don't count here. There's nothing magic about it. Now you're just being modest. -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
[Haskell-cafe] Re: reliable (bi)directional pipe to a process
http://okmij.org/ftp/Haskell/MySysOpen.hs when I run the test case in the file, the first read_back gets until count=9890, then hangs (I don't see Doing it again) (CPU is idle) (with ghc-6.10.1) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ByteString/parsec
Pieter Laeremans [EMAIL PROTECTED] writes: Are there any good examples of open source projects which parse ByteString data ? Don't know about good, but here are some working examples that may or may not be useful to you. Pointers are inside the darcs repo, you can of course 'darcs get http://malde.org/~ketil/biohaskell/biolib' to obtain the whole deal. A simple parser for the even simpler FASTA format: http://malde.org/~ketil/biohaskell/biolib/Bio/Sequence/Fasta.hs Parser to decode the ACE format by tokenizing to Bytestring, then using Parsec: http://malde.org/~ketil/biohaskell/biolib/Bio/Alignment/ACE.hs The repo also contains parsers for other formats like FASTQ, and binary formats like SFF. Please email me with any questions or comments. -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
[Haskell-cafe] Proof that Haskell is RT
Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? (I was writing a blog post about the origins of the phrase 'referentially transparent' and it made me think about this) Andrew -- - http://www.nobugs.org - ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Anatoly Yakovenko [EMAIL PROTECTED] wrote: Has there been any progress in getting ghc set up for porting to non x86/unix/windows platforms? Can it generate ropi code? It would also be nice to be able to compile to C that rvct/arm tools can compile in thumb mode. AFAIK, you can bootstrap ghc onto lots of non-PC-centric platforms, using the unregisterized porting guide. However, it is not a trivial exercise, and it does not address the question of setting ghc up as a cross-compiler, should your device be too small to host ghc at all. Other Haskell compilers might be a better starting point. For instance, nhc98 uses portable C as a target language, and has a configure-time option to set it up as a cross-compiler. See http://www.cs.york.ac.uk/fp/nhc98/install.html (cross-compiler info towards the bottom of the page). The example given is for ARM/linux. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Searching for ADT patterns with elem and find
Thanks Tom, That is indeed a very elegant solution; I too often forget about the wonders of list comprehension. I guess one drawback compared to Neil's suggested use of any (and staying with a separate isTypeB) is that your solution will iterate over the entire list, regardless of an early hit. But I don't think your second (as-pattern) solution for findBs is ugly; I quite like it actually. Cheers, Paul -Original Message- From: Tom Nielsen [mailto:[EMAIL PROTECTED] Sent: Wed 12/11/2008 12:39 To: Paul Keir Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Searching for ADT patterns with elem and find somebody pointed out a few months back that list comprehensions do this nicely: containsTypeB ts = not $ null [x | (B x) - ts] no need for defining isTypeB. not quite sure how you would write findBs :: [T]-[T] succinctly; maybe findBs ts = [b | b@(B _) - ts] or findBs ts = [B x | (B x) - ts] both of them compile but the first is ugly and the second is inefficient (Tags a new T for every hit). Tom 2008/11/12 Paul Keir [EMAIL PROTECTED]: Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype B Double, must my containsTypeX function use a second isTypeX function as follows: isTypeB :: T - Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] - Bool containsTypeB ts = maybe False (\x - True) (find isTypeB ts) I understand that while something like find C ts will work, find (isTypeB _) ts will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual isTypeB functions now. Regards, Paul ___ 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] What *not* to use Haskell for
Hi Reinier, On Wed, Nov 12, 2008 at 14:22, Reinier Lamers [EMAIL PROTECTED] wrote: Also, in my experience Haskell is not so good at data structures where you can't do structural recursion easily, like graphs. In such cases you want a language with easy pointers and destructive updates. You can do those things in pure Haskell by using the ST monad, but the code will be more verbose than in Java or C++, and it will occasionally drive you insane with type messages like the above (You thought you could use '$' freely instead of application? Wrong!). Can you give examples of what you mean and why algebraic data types are not sufficient? In my research most things are structurally recursive and it was because Haskell is so good at such things that I started using it. cheers, Arnar ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
Lennart Augustsson wrote: You can't write a straightforward dynamic semantics (in, say, denotational style) for Haskell. The problem is that with type classes you need to know the types compute the values. You could use a two step approach: first make a static semantics that does type inference/checking and translates Haskell into a different form that has resolved all overloading. And, secondly, you can write a dynamic semantics for that language. But since the semantics has to have the type inference engine inside it, it's going to be a pain. It's possible that there's some more direct approach that represents types as some kind of runtime values, but nobody (to my knowledge) has done that. This has been done. For example, check out the type class semantics given in Thatte, Semantics of type classes revisited, LFP '94 Stuckey and Sulzmann, A Theory of Overloading, TOPLAS'05 Harrison: A Simple Semantics for Polymorphic Recursion. APLAS 2005 is also related I think. The ICFP'08 poster Unified Type Checking for Type Classes and Type Families , Tom Schrijvers and Martin Sulzmann suggests that a type-passing semantics can even be programmed by (mis)using type families. - Martin -- Lennart On Wed, Nov 12, 2008 at 12:39 PM, Luke Palmer [EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean [EMAIL PROTECTED] wrote: Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? The (well, a natural approach to a) formal proof would be to give a formal semantics for haskell. Haskell 98 does not seem that big to me (it's not teeny, but it's nothing like C++), yet we are continually embarrassed about not having any formal semantics. What are the challenges preventing its creation? Luke ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problem with boolean splicing in templates in ghc 6.10.1
On Tue, Nov 11, 2008 at 02:16:21PM -0600, Leonidas Fegaras wrote: Seems that boolean splicing in haskell templates in ghc 6.10.1 does not work correctly. If you do: $((\b - [| b |]) True) you get the error: Can't find interface-file declaration for data constructor GHC.Base.True Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error It seems that GHC.Base.True is now GHC.Bool.True, but the splicing code still generates the former. Fixed in HEAD and 6.10 branch, and I've added a test to the testsuite. If you want to build a fixed template-haskell package locally then the fix is: hunk ./Language/Haskell/TH/Syntax.hs 264 -trueName = mkNameG DataName base GHC.Base True -falseName = mkNameG DataName base GHC.Base False +trueName = mkNameG DataName ghc-prim GHC.Bool True +falseName = mkNameG DataName ghc-prim GHC.Bool False Thanks Ian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Searching for ADT patterns with elem and find
I guess one drawback compared to Neil's suggested use of any (and staying with a separate isTypeB) is that your solution will iterate over the entire list, regardless of an early hit. Nope, it will stop on the first one - Haskell is lazy like that :-) Thanks, Neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Keir Sent: 12 November 2008 1:45 pm To: Tom Nielsen Cc: haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] Searching for ADT patterns with elem and find Thanks Tom, That is indeed a very elegant solution; I too often forget about the wonders of list comprehension. I guess one drawback compared to Neil's suggested use of any (and staying with a separate isTypeB) is that your solution will iterate over the entire list, regardless of an early hit. But I don't think your second (as-pattern) solution for findBs is ugly; I quite like it actually. Cheers, Paul -Original Message- From: Tom Nielsen [mailto:[EMAIL PROTECTED] Sent: Wed 12/11/2008 12:39 To: Paul Keir Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Searching for ADT patterns with elem and find somebody pointed out a few months back that list comprehensions do this nicely: containsTypeB ts = not $ null [x | (B x) - ts] no need for defining isTypeB. not quite sure how you would write findBs :: [T]-[T] succinctly; maybe findBs ts = [b | b@(B _) - ts] or findBs ts = [B x | (B x) - ts] both of them compile but the first is ugly and the second is inefficient (Tags a new T for every hit). Tom 2008/11/12 Paul Keir [EMAIL PROTECTED]: Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype B Double, must my containsTypeX function use a second isTypeX function as follows: isTypeB :: T - Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] - Bool containsTypeB ts = maybe False (\x - True) (find isTypeB ts) I understand that while something like find C ts will work, find (isTypeB _) ts will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual isTypeB functions now. Regards, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
2008/11/11 Dave Tapley [EMAIL PROTECTED]: So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Let's say something controversial: I think that Haskell's type system gets in your way when you're writing one-shot scripts that don't need to conform to the highest correctness standards. Imagine typing a command at the shell prompt and getting the sort of abstract error message that Haskell compilers give every now and then, like: whyerror.lhs:36:25: Ambiguous type variable `a' in the constraint: `Arrow a' arising from use of `' at whyerror.lhs:36:25-27 Possible cause: the monomorphism restriction applied to the following: liftA2' :: forall b a1 b1 c. (a1 - b1 - c) - a b a1 - a b b1 - a b c (bound at whyerror.lhs:36:1) unsplit' :: forall a1 b c. (a1 - b - c) - a (a1, b) c (bound at whyerror.lhs:34:1) split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1) Probable fix: give these definition(s) an explicit type signature or use -fno-monomorphism-restriction You don't want to be bothered by such monstrosities (yes, they are, even though many of you may not see it because of years of conditioning) when you're just hacking up a simple script to make a catalog of your MP3 collection / check for patterns in log files / whatever. Also, in my experience Haskell is not so good at data structures where you can't do structural recursion easily, like graphs. In such cases you want a language with easy pointers and destructive updates. You can do those things in pure Haskell by using the ST monad, but the code will be more verbose than in Java or C++, and it will occasionally drive you insane with type messages like the above (You thought you could use '$' freely instead of application? Wrong!). Regards, Reinier ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] TimeDiff to Int?
Hi folks, I had some code using the oldtime package, and want to convert it to use the time package. One of the things I need to do is calculate the number of seconds since midnight. The easy part is getting a TimeDiff result: utc - getCurrentTime tz - getCurrentTimeZone let td = timeOfDayToTime $ localTimeOfDay $ utcToLocalTime tz utc Now td is a TimeDiff representation of the number of seconds since midnight. It prints nicely, but I'm having a heck of a time figuring out how to truncate it to an Int. The floor function is only supported by the RealFrac class. Although TimeDiff has an instance of RealFrac and Fractional, it doesn't have an instance of RealFrac. I looked up the various to* and from* functions and have come up short. fromEnum yields an Int but it's the wrong value. I know I could use show and then use readS to get an Integer, or use formatTime (and reparse that), but that's a hack. I can convert it to a TimeOfDay which gives me hours, minutes, and seconds, but then I have to do arithmetic on it, and the seconds are of type Pico, which I can't call floor on either. I can convert it to a Rational via timeOfDayToDayFraction, but a TimeDiff is already a Rational those don't have floor. What am I missing? There has got to be an easy way to count seconds! Thanks, Lyle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage web interface
Hi, When previewing some package via the Hackage web interface, I get the following warning: Exposed modules use unallocated top-level names: AI assume that if you define some module A.B, it expects the top-level name A to be a module. Does this make sense? Thanks, hugo -- www.di.uminho.pt/~hpacheco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] abstract extensible types?
On 2008 Nov 12, at 5:38, Alberto G. Corona wrote: Is there any abstract container that permits the addition of new types of data? I know how to simulate the extension of Algebraic datatypes, but this does not permit the addition of data with new types in the same container and recover them in a type-safe way. Did I reinvent the Weel? I found something, that permits this for any Typeable datatype. For example I think you want http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Dynamic.html . -- 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] Proof that Haskell is RT
It's possible that there's some more direct approach that represents types as some kind of runtime values, but nobody (to my knowledge) has done that. It don't think its possible - I tried it and failed. Consider: show (f []) Where f has the semantics of id, but has either the return type [Int] or [Char] - you get different results. Without computing the types everywhere, I don't see how you can determine the precise type of []. Thanks Neil On Wed, Nov 12, 2008 at 12:39 PM, Luke Palmer [EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean [EMAIL PROTECTED] wrote: Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? The (well, a natural approach to a) formal proof would be to give a formal semantics for haskell. Haskell 98 does not seem that big to me (it's not teeny, but it's nothing like C++), yet we are continually embarrassed about not having any formal semantics. What are the challenges preventing its creation? Luke ___ 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 == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Searching for ADT patterns with elem and find
containsTypeB ts = not $ null [x | (B x) - ts] No need for the brackets on the left of the -: not $ null [x | B x - ts] findBs ts = [b | b@(B _) - ts] or findBs ts = [B x | (B x) - ts] both of them compile but the first is ugly and the second is inefficient (Tags a new T for every hit). If optimised does it really create a new B tag for each node? That seems like something that could be optimised away by the compiler. Either way, the difference is probably minimal. (There may be possible space leaks if the compiler did share the B, but I can't think of any off hand) Thanks Neil 2008/11/12 Paul Keir [EMAIL PROTECTED]: Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype B Double, must my containsTypeX function use a second isTypeX function as follows: isTypeB :: T - Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] - Bool containsTypeB ts = maybe False (\x - True) (find isTypeB ts) I understand that while something like find C ts will work, find (isTypeB _) ts will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual isTypeB functions now. Regards, Paul ___ 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 == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 12, 2008, at 7:09 AM, Lennart Augustsson wrote: It's possible that there's some more direct approach that represents types as some kind of runtime values, but nobody (to my knowledge) has done that. I think JHC passes types at runtime, using them in C switch statements for overloading, but I don't know if an implementation like that is really what we would need for this. - - Jake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkka6LcACgkQye5hVyvIUKnlfwCgmpcvghHK9lYd3XwK7sfwARnM xlYAoLXxw3sz4CNaThaNV9GGsX4ALR/L =0q26 -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal for associated type synonyms in Template Haskell
Hi Pedro, You are right, it is a partial implementation. We chose not to propose an implementation for associated datatypes and type families because it is unknown if there is a demand for it. But I don't think coming up with the TH AST modifications for associated type synonyms and type families is that much harder. Especially associated datatypes are very similar to associated type synonyms. The difficult part is in the GHC translation of course. Regards, Thomas José Pedro Magalhães wrote: Hello Thomas, I see this is a proposal for a partial implementation of #1673 (http://hackage.haskell.org/trac/ghc/ticket/1673). Maybe it would be good if the remaining syntax (associated datatypes and type families) would also be defined and implemented in TH. Or maybe there isn't much demand for this?... Cheers, Pedro On Wed, Nov 5, 2008 at 15:57, Thomas van Noort [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello, Recently, we released a library on Hackage for generic rewriting (package rewriting if you are curious). The user of the library is expected to define type class instances to enable rewriting on his or her own datatypes. As these instances follow the datatype declarations closely, we tried to generate the instances using Template Haskell. Unfortunately, associated type synonyms are not yet supported by TH. After a presentation at the WGP'08, Simon encouraged us to write a proposal about adding associated type synonyms to TH, so that it can be added to GHC. So, here is our proposal. The TH AST must allow 1) kind declarations of associated type synonyms in class declarations and 2) their definitions in instance declarations. For example, class Foo a where type Bar a :: * instance Foo Int where type Bar Int = String The TH library defines a datatype Dec which contains a constructor for class declarations and instance declarations: data Dec = ... | ClassD Cxt Name [Name] [FunDep] [Dec] | InstanceD Cxt Type [Dec] ... 1) Associated type synonym kind declarations We suggest to add a constructor to the Dec type: ... | AssocTySynKindD Name [Name] (Maybe Kind) ... assocTySynKindD :: Name - [Name] - Maybe KindQ - DecQ The first field is the name of the associated type synonym, the second field is a list of type variables, and the third field is an optional kind. Since kinds are not yet defined in TH, we have to add some kind of kind definition (pun intended): data Kind = StarK | ArrowK Kind Kind type KindQ = Q Kind starK :: KindQ arrowK :: KindQ - KindQ - KindQ We explicitly choose not to reuse the Type type to define kinds (i.e., type Kind = Type as in GHC) since we think a separation between the two worlds is much clearer to the users of TH. 2) Associated type synonym definitions We suggest to add another constructor to the Dec type: ... | AssocTySynD Name [Type] Type ... assocTySynD :: Name - [TypeQ] - TypeQ - DecQ The first field is the name of the type synonym, the second field is a list of type arguments, and the third field is the body of the type synonym. We would like to hear your comments to this proposal. Regards, Thomas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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] Proof that Haskell is RT
Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? The (well, a natural approach to a) formal proof would be to give a formal semantics for haskell. Referential transparency would be an obvious property of the semantics. Soundness would show that it carried over to the language. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Searching for ADT patterns with elem and find
Hi Paul, maybe False (\x - True) (find isTypeB ts) This can be more neatly expressed as: isJust (find isTypeB ts) But your entire thing can be expressed as: containsTypeB ts = any isTypeB ts I recommend reading through the Prelude interface and the List interface, it has many useful functions that will help. Thanks Neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Keir Sent: 12 November 2008 10:09 am To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Searching for ADT patterns with elem and find Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype B Double, must my containsTypeX function use a second isTypeX function as follows: isTypeB :: T - Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] - Bool containsTypeB ts = maybe False (\x - True) (find isTypeB ts) I understand that while something like find C ts will work, find (isTypeB _) ts will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual isTypeB functions now. Regards, Paul == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Calling Haskell from other languages?
Hi Colin As an alternative you may consider using Thrift: http://incubator.apache.org/thrift/ Cheers, Dave On Tue, 2008-11-11 at 16:45 +, Colin Paul Adams wrote: Is there a way to call Haskell code from other languages? I have looked on the wiki, and as far as I can see, it only talks about the other way round (when Haskell is the main program). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Searching for ADT patterns with elem and find
Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype B Double, must my containsTypeX function use a second isTypeX function as follows: isTypeB :: T - Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] - Bool containsTypeB ts = maybe False (\x - True) (find isTypeB ts) I understand that while something like find C ts will work, find (isTypeB _) ts will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual isTypeB functions now. Regards, Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
Correct Lennart. The below mentioned papers assume some evidence translation of type class programs. If you need/want a direct semantics/translation of programs you'll need to impose some restrictions on the set of allowable type class programs. For such an approach see Martin Odersky, Philip Wadler, Martin Wehr: A Second Look at Overloading. FPCA 1995: Roughly, the restriction says, you can overload the argument but not the result (types). - Martin Lennart Augustsson wrote: I had a quick look at Stuckey and Sulzmann, A Theory of Overloading and it looks to me like the semantics is given by evidence translation. So first you do evidence translation, and then give semantics to the translated program. So this looks like the two step approach I first mentioned. Or have I misunderstood what you're doing? What I meant hasn't been done is a one step semantics directly in terms of the source language. I guess I also want it to be compositional, which I think is where things break down. -- Lennart On Wed, Nov 12, 2008 at 2:26 PM, Martin Sulzmann [EMAIL PROTECTED] wrote: Lennart Augustsson wrote: You can't write a straightforward dynamic semantics (in, say, denotational style) for Haskell. The problem is that with type classes you need to know the types compute the values. You could use a two step approach: first make a static semantics that does type inference/checking and translates Haskell into a different form that has resolved all overloading. And, secondly, you can write a dynamic semantics for that language. But since the semantics has to have the type inference engine inside it, it's going to be a pain. It's possible that there's some more direct approach that represents types as some kind of runtime values, but nobody (to my knowledge) has done that. This has been done. For example, check out the type class semantics given in Thatte, Semantics of type classes revisited, LFP '94 Stuckey and Sulzmann, A Theory of Overloading, TOPLAS'05 Harrison: A Simple Semantics for Polymorphic Recursion. APLAS 2005 is also related I think. The ICFP'08 poster Unified Type Checking for Type Classes and Type Families , Tom Schrijvers and Martin Sulzmann suggests that a type-passing semantics can even be programmed by (mis)using type families. - Martin -- Lennart On Wed, Nov 12, 2008 at 12:39 PM, Luke Palmer [EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean [EMAIL PROTECTED] wrote: Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? The (well, a natural approach to a) formal proof would be to give a formal semantics for haskell. Haskell 98 does not seem that big to me (it's not teeny, but it's nothing like C++), yet we are continually embarrassed about not having any formal semantics. What are the challenges preventing its creation? Luke ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TimeDiff to Int?
2008/11/12 Lyle Kopnicky [EMAIL PROTECTED] Hi folks, I had some code using the oldtime package, and want to convert it to use the time package. One of the things I need to do is calculate the number of seconds since midnight. The easy part is getting a TimeDiff result: utc - getCurrentTime tz - getCurrentTimeZone let td = timeOfDayToTime $ localTimeOfDay $ utcToLocalTime tz utc Now td is a TimeDiff representation of the number of seconds since midnight. It prints nicely, but I'm having a heck of a time figuring out how to truncate it to an Int. The floor function is only supported by the RealFrac class. Although TimeDiff has an instance of RealFrac and Fractional, it doesn't have an instance of RealFrac. I looked up the various to* and from* functions and have come up short. fromEnum yields an Int but it's the wrong value. I know I could use show and then use readS to get an Integer, or use formatTime (and reparse that), but that's a hack. I can convert it to a TimeOfDay which gives me hours, minutes, and seconds, but then I have to do arithmetic on it, and the seconds are of type Pico, which I can't call floor on either. I can convert it to a Rational via timeOfDayToDayFraction, but a TimeDiff is already a Rational those don't have floor. What am I missing? There has got to be an easy way to count seconds! Well, you could always (read . takeWhile (not . (=='.')) . show), but here's a better way: let x = toRational td in numerator x `div` denominator x This was just the first thing I could come up with. I bet there's a nicer way. - Phil Thanks, Lyle ___ 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] Turning all the Nothings into Just defaultValue using Data.Generics
I want to use Data.Generics to write a function to turn all the Nothings in
a data structure into Just defaultValue, as shown below. I get the
following error because the compiler doesn't know enough about Maybe a for
mkT to create the generic function that everywhere requires, I guess.
Test.hs:26:16:
Ambiguous type variable `a' in the constraints:
`Typeable a'
arising from a use of `mkT' at Senior/Test2.hs:26:16-30
`Default a'
arising from a use of `justDefault' at Senior/Test2.hs:26:20-30
Probable fix: add a type signature that fixes these type variable(s)
Here is the example. It all works except for test. Any suggestions how
to do this?
{-# LANGUAGE DeriveDataTypeable, FlexibleContexts, FlexibleInstances,
MultiParamTypeClasses, RankNTypes, TemplateHaskell, TypeSynonymInstances #-}
{-# OPTIONS_GHC -fallow-undecidable-instances #-}
module Test where
import Data.Generics
class Default a where
defaultValue :: a
instance Default Int where
defaultValue = 0
instance Default String where
defaultValue =
instance Default (Maybe a) where
defaultValue = Nothing
data A = A {b :: Int, c :: Maybe String} deriving (Show, Data, Typeable)
instance Default A where
defaultValue = A {b = defaultValue, c = defaultValue}
test =
everywhere (mkT justDefault) (defaultValue :: A)
where
justDefault Nothing = Just defaultValue
justDefault (Just x) = Just x
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
I had a quick look at Stuckey and Sulzmann, A Theory of Overloading and it looks to me like the semantics is given by evidence translation. So first you do evidence translation, and then give semantics to the translated program. So this looks like the two step approach I first mentioned. Or have I misunderstood what you're doing? What I meant hasn't been done is a one step semantics directly in terms of the source language. I guess I also want it to be compositional, which I think is where things break down. -- Lennart On Wed, Nov 12, 2008 at 2:26 PM, Martin Sulzmann [EMAIL PROTECTED] wrote: Lennart Augustsson wrote: You can't write a straightforward dynamic semantics (in, say, denotational style) for Haskell. The problem is that with type classes you need to know the types compute the values. You could use a two step approach: first make a static semantics that does type inference/checking and translates Haskell into a different form that has resolved all overloading. And, secondly, you can write a dynamic semantics for that language. But since the semantics has to have the type inference engine inside it, it's going to be a pain. It's possible that there's some more direct approach that represents types as some kind of runtime values, but nobody (to my knowledge) has done that. This has been done. For example, check out the type class semantics given in Thatte, Semantics of type classes revisited, LFP '94 Stuckey and Sulzmann, A Theory of Overloading, TOPLAS'05 Harrison: A Simple Semantics for Polymorphic Recursion. APLAS 2005 is also related I think. The ICFP'08 poster Unified Type Checking for Type Classes and Type Families , Tom Schrijvers and Martin Sulzmann suggests that a type-passing semantics can even be programmed by (mis)using type families. - Martin -- Lennart On Wed, Nov 12, 2008 at 12:39 PM, Luke Palmer [EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean [EMAIL PROTECTED] wrote: Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? The (well, a natural approach to a) formal proof would be to give a formal semantics for haskell. Haskell 98 does not seem that big to me (it's not teeny, but it's nothing like C++), yet we are continually embarrassed about not having any formal semantics. What are the challenges preventing its creation? Luke ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? (I was writing a blog post about the origins of the phrase 'referentially transparent' and it made me think about this) Answering this question, or actually even formalizing the statement you want to prove, is more or less equivalent to writing down a full denotational candidate semantics for Haskell in a compositional style, and proving that it is equivalent to the *actual* semantics of Haskell Nobody has done this. Well, there is no *actual* semantics anywhere around to which you one could prove equivalence. So, to be precise, the question you are interested in cannot even really be asked at the moment. Ciao, Janis. -- Dr. Janis Voigtlaender http://wwwtcs.inf.tu-dresden.de/~voigt/ mailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
See What is a purely functional language by Sabry. Not quite a formal proof about *Haskell*, but then we would first need a formal semantics of Haskell to be able to do that proof ;-) On 12 Nov 2008, at 10:11, Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter- examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? (I was writing a blog post about the origins of the phrase 'referentially transparent' and it made me think about this) Andrew -- - http://www.nobugs.org - ___ 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] Hackage web interface
On Wed, Nov 12, 2008 at 04:14:48PM +, Hugo Pacheco wrote: When previewing some package via the Hackage web interface, I get the following warning: Exposed modules use unallocated top-level names: A I assume that if you define some module A.B, it expects the top-level name A to be a module. Not a module, but one of a few names. See http://www.haskell.org/haskellwiki/Hierarchical_module_names ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On 12 Nov 2008, at 11:11, Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter- examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? (I was writing a blog post about the origins of the phrase 'referentially transparent' and it made me think about this) I think the informal proof goes along the lines of because that's what the spec says -- Haskell's operational semantics are not specified in the report, only IIRC a wooly description of having some sort of non-strict beta-reduction behavior. Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: reliable (bi)directional pipe to a process
[EMAIL PROTECTED] wrote: I'd like to point out a reliable, proven and simple way of interacting with another process, via unidirectional or bidirectional pipes. The method supports Unix sockets, pipes, and TCP sockets. I too have noticed insidious bugs in GHC run-time when communicating with another process via a pipe. I tried to use runInteractiveProcess; it worked -- up to file sizes of about 300Kb. Then GHC run-time seems to `loses synchronization' -- and corrupts IO buffers, receiving stuff that cannot have been possibly sent. This is because handle operations are asynchronous and the GHC scheduler seems to have race conditions. That behavior was totally unacceptable. I was writing a production code, and can't afford such errors. If there are bugs of this kind, we really need to get them fixed - I'm not aware of anything like this being reported. Please, if anyone can reproduce this, or even if you can't, submit a bug giving as many details as you can. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Searching for ADT patterns with elem and find
Thanks Neil, Great. I hadn't noticed isJust, and I'd forgotten any. Actually I was browsing Prelude just the other day and picked up zipWith f as bs as a replacement for map f $ zip as bs. Cheers, Paul -Original Message- From: Mitchell, Neil [mailto:[EMAIL PROTECTED] Sent: Wed 12/11/2008 10:23 To: Paul Keir; haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] Searching for ADT patterns with elem and find Hi Paul, maybe False (\x - True) (find isTypeB ts) This can be more neatly expressed as: isJust (find isTypeB ts) But your entire thing can be expressed as: containsTypeB ts = any isTypeB ts I recommend reading through the Prelude interface and the List interface, it has many useful functions that will help. Thanks Neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Keir Sent: 12 November 2008 10:09 am To: haskell-cafe@haskell.org Subject: [Haskell-cafe] Searching for ADT patterns with elem and find Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype B Double, must my containsTypeX function use a second isTypeX function as follows: isTypeB :: T - Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] - Bool containsTypeB ts = maybe False (\x - True) (find isTypeB ts) I understand that while something like find C ts will work, find (isTypeB _) ts will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual isTypeB functions now. Regards, Paul == Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html == ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Searching for ADT patterns with elem and find
somebody pointed out a few months back that list comprehensions do this nicely: containsTypeB ts = not $ null [x | (B x) - ts] no need for defining isTypeB. not quite sure how you would write findBs :: [T]-[T] succinctly; maybe findBs ts = [b | b@(B _) - ts] or findBs ts = [B x | (B x) - ts] both of them compile but the first is ugly and the second is inefficient (Tags a new T for every hit). Tom 2008/11/12 Paul Keir [EMAIL PROTECTED]: Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype B Double, must my containsTypeX function use a second isTypeX function as follows: isTypeB :: T - Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] - Bool containsTypeB ts = maybe False (\x - True) (find isTypeB ts) I understand that while something like find C ts will work, find (isTypeB _) ts will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual isTypeB functions now. Regards, Paul ___ 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] Searching for ADT patterns with elem and find
On Wed, Nov 12, 2008 at 10:20 AM, Derek Elkins [EMAIL PROTECTED] wrote: In addition to what others have said, I recommend using functions like isTypeB :: T - Maybe Double isTypeB (B d) = Just d isTypeB _ = Nothing You can recover the Bool version of isTypeB just by post-composing with isJust, but this version avoids needing partial functions and often is more what you want (i.e. it's a first-class pattern). Combining it with catMaybes is also a common pattern. Although if you are using Maybe as a monad, these two pieces of code are equivalent: test1 t1 t2 = do d1 - isTypeB t1 d2 - isTypeB t2 return (d1 + d2) test2 t1 t2 = do B d1 - return t1 B d2 - return t2 return (d1 + d2) This is because pattern-matching in do-notation implicitly calls fail when the pattern match fails. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Searching for ADT patterns with elem and find
Paul Keir wrote: Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype B Double, must my containsTypeX function use a second isTypeX function as follows: isTypeB :: T - Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] - Bool containsTypeB ts = maybe False (\x - True) (find isTypeB ts) Many other good posts have obviated the original question, but just to answer it directly. You can turn isTypeB into a lambda by using a case expression: isTypeB = \t - case t of B _ - True ; _ - False And from there you can just inline the definition in order to remove isTypeB. Pattern matching in function definitions is just sugar for the case expression version, so this transformation is just what the compiler would be doing anyways. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On a totally non-theory side, Haskell isn't referentially transparent. In particular, any code that calls unsafePerformIO or unsafeInterleaveIO is not necessarily RT. Given that getContents and interact use unsafeInterleaveIO, this includes most toy programs as well as almost every non-toy program; almost all use unsafePerformIO intentionally. That said, the situations in which these functions are RT are not that hard to meet, but they would muddy up any formal proof significantly. Personally, I'm happy with the hand-wavy proof that goes like this: 1) pure functions don't have side effects. 2) side-effect free functions can be duplicated or shared without affecting the results of the program that uses them (in the absence of considerations of resource limitation like running out of memory) 3) any function that only uses other pure functions is pure 4) all Haskell98 functions that don't use unsafe* are pure 5) therefore Haskell98 minus unsafe functions is referentially transparent. Note that I am including I/O actions as pure when observed as the GHC implementation of IO a ~~ World - (World, a); the function result that is the value of main is pure. It is only the observation of that function by the runtime that causes side effects. -- ryan On Wed, Nov 12, 2008 at 2:11 AM, Andrew Birkett [EMAIL PROTECTED] wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? (I was writing a blog post about the origins of the phrase 'referentially transparent' and it made me think about this) Andrew -- - http://www.nobugs.org - ___ 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] What *not* to use Haskell for
tux_rocker: 2008/11/11 Dave Tapley [EMAIL PROTECTED]: So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Let's say something controversial: I think that Haskell's type system gets in your way when you're writing one-shot scripts that don't need to conform to the highest correctness standards. Imagine typing a command at the shell prompt and getting the sort of abstract error message that Haskell compilers give every now and then, like: whyerror.lhs:36:25: Ambiguous type variable `a' in the constraint: `Arrow a' arising from use of `' at whyerror.lhs:36:25-27 Possible cause: the monomorphism restriction applied to the following: liftA2' :: forall b a1 b1 c. (a1 - b1 - c) - a b a1 - a b b1 - a b c (bound at whyerror.lhs:36:1) unsplit' :: forall a1 b c. (a1 - b - c) - a (a1, b) c (bound at whyerror.lhs:34:1) split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1) Probable fix: give these definition(s) an explicit type signature or use -fno-monomorphism-restriction You don't want to be bothered by such monstrosities (yes, they are, even though many of you may not see it because of years of conditioning) when you're just hacking up a simple script to make a catalog of your MP3 collection / check for patterns in log files / whatever. Why are you using Arrows in your one shot scripts? Do you use Arrows in your shell scripts? Seems like a strawman argument.. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
On Wed, 2008-11-12 at 10:50 -0800, Don Stewart wrote:
tux_rocker:
2008/11/11 Dave Tapley [EMAIL PROTECTED]:
So I should clarify I'm not a troll and do see the Haskell light. But
one thing I can never answer when preaching to others is what does
Haskell not do well?
Let's say something controversial: I think that Haskell's type system
gets in your way when you're writing one-shot scripts that don't need
to conform to the highest correctness standards. Imagine typing a
command at the shell prompt and getting the sort of abstract error
message that Haskell compilers give every now and then, like:
whyerror.lhs:36:25:
Ambiguous type variable `a' in the constraint:
`Arrow a' arising from use of `' at whyerror.lhs:36:25-27
Possible cause: the monomorphism restriction applied to the
following:
liftA2' :: forall b a1 b1 c. (a1 - b1 - c) - a b a1 - a b
b1 - a b c
(bound at whyerror.lhs:36:1)
unsplit' :: forall a1 b c. (a1 - b - c) - a (a1, b) c
(bound at whyerror.lhs:34:1)
split' :: forall b. a b (b, b) (bound at whyerror.lhs:33:1)
Probable fix: give these definition(s) an explicit type signature
or use -fno-monomorphism-restriction
You don't want to be bothered by such monstrosities (yes, they are,
even though many of you may not see it because of years of
conditioning) when you're just hacking up a simple script to make a
catalog of your MP3 collection / check for patterns in log files /
whatever.
Why are you using Arrows in your one shot scripts?
Because a generic operator like () is
a) More likely to exist, and
b) easier to remember
than a special case operator like --- actually, I don't think GHC does
come with a standard version of () type-specialized to functions,
only a version of (). Or if it does, I can't remember it.
Do you use Arrows in
your shell scripts?
I use pipelines. Frequently. I even type them up at the command line.
Beyond that, I was considering the pipeline
uses -l snippet_calculate\\b |
perl -lne 'chomp; print $_ unless qx{svn st | grep $_}'
(`uses' is a recursive grep-like shell function I have). The use of
perl immediately suggested that it could profitably be re-written in
Haskell (actually, in a similar FP language I've been designing --- not
relevant); my translation included a line something like
interactiveM $ filterM $ comp \ x - translation of qx{svn st |
grep $x}
So yeah, I use arrows in my shell scripts. Who doesn't?
(On the other hand, I'm actively designing an FP shell-like language...)
jcc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] abstract extensible types?
http://www.cs.nott.ac.uk/~wss/Publications/DataTypesALaCarte.pdf This lets you create sets of types to store in a container, with the static guarantee that only members of the set of types are included. The types can contain other elements of the set within them recursively. To extract value from the container, you can provide observation algebras that work on subsets of these values. It's a great solution to this problem and avoids the anything with Typeable issue that you get using Dynamic, which adds lots of run-time failure cases if something you didn't expect makes it into your data. -- ryan 2008/11/12 Alberto G. Corona [EMAIL PROTECTED]: Is there any abstract container that permits the addition of new types of data? I know how to simulate the extension of Algebraic datatypes, but this does not permit the addition of data with new types in the same container and recover them in a type-safe way. Did I reinvent the Weel? I found something, that permits this for any Typeable datatype. For example x=5 list= [put x, put hello] [t1,t2 ]= list x' = get t1 :: Int s = get t2 :: String print (x' +1) -- 2 print s-- hello x''= get t2 :: Int--get: casting from String to type Int The code: data Abstract= forall a. Typeable a = T !String a class FromToAbstract x where put :: x - Abstract get :: Abstract - x unsafeGet :: Abstract - x -- get(put x)== x instance Typeable x = FromToAbstract x where put x= T (typeString x) x get (Abstract type1 a)= if type2 == type1 then v else error (get: casting ++ from type ++type1++ to type ++type2) where v= unsafeCoerce a :: x type2= typeString v unsafeGet (Abstract type1 a)= unsafeCoerce a typeString !x= tyConString $ typeRepTyCon $ typeOf x instance Typeable T where typeOf _= mkTyConApp (mkTyCon Abstract) [] ___ 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] Proof that Haskell is RT
On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean [EMAIL PROTECTED] wrote: Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? The (well, a natural approach to a) formal proof would be to give a formal semantics for haskell. Haskell 98 does not seem that big to me (it's not teeny, but it's nothing like C++), yet we are continually embarrassed about not having any formal semantics. What are the challenges preventing its creation? Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
Hi all, On Wed, Nov 12, 2008 at 2:09 PM, Lennart Augustsson [EMAIL PROTECTED]wrote: You can't write a straightforward dynamic semantics (in, say, denotational style) for Haskell. The problem is that with type classes you need to know the types compute the values. ... It's possible that there's some more direct approach that represents types as some kind of runtime values, but nobody (to my knowledge) has done that. It seems to me that if you don't need your semantics to do the work of type-*checking* (i.e., you don't care if the rules assign some strange denotation to an ill-typed term), there is a natural approach to giving semantics to 98-style type classes. I'm figuring out the details as I type, though; if anybody sees anything that does not work, please do tell! Let type mean a non-overloaded type expression (i.e., not containing variables). I'll suppose that you already know the set of types in the program and the domain associated with each type. (This is usual in denotational treatments, right?) Let the domains be such that all sets of elements have a join (i.e., complete lattices). Define the domain of overloaded values to be the domain of functions from types to values of these types or bottom (when I say bottom in the following, it is this bottom, which is below the domain's bottom), i.e., the product of the liftings of the domains of all possible types. The interpretation of bottom is, this overloaded value doesn't have an instance at this type (e.g., [7,9] is bottom at type Bool). An *environment* is a function from symbols to overloaded values. The denotation of an expression is a function from environments to overloaded values; the denotation of a definition list is a function from environments to environments; the denotation of a whole program is the least fixed point of the definition list that makes up the program. Expressions are interpreted as follows (update :: Symbol - OverloadedValue - Environment - Environment is defined in the natural way): [[x]] = \env type. env x type [[T :: TYPE]] = \env type. if type instance of TYPE then [[T]] env type else bottom [[F X]] = Join_type2. \env type1. [[F]] env (type1 - type2) $ [[X]] env type2 [[\x. T]] = \env type. case type of (type1 - type2) - \val. [[T]] (update x (mono type1 val) env) type2 otherwise - bottom where mono ty val = \ty'. if ty == ty' then val else bottom [[let x=S in T]] = \env type. [[T]] (fix $ \env'. update x ([[S]] env') env) type Simple definitions are interpreted in the obvious way: [[x = T]] = \env sym. if sym == x then ([[T]] env) else (env sym) [[x :: Ty; x = T]] = [[x = T :: Ty]] Finally, instance declarations are interpreted in a special way. To interpret the declaration instance C Ty1 .. Tyn where ...; xi = Ti; ... we need to know the set of possible types for xi. (No type inference should be necessary -- the class declaration + the Ty1 .. Tyn from the instance declaration should give us all the necessary information, right?) Call this set Types. Then, [[xi = Ti]] = \env sym type. if sym == xi type in Types then [[T]] env type else env sym type That is, an instance declaration sets the value of a symbol at some types, and leaves the values at the other types alone. Some notes: * If T is a well-typed term and type is *not* a type instance of that term, then ([[T]] env type) is bottom. * In particular, [[T :: TYPE]] env type = [[T]] env type, when type is an instance of TYPE; otherwise, [[T :: TYPE]] env type = bottom. * Application is supposed to be strict in bottom: bottom x = bottom; f bottom = bottom. * In interpreting [[F X]], we take the join over all possible types of X (type2). If X is monomorphic, then ([[X]] env type2) is bottom for all types except the correct one, so the join gives the correct denotation. If X is polymorphic, but the type of F together with the type forced by the context of (F X) together determine what type of X must be used, then either ([[F]] env (type1 - type2)) or ([[X]] env type2) will be bottom for every type2 exept for the one we want to use; so the application ([[F]] ... $ [[X]] ...) will be bottom except for the correct type; so again, the join will give the correct denotation. (Caveat lector: I haven't proved this, I'm running on intuition :)) * In the interpretation of expressions like (show (read 5)), the join is non-degenerate: it consists of the join of 5, 5.0 etc. But since such expressions are rejected by the type-checker, we don't care. * Lets containing multiple definitions can be translated as in the Haskell report, if we add an interpretation for a case construct (I'm too lazy to try): http://www.haskell.org/onlinereport/exps.html#sect3.12 * In the interpretation of the lambda expression, we need to interpret the body of the expression separately for every type of the lambda expression; the function 'mono' converts the monomorphic parameter value into an OverloadedValue that is bottom everywhere except at the
Re: [Haskell-cafe] Proof that Haskell is RT
Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Since you are talking to the outside world any behaviour is acceptable. All the weird interactions between getContents and writing the same file from the same program could, in principle, happen if a different program wrote the file. The unsafePerformIO function can break RT, but I think everyone is aware of that. :) -- Lennart On Wed, Nov 12, 2008 at 6:47 PM, Ryan Ingram [EMAIL PROTECTED] wrote: On a totally non-theory side, Haskell isn't referentially transparent. In particular, any code that calls unsafePerformIO or unsafeInterleaveIO is not necessarily RT. Given that getContents and interact use unsafeInterleaveIO, this includes most toy programs as well as almost every non-toy program; almost all use unsafePerformIO intentionally. That said, the situations in which these functions are RT are not that hard to meet, but they would muddy up any formal proof significantly. Personally, I'm happy with the hand-wavy proof that goes like this: 1) pure functions don't have side effects. 2) side-effect free functions can be duplicated or shared without affecting the results of the program that uses them (in the absence of considerations of resource limitation like running out of memory) 3) any function that only uses other pure functions is pure 4) all Haskell98 functions that don't use unsafe* are pure 5) therefore Haskell98 minus unsafe functions is referentially transparent. Note that I am including I/O actions as pure when observed as the GHC implementation of IO a ~~ World - (World, a); the function result that is the value of main is pure. It is only the observation of that function by the runtime that causes side effects. -- ryan On Wed, Nov 12, 2008 at 2:11 AM, Andrew Birkett [EMAIL PROTECTED] wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? (I was writing a blog post about the origins of the phrase 'referentially transparent' and it made me think about this) Andrew -- - http://www.nobugs.org - ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: What *not* to use Haskell for
So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? The most obvious cases where Haskell does not do well, for me: - When you feed it Java code. Incidentally, the same holds when you feed it C code. - When you try to write a malloc library. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On 12 Nov 2008, at 14:47, Mitchell, Neil wrote: It's possible that there's some more direct approach that represents types as some kind of runtime values, but nobody (to my knowledge) has done that. It don't think its possible - I tried it and failed. Consider: show (f []) Where f has the semantics of id, but has either the return type [Int] or [Char] - you get different results. Without computing the types everywhere, I don't see how you can determine the precise type of []. Surely all this means is that part of the semantics of Haskell is the semantics of the type system -- isn't this expected? Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Searching for ADT patterns with elem and find
On Wed, 2008-11-12 at 10:09 +, Paul Keir wrote: Hi All, If I have an ADT, say data T = A String Integer | B Double | C deriving(Eq) and I want to find if a list (ts) of type T contains an element of subtype B Double, must my containsTypeX function use a second isTypeX function as follows: isTypeB :: T - Bool isTypeB (B _) = True isTypeB _ = False containsTypeB :: [T] - Bool containsTypeB ts = maybe False (\x - True) (find isTypeB ts) I understand that while something like find C ts will work, find (isTypeB _) ts will not, but is there no such thing as a pattern combinator(?), or lambda that could help with this situation. I find I have many individual isTypeB functions now. In addition to what others have said, I recommend using functions like isTypeB :: T - Maybe Double isTypeB (B d) = Just d isTypeB _ = Nothing You can recover the Bool version of isTypeB just by post-composing with isJust, but this version avoids needing partial functions and often is more what you want (i.e. it's a first-class pattern). Combining it with catMaybes is also a common pattern. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On Wed, Nov 12, 2008 at 12:35 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Since you are talking to the outside world any behaviour is acceptable. All the weird interactions between getContents and writing the same file from the same program could, in principle, happen if a different program wrote the file. Yes, I was thinking about this on my way to work and thought that I may have spoken too soon; I couldn't come up with a way for unsafeInterleaveIO to break referential transparency (although I couldn't prove to myself that it couldn't, either). Your argument seems good to me, though. -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
Dave Tapley wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Anything with hard performance requirements, and/or that needs to run on tiny computational resources (CPU speed, RAM size, etc.) I'd say device drivers too, except that the House guys apparently managed to do this... I'd really love to tell everybody that Haskell is *the* language of algorithms - except that it tends to not be very performant. Unfortunately, with the current state of the art, high-performance computer programs still require lots of low-level details to be explicitly managed. Hopefully one day this will cease to be the case. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interactive
On Wed, 12 Nov 2008, Andrew Coppin wrote: I have a small question... Given that interactivity is Really Hard to do in Haskell, and that mutable state is to be strongly avoided, how come Frag exists? (I.e., how did they successfully solve these problems?) Because the givens are bull :-) That said, Frag doesn't throw too many different types of entities around and its performance isn't great when you look at the game simulation (largely because it was an experiment in using FRP). -- [EMAIL PROTECTED] A problem that's all in your head is still a problem. Brain damage is but one form of mind damage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interactive
Here are the links that hold the information you desire: http://www.haskell.org/haskellwiki/Frag http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf In short: FRP http://www.haskell.org/frp/ On Wed, Nov 12, 2008 at 1:52 PM, Andrew Coppin [EMAIL PROTECTED]wrote: I have a small question... Given that interactivity is Really Hard to do in Haskell, and that mutable state is to be strongly avoided, how come Frag exists? (I.e., how did they successfully solve these problems?) ___ 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] Proof that Haskell is RT
You can't write a straightforward dynamic semantics (in, say, denotational style) for Haskell. The problem is that with type classes you need to know the types compute the values. You could use a two step approach: first make a static semantics that does type inference/checking and translates Haskell into a different form that has resolved all overloading. And, secondly, you can write a dynamic semantics for that language. But since the semantics has to have the type inference engine inside it, it's going to be a pain. It's possible that there's some more direct approach that represents types as some kind of runtime values, but nobody (to my knowledge) has done that. -- Lennart On Wed, Nov 12, 2008 at 12:39 PM, Luke Palmer [EMAIL PROTECTED] wrote: On Wed, Nov 12, 2008 at 3:21 AM, Jules Bean [EMAIL PROTECTED] wrote: Andrew Birkett wrote: Hi, Is a formal proof that the Haskell language is referentially transparent? Many people state haskell is RT without backing up that claim. I know that, in practice, I can't write any counter-examples but that's a bit handy-wavy. Is there a formal proof that, for all possible haskell programs, we can replace coreferent expressions without changing the meaning of a program? The (well, a natural approach to a) formal proof would be to give a formal semantics for haskell. Haskell 98 does not seem that big to me (it's not teeny, but it's nothing like C++), yet we are continually embarrassed about not having any formal semantics. What are the challenges preventing its creation? Luke ___ 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] What *not* to use Haskell for
On Tue, Nov 11, 2008 at 5:18 AM, Jules Bean [EMAIL PROTECTED] wrote: Dave Tapley wrote: Hi everyone So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? GHC's scheduler lacks any hard timeliness guarantees. Thus it's quite hard to use haskell in realtime or even soft-realtime environments. Actually, Haskell is an excellent language for hard real-time applications. At Eaton we're using it for automotive powertrain control. Of course, the RTS is not running in the loop. Instead, we write in a DSL, which generates C code for our vehicle ECU. Thanks to this great language, we traded 100K lines of Simulink for 3K lines of Haskell. Our current program is planned to hit the production lines in a few months. With similar methods, Haskell is also a great language for ASIC and FPGA design. -Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
Edsko de Vries wrote: See What is a purely functional language by Sabry. Not quite a formal proof about *Haskell*, but then we would first need a formal semantics of Haskell to be able to do that proof ;-) Thanks for the reference, and also to everyone who replied - all very useful and interesting. For what it's worth, the blog posts I was writing are here: http://www.nobugs.org/blog/archives/2008/11/12/why-do-they-call-it-referentially-transparent/ http://www.nobugs.org/blog/archives/2008/11/12/why-do-they-call-it-referentially-transparent-ii/ Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What *not* to use Haskell for
andrewcoppin: So I should clarify I'm not a troll and do see the Haskell light. But one thing I can never answer when preaching to others is what does Haskell not do well? Usually I'll avoid then question and explain that it is a 'complete' language and we do have more than enough libraries to make it useful and productive. But I'd be keen to know if people have any anecdotes, ideally ones which can subsequently be twisted into an argument for Haskell ;) Anything with hard performance requirements, and/or that needs to run on tiny computational resources (CPU speed, RAM size, etc.) I'd say device drivers too, except that the House guys apparently managed to do this... I'd really love to tell everybody that Haskell is *the* language of algorithms - except that it tends to not be very performant. Depends on who's writing the Haskell in my experience. GHC's a perfectly capable compiler if you feed it the proper diet. -- Don (Board member of the Don't think linked lists are the same as UArr Double movement) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] abstract extensible types?
Is there any abstract container that permits the addition of new types of data? I know how to simulate the extension of Algebraic datatypes, but this does not permit the addition of data with new types in the same container and recover them in a type-safe way. Did I reinvent the Weel? I found something, that permits this for any Typeable datatype. For example x=5 list= [put x, put hello] [t1,t2 ]= list x' = get t1 :: Int s = get t2 :: String print (x' +1) -- 2 print s-- hello x''= get t2 :: Int--get: casting from String to type Int The code: data Abstract= forall a. Typeable a = T !String a class FromToAbstract x where put :: x - Abstract get :: Abstract - x unsafeGet :: Abstract - x -- get(put x)== x instance Typeable x = FromToAbstract x where put x= T (typeString x) x get (Abstract type1 a)= if type2 == type1 then v else error (get: casting ++ from type ++type1++ to type ++type2) where v= unsafeCoerce a :: x type2= typeString v unsafeGet (Abstract type1 a)= unsafeCoerce a typeString !x= tyConString $ typeRepTyCon $ typeOf x instance Typeable T where typeOf _= mkTyConApp (mkTyCon Abstract) [] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Turning all the Nothings into Just defaultValue using Data.Generics
Hello,
I can *almost* do it like this:
test = (id `ext1T` justDefault) (defaultValue :: A)
justDefault :: forall f. (Default f, Data f) = Maybe f - Maybe f
justDefault Nothing = defaultValue
justDefault (Just x) = Just x
Except it fails with:
Could not deduce (Default d1) from the context (Data d1)
arising from a use of `justDefault' at /tmp/type.hs:31:19-29
Possible fix:
add (Default d1) to the context of
the polymorphic type `forall d1. (Data d1) = t d1 - t d1'
In the second argument of `ext1T', namely `justDefault'
In the expression: (id `ext1T` justDefault) (defaultValue :: A)
In the definition of `test':
test = (id `ext1T` justDefault) (defaultValue :: A)
If we could figure out a way to write justDefault so that it did not
require the Default class, then things would work. It would be nice if
there was a way to do one thing if a value is an instance of Default
and something else if it is not. Here is some psuedo-Haskell code
showing what I mean:
justDefault :: forall f. (Data f) = Maybe f - Maybe f
justDefault Nothing
| (Default f) = defaultValue
| _ = Nothing
justDefault (Just x) = Just x
Any ideas?
j.
At Wed, 12 Nov 2008 09:46:05 -0800,
David Fox wrote:
[1 multipart/alternative (7bit)]
[1.1 text/plain; ISO-8859-1 (7bit)]
I want to use Data.Generics to write a function to turn all the Nothings in
a data structure into Just defaultValue, as shown below. I get the
following error because the compiler doesn't know enough about Maybe a for
mkT to create the generic function that everywhere requires, I guess.
Test.hs:26:16:
Ambiguous type variable `a' in the constraints:
`Typeable a'
arising from a use of `mkT' at Senior/Test2.hs:26:16-30
`Default a'
arising from a use of `justDefault' at Senior/Test2.hs:26:20-30
Probable fix: add a type signature that fixes these type variable(s)
Here is the example. It all works except for test. Any suggestions how
to do this?
{-# LANGUAGE DeriveDataTypeable, FlexibleContexts, FlexibleInstances,
MultiParamTypeClasses, RankNTypes, TemplateHaskell, TypeSynonymInstances #-}
{-# OPTIONS_GHC -fallow-undecidable-instances #-}
module Test where
import Data.Generics
class Default a where
defaultValue :: a
instance Default Int where
defaultValue = 0
instance Default String where
defaultValue =
instance Default (Maybe a) where
defaultValue = Nothing
data A = A {b :: Int, c :: Maybe String} deriving (Show, Data, Typeable)
instance Default A where
defaultValue = A {b = defaultValue, c = defaultValue}
test =
everywhere (mkT justDefault) (defaultValue :: A)
where
justDefault Nothing = Just defaultValue
justDefault (Just x) = Just x
[1.2 text/html; ISO-8859-1 (7bit)]
[2 text/plain; us-ascii (7bit)]
___
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: What *not* to use Haskell for
what does Haskell not do well? - When you feed it Java code. Incidentally, the same holds when you feed it C code. I've heard that Haskell's new (developed in this year's GSoC) Language.C libraries were able to parse millions of lines of C code from the Linux kernel, including many gcc extensions, without a single error. That doesn't sound too shabby to me. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Really? It seems easy to create things with it which when passed to ostensibly pure functions yield different results depending on their evaluation order: module Main where import System.IO.Unsafe import Data.IORef main = do w1 - weirdTuple print w1 w2 - weirdTuple print $ swap w2 swap (x, y) = (y, x) weirdTuple :: IO (Int, Int) weirdTuple = do it - newIORef 1 x - unsafeInterleaveIO $ readIORef it y - unsafeInterleaveIO $ do writeIORef it 2 return 1 return (x, y) [EMAIL PROTECTED]:~$ ./Unsafe (1,1) (1,2) So show isn't acting in a referentially transparent way: If the second part of the tuple were evaluated before the first part it would give a different answer (as swapping demonstrates). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] TimeDiff to Int?
Thanks Philip and Roger, I think I'll use... floor $ toRational td ...although I could have sworn that didn't work last night. I don't see that TimeDiff has an instance of RealFrac, where floor is defined, though it does have a instances of Real and Fractional. Yes, the numeric classes are a bit hard to follow. Especially confusing is the conversions. I'm thinking of making a multiparameter Coercible class, with a coerce function, to help address that. - Lyle On Wed, Nov 12, 2008 at 9:43 AM, Philip Weaver [EMAIL PROTECTED]wrote: 2008/11/12 Lyle Kopnicky [EMAIL PROTECTED] Hi folks, I had some code using the oldtime package, and want to convert it to use the time package. One of the things I need to do is calculate the number of seconds since midnight. The easy part is getting a TimeDiff result: utc - getCurrentTime tz - getCurrentTimeZone let td = timeOfDayToTime $ localTimeOfDay $ utcToLocalTime tz utc Now td is a TimeDiff representation of the number of seconds since midnight. It prints nicely, but I'm having a heck of a time figuring out how to truncate it to an Int. The floor function is only supported by the RealFrac class. Although TimeDiff has an instance of RealFrac and Fractional, it doesn't have an instance of RealFrac. I looked up the various to* and from* functions and have come up short. fromEnum yields an Int but it's the wrong value. I know I could use show and then use readS to get an Integer, or use formatTime (and reparse that), but that's a hack. I can convert it to a TimeOfDay which gives me hours, minutes, and seconds, but then I have to do arithmetic on it, and the seconds are of type Pico, which I can't call floor on either. I can convert it to a Rational via timeOfDayToDayFraction, but a TimeDiff is already a Rational those don't have floor. What am I missing? There has got to be an easy way to count seconds! Well, you could always (read . takeWhile (not . (=='.')) . show), but here's a better way: let x = toRational td in numerator x `div` denominator x This was just the first thing I could come up with. I bet there's a nicer way. - Phil Thanks, Lyle ___ 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] Interactive
I have a small question... Given that interactivity is Really Hard to do in Haskell, and that mutable state is to be strongly avoided, how come Frag exists? (I.e., how did they successfully solve these problems?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.10, strange behaviour when profiling?
Compiled with ghc-6.10.1.20081112 it runs approximately as it did with ghc-6.8.3 so the problem seems to be fixed. Thank you for your help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On Wed, 2008-11-12 at 22:16 +, David MacIver wrote: On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Really? It seems easy to create things with it which when passed to ostensibly pure functions yield different results depending on their evaluation order: module Main where import System.IO.Unsafe import Data.IORef main = do w1 - weirdTuple print w1 w2 - weirdTuple print $ swap w2 swap (x, y) = (y, x) weirdTuple :: IO (Int, Int) weirdTuple = do it - newIORef 1 x - unsafeInterleaveIO $ readIORef it y - unsafeInterleaveIO $ do writeIORef it 2 return 1 return (x, y) [EMAIL PROTECTED]:~$ ./Unsafe (1,1) (1,2) So show isn't acting in a referentially transparent way: If the second part of the tuple were evaluated before the first part it would give a different answer (as swapping demonstrates). It seems that this argument depends on being able to find a case where w1 and swap w1 actually behave differently. weirdTuple is non-deterministic, but that's fine, since it's in the IO monad. And w1 and w2 are simply two (distinct!) lambda-bound variables; there is no requirement that two different lambda-bound variables behave in the same fashion, regardless of how values may be expected to be supplied for them at run time (what values the functions in question may be expected to be applied to) unless the function(s) they are formal parameters of are (both) applied to the same expression. (=) certainly does not count as `application' for present purposes. Even if it is insisted (why? I don't think GHC actually guarantees to produce the above result when main is executed) that main must always yield the above result, it does not follow that unsafePerformIO is non-RT; it is still only non-causal. But referential transparency doesn't require that the result of an IO action must depend only on events that transpire by the time it finishes running; it places, in fact, no requirement on the run-time behavior of any IO action at all. It requires only that equal expressions be substitutable for equals; and, again, w1 and w2 being the result of calling a single IO action with no dependence on the outside world does not require them to be equal, under any system of semantics. So, no violation of RT. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
david.maciver: On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Really? It seems easy to create things with it which when passed to ostensibly pure functions yield different results depending on their evaluation order: module Main where import System.IO.Unsafe import Data.IORef main = do w1 - weirdTuple print w1 w2 - weirdTuple print $ swap w2 swap (x, y) = (y, x) weirdTuple :: IO (Int, Int) weirdTuple = do it - newIORef 1 x - unsafeInterleaveIO $ readIORef it y - unsafeInterleaveIO $ do writeIORef it 2 return 1 return (x, y) [EMAIL PROTECTED]:~$ ./Unsafe (1,1) (1,2) So show isn't acting in a referentially transparent way: If the second part of the tuple were evaluated before the first part it would give a different answer (as swapping demonstrates). Mmmm? No. Where's the pure function that's now producing different results? I only see IO actions at play, which are operating on the state of the world. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On Wed, Nov 12, 2008 at 10:46 PM, Don Stewart [EMAIL PROTECTED] wrote: david.maciver: On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Really? It seems easy to create things with it which when passed to ostensibly pure functions yield different results depending on their evaluation order: module Main where import System.IO.Unsafe import Data.IORef main = do w1 - weirdTuple print w1 w2 - weirdTuple print $ swap w2 swap (x, y) = (y, x) weirdTuple :: IO (Int, Int) weirdTuple = do it - newIORef 1 x - unsafeInterleaveIO $ readIORef it y - unsafeInterleaveIO $ do writeIORef it 2 return 1 return (x, y) [EMAIL PROTECTED]:~$ ./Unsafe (1,1) (1,2) So show isn't acting in a referentially transparent way: If the second part of the tuple were evaluated before the first part it would give a different answer (as swapping demonstrates). Mmmm? No. Where's the pure function that's now producing different results? I only see IO actions at play, which are operating on the state of the world. I suppose so. The point is that you have a pure function (show) and the results of evaluating it totally depend on its evaluation order. But you're still in the IO monad at this point so I suppose it technically doesn't count because it's only observable as the result of IO. It's pretty suspect behaviour, but not actually a failure of referential transparency. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On Wed, 2008-11-12 at 23:02 +, David MacIver wrote: On Wed, Nov 12, 2008 at 10:46 PM, Don Stewart [EMAIL PROTECTED] wrote: david.maciver: On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Really? It seems easy to create things with it which when passed to ostensibly pure functions yield different results depending on their evaluation order: module Main where import System.IO.Unsafe import Data.IORef main = do w1 - weirdTuple print w1 w2 - weirdTuple print $ swap w2 swap (x, y) = (y, x) weirdTuple :: IO (Int, Int) weirdTuple = do it - newIORef 1 x - unsafeInterleaveIO $ readIORef it y - unsafeInterleaveIO $ do writeIORef it 2 return 1 return (x, y) [EMAIL PROTECTED]:~$ ./Unsafe (1,1) (1,2) So show isn't acting in a referentially transparent way: If the second part of the tuple were evaluated before the first part it would give a different answer (as swapping demonstrates). Mmmm? No. Where's the pure function that's now producing different results? I only see IO actions at play, which are operating on the state of the world. I suppose so. The point is that you have a pure function (show) and the results of evaluating it totally depend on its evaluation order. Sure. But only because the argument to it depends on its evaluation order, as well. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On Wed, Nov 12, 2008 at 11:05 PM, Jonathan Cast [EMAIL PROTECTED] wrote: On Wed, 2008-11-12 at 23:02 +, David MacIver wrote: On Wed, Nov 12, 2008 at 10:46 PM, Don Stewart [EMAIL PROTECTED] wrote: david.maciver: On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Really? It seems easy to create things with it which when passed to ostensibly pure functions yield different results depending on their evaluation order: module Main where import System.IO.Unsafe import Data.IORef main = do w1 - weirdTuple print w1 w2 - weirdTuple print $ swap w2 swap (x, y) = (y, x) weirdTuple :: IO (Int, Int) weirdTuple = do it - newIORef 1 x - unsafeInterleaveIO $ readIORef it y - unsafeInterleaveIO $ do writeIORef it 2 return 1 return (x, y) [EMAIL PROTECTED]:~$ ./Unsafe (1,1) (1,2) So show isn't acting in a referentially transparent way: If the second part of the tuple were evaluated before the first part it would give a different answer (as swapping demonstrates). Mmmm? No. Where's the pure function that's now producing different results? I only see IO actions at play, which are operating on the state of the world. I suppose so. The point is that you have a pure function (show) and the results of evaluating it totally depend on its evaluation order. Sure. But only because the argument to it depends on its evaluation order, as well. That's not really better. :-) To put it a different way, in the absence of unsafeInterleaveIO the IO monad has the property that if f and g are observably equal up to termination then x = f and x = g are equivalent in the IO monad (actually this may not be true due to exception handling. Our three main weapons...). In the presence of unsafeInterleaveIO this property is lost even though referential transparency is retained. Anyway, I'll shut up now. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: hpapi 0.1 release
I am pleased to announce the first release of hpapi, Performance API (PAPI) bindings for Haskell. The release is on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hpapi The source repository is at: http://code.haskell.org/hpapi/ Please send bug reports to adamsmd [AT] cs.indiana.edu What is it == This is a simple set of bindings for the Performance API (PAPI). PAPI provides access to various CPU counters such as cache-miss, instruction and pipeline stall counts. The easiest way to use this library is the withCounts function: withCounts :: [EventCode] - IO a - IO (a, [Integer]) Given a list of events to count and an IO operation it will run the operation and return the resulting counts. So you could do something like: main = do [l1,tlb,fp] - withCounters [papi_l1_dcm, papi_tlb_dm, papi_fp_ins] ioOperationToMeasure printLn (l1, tlb, fp) To use it one will of course need the PAPI C library and any necessary kernel modifications installed. Status == The High Level interface (which will be sufficient for most people's needs) should be usable, but the low level interface is still alpha quality. That is to say, it is ready for people to start banging on it, but it is largely untested and the modules/interfaces may be reorganized based on user feedback. All of PAPI is supported with the exception of the following advanced features: - Multiplexing - Threads - Locks - Overflow - Statistical Profiling Future Directions = Future directions will be determined largely by user feedback. Principal areas that I am looking for feedback on are: - documentation - module organization - the handling of PAPI errors (currently it throws an IO error) - the design of the Haskell interface build on top of the C level PAPI_get_opt and PAPI_set_opt - what advanced features of PAPI to build bindings for next Comparison with GHC's built-in PAPI === GHC supports a built-in version of PAPI (see http://hackage.haskell.org/trac/ghc/wiki/PAPI). This system is different in a few ways. First, hpapi allows you to measure specific parts of a program while GHCI's PAPI only does whole program measurement Second, since hpapi is a library you can have fine grained and sophisticated control over how things are measured. On the other hand GHC's PAPI as part of the RTS gives you less control, but on the plus side doesn't require any modification to the program. Finally, GHC's PAPI splits apart the counts that come from the garbage collector from those that come from the mutator, while hpapi combines them. This is a limitation of hpapi we hope to correct some time in the future. It remains to be seen whether it would be worth while to unify these two systems. Bug reports as well as suggestions, feedback or contributions to the API or the documentation most welcome. Michael D. Adams ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On Wed, 2008-11-12 at 23:18 +, David MacIver wrote: On Wed, Nov 12, 2008 at 11:05 PM, Jonathan Cast [EMAIL PROTECTED] wrote: On Wed, 2008-11-12 at 23:02 +, David MacIver wrote: On Wed, Nov 12, 2008 at 10:46 PM, Don Stewart [EMAIL PROTECTED] wrote: david.maciver: On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Really? It seems easy to create things with it which when passed to ostensibly pure functions yield different results depending on their evaluation order: module Main where import System.IO.Unsafe import Data.IORef main = do w1 - weirdTuple print w1 w2 - weirdTuple print $ swap w2 swap (x, y) = (y, x) weirdTuple :: IO (Int, Int) weirdTuple = do it - newIORef 1 x - unsafeInterleaveIO $ readIORef it y - unsafeInterleaveIO $ do writeIORef it 2 return 1 return (x, y) [EMAIL PROTECTED]:~$ ./Unsafe (1,1) (1,2) So show isn't acting in a referentially transparent way: If the second part of the tuple were evaluated before the first part it would give a different answer (as swapping demonstrates). Mmmm? No. Where's the pure function that's now producing different results? I only see IO actions at play, which are operating on the state of the world. I suppose so. The point is that you have a pure function (show) and the results of evaluating it totally depend on its evaluation order. Sure. But only because the argument to it depends on its evaluation order, as well. That's not really better. :-) I never said it was. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On Wed, 2008-11-12 at 23:02 +, David MacIver wrote: On Wed, Nov 12, 2008 at 10:46 PM, Don Stewart [EMAIL PROTECTED] wrote: david.maciver: On Wed, Nov 12, 2008 at 8:35 PM, Lennart Augustsson [EMAIL PROTECTED] wrote: Actually, unsafeInterleaveIO is perfectly fine from a RT point of view. Really? It seems easy to create things with it which when passed to ostensibly pure functions yield different results depending on their evaluation order: module Main where import System.IO.Unsafe import Data.IORef main = do w1 - weirdTuple print w1 w2 - weirdTuple print $ swap w2 swap (x, y) = (y, x) weirdTuple :: IO (Int, Int) weirdTuple = do it - newIORef 1 x - unsafeInterleaveIO $ readIORef it y - unsafeInterleaveIO $ do writeIORef it 2 return 1 return (x, y) [EMAIL PROTECTED]:~$ ./Unsafe (1,1) (1,2) So show isn't acting in a referentially transparent way: If the second part of the tuple were evaluated before the first part it would give a different answer (as swapping demonstrates). Mmmm? No. Where's the pure function that's now producing different results? I only see IO actions at play, which are operating on the state of the world. I suppose so. The point is that you have a pure function (show) and the results of evaluating it totally depend on its evaluation order. But you're still in the IO monad at this point so I suppose it technically doesn't count because it's only observable as the result of IO. It's pretty suspect behaviour, but not actually a failure of referential transparency. Indeed. There's a difference between purity and referential transparency. A lack of purity is when behaviour, as in semantics, depends on evaluation order (modulo bottom of course). Referential transparency is being able to substitute equals for equals. These notions are related but independent. Examples of failures of referential transparency that aren't failures of purity are easy to find. A simple one would be some kind of introspection feature, such as various forms of quotation, being able to ask for the name of a variable, being able to serialize functions. So purity doesn't imply referential transparency. Failures of purity that aren't failures of referential transparency are a bit trickier since without purity (i.e. evaluation order independence) what constitutes a valid substitution may vary. Still, as an easy start, a language with no binding forms is trivially referentially transparent regardless of how impure it may be. If you use a call-by-name evaluation order, the full beta rule holds and evaluation proceeds by substituting equals for equals and therefore such a language is also referentially transparent. So referential transparency doesn't imply purity. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On Wednesday 12 November 2008 6:18:38 pm David MacIver wrote: To put it a different way, in the absence of unsafeInterleaveIO the IO monad has the property that if f and g are observably equal up to termination then x = f and x = g are equivalent in the IO monad (actually this may not be true due to exception handling. Our three main weapons...). In the presence of unsafeInterleaveIO this property is lost even though referential transparency is retained. I'm not sure what exactly you mean by this, but, for instance: randomIO = (print :: Int - IO ()) obviously isn't going to give the same results as: randomIO = (print :: Int - IO ()) every time. Your weirdTuple is semantically similar, in that it selects between returning (1,1) and (2,1), but instead of being random, it operationally selects depending on how you subsequently evaluate the value. That may not seem like the same thing, because you know what's going on, but formally, I imagine you can treat it all as a black box where either this time it gave (2,1) or this time it gave (1,1), and what you see is always consistent. The fact that it sort of uses an oracle to see what will happen in its future is just The Power of IO (it does have a sort of spooky action feel to it). :) -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
On Wed, 2008-11-12 at 18:47 -0500, Dan Doel wrote: On Wednesday 12 November 2008 6:18:38 pm David MacIver wrote: To put it a different way, in the absence of unsafeInterleaveIO the IO monad has the property that if f and g are observably equal up to termination then x = f and x = g are equivalent in the IO monad (actually this may not be true due to exception handling. Our three main weapons...). In the presence of unsafeInterleaveIO this property is lost even though referential transparency is retained. I'm not sure what exactly you mean by this, but, for instance: randomIO = (print :: Int - IO ()) obviously isn't going to give the same results as: randomIO = (print :: Int - IO ()) every time. Your weirdTuple is semantically similar, in that it selects between returning (1,1) and (2,1), but instead of being random, it operationally selects depending on how you subsequently evaluate the value. I think the point is that randomIO is non-deterministic (technically, pseudo-random) but causal --- the result is completely determined by events that precede its completion. unsafeInterleaveIO, by contrast, is arguably (sometimes) deterministic --- but is, regardless, definitely not causal. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
But how can you tell something being causal or not? Assuming that all IO operations return random result, of course. :) From a practical point of view unsafeInterleaveIO can give suspect results. But theoretically you can't fault it until you have given a semantics for the IO monad operations so you have something to compare it against. -- Lennart On Thu, Nov 13, 2008 at 12:05 AM, Jonathan Cast [EMAIL PROTECTED] wrote: On Wed, 2008-11-12 at 18:47 -0500, Dan Doel wrote: On Wednesday 12 November 2008 6:18:38 pm David MacIver wrote: To put it a different way, in the absence of unsafeInterleaveIO the IO monad has the property that if f and g are observably equal up to termination then x = f and x = g are equivalent in the IO monad (actually this may not be true due to exception handling. Our three main weapons...). In the presence of unsafeInterleaveIO this property is lost even though referential transparency is retained. I'm not sure what exactly you mean by this, but, for instance: randomIO = (print :: Int - IO ()) obviously isn't going to give the same results as: randomIO = (print :: Int - IO ()) every time. Your weirdTuple is semantically similar, in that it selects between returning (1,1) and (2,1), but instead of being random, it operationally selects depending on how you subsequently evaluate the value. I think the point is that randomIO is non-deterministic (technically, pseudo-random) but causal --- the result is completely determined by events that precede its completion. unsafeInterleaveIO, by contrast, is arguably (sometimes) deterministic --- but is, regardless, definitely not causal. jcc ___ 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] HOpenGL shading problem
Hi,
last few days I spent making remake of glxgears. Nothing
fancy, I just wanted easily configurable gears. The current
performance is only about 70% of glxgears.
But I have a problem with shading. Whatever I have been trying,
I still don't understand how the shading can be activated. I have
light, I have color, but not even Flat shading.
Please can you give me a hand?
Thanks,
Martin
PS: I didn't find any attachment size policy for this list, so I hope
that the attachment is small enough.
-
--
-- Copyright (c) 2008 Martin 'Trin' Kudlvasr
-- All rights reserved.
--
-- Redistribution and use in sourse and binary forms are permitted
-- provided that the above copyright notice and this paragraph are
-- duplicated in all such forms and that any documentation,
-- advertising materials, and other materials related to such
-- distribution and use acknowledge that the software was developed
-- by Martin Kudlvasr. The name of Martin Kudlvasr
-- may not be used to endorse or promote products derived from this
-- software without specific prior written permission.
-- THIS SOFTWARE IS PROVIDED 'AS IS' AND WITHOUT ANY EXPRESS OR
-- IMPLIED WARRANTIES, INCLUDING LIMITATION, THE IMPLIED
-- WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
--
---
-
--
-- Author -
-- Martin 'Trin' Kudlvasr
-- www.trinpad.eu
-- November, 2008
module Gear where
import Graphics.Rendering.OpenGL
import Data.List
data ToothDim = ToothDim { top :: GLfloat, -- width at the top of a tooth
bottom :: GLfloat, -- width at the base of a tooth
height :: GLfloat } -- height of the tooth
data Gear = Gear { bottomRadius, -- from center to tooth bottom corner
topRadius, -- from center to tooth top corner
bottomAngle, -- angle that tooth bottom line takes
topAngle, -- angle that tooth top line takes
betweenAngle, -- angle between top and bottom tooth line
innerRadius, -- inner circle of gear
thickness :: GLfloat, -- z axis thickness
gColor :: Color4 GLfloat
}
-- angles of gear contour points
angles gear = 0 : takeWhile (2*pi) [ sum $ take i as | i - [1..] ] ++ [0]
where
as = cycle $ map (\f - f gear) [ bottomAngle, betweenAngle, topAngle, betweenAngle ]
-- angle of 1 phase
toothAngle gear = sum $ map (\f - f gear) [bottomAngle, betweenAngle, topAngle, betweenAngle]
-- radius depends on teeth amount and dimensions. This is error with which radius is calculated
_MAX_ERROR = 0.001
calculateGearRadius toothDim teethCount =
calculateGearRadius' toothDim teethCount 1000 0.5
calculateGearRadius' toothDim targetTeeth tmpRadius factor =
case countTeeth top bottom newRadius of
tmpTeeth
| tmpTeeth targetTeeth + _MAX_ERROR - calculateGearRadius' toothDim targetTeeth newRadius factor
| tmpTeeth targetTeeth - calculateGearRadius' toothDim targetTeeth tmpRadius (factor/2)
| otherwise - newRadius
where
ToothDim top bottom height = toothDim
newRadius = tmpRadius*(1-factor)
countTeeth top bottom radius =
pi / ( asin (top / (2*radius)) + asin(bottom / (2*radius) ) )
newTeethCountGear toothDim teethCount innerR thickness c =
Gear bottomR topR bottomA topA betweenA innerR thickness c
where
bottomR = calculateGearRadius toothDim teethCount
topR= sqrt ( (bottomR*bottomR) - (bottom*bottom/4) ) + height
ToothDim top bottom height = toothDim
bottomA = 2 * asin (top / (2*bottomR))
topA= 2 * asin (top / (2*(bottomR+height)))
totalA = 2 * pi / teethCount
betweenA= (totalA - topA - bottomA) / 2
newGear = newTeethCountGear
newMinimumRadiusGear toothDim minRadius innerR thickness c =
newGear toothDim (fromIntegral teethCount + 1) innerR thickness c
where
ToothDim top bottom height = toothDim
toothA = 2 * ( asin (top / (2*minRadius)) + asin (bottom / (2*minRadius)) )
(teethCount, _) = properFraction ( 2 * pi / toothA )
gearContourPoints gear =
zipWith3 zipF [0,1..] inCircle outCircle
where
zipF i inP outP | i `mod` 4 == 0 = inP
| i `mod` 4 == 1 = inP
| otherwise = outP
inCircle = angleCirclePoints as $ bottomRadius gear
outCircle = angleCirclePoints as $ topRadiusgear
as = angles gear
gearFacePoints gear =
concat $ zipWith (\x y - [x,y]) contourPs innerPs
where
contourPs = gearContourPoints gear
innerPs = angleCirclePoints (angles gear) (innerRadius gear)
setZ ps newZ =
Re: [Haskell-cafe] What *not* to use Haskell for
G'day all. Quoting Tom Hawkins [EMAIL PROTECTED]: Actually, Haskell is an excellent language for hard real-time applications. At Eaton we're using it for automotive powertrain control. Of course, the RTS is not running in the loop. Instead, we write in a DSL, which generates C code for our vehicle ECU. Bingo! And thanks for someone for admitting that they do this. :-) Hard real-time applications is a huge area, and not all of the code that you write is code that ends up running on the target. Generally, in DSL/MDD-style development, not very much of the code that you write ends up running on the target. In some cases, _none_ of the code you write ends up running on the target. Haskell is almost ideal for tasks like this. Cheers, Andrew Bromage ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Linker errors to OpenGL with GHC 6.10.1
Do you know how I can fix these linker errors? C:\projects\funcat HelloWorld.hs import Graphics.Rendering.OpenGL import Graphics.UI.GLUT main = do (progname, _) - getArgsAndInitialize createWindow Hello World displayCallback $= clear [ColorBuffer] mainLoop C:\projects\funls lib GlU32.Lib glut32.lib OpenGL32.Lib glut.def glut32.dll C:\projects\funghc -Llib -lglut32 -lglu32 -lopengl32 HelloWorld.hs --make Linking HelloWorld.exe ... C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Begin.o):fake:(.text+0x1cb): undefined reference to `glutGet' C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Begin.o):fake:(.text+0x8af): undefined reference to `glutMainLoop' C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Window.o):fake:(.text+0x3cd): undefined reference to `glutEntryFunc' C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Window.o):fake:(.text+0x40d): undefined reference to `glutVisibilityFunc' C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Window.o):fake:(.text+0x3595): undefined reference to `glutPassiveMotionFunc' ...hundreds more... Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proof that Haskell is RT
Interesting posts. Thanks! On Wed, Nov 12, 2008 at 2:02 PM, Andrew Birkett [EMAIL PROTECTED] wrote: Thanks for the reference, and also to everyone who replied - all very useful and interesting. For what it's worth, the blog posts I was writing are here: http://www.nobugs.org/blog/archives/2008/11/12/why-do-they-call-it-referentially-transparent/ http://www.nobugs.org/blog/archives/2008/11/12/why-do-they-call-it-referentially-transparent-ii/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linker errors to OpenGL with GHC 6.10.1
2008/11/13 Greg Fitzgerald [EMAIL PROTECTED]: Do you know how I can fix these linker errors? C:\projects\funcat HelloWorld.hs import Graphics.Rendering.OpenGL import Graphics.UI.GLUT main = do (progname, _) - getArgsAndInitialize createWindow Hello World displayCallback $= clear [ColorBuffer] mainLoop C:\projects\funls lib GlU32.Lib glut32.lib OpenGL32.Lib glut.def glut32.dll C:\projects\funghc -Llib -lglut32 -lglu32 -lopengl32 HelloWorld.hs --make Linking HelloWorld.exe ... C:\Program Files\Haskell\GLUT-2.1.1.2\ghc-6.10.1/libHSGLUT-2.1.1.2.a(Begin.o):fake:(.text+0x1cb): undefined reference to `glutGet' [...] Thanks, Greg I'm assuming this is on Windows because of C:\... These kinds of linker errors happened to me when I built libHSGLUT with a wrong type of calling convention (by accident). There are two callconvs, and they are called stdcall and ccall on the Haskell side. The 'runhaskell setup configure' step is supposed to detect the correct one to use, so you should run it and then grep for lines with CALLCONV. They should say stdcall on Windows. If you find them saying ccall, that's likely the cause of all the linker errors. (Most Windows dynamic libraries use stdcall, but for extra configuration fun OpenAL uses ccall.) If this is the problem, you can change the offending ccall in the configuration files to stdcall and rebuild the library. Grepping for CALLCONV will also show the places you need to change this way. In my case the wrong configuration came from using the sh program from Cygwin. With the MSYS variety there was no problem. To be exact, it came down to the $host variable checked by the configuration script. Pekka ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] getLine and ^C on Windows
Hi folks, I'm using System.IO.getLine to read input in my program. I've compiled it on Windows Vista with ghc-6.10.1. I've noticed that if I press Ctrl+C while the program is waiting for input, it will get stuck. No keypresses can get me out of the program - I have to kill the shell. I've tried cmd.exe, Powershell and cygwin - same behavior. I'm sure editline would work better, but it's overkill. I just want to read lines of text and don't need fancy edit behavior. And I think editline complicates the build process. I also want my program to work right in non-interactive mode, reading redirected input. Am I missing something? Thanks, Lyle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
