[Haskell-cafe] Re: [Haskell] Interesting experiences of test automation in Haskell? Automation of Software Test 2010
On Fri, Nov 27, 2009 at 9:30 PM, John Hughes r...@chalmers.se wrote: This is a heads up about a workshop on test automation that I just joined the programme committee of. Automation of Software Test will be co-located with ICSE in Cape Town in May--the workshop home page is here: http://www.cs.allegheny.edu/ast2010/ Tools like QuickCheck, SmallCheck and HUnit fit the call for papers perfectly. So if you're doing some interesting automated testing in Haskell, why not submit a paper about it, and show a new audience what the Haskell community is up to? Both research papers and case studies are welcome, and the latter can even be in the form of a presentation of up to 15 slides--so there's no excuse for not putting something together! Recently we added a unit testing framework to Atom: a haskell DSL for hard realtime embedded applications. The framework hooks into Atom's assertion and functional coverage statements and provides some basic randomization utilities for automatic test generation. We've used this framework to test the embedded software of Eaton's parallel hydraulic hybrid application (HLA). One nice feature we've incorporated for our application is in the event of an assertion violation, simulation data is formated such that we can use the same analysis and debug tools that we use for real vehicle telemetry. I don't think we can make it to Cape Town, but I'll see if one of us can write up a case study. (Shruti, Tejas, Jake, any interest?) Here's an example test log from Language.Atom.Unit: pass: processTest1 cycles =1000 pass: dualProcessTest cycles =1000 pass: processNoDeactivationGuard cycles =1000 pass: processNoActivationGuard cycles =1000 pass: processDuelingProcesses cycles =1000 pass: arbiterTest1 cycles =1000 pass: arbiterTest2 cycles =1000 pass: arbiterTest3 cycles =1000 pass: arbiterTest8 cycles =1000 pass: arbiterTest10 cycles =1000 pass: absDisengagementTest cycles = 35000 pass: cruiseControlDisengagementTest cycles = 35000 pass: engineSpeedDisengagementTest cycles = 35000 pass: pumpSpeedDisengagementTest cycles = 35000 pass: ignitionDisengagementTest cycles = 35000 pass: selectedGearDisengagementTest cycles = 35000 pass: currentGearDisengagementTest cycles = 35000 pass: modeDisengagementTest cycles = 35000 pass: commissioningProcessDisengagementTest cycles = 35000 pass: canEEC1DisengagementTest cycles = 35000 pass: canEEC2DisengagementTest cycles = 35000 pass: canETC1DisengagementTest cycles = 35000 pass: canETC2DisengagementTest cycles = 35000 pass: canEBCDisengagementTest cycles = 35000 pass: canECCDisengagementTest cycles = 35000 pass: driverisolationFaultDisengagementTest cycles = 35000 pass: drivermodeDrainFaultDisengagementTest cycles = 35000 pass: drivermodeFillFaultDisengagementTest cycles = 35000 pass: drivermainBypassFaultDisengagementTest cycles = 35000 pass: driverchargeBypassFaultDisengagementTest cycles = 35000 pass: driverclutch1FaultDisengagementTest cycles = 35000 pass: driverclutch2FaultDisengagementTest cycles = 35000 pass: driverclutch3FaultDisengagementTest cycles = 35000 pass: driverpumpFaultDisengagementTest cycles = 35000 pass: drivermotorFaultDisengagementTest cycles = 35000 pass: coolerFanOnOffTest cycles = 4 pass: stateTransitionTest cycles = 75000 pass: swashCmdInBootstrapTest cycles = 4 pass: brakePressureAboveRangeAndTxSpeedDisengagementTest cycles = 35000 pass: brakePressureAboveRangeDisengagementTest cycles = 35000 pass: accumulatorPressureBelowRangeDisengagementTest cycles = 35000 pass: accumulatorPressureAboveRangeDisengagementTest cycles = 35000 pass: sawsh1BelowRangeDisengagementTest cycles = 35000 pass: swash1AboveRangeDisengagementTest cycles = 35000 pass: swash2BelowRangeDisengagementTest cycles = 35000 pass: swash2AboveRangeDisengagementTest cycles = 35000 pass: swashDiffOnBoundaryDisengagementTest cycles = 35000 pass: swashDiffAboveRangeDisengagementTest cycles = 35000 pass: pumpCaseOilTempCAboveRangeDisengagementTest cycles = 35000 pass: pumpCaseOilTempCBelowRangeDisengagementTest cycles = 35000 pass: pumpCaseOilTempCBoundaryDisengagementTest cycles = 35000 pass: reservoirOilTempCAboveRangeDisengagementTest cycles = 35000 pass: reservoirOilTempCBelowRangeDisengagementTest cycles = 35000 pass: reservoirOilTempCBoundaryDisengagementTest cycles = 35000 pass: tempSensorMiscompareAboveRangeDisengagementTest cycles = 35000 pass: tempSensorMiscompareBoundaryDisengagementTest cycles = 35000 pass: reservoirOilTempCTooExtremeDisengagementTest cycles = 35000 pass: reservoirOilTempCTooExtremeBoundaryDisengagementTest cycles = 35000 pass: reservoirOilLevelGalLDisengagementTest cycles = 35000 pass: reservoirOilLevelGalHDisengagementTest cycles = 35000 pass:
Re: [Haskell-cafe] Finding HP
On Wed, Dec 2, 2009 at 11:44 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: On a more serious note, Download Haskell /= Download Haskell Platform, so if I were glancing down the sidebar looking for a link to download the Haskell Platform then the first link wouldn't have registered for me. And putting a X has been released link! in the news does not count as a prominent download link. If I wanted to know something *about* the *Haskell Platform* I would click the link The Haskell Platform under the section About. So it is actually mentioned 3 times on the front page. What could be improved are the 2 download links: Download Haskell and Download GHC. It would perhaps be better to have one nice big Download button that takes you to a separate download page. Furthermore, when someone offers feedback designed to improve a page, and does so in a very non-threatening way: ... then in my own humble opinion, snapping back with Are you sure this isn't user error? is not a particularly nice response. E-mail isn't the best medium to convey emotion. I read Dons reply as Are you sure this is a problem with the front page and not a slight oversight on your part? Regards, Roel van Dijk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finding HP
Furthermore, when someone offers feedback designed to improve a page, and does so in a very non-threatening way: On Dec 2, 2009, at 2:26 PM, Andrew Coppin wrote: My suggestion is that if we really want people to grab the HP rather than download GHC directly, maybe we could make the link slightly more prominent? It also wouldn't hurt to mention it from the Implementations page, and maybe the GHC homepage? Just a suggestion... ... then in my own humble opinion, snapping back with Are you sure this isn't user error? is not a particularly nice response. When someone asks a question after being offered feedback designed to improve a page, and does so in a very non-threatening way: Are you sure this isn't user error? ... then in my own humble opinion, snapping back with \Are you sure this isn't a user error?\ is not a particularly nice response is not a particularly nice response. -- Tony Morris http://tmorris.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finding HP
2009/12/3 Tony Morris tonymor...@gmail.com: Furthermore, when someone offers feedback designed to improve a page, and does so in a very non-threatening way: On Dec 2, 2009, at 2:26 PM, Andrew Coppin wrote: My suggestion is that if we really want people to grab the HP rather than download GHC directly, maybe we could make the link slightly more prominent? It also wouldn't hurt to mention it from the Implementations page, and maybe the GHC homepage? Just a suggestion... ... then in my own humble opinion, snapping back with Are you sure this isn't user error? is not a particularly nice response. When someone asks a question after being offered feedback designed to improve a page, and does so in a very non-threatening way: Are you sure this isn't user error? ... then in my own humble opinion, snapping back with \Are you sure this isn't a user error?\ is not a particularly nice response is not a particularly nice response. HumbleOpinion putStrLn response *** Exception: stack overflow Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Haddock Secrets?
From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Gregory Crosswhite Is there some secret to getting Haddock to work with literate Haskell sources that I am missing? For example, when I download Takusen and type cabal configure cabal haddock It produces HTML files complete with a table of contents, but with all of the documentation stripped out. Oddly, I know that it is *possible* to process the literate sources into documentation because it appears on Hackage! You need a recent version of cabal i.e. = 1.6.0.3. I don't think the haddock version matters much (cabal can handle haddock-1 and haddock-2, I think). The problem is that haddock does not retain literate comments i.e. the .lhs preprocessor is run before haddock parses the file, and literate comments are stripped. This has been fixed in cabal by having cabal preprocess the .lhs file itself, with a special preprocessor that retains literate comments. The resulting .hs file is passed to haddock, and voilà. Before cabal solved the problem, I used to run a similar custom preprocessor over the Takusen source tree, and then invoke haddock manually to create the html docs. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finding HP
If I wanted to know something *about* the *Haskell Platform* I would click the link The Haskell Platform under the section About. So it is actually mentioned 3 times on the front page. What could be improved are the 2 download links: Download Haskell and Download GHC. It would perhaps be better to have one nice big Download button that takes you to a separate download page. Good thinking! Furthermore, when someone offers feedback designed to improve a page, and does so in a very non-threatening way: ... then in my own humble opinion, snapping back with Are you sure this isn't user error? is not a particularly nice response. E-mail isn't the best medium to convey emotion. I read Dons reply as Are you sure this is a problem with the front page and not a slight oversight on your part? Fair enough, and I will be the first person to admit that my own response was not the nicest way that I could have --- wait, hold on... darn you Tony Morris, you beat me to it! Fine, in that case I will be the *second* person to admit that my own response was not the nicest way that I could have counter-responded. I maintain, though, that when someone describes an experience they had using something in which they got confused, and offers constructive feedback on how things might be improved so that others could be less confused in the future, then it is much better to reply to the person's suggestions and whether they are good or bad ideas, rather than to describe why it was unreasonable for the person to have been confused, since the latter kind of response will just turn the person off from offering potentially helpful suggestions in the future. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] On the Meaning of Haskell 8
This is a continuation of what I wrote on the Haskell Prime mailing list which accounts for why this is the eighth in the series. These are lecture notes and if anyone has not already noticed from the Haskell Prime mailing list. I am giving a lecture. Type aliases allow you to extend the type system beyond the capabilities of the language. For example, natural numbers are not part of the type system, but you can say that a number has the natural number type by using a type alias. Ensuring that a number is indeed a natural number is your problem. The compiler will only ensure that it is at least an integer. There are a variety of instances where type aliases are useful. A prominent application in computer programming languages is to establish a form verses function relationship. Types in functional languages are formal types and not functional types ironically. A common example of this is to define an address type alias where you declare it as a string. Yes, it is a string formally, but it does not function as such. Its semantics are more specific and so it is not merely a string. How it behaves in context will differ and be more specific than a string. To quote Dune, There is a place terrifying to us, women, that we cannot go. The compiler cannot go there, but it can verify that it is at least a string. The form verses function distinction is especially useful when unifying against a tuple. Functional types can in large measure supplant labels. When you know its functional type you will usually know enough to know what it is referring to. When all you know is its formal type it can be touch and go. It is possible as the programmer to develop a set of rules beyond those that ensure that the address type is a string that for the benefit of the programmer describe where it is grammatically correct for variables of the address type may appear to which the compiler is wholly ignorant. When defining tuple types, type aliases were intended to replace labels. The result is more compact. The down side is that to access members unification must be employed. In the C language type aliases can be created using either the C preprocessor or the typedef construct. Consequently, this notion of type alias does not apply exclusively to functional languages.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hi, Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? not sure if this is what you are thinking at, but everytime I wrap a type Foo in a newtype MyFoo to define my own instances (or just for more expressiveness code), I wish I had a way to tell the compiler: „Please define function myfoo to be the same as foo, with all occurences of Foo in its type signature replaced by MyFoo.“ Instead I find my self writing manually code like myfoo :: (Blubb - MyFoo) - MyFoo - MyFoo - MyFoo myfoo f (MyFoo a) (MyFoo b) = MyFoo (foo (unMyFoo . f) a b) I guess TH could probably do this. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hmm, as long as you provide a type signature, Haskell could do implicit wrapping as well. If I'm not mistaken, the compiler should be able to figure out what to do in this case: myfoo :: (Blubb - MyFoo) - MyFoo - MyFoo - MyFoo myfoo = foo Sjoerd On Dec 3, 2009, at 11:07 AM, Joachim Breitner wrote: Hi, Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? not sure if this is what you are thinking at, but everytime I wrap a type Foo in a newtype MyFoo to define my own instances (or just for more expressiveness code), I wish I had a way to tell the compiler: „Please define function myfoo to be the same as foo, with all occurences of Foo in its type signature replaced by MyFoo.“ Instead I find my self writing manually code like myfoo :: (Blubb - MyFoo) - MyFoo - MyFoo - MyFoo myfoo f (MyFoo a) (MyFoo b) = MyFoo (foo (unMyFoo . f) a b) I guess TH could probably do this. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjo...@w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hi,
Am Donnerstag, den 03.12.2009, 11:25 +0100 schrieb Sjoerd Visscher:
Hmm, as long as you provide a type signature, Haskell could do implicit
wrapping as well.
If I'm not mistaken, the compiler should be able to figure out what to do in
this case:
myfoo :: (Blubb - MyFoo) - MyFoo - MyFoo - MyFoo
myfoo = foo
Maybe it should, but it does not:
$ cat test.hs
data Foo = Foo
newtype MyFoo = MyFoo { unMyFoo :: Foo }
foo :: Foo - (() - Foo) - Foo
foo Foo f = Foo
myfoo :: MyFoo - (() - MyFoo) - MyFoo
myfoo = foo
$ runhaskell test.hs
test.hs:9:8:
Couldn't match expected type `MyFoo' against inferred type `Foo'
In the expression: foo
In the definition of `myfoo': myfoo = foo
Greetings,
JOachim
--
Joachim Breitner
e-Mail: m...@joachim-breitner.de
Homepage: http://www.joachim-breitner.de
ICQ#: 74513189
Jabber-ID: nome...@joachim-breitner.de
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
I am uncertain if what any of you seek makes sense. The type checker is concerned with establishing a principle type and that is what is being reported, the principle type. The compiler as I pointed out in On the Meaning of Haskell 8 by design has not a clue as to the significance your type alias has.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping]
Am Donnerstag, den 03.12.2009, 01:40 +0100 schrieb Sjoerd Visscher: The idea is that there's just enough unwrapping such that you don't need to use getDual and appEndo. Yes, but what does Dual [1] `mappend Dual [2] mean then? Should it use the Monoid instance of Dual and return Dual [2, 1] ? Should it unwrap the lists beforehand and re-wrap them afterwards and return Dual [1, 2] ? Should it unwrap the resulting list afterwards and return [1, 2] or even [2,1] ? That's not obvious to me. On Dec 3, 2009, at 1:25 AM, Holger Siegel wrote: Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? 1) instance Monoid a = Monoid (Dual a) 2) instance Monoid (Endo a) instance Monoid b = Monoid (a - b) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjo...@w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] universal binary version of Haskell Platform?
On Thu, 2009-12-03 at 14:05 +0900, Benjamin L.Russell wrote: Recently, in changing my work schedule to work mainly from home, I switched from mainly using a work Wintel machine running Windows XP Professional, Service Pack 3, to mainly using my home PowerPC G4 PowerBook Macintosh, currently upgraded to Mac OS X 10.5.8 Leopard. However, to my surprise, there does not seem to be a version of the Haskell Platform that runs natively on my current OS. Does anybody know where to find a universal binary version of the Haskell Platform, or at least of GHC 6.10.4? Otherwise, I'm stuck without a native version. There no binary platform installer for OSX PPC. You'll have to grab ghc-6.10.4 for PPC from the ghc download page and then install the platform from the generic source tarball. If you'd like to help us next time to make a platform binary for PPC then that'd be great. I don't think we have the setup to make universal binaries but it should be possible to make a PPC build if we have a volunteer. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping]
In the case of Dual [1] `mappend` Dual [2] there's no need to do any unwrapping. There is if you say: l :: [Int] l = Dual [1] `mappend` Dual [2] The way I think this could work is that when the type checker detects a type error, it will first try to resolve it by newtype unwrapping (or wrapping even). Sjoerd On Dec 3, 2009, at 11:47 AM, Holger Siegel wrote: Am Donnerstag, den 03.12.2009, 01:40 +0100 schrieb Sjoerd Visscher: The idea is that there's just enough unwrapping such that you don't need to use getDual and appEndo. Yes, but what does Dual [1] `mappend Dual [2] mean then? Should it use the Monoid instance of Dual and return Dual [2, 1] ? Should it unwrap the lists beforehand and re-wrap them afterwards and return Dual [1, 2] ? Should it unwrap the resulting list afterwards and return [1, 2] or even [2,1] ? That's not obvious to me. On Dec 3, 2009, at 1:25 AM, Holger Siegel wrote: Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? 1) instance Monoid a = Monoid (Dual a) 2) instance Monoid (Endo a) instance Monoid b = Monoid (a - b) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjo...@w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Sjoerd Visscher sjo...@w3future.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] instance Binary UTCTime (Was: Oprhan instances)
On Wed, 2009-12-02 at 23:03 +0100, Joachim Breitner wrote: Would it be techically possible and feasible to write instance that do not actually cause a dependency on the package that defines the class resp. the data type? From a distributor point of view, I could live quite well with a setup like this: * When the package providing class Foo is compiled, instances for all interesting data types in the distribution are defined. This means a lot of build-dependencies, but they are not too bad (although annoying). * The generated package does (somehow) not depend on all these data packages. Of course, any part of the code that uses these data types, especially the class instances, are only usable when the corresponding package is also installed. I guess this would need compiler support, to not choke on code that uses unknown data types. * Packages needing an instance Foo Bar would just depend on the packges providing foo and bar, and the instance will be available and functional. This idea works symmetric: The instances could also be defined in the data type package, with no hard dependency on the package providing the class definition. Aye, I've thought about a model like this before. I think it's worth considering and working out if it'd be technically feasible. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Fwd: Re: [Haskell-cafe] Implicit newtype unwrapping]
Sjoerd Visscher wrote:
In the case of Dual [1] `mappend` Dual [2] there's no need to do any
unwrapping. There is if you say:
l :: [Int]
l = Dual [1] `mappend` Dual [2]
The way I think this could work is that when the type checker detects a type
error, it will first try to resolve it by newtype unwrapping (or wrapping even).
So if I have:
l :: Dual [Int]
l = [1] `mappend` [2]
It will wrap after the mappend, rather than before? But:
l :: Dual [Int]
l = Dual [1] `mappend` [2]
Would wrap the RHS in Dual? Does this version unwrap the LHS:
l :: [Int]
l = Dual [1] `mappend` [2]
And finally, what about:
l :: [Int]
l = Dual [1] `mappend` Endo [2]
Automatic wrapping and unwrapping, like automatic coercions, look like
an opportunity for surprising behaviour. OTOH, perhaps some sort of
deriving mechanism would be good. To revisit someone's previous
suggestion, perhaps you could allow functions in the deriving clause, so
that if you have:
f :: Foo - Foo - Foo
newtype MyFoo = MyFoo {getFoo :: Foo}
deriving (f as g)
will generate:
g :: MyFoo - MyFoo - MyFoo
g x y = Foo (f (getFoo x) (getFoo y))
I think it's not something worth adding (too subtle), but I thought I'd
throw it in as a possibility.
Neil.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
Nice. It would be fantastic to have a little practical real-world challenge (like building a simple music system, or a simple multi-channel sound mixer), and work this out in an imperative language, an object-oriented language, a functional language, and maybe other languages too, like logic languages or constraint languages (does the latter exist?) When OO is about constructing a machine and talking about objects, and FP is about making little algebraic languages, what would C or Pascal be like? In these languages, you don't think about objects, but you don't think about an algebra either? It's been a very long time since I worked with these languages, but as far as I recall, I started thinking about data structures and procedures operating on these data structures, which sounds a look like making ADTs and functions/operations on these... So this sounds odd, because it would mean that C and Pascal are in a sense closer to FP than OO is? Also Luke Palmer talked a couple of times about co-algebraic approaches, but not being a computer scientist, I never really understood what that meant (just reverse all the arrows?) On Thu, Nov 26, 2009 at 3:49 PM, Gregg Reynolds d...@mobileink.com wrote: On Thu, Nov 26, 2009 at 6:44 AM, Stephen Tetley stephen.tet...@gmail.com wrote: 2009/11/26 Gregg Reynolds d...@mobileink.com: Modeling musical stuff could provide an excellent illustration of the difference between OO and the Haskell way; it's the difference between metaphysical engineering and constructive mathematics. Hmm, Stephen Travis Pope's SmOKe - a design that has been the basis of various state-of-the-art Smalltalk music systems - seems pretty concrete to me rather than metaphysical. http://heaveneverywhere.com/stp/PostScript/icmc.94.mode.pdf Looks interesting, but what I was trying to get at - ``metaphysical engineering'' just popped into my head and sounded kinda cool so I went with it - is that these are two radically different ways of thinking about what we're doing when we write programs. For example, Pope talks about music in terms of properties, but then says [t]hese properties may be music-specific _objects_ (such as pitches or spatial positions)... (emphasis added). This is standard OO-speak; there's nothing wrong with it, the point is just that the domain of interest is viewed as a collection of ``objects'' and their behaviors, where ``object'' is the word we use for lack of a better term to refer to things that exist - hence metaphysics. Are there _really_ any objects involved, especially where properties are concerned? Not for me, though others may differ. In any case, the overall picture is that programs are combinations of such objects, so the program is viewed as the description of a kind of machine - hence engineering. In order to describe music, the programmer describes a machine. By contrast, a ``purely functional'' approach (I prefer ``algebraic'' as more accurate or at least more revealing) might construe such properties in terms of types and operations on values of the types, which capture the notion of property directly without implicating objects in any way. A music library would be viewed in terms of a language (algebra), with customized names for domain-specific types and operations, that the programmer can use to describe music instead of describing a machine that produces music. Which makes the programmer a litterateur rather than a constructor of machines, among other things. Cheers, Gregg ___ 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] Patches and forks for GHC 6.12
Some packages will need modifications to build or work with GHC 6.12 (in some cases, just modifications to the .cabal file). I've created this wiki page to track work people have done on that which hasn't yet been included into official packages or repositories: http://haskell.org/haskellwiki/Patches_and_forks_for_GHC_6.12 Please add any ones you know of (or just email me and I'll add them for you). -- Robin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Perhaps what you are looking for is a more powerful defining semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo Matthew not sure if this is what you are thinking at, but everytime I wrap a type Foo in a newtype MyFoo to define my own instances (or just for more expressiveness code), I wish I had a way to tell the compiler: „Please define function myfoo to be the same as foo, with all occurences of Foo in its type signature replaced by MyFoo.“ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Of course, I meand 'deriving', not 'defining' /me embarsed 2009/12/3 Matthew Pocock matthew.poc...@ncl.ac.uk Perhaps what you are looking for is a more powerful defining semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hi, Am Donnerstag, den 03.12.2009, 11:13 + schrieb Matthew Pocock: Perhaps what you are looking for is a more powerful defining semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo it goes into the right direction, but I’d also like to have this also capeable to derive single functions (giving them a new name), and not only class instances. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are there standard idioms for lazy, pure error handling?
Duncan Coutts duncan.cou...@googlemail.com writes: [1] http://hackage.haskell.org/package/failable-list Nice. I agree this is needed (or rather, would be nice to standardise). Although I don't care for the cutesy naming suggested in the 'Train' datatype, failable-list could be made more general. Why is there a specific constructor 'Done', instead of just allowing the user to select a value of type 'e' (using 'Maybe b' if nothing else works)? Perhaps we could also consider an infix notation, like: data TerminatedList a e = Then a (TerminatedList a e) | Finally e (So you could do e.g: 4 `Then` 5 `Then` 1 `Finally` success!. Of course, you might prefer symbols instead.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are there standard idioms for lazy, pure error handling?
data TerminatedList a e = Then a (TerminatedList a e) | Finally e Nice. (So you could do e.g: 4 `Then` 5 `Then` 1 `Finally` success!. Errm, you mean: 4 `Then` 5 `Then` 1 `Then` Finally success! Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: atom-0.1.3
This release of Atom slightly changes the semantics of assertions and coverage. Assertion and coverage are now checked between the execution of every rule, instead of only when the rules containing assertions are fired. They are still subject to parental guard conditions, but not period or phase constraints. This means... period 20 $ atom checkSomeStuff $ do cond ok assert A a assert B b cover C c ... A, B, and C are checked all the time ok is true, not just every 20th cycle. Checking between every rule execution obviously impacts simulation time, but the increased testing rigor is worth it. I also added 'linear' to Common, which does linear interpolation and extrapolation on a line given two points. (I found I was replicating this function everywhere for sensor calibrations, control limits, etc.) http://hackage.haskell.org/package/atom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Are there standard idioms for lazy, pure error handling?
wren ng thornton wrote: Nicolas Pouillard wrote: Excerpts from Heinrich Apfelmus's message of Tue Dec 01 11:29:24 +0100 2009: For mnemonic value, we could call it a train: data Train a b = Wagon a (Train a b) | Loco b I rather like it too. The mnemonic version sounds a lot nicer than ListEnd, though I'd probably call the constructors Cabin and Caboose. I suspect the Train name runs into cultural differences. Cabin and Caboose are not names I know in relation to trains, and even Wagon and Loco don't immediately convey to me which one is which. I think a more obvious Cons/Terminator naming scheme is best. Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Optimization with Strings ?
Hello In my futur program, it use a lot of binary trees with strings (words) as leaf. There is just arround 1000 words and they will appear a lot of times. The program will possibly consume a lot of process and memory (it is a mathematics proover). I began this program in C++ but haskell has a prety good speed and memory footprint and is easier. But I don't know if it worth to do this optimization: having a dictionary to translate string words in Int. The answer depends on the automatic optimizations in GHC, because GHC could compare quickely two strings if it is the same object, so it depends if program generated by GHC have a dictionary (tree) of strings internaly. Someone knows this ? (Sorry for my english, I'm french) thank you -- Emmanuel Chantréau ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
On Thu, Dec 3, 2009 at 1:03 PM, Emmanuel CHANTREAU echant+hask...@maretmanu.org wrote: In my futur program, it use a lot of binary trees with strings (words) as leaf. There is just arround 1000 words and they will appear a lot of times. The program will possibly consume a lot of process and memory (it is a mathematics proover). I began this program in C++ but haskell has a prety good speed and memory footprint and is easier. But I don't know if it worth to do this optimization: having a dictionary to translate string words in Int. The answer depends on the automatic optimizations in GHC, because GHC could compare quickely two strings if it is the same object, so it depends if program generated by GHC have a dictionary (tree) of strings internaly. Someone knows this ? It doesn't work this way : Strings are just lists of Chars. Comparison is made recursively, Char by Char. You can have a look at the source to make sure : instance (Eq a) = Eq [a] where [] == [] = True (x:xs) == (y:ys) = x == y xs == ys _xs== _ys= False So you will have to code your own optimisation. David. P.S. In French if you didn't understand: Ca ne marche pas comme ça. Les chaines de caractères ne sont que des listes de caractères. La comparaison sur les listes est faite récursivement, caractère par caractère, il suffit pour s'en assurer de regarder au source : Donc il vaut mieux que tu implémente ton propre dictionnaire. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
Hello Emmanuel, Thursday, December 3, 2009, 3:03:02 PM, you wrote: memory footprint and is easier. But I don't know if it worth to do this optimization: having a dictionary to translate string words in Int. GHC compiler already has this optimization. unfortunately it's not in the code it generates but in compiler itself (GHC is written in Haskell and compiled by itself). so it is definitely worth an implementation if you handle lots of strings as compiler does -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
On Thu, Dec 3, 2009 at 4:09 AM, Peter Verswyvelen bugf...@gmail.com wrote:
Also Luke Palmer talked a couple of times about co-algebraic
approaches, but not being a computer scientist, I never really
understood what that meant (just reverse all the arrows?)
Disclaimer: I am not a category theorist. I think my intuition
matches the terminology pretty well, but I would like to see someone
who knows what they are talking about elaborate or correct me.
The way I use the term, a coalgebraic data type is still very much
functional in nature. Here's how I see it:
An initial algebra focuses on the constructors. You see:
data Nat = Zero | Succ !Nat
Notice Zero :: Nat, Succ :: Nat - Nat. We say that Nat is the
smallest data type that supports both of those constructrs (because of
Haskell's laziness, if I hadn't put the ! there, it wouldn't be the
least).
When you want to construct one, you use one of the constructors
(because it is by def. just large enough to have those)
When you want to destruct one, i.e. write a function f :: Nat - A for
some A, you say well it had to have been made with Zero or Succ, so
you pattern match on Zero and pattern match on Succ.
A final coalgebra focuses on the projections. You might see:
data Conat = Conat { proj :: Either () Conat }
So proj :: Conat - Either () Conat. But we can't say that it's the
smallest data type that supports that projection, because that is a
very small data type (it always projects to ()). Rather it is the
*largest* data type that still supports that projection.
When you want to destruct one, you just use one of the projection,
because it is by def. still small enough to always have them.
When you want to construct one, it is enough to specify the values for
each of the projections, because the data type is large enough to hold
any (well-defined) projection you can think of.
See the dualities?
The difference between Nat and Conat is that Conat has one additional
element, fix (Conat . Right). Technically all the lazy data types are
final coalgebras (just stated with focus on the constructors), because
they have these infinite elements, but it is convenient to pretend
that they don't sometimes. But go to any of the popular total
dependently-typed languages and there are some differences (one of
those differences being that none of them get final coalgebras
right[1]).
Luke
[1] Conor McBride. Let's see how things unfold.
http://strictlypositive.org/ObsCoin.pdf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are there standard idioms for lazy, pure error handling?
On Thu, 2009-12-03 at 12:34 +0100, Ketil Malde wrote: Duncan Coutts duncan.cou...@googlemail.com writes: [1] http://hackage.haskell.org/package/failable-list Nice. I agree this is needed (or rather, would be nice to standardise). Although I don't care for the cutesy naming suggested in the 'Train' datatype, failable-list could be made more general. Why is there a specific constructor 'Done', instead of just allowing the user to select a value of type 'e' (using 'Maybe b' if nothing else works)? Perhaps we could also consider an infix notation, like: data TerminatedList a e = Then a (TerminatedList a e) | Finally e (So you could do e.g: 4 `Then` 5 `Then` 1 `Finally` success!. Of course, you might prefer symbols instead.) I agree the naming could do with some work and it's worth trying a few variants to see what seems nicest. I've got an open mind on the suggestion to amalgamate the two ways the list could end. I'm not especially in favour of generalising for the sake of generalising, especially if it looses the connection to the notion of annotating your ordinary data structure with extra errors. If I effectively always have to use an Either for the final value then perhaps it does not buy anything and just makes the folds uglier (since it might loose the connection with the ordinary fold). But it could make even that use case simpler so it's worth looking at in a few examples (eg the tar package). Note that another similar use case is lazy progress reporting. In cabal-install's dependency solver I've used: -- | A type to represent the unfolding of an expensive long running -- calculation that may fail. We may get intermediate steps before the -- final result which may be used to indicate progress and/or logging -- messages. -- data Progress step fail done = Step step (Progress step fail done) | Fail fail | Done done It's a difference in emphasis but I think it may also have a different Monad instance since we consider Progress to be a single value, not a list. It's like the Either error monad but with extra writer style logging. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hi Martijn On 3 Dec 2009, at 00:16, Martijn van Steenbergen wrote: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? Subtyping. What advantages and disadvantages would it have? The typechecker being psychic; the fact that it isn't. It's very easy to add forms of subtyping and make a mess of type and instance inference. In what cases would this lead to ambiguous code? If f :: x - ZipList y we get traverse f :: t x - [t y] but it is not clear whether to attach the unpacking to f or to the result, and that will determine the idiom in which the traversal occurs. And that's before you start mixing the sugar of newtypes with the fertiliser of GADTs... But even if it's dangerous to unpack newtypes silently, it's rather nice to do it systematically, via a type class. Here are old posts of mine which mention this and then show off a bit. http://www.mail-archive.com/haskell-cafe@haskell.org/msg37213.html http://www.haskell.org/pipermail/libraries/2008-January/008917.html These days, how about class Newtype n where type Unpack n pack :: Unpack n - n unpack :: n - Unpack n and related machinery? Cheers Conor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
There is another point that needs to be made. A type signature isn't actually a type specification. It is a type assertion and a type specification in the event that the compiler needs your help. Most of the time the compiler can care less what you think and does not require your assistance. In languages like C you get to call the shots. In languages such as Haskell you don't get that opportunity.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Card games
Hi Tom, Did you make any progress on your Dominion quest? I guess you could start by modeling `Big Money' and add the other cards (and interaction) from there. Also I guess there is a common baseline of things that are inherent in a lot of card games --- mechanics that cards support: Shuffling, having two sides, hiding one of two sides, picking a random card from a subset (or at least one where you can only see one side), placing cards in constellations on a table (with one side up). I guess with a bit of type system trickery you can even make sure that strategies don't look at the sides of the cards they are not supposed to look at --- without having to do any other information hiding like only providing access by getter functions. Matthias. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] seems like I'm on the wrong track
Michael P Mossey schrieb: Perhaps someone could either (1) help me do what I'm trying to do, or (2) show me a better way. I have a problem that is very state-ful and I keep thinking of it as OO, which is driving me crazy. Haskell is several times harder to use than Python in this instance, probably because I'm doing it wrong. To give you a larger context, this problem is essentially compiling a description of music (my own) into a kind of music-machine-language (CSound). CSound is relatively untidy. There are currently two public interfaces to CSound: http://hackage.haskell.org/packages/archive/haskore/0.1/doc/html/Haskore-Interface-CSound.html http://hackage.haskell.org/package/hCsound You may also want to use SuperCollider: http://hackage.haskell.org/package/hsc3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are there standard idioms for lazy, pure error handling?
Malcolm Wallace malcolm.wall...@cs.york.ac.uk writes: Errm, you mean: 4 `Then` 5 `Then` 1 `Then` Finally success! Yes, sorry, and thanks. I guess I should learn to check with ghci before posting... How about this for a nicer syntax? infixr 8 :+ infixr 8 +: data TList a e = a :+ (TList a e) | Return e deriving Show x +: y = x :+ (Return y) *Main 2 :+ 4 +: success 2 :+ (4 :+ Return success) I like the generic terminal value, it allows things like: *Main let count = go 0 where go i (x:xs) = x :+ go (i+1) xs; go i [] = Return i *Main :t count count :: [t] - TList t Integer *Main count [1..5] 1 :+ (2 :+ (3 :+ (4 :+ (5 :+ Return 5 (But perhaps these things can be done more elegantly using State or similar?) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] seems like I'm on the wrong track
On Wed, 2 Dec 2009, Stephen Tetley wrote: As for the second half of what you get from a programming language, your system description frames what you want to do with an emphasis on dynamic aspects. This seems a good way off from the prior art in Haskell. For instance there are Haskell synthesizers - George Giorgidze's yampa-synth and Jerzy Karczmarczuk's Clarion (actually in Clean, but near enough). Here you build signal processing modules - unit generators, of course - Yampasynth uses arrows to do this Clarion uses infinite streams. With both you would build a synthesizer statically from unit generators and somehow run it to produce sounds[1]. Shameless advertisement here: http://hackage.haskell.org/package/synthesizer-core http://www.youtube.com/watch?v=KA6DE9jlpSY ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
Le Thu, 3 Dec 2009 13:20:31 +0100, David Virebayre dav.vire+hask...@gmail.com a écrit : It doesn't work this way : Strings are just lists of Chars. Comparison is made recursively, Char by Char. You can have a look at the source to make sure : instance (Eq a) = Eq [a] where [] == [] = True (x:xs) == (y:ys) = x == y xs == ys _xs== _ys= False Hello Thank you David and Bulat for your answers. I don't see the proof you see. Because GHC could store two sames objects juste once and by the definition of == on lists it could deduce that forall x; List x = x==x. GHC have all informations to do this optimization job, because haskell functions definitions are mathematics definitions. Bulat says that this optimization is not done, so I will do it by my hands (ho my poor lazy hands). -- Emmanuel Chantréau ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] happstack homepage
I noticed that happstack.com and tutorial.happstack.com are both equal to patch-tag.com. Google's cache has the original pages. Is this the result of some misconfiguration or something else? I want to play with happstack and this is a slight inconvenience. On the other hand, all happstack packages build without problems so I'll build the tutorial locally and work from there. Regards, Roel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
Emmanuel CHANTREAU wrote: Le Thu, 3 Dec 2009 13:20:31 +0100, David Virebayre dav.vire+hask...@gmail.com a écrit : It doesn't work this way : Strings are just lists of Chars. Comparison is made recursively, Char by Char. You can have a look at the source to make sure : instance (Eq a) = Eq [a] where [] == [] = True (x:xs) == (y:ys) = x == y xs == ys _xs== _ys= False Hello Thank you David and Bulat for your answers. I don't see the proof you see. Because GHC could store two sames objects juste once and by the definition of == on lists it could deduce that forall x; List x = x==x. GHC have all informations to do this optimization job, because haskell functions definitions are mathematics definitions. Besides any other reasons, Haskell has the error function, and infinite lists. Consider: p :: String p = error Haha! q :: String q = repeat 'a' pEqualsP :: Bool pEqualsP = p == p qEqualsQ :: Bool qEqualsQ = q == q By your rule, pEqualsP and qEqualsQ should be True. In fact, the correct answer is that pEqualsP should produce an error and qEqualsQ should never terminate. Since Strings can contain such errors and infinite lists, you can't know for certain that an object equals itself without checking its entire length, which is what the original definition for equals did anyway. There may be strict data structures for which your optimisation might be applicable, though. Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC magic optimization ?
Hello One thing is magic for me: how GHC can know what function results to remember and what results can be forgotten ? Is it just a stupid buffer algorithm or is there some mathematics truths behind this ? I'm very happy about Haskell, it's so great to put some smart ideas in a computer. thanks -- Emmanuel Chantréau ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
Am Donnerstag, den 03.12.2009, 16:23 +0100 schrieb Emmanuel CHANTREAU: Le Thu, 3 Dec 2009 13:20:31 +0100, David Virebayre dav.vire+hask...@gmail.com a écrit : It doesn't work this way : Strings are just lists of Chars. Comparison is made recursively, Char by Char. You can have a look at the source to make sure : instance (Eq a) = Eq [a] where [] == [] = True (x:xs) == (y:ys) = x == y xs == ys _xs== _ys= False Hello Thank you David and Bulat for your answers. I don't see the proof you see. Because GHC could store two sames objects juste once and by the definition of == on lists it could deduce that forall x; List x = x==x. GHC have all informations to do this optimization job, because haskell functions definitions are mathematics definitions. This does not always hold, because the equivalence known from mathematics differs from Haskell's strict equality when it comes to infinite or undefined values. Consider let x = repeat () in x == x and let x = error oops in x == x In both cases your optimized program would return True, although the value is undefined (bottom). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC magic optimization ?
On Thu, 3 Dec 2009, Emmanuel CHANTREAU wrote: Hello One thing is magic for me: how GHC can know what function results to remember and what results can be forgotten ? Is it just a stupid buffer algorithm or is there some mathematics truths behind this ? Although it is not required by the Haskell 98 report, the 'let' expression usually stores variable values (sharing) and top-level constants are also stored. I wonder how much of currently existing Haskell code would still work, if this would be changed, since this behavior is essential for memory usage and speed. If you want to cache function results, see: http://www.haskell.org/haskellwiki/Memoization ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC magic optimization ?
Hi. There is actually no magic at all going on. Haskell has a reasonably well-defined evaluation model; you can approximate it, at least not taking IO into account, with lazy graph reduction (look that up on google). Probably that is the mathematical truth you're looking for. Actually, if Haskell had any magic, it would be bad, because magic can't be reliable (if you can't describe it, you can't rely on it) and your magically-efficient program would suddenly and unexplainably break at random changes in the source or in the compiler version. I remember being slightly shocked when I discovered that even in Prolog no magic is going on and it has a well-defined evaluation model, too (before that, when I only heard of Prolog but hadn't read anything serious about it, I thought that it is a bunch of unthinkable theorem proving wizardry). 2009/12/3 Emmanuel CHANTREAU echant+hask...@maretmanu.org: Hello One thing is magic for me: how GHC can know what function results to remember and what results can be forgotten ? Is it just a stupid buffer algorithm or is there some mathematics truths behind this ? I'm very happy about Haskell, it's so great to put some smart ideas in a computer. thanks -- Emmanuel Chantréau ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC magic optimization ?
Does this really mean that you want to know how the garbage collector works? Emmanuel CHANTREAU wrote: Hello One thing is magic for me: how GHC can know what function results to remember and what results can be forgotten ? Is it just a stupid buffer algorithm or is there some mathematics truths behind this ? I'm very happy about Haskell, it's so great to put some smart ideas in a computer. thanks ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Optimization with Strings ?
Hello Emmanuel, Thursday, December 3, 2009, 6:23:56 PM, you wrote: that forall x; List x = x==x. GHC have all informations to do this optimization job, because haskell functions definitions are mathematics definitions. GHC doesn't make ALL possible optimizations, isn't it obvious? ;) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Optimization with Strings ?
Dear Emmanuel Chantréau, You may want to look into Objective CAML http://caml.inria.fr/ which is a French product as you can see from the Internet address. It is likely better suited to the task than Haskell and has a reputation for speed. For those who prefer object oriented programming it has facilities for that which may ease your transition from C++. The Microsoft F# language is based on Objective CAML. Haskell has a problem with its type system and is not rigorous. Haskell is not a suitable language for proof assistants and so I would advise you to stay clear of Haskell. Standard ML was engineered with the needs of proof assistants in mind and so you may want to look into Standard ML, but you should be very happy with Objective CAML. It has an excellent reputation. The Coq proof assistant which is another French product is based on Objective CAML. If you do decide that Haskell is the way, it will help ease your transition to Haskell. There is nothing that says you can't keep your fingers in several pies at once.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
Am Donnerstag 03 Dezember 2009 16:31:56 schrieb Neil Brown: Emmanuel CHANTREAU wrote: Le Thu, 3 Dec 2009 13:20:31 +0100, David Virebayre dav.vire+hask...@gmail.com a écrit : It doesn't work this way : Strings are just lists of Chars. Comparison is made recursively, Char by Char. You can have a look at the source to make sure : instance (Eq a) = Eq [a] where [] == [] = True (x:xs) == (y:ys) = x == y xs == ys _xs== _ys= False Hello Thank you David and Bulat for your answers. I don't see the proof you see. Because GHC could store two sames objects juste once and by the definition of == on lists it could deduce that forall x; List x = x==x. GHC have all informations to do this optimization job, because haskell functions definitions are mathematics definitions. Besides any other reasons, Haskell has the error function, and infinite lists. Consider: p :: String p = error Haha! q :: String q = repeat 'a' pEqualsP :: Bool pEqualsP = p == p qEqualsQ :: Bool qEqualsQ = q == q By your rule, pEqualsP and qEqualsQ should be True. In fact, the correct answer is that pEqualsP should produce an error and qEqualsQ should never terminate. Since Strings can contain such errors and infinite lists, you can't know for certain that an object equals itself without checking its entire length, which is what the original definition for equals did anyway. There may be strict data structures for which your optimisation might be applicable, though. Neil. However, GHC offers a *really unsafe* function that allows to quickly check whether two values refer to the same heap-object. But it won't help Emmanuel, because any indirection causes it to say no and let x = expression in x == x should never appear in code anyway. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
JohnDEarle: You may want to look into Objective CAML http://caml.inria.fr/ which is a French product as you can see from the Internet address. It is likely better suited to the task than Haskell and has a reputation for speed. For those who prefer object oriented programming it has facilities for that which may ease your transition from C++. The Microsoft F# language is based on Objective CAML. Haskell has a problem with its type system and is not rigorous. Haskell is not a suitable language for proof assistants and so I would advise you to stay clear of Haskell. Standard ML was engineered with the needs of proof assistants in mind and so you may want to look into Standard ML, but you should be very happy with Objective CAML. It has an excellent reputation. The Coq proof assistant which is another French product is based on Objective CAML. Ok, that is serious trolling. There are several proof assistants written in Haskell: http://hackage.haskell.org/package/Agda http://hackage.haskell.org/package/ivor http://www.e-pig.org/ http://wiki.di.uminho.pt/wiki/bin/view/PURe/Camila http://www.cwi.nl/~jve/demo/ http://www.haskell.org/dumatel/ http://www.cs.chalmers.se/~koen/folkung/ http://taz.cs.wcupa.edu/~dmead/code/prover/ http://www.math.chalmers.se/~koen/paradox/ http://proofgeneral.inf.ed.ac.uk/Kit http://www.haskell.org/yarrow/ and the guarantees of purity the type system provides are extremely useful for verification purposes. Please, before posting like this to the Haskell community, inform yourself more of what the Haskell community has produced. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finding HP
vandijk.roel: On Wed, Dec 2, 2009 at 11:44 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: On a more serious note, Download Haskell /= Download Haskell Platform, so if I were glancing down the sidebar looking for a link to download the Haskell Platform then the first link wouldn't have registered for me. And putting a X has been released link! in the news does not count as a prominent download link. If I wanted to know something *about* the *Haskell Platform* I would click the link The Haskell Platform under the section About. So it is actually mentioned 3 times on the front page. What could be improved are the 2 download links: Download Haskell and Download GHC. It would perhaps be better to have one nice big Download button that takes you to a separate download page. Having a single download link that only points to the Haskell Platform would be a bit of a policy shift. Is the community ready to accept that users looking for Haskell should be given the HP binaries? If so, I can change it to have a single Download button. Though it might be preferable to do that after the next release (the first non-beta release). -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finding HP
I think it makes sense, the HP is supposed to set up the entire environment needed for typical haskell development (at least, that is my understanding). As such, what's the point in making downloading haskell mean downloading a single _peice_ of haskell (GHC) only to have to download _everything else anyway_ (cabal-et-al, various standard libraries, etc). Perhaps we could put it to some kind of community vote. /Joe On Dec 3, 2009, at 11:43 AM, Don Stewart wrote: vandijk.roel: On Wed, Dec 2, 2009 at 11:44 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: On a more serious note, Download Haskell /= Download Haskell Platform, so if I were glancing down the sidebar looking for a link to download the Haskell Platform then the first link wouldn't have registered for me. And putting a X has been released link! in the news does not count as a prominent download link. If I wanted to know something *about* the *Haskell Platform* I would click the link The Haskell Platform under the section About. So it is actually mentioned 3 times on the front page. What could be improved are the 2 download links: Download Haskell and Download GHC. It would perhaps be better to have one nice big Download button that takes you to a separate download page. Having a single download link that only points to the Haskell Platform would be a bit of a policy shift. Is the community ready to accept that users looking for Haskell should be given the HP binaries? If so, I can change it to have a single Download button. Though it might be preferable to do that after the next release (the first non-beta release). -- Don ___ 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] Finding HP
I'm all for making HP the default as long as we find a way to make some of the larger packages (I'm thinking gtk2hs) either ship with HP in Windows or install correctly with HP. On Thu, Dec 3, 2009 at 11:46 AM, Joe Fredette jfred...@gmail.com wrote: I think it makes sense, the HP is supposed to set up the entire environment needed for typical haskell development (at least, that is my understanding). As such, what's the point in making downloading haskell mean downloading a single _peice_ of haskell (GHC) only to have to download _everything else anyway_ (cabal-et-al, various standard libraries, etc). Perhaps we could put it to some kind of community vote. /Joe On Dec 3, 2009, at 11:43 AM, Don Stewart wrote: vandijk.roel: On Wed, Dec 2, 2009 at 11:44 PM, Gregory Crosswhite gcr...@phys.washington.edu wrote: On a more serious note, Download Haskell /= Download Haskell Platform, so if I were glancing down the sidebar looking for a link to download the Haskell Platform then the first link wouldn't have registered for me. And putting a X has been released link! in the news does not count as a prominent download link. If I wanted to know something *about* the *Haskell Platform* I would click the link The Haskell Platform under the section About. So it is actually mentioned 3 times on the front page. What could be improved are the 2 download links: Download Haskell and Download GHC. It would perhaps be better to have one nice big Download button that takes you to a separate download page. Having a single download link that only points to the Haskell Platform would be a bit of a policy shift. Is the community ready to accept that users looking for Haskell should be given the HP binaries? If so, I can change it to have a single Download button. Though it might be preferable to do that after the next release (the first non-beta release). -- Don ___ 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] Is Haskell a Fanatic?
See [Haskell-cafe] Optimization with Strings ? for background. Don Stewart wrote, the guarantees of purity the type system provides are extremely useful for verification purposes. My response to this is in theory. This is what caught my attention initially, but the language lacks polish and does not appear to be going in a direction where it shows signs where it will self-correct. It may even be beyond repair. I care about others and I don't want people to be misled. I am already well aware of the numbers. They do not impress me. I have written on this already. I have given Haskell the benefit of the doubt and said, What's wrong with being uncompromising? There is something wrong with it, if it has taken you off the path of truth. This is not uncompromising. This is something else. It is called fanaticism and this is the opinion that I have come to after due consideration. If you are going to argue your case, be constructive. Tell me how the type system is not flawed and how the Haskell language is rigorous. What proof do you have of this? Explain to me how Haskell has been merely uncompromising in its pursuit of perfection and did not manage to step over the threshold into fanaticism. Please remain on topic and on point. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Haskell a Fanatic?
The burden of proof is on you to demonstrate that it _is_. On Thu, Dec 3, 2009 at 12:09 PM, John D. Earle johndea...@cox.net wrote: See [Haskell-cafe] Optimization with Strings ? for background. Don Stewart wrote, the guarantees of purity the type system provides are extremely useful for verification purposes. My response to this is in theory. This is what caught my attention initially, but the language lacks polish and does not appear to be going in a direction where it shows signs where it will self-correct. It may even be beyond repair. I care about others and I don't want people to be misled. I am already well aware of the numbers. They do not impress me. I have written on this already. I have given Haskell the benefit of the doubt and said, What's wrong with being uncompromising? There is something wrong with it, if it has taken you off the path of truth. This is not uncompromising. This is something else. It is called fanaticism and this is the opinion that I have come to after due consideration. If you are going to argue your case, be constructive. Tell me how the type system is not flawed and how the Haskell language is rigorous. What proof do you have of this? Explain to me how Haskell has been merely uncompromising in its pursuit of perfection and did not manage to step over the threshold into fanaticism. Please remain on topic and on point. ___ 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] Is Haskell a Fanatic?
*flawed, that is On Thu, Dec 3, 2009 at 12:13 PM, John Van Enk vane...@gmail.com wrote: The burden of proof is on you to demonstrate that it _is_. On Thu, Dec 3, 2009 at 12:09 PM, John D. Earle johndea...@cox.net wrote: See [Haskell-cafe] Optimization with Strings ? for background. Don Stewart wrote, the guarantees of purity the type system provides are extremely useful for verification purposes. My response to this is in theory. This is what caught my attention initially, but the language lacks polish and does not appear to be going in a direction where it shows signs where it will self-correct. It may even be beyond repair. I care about others and I don't want people to be misled. I am already well aware of the numbers. They do not impress me. I have written on this already. I have given Haskell the benefit of the doubt and said, What's wrong with being uncompromising? There is something wrong with it, if it has taken you off the path of truth. This is not uncompromising. This is something else. It is called fanaticism and this is the opinion that I have come to after due consideration. If you are going to argue your case, be constructive. Tell me how the type system is not flawed and how the Haskell language is rigorous. What proof do you have of this? Explain to me how Haskell has been merely uncompromising in its pursuit of perfection and did not manage to step over the threshold into fanaticism. Please remain on topic and on point. ___ 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] Is Haskell a Fanatic?
It will be better for all of you to figure it out for yourselves and gain more experience about what is out there. Haskell isn't the world. Haskell would be the cutting edge if it didn't have competition.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Haskell a Fanatic?
On 3 Dec 2009, at 20:09, John D. Earle wrote: See [Haskell-cafe] Optimization with Strings ? for background. Somehow all your posts to the Optimization... thread were classified as spam by my e-mail client. Seems like it's developing self-awareness. If you are going to argue your case, be constructive. Tell me how the type system is not flawed and how the Haskell language is rigorous. What proof do you have of this? Explain to me how Haskell has been merely uncompromising in its pursuit of perfection and did not manage to step over the threshold into fanaticism. Please remain on topic and on point. Happily. But it takes two to make a conversation. Why don't YOU start first? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
Emmanuel CHANTREAU on 2009-12-03 13:03:02 +0100: In my futur program, it use a lot of binary trees with strings (words) as leaf. There is just arround 1000 words and they will appear a lot of times. The program will possibly consume a lot of process and memory (it is a mathematics proover). I began this program in C++ but haskell has a prety good speed and memory footprint and is easier. But I don't know if it worth to do this optimization: having a dictionary to translate string words in Int. The answer depends on the automatic optimizations in GHC, because GHC could compare quickely two strings if it is the same object, so it depends if program generated by GHC have a dictionary (tree) of strings internaly. Someone knows this ? I don't know of a library to intern strings, but it's not too hard to implement. I couldn't find the code I wrote to do this, but I looked around a bit and this is about what I remember doing: http://www.haskell.org/pipermail/haskell-cafe/2005-June/010335.html For the application I was using, interning strings did provide a significant reduction in memory, but for whatever reason didn't help with speed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Haskell a Fanatic?
OK, that was certainly constructive. Sorry, don't need a self- appointed messiah here. On 3 Dec 2009, at 20:31, John D. Earle wrote: It will be better for all of you to figure it out for yourselves and gain more experience about what is out there. Haskell isn't the world. Haskell would be the cutting edge if it didn't have competition. ___ 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: seems like I'm on the wrong track
From: Henning Thielemann lemm...@henning-thielemann.de Michael P Mossey schrieb: Perhaps someone could either (1) help me do what I'm trying to do, or (2) show me a better way. I have a problem that is very state-ful and I keep thinking of it as OO, which is driving me crazy. Haskell is several times harder to use than Python in this instance, probably because I'm doing it wrong. To give you a larger context, this problem is essentially compiling a description of music (my own) into a kind of music-machine-language (CSound). CSound is relatively untidy. There are currently two public interfaces to CSound: http://hackage.haskell.org/packages/archive/haskore/0.1/doc/html/Haskore-Interface-CSound.html http://hackage.haskell.org/package/hCsound Incidentally, these two packages serve very different purposes. hCsound is an interface to the Csound runtime API, while the Haskore interface is an EDSL front-end to Csound's own input format. There is very little overlap in functionality between the two. The Haskore interface is much closer to what Michael wants to do, but as he's commented already, it is a bit dated. hCsound is unlikely to be of much use for compiling a secondary language to csound code. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existencial Types
Dear Luke, thanks for your answers
If SelectScecario is used for other purposes, then give an explicit
cast function
Sure, as I mentioned, we have different transformations and it would be worth
to filter a list of transformations by a particular type or even apply the list
of transformations in a particular order considering their type.
toTransformation :: SelectScenario - Transformation
toTransformation (SelectScenario ids) = Transformation {
(+) = {- implementation of (+) just as if it were a class method -}
}
I understand your idea, but I will have to implement several variations of
toTransformation, one for each kind of transformation. Moreover, I couldn't
realize how is possible to define a function that could be applied to different
transformations without using type classes--- I have to restrict the
types of argument of such a function. Moreover, I couldn't figure out what are
the benefits of your solution. Please, if possible, could you elaborate
that a bit more, in order that I could understand why your design is better (I
mean, more legible, reusable or concise)?
Thanks in advance,
Rodrigo.
Em 01/12/2009 22:44, Luke Palmer lrpal...@gmail.com escreveu:
On Tue, Dec 1, 2009 at 4:21 PM, rodrigo.bonifacio
wrote:
Thanks Luke.
In fact I, will have different implementations of the Transformation type.
Something like:
data SelectScenarios = SelectScenarios {
scIds :: [Id]
}
What is this different type buying you? You can never downcast to it later.
And then I should be able to make SelectScenarios a kind of Transformation.
So I think that I really need a class. What do you think about it?
instance Transformation SelectScenario where
(+)
So instead of making a type and an instance, just implement it
directly as a Transformation:
selectScenario :: [Id] - Transformation
selectScenario ids = Transformation {
(+) = {- whatever implementation you gave for (+) above, using ids -}
}
If the only purpose of SelectScenario (your type) is to be used
polymorphically as a Transformation, then this approach is isomorphic
-- i.e. anything you can do with the existential type trick you can do
with this approach.
If SelectScecario is used for other purposes, then give an explicit
cast function
toTransformation :: SelectScenario - Transformation
toTransformation (SelectScenario ids) = Transformation {
(+) = {- implementation of (+) just as if it were a class method -}
}
Existential types only buy you power when the quantified variable
appears more than once on the right hand side, for example: forall a.
Num a = (a,a). But even those can usually be factored out into more
direct representations (I seem to recall Oleg has a proof that they
always can, actually).
Luke
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
On Thu, Dec 3, 2009 at 12:32 PM, Alec Berryman a...@thened.net wrote: Emmanuel CHANTREAU on 2009-12-03 13:03:02 +0100: In my futur program, it use a lot of binary trees with strings (words) as leaf. There is just arround 1000 words and they will appear a lot of times. The program will possibly consume a lot of process and memory (it is a mathematics proover). I began this program in C++ but haskell has a prety good speed and memory footprint and is easier. But I don't know if it worth to do this optimization: having a dictionary to translate string words in Int. The answer depends on the automatic optimizations in GHC, because GHC could compare quickely two strings if it is the same object, so it depends if program generated by GHC have a dictionary (tree) of strings internaly. Someone knows this ? I don't know of a library to intern strings, but it's not too hard to implement. I couldn't find the code I wrote to do this, but I looked around a bit and this is about what I remember doing: http://www.haskell.org/pipermail/haskell-cafe/2005-June/010335.html For the application I was using, interning strings did provide a significant reduction in memory, but for whatever reason didn't help with speed. I'd use a trie. Edison provides Data.Edison.Assoc.TernaryTrie, and there are a few other trie packages at hackage. -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
On Thu, Dec 3, 2009 at 6:28 AM, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Donnerstag, den 03.12.2009, 11:13 + schrieb Matthew Pocock: Perhaps what you are looking for is a more powerful defining semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo it goes into the right direction, but I’d also like to have this also capeable to derive single functions (giving them a new name), and not only class instances. Something like the restricted type synonym extension in Hugs? http://cvs.haskell.org/Hugs/pages/users_guide/restricted-synonyms.html -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Haskell a Fanatic?
John, Miguel (and others), Don Stewart wrote, the guarantees of purity the type system provides are extremely useful for verification purposes. My response to this is in theory. This is what caught my attention initially, but the language lacks polish and does not appear to be going in a direction where it shows signs where it will self-correct. It may even be beyond repair. I care about others and I don't want people to be misled. [...] The burden of proof is on you to demonstrate that it _is_. I admit it's tempting, but wouldn't you agree that, especially in this case, it's better not to feed the troll? Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
Thank you Sir for giving me a good laugh! On Thu, Dec 3, 2009 at 5:25 PM, John D. Earle johndea...@cox.net wrote: Dear Emmanuel Chantréau, You may want to look into Objective CAML http://caml.inria.fr/ which is a French product as you can see from the Internet address. It is likely better suited to the task than Haskell and has a reputation for speed. For those who prefer object oriented programming it has facilities for that which may ease your transition from C++. The Microsoft F# language is based on Objective CAML. Haskell has a problem with its type system and is not rigorous. Haskell is not a suitable language for proof assistants and so I would advise you to stay clear of Haskell. Standard ML was engineered with the needs of proof assistants in mind and so you may want to look into Standard ML, but you should be very happy with Objective CAML. It has an excellent reputation. The Coq proof assistant which is another French product is based on Objective CAML. If you do decide that Haskell is the way, it will help ease your transition to Haskell. There is nothing that says you can't keep your fingers in several pies at once. ___ 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: Implicit newtype unwrapping
I guess TH could probably do this. I think this does what you wish for: http://hackage.haskell.org/packages/archive/peakachu/0.2/doc/html/Data-Newtype.html Example: $(mkWithNewtypeFuncs [2] ''ZipList) withZipList2 (*) [(+3), (*3)] [6, 7] [9, 21] $(mkInNewtypeFuncs [2] ''ZipList) getZipList $ inZipList2 (++) (ZipList hello ) (ZipList world) hello world in some future this won't be in this unrelated peakachu package, and be incorporated into Neil M's derive. but for now this is where you can find it. cheers, Yair On Dec 3, 12:07 pm, Joachim Breitner m...@joachim-breitner.de wrote: Hi, Am Donnerstag, den 03.12.2009, 01:16 +0100 schrieb Martijn van Steenbergen: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? What advantages and disadvantages would it have? In what cases would this lead to ambiguous code? not sure if this is what you are thinking at, but everytime I wrap a type Foo in a newtype MyFoo to define my own instances (or just for more expressiveness code), I wish I had a way to tell the compiler: „Please define function myfoo to be the same as foo, with all occurences of Foo in its type signature replaced by MyFoo.“ Instead I find my self writing manually code like myfoo :: (Blubb - MyFoo) - MyFoo - MyFoo - MyFoo myfoo f (MyFoo a) (MyFoo b) = MyFoo (foo (unMyFoo . f) a b) I guess TH could probably do this. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de |http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc 1KViewDownload ___ Haskell-Cafe mailing list haskell-c...@haskell.orghttp://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] Card games
2009/12/3 Matthias Görgens matthias.goerg...@googlemail.com: Hi Tom, Did you make any progress on your Dominion quest? I guess you could start by modeling `Big Money' and add the other cards (and interaction) from there. No, I'm still trying to tune a partitionM function I wrote. (I'm still a beginner.) ^_^ I'd like to write a Dominion library or some more generic superset at some point, though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Optimization with Strings ?
Use makeStableName from System.Mem.StableName StableName`s are just for checking pointer equality. Instead of checking for equality of the strings, check for pointer equality of their stableNames a dirty way: pointerEq x y= unsafePerformIO $ do px - makeStableName x py - makeStableName y return x == y pEq x y | pointerEq x y == True = True | otherwise = x == y 2009/12/3 David Virebayre dav.vire+hask...@gmail.comdav.vire%2bhask...@gmail.com On Thu, Dec 3, 2009 at 1:03 PM, Emmanuel CHANTREAU echant+hask...@maretmanu.org echant%2bhask...@maretmanu.org wrote: In my futur program, it use a lot of binary trees with strings (words) as leaf. There is just arround 1000 words and they will appear a lot of times. The program will possibly consume a lot of process and memory (it is a mathematics proover). I began this program in C++ but haskell has a prety good speed and memory footprint and is easier. But I don't know if it worth to do this optimization: having a dictionary to translate string words in Int. The answer depends on the automatic optimizations in GHC, because GHC could compare quickely two strings if it is the same object, so it depends if program generated by GHC have a dictionary (tree) of strings internaly. Someone knows this ? It doesn't work this way : Strings are just lists of Chars. Comparison is made recursively, Char by Char. You can have a look at the source to make sure : instance (Eq a) = Eq [a] where [] == [] = True (x:xs) == (y:ys) = x == y xs == ys _xs== _ys= False So you will have to code your own optimisation. David. P.S. In French if you didn't understand: Ca ne marche pas comme ça. Les chaines de caractères ne sont que des listes de caractères. La comparaison sur les listes est faite récursivement, caractère par caractère, il suffit pour s'en assurer de regarder au source : Donc il vaut mieux que tu implémente ton propre dictionnaire. ___ 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] Optimization with Strings ?
You might want to check out the stringtable-atom and bytestring-trie packages; these are the packages to which I turn when I want to see if I can speed up my code by using a different data structure to map String's to values. Cheers, Greg On Dec 3, 2009, at 4:03 AM, Emmanuel CHANTREAU wrote: Hello In my futur program, it use a lot of binary trees with strings (words) as leaf. There is just arround 1000 words and they will appear a lot of times. The program will possibly consume a lot of process and memory (it is a mathematics proover). I began this program in C++ but haskell has a prety good speed and memory footprint and is easier. But I don't know if it worth to do this optimization: having a dictionary to translate string words in Int. The answer depends on the automatic optimizations in GHC, because GHC could compare quickely two strings if it is the same object, so it depends if program generated by GHC have a dictionary (tree) of strings internaly. Someone knows this ? (Sorry for my english, I'm french) thank you -- Emmanuel Chantréau ___ 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] Optimization with Strings ?
In fact, the correct answer is that pEqualsP should produce an error and qEqualsQ should never terminate ¿¿??? should? or you want to say actually do that so the optimization does is not done? The correct amswer is not the sould you mention, but True (IMHO). So the optimization can be done anyway. 2009/12/3 Neil Brown nc...@kent.ac.uk Emmanuel CHANTREAU wrote: Le Thu, 3 Dec 2009 13:20:31 +0100, David Virebayre dav.vire+hask...@gmail.comdav.vire%2bhask...@gmail.com a écrit : It doesn't work this way : Strings are just lists of Chars. Comparison is made recursively, Char by Char. You can have a look at the source to make sure : instance (Eq a) = Eq [a] where [] == [] = True (x:xs) == (y:ys) = x == y xs == ys _xs== _ys= False Hello Thank you David and Bulat for your answers. I don't see the proof you see. Because GHC could store two sames objects juste once and by the definition of == on lists it could deduce that forall x; List x = x==x. GHC have all informations to do this optimization job, because haskell functions definitions are mathematics definitions. Besides any other reasons, Haskell has the error function, and infinite lists. Consider: p :: String p = error Haha! q :: String q = repeat 'a' pEqualsP :: Bool pEqualsP = p == p qEqualsQ :: Bool qEqualsQ = q == q By your rule, pEqualsP and qEqualsQ should be True. In fact, the correct answer is that pEqualsP should produce an error and qEqualsQ should never terminate. Since Strings can contain such errors and infinite lists, you can't know for certain that an object equals itself without checking its entire length, which is what the original definition for equals did anyway. There may be strict data structures for which your optimisation might be applicable, though. Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Card games
Am Donnerstag 03 Dezember 2009 19:23:24 schrieb Tom Tobin: 2009/12/3 Matthias Görgens matthias.goerg...@googlemail.com: Hi Tom, Did you make any progress on your Dominion quest? I guess you could start by modeling `Big Money' and add the other cards (and interaction) from there. No, I'm still trying to tune a partitionM function I wrote. Maybe we can help? (I'm still a beginner.) ^_^ I'd like to write a Dominion library or some more generic superset at some point, though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Card games
Yah! We like helping! On Dec 3, 2009, at 2:37 PM, Daniel Fischer wrote: Am Donnerstag 03 Dezember 2009 19:23:24 schrieb Tom Tobin: 2009/12/3 Matthias Görgens matthias.goerg...@googlemail.com: Hi Tom, Did you make any progress on your Dominion quest? I guess you could start by modeling `Big Money' and add the other cards (and interaction) from there. No, I'm still trying to tune a partitionM function I wrote. Maybe we can help? (I'm still a beginner.) ^_^ I'd like to write a Dominion library or some more generic superset at some point, though. ___ 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] Implicit newtype unwrapping
On Thu, Dec 3, 2009 at 5:34 AM, Conor McBride wrote: http://www.haskell.org/pipermail/libraries/2008-January/008917.html On Tue, Jan 15, 2008 at 3:31 PM, Conor McBride wrote: Haskell's classes are the best damn rhythm section in the industry: you hum it, they play it. On Fri, Dec 10, 2004 at 2:21 AM, Conor McBride wrote: If you're willing to make the types distinguish the idioms you're using, as in choice-lists and vector-lists, then a lot of routine operations wither to a huddle of combinators sitting under a type signature which actually does most of the work. Instance inference is like having a great rhythm section: you hum it, they play it. Very eloquent Conor. Can we get this guy quoted in HWN? I think he's earned it. :-) On Thu, Dec 3, 2009 at 5:34 AM, Conor McBride wrote: class Newtype n where type Unpack n pack :: Unpack n - n unpack :: n - Unpack n Nice. Would the code below be a good way to deal with subtyping? It'd be convenient to have some way to go from a 64-bit Double to a 32-bit Float and be informed when a Double can't be represented precisely by a Float, but to have the option to move forward with the minor loss of precision. class Subset n where type Superset n demote :: Superset n - Either n n promote :: n - Superset n squeeze :: Subset n = Superset n - n squeeze = either id id . demote In action: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=13554#a13554 Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Haskell a Fanatic?
Am Donnerstag 03 Dezember 2009 19:14:40 schrieb Stefan Holdermans: John, Miguel (and others), Don Stewart wrote, the guarantees of purity the type system provides are extremely useful for verification purposes. My response to this is in theory. This is what caught my attention initially, but the language lacks polish and does not appear to be going in a direction where it shows signs where it will self-correct. It may even be beyond repair. I care about others and I don't want people to be misled. [...] The burden of proof is on you to demonstrate that it _is_. I admit it's tempting, but wouldn't you agree that, especially in this case, it's better not to feed the troll? To feed, or not to feed: that is the question: Whether 'tis nobler in the mind to suffer The quips and ramblings of outrageous trolling, Or to take arms against a sea of nonsense, And by opposing end them? Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Haskell a Fanatic?
Brilliant. Just brilliant. On 3 Dec 2009, at 22:54, Daniel Fischer wrote: Am Donnerstag 03 Dezember 2009 19:14:40 schrieb Stefan Holdermans: John, Miguel (and others), Don Stewart wrote, the guarantees of purity the type system provides are extremely useful for verification purposes. My response to this is in theory. This is what caught my attention initially, but the language lacks polish and does not appear to be going in a direction where it shows signs where it will self-correct. It may even be beyond repair. I care about others and I don't want people to be misled. [...] The burden of proof is on you to demonstrate that it _is_. I admit it's tempting, but wouldn't you agree that, especially in this case, it's better not to feed the troll? To feed, or not to feed: that is the question: Whether 'tis nobler in the mind to suffer The quips and ramblings of outrageous trolling, Or to take arms against a sea of nonsense, And by opposing end them? Cheers, Stefan ___ 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] Is Haskell a Fanatic?
I think you meant to say: Now is the winter of our discontent with this troll made glorious summer by this son of Fischer. So long as we bastardize the bard, we best bastardize him fully! :) /Joe On Dec 3, 2009, at 2:58 PM, Miguel Mitrofanov wrote: Brilliant. Just brilliant. On 3 Dec 2009, at 22:54, Daniel Fischer wrote: Am Donnerstag 03 Dezember 2009 19:14:40 schrieb Stefan Holdermans: John, Miguel (and others), Don Stewart wrote, the guarantees of purity the type system provides are extremely useful for verification purposes. My response to this is in theory. This is what caught my attention initially, but the language lacks polish and does not appear to be going in a direction where it shows signs where it will self-correct. It may even be beyond repair. I care about others and I don't want people to be misled. [...] The burden of proof is on you to demonstrate that it _is_. I admit it's tempting, but wouldn't you agree that, especially in this case, it's better not to feed the troll? To feed, or not to feed: that is the question: Whether 'tis nobler in the mind to suffer The quips and ramblings of outrageous trolling, Or to take arms against a sea of nonsense, And by opposing end them? Cheers, Stefan ___ 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] Card games
On Thu, Dec 3, 2009 at 1:37 PM, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Donnerstag 03 Dezember 2009 19:23:24 schrieb Tom Tobin: No, I'm still trying to tune a partitionM function I wrote. Maybe we can help? Sure; should I post it to haskell-beginners? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Card games
Am Donnerstag 03 Dezember 2009 21:24:11 schrieb Tom Tobin: On Thu, Dec 3, 2009 at 1:37 PM, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Donnerstag 03 Dezember 2009 19:23:24 schrieb Tom Tobin: No, I'm still trying to tune a partitionM function I wrote. Maybe we can help? Sure; should I post it to haskell-beginners? Here, there, most of us are subscribed to both lists. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Card games
On Thu, Dec 3, 2009 at 2:29 PM, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Donnerstag 03 Dezember 2009 21:24:11 schrieb Tom Tobin: On Thu, Dec 3, 2009 at 1:37 PM, Daniel Fischer daniel.is.fisc...@web.de wrote: Am Donnerstag 03 Dezember 2009 19:23:24 schrieb Tom Tobin: No, I'm still trying to tune a partitionM function I wrote. Maybe we can help? Sure; should I post it to haskell-beginners? Here, there, most of us are subscribed to both lists. I posted it to the beginners list, subject partitionM. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Haskell a Fanatic?
Daniel Fischer daniel.is.fisc...@web.de writes: To feed, or not to feed: that is the question: Out, out, brief troll! This is certainly a thread that's full of sound and fury, but (or so I'm afraid) signifying nothing. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
Hi, Am Donnerstag, den 03.12.2009, 13:03 -0500 schrieb David Menendez: On Thu, Dec 3, 2009 at 6:28 AM, Joachim Breitner m...@joachim-breitner.de wrote: Am Donnerstag, den 03.12.2009, 11:13 + schrieb Matthew Pocock: Perhaps what you are looking for is a more powerful defining semantics? newtype MyFoo = Foo defining (Foo(..)) -- all class instances that Foo has are delegated through from MyFoo it goes into the right direction, but I’d also like to have this also capeable to derive single functions (giving them a new name), and not only class instances. Something like the restricted type synonym extension in Hugs? http://cvs.haskell.org/Hugs/pages/users_guide/restricted-synonyms.html yes, this is very close to what I’d hope for. Last minor (but really minor) wish: I don’t think it would hurt to allow the use of this feature independent of the definition of the newtype: I could have a newtype Foo = Foo Int somewhere, possibly in a different module, and write something like myFoo :: Foo - (Foo,Foo) resolving Foo myFoo a = (a,a+a) (syntax and wording very ad hoc and not thought through). But yes, I think I’d be happy to have hugs’ extension here at hand sometimes. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implicit newtype unwrapping
On Wed, Dec 2, 2009 at 7:16 PM, Martijn van Steenbergen mart...@van.steenbergen.nl wrote: So here's a totally wild idea Sjoerd and I came up with. What if newtypes were unwrapped implicitly? As several have suggested, this creates ambiguity. But it might be handy to have a way to declare a scope in which the newtype is transparent. E.g., newtype N = N T f :: T - T - T f = ... open N in -- in this block, N is treated as a synonym for T g :: N - N - N g = f This is similar to the restricted type synonyms feature in Hugs, and I think it's straightforward to encode in GHC's System FC. From my perspective, the primary advantage to a feature like this is that it avoids the need to convert [N] to [T], which under the current system effectively requires mapping an identity function over the entire list. But that also exposes the danger of this idea, where GADTs and type families are involved. data G where A :: G N B :: G T a :: G N - N a ~A = N -- should never fail, because A is the only (non-bottom) value of type G N. Now, what stops me from writing something like this? open N in ... a B ... (See the discussion at http://hackage.haskell.org/trac/ghc/ticket/1496 for how this problem crops up with generalized newtype deriving.) -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implicit newtype unwrapping
Hi, Am Donnerstag, den 03.12.2009, 10:22 -0800 schrieb yair...@gmail.com: I guess TH could probably do this. I think this does what you wish for: http://hackage.haskell.org/packages/archive/peakachu/0.2/doc/html/Data-Newtype.html Example: $(mkWithNewtypeFuncs [2] ''ZipList) withZipList2 (*) [(+3), (*3)] [6, 7] [9, 21] $(mkInNewtypeFuncs [2] ''ZipList) getZipList $ inZipList2 (++) (ZipList hello ) (ZipList world) hello world in some future this won't be in this unrelated peakachu package, and be incorporated into Neil M's derive. but for now this is where you can find it. Nice, and close. It seems it does not handle the datatype in arbitrary positions in the type (as in Foo - ( a - Either Foo ())) - (Foo, ())). But thanks for the pointer. Maybe I should give it a shot. Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: error-message
If there is one thing that we really don't have enough of in Haskell, it is *ways to handle errors*! Thus, I am pleased to announce the release of the error-message package to help in filling this, erm, gap. This philosophy behind this package is that it is often better to find out all of the errors that have occured in a computation and report them simultaneously, rather than aborting as soon as the first error is encountered. Towards this end, this package supplies a type of /combinable error messages/ (ErrorMessage in the Data.ErrorMessage module) so that all of the errors from subcomputations can be gathered and presented together. The following provides an example of how these can be used: == sqrtWithError :: Float - Either ErrorMessage Float sqrtWithError x | x 0 = leftErrorMessageText (Error computing the square root of ++ (show x) ++ :) Square roots cannot be taken of negative numbers. | otherwise = Right (sqrt x) sumWithError :: Either ErrorMessage Float - Either ErrorMessage Float - Either ErrorMessage Float sumWithError (Left error1) (Left error2) = Left (error1 `mappend` error2) sumWithError (Left error) _ = Left error sumWithError _ (Left error) = Left error sumWithError (Right value1) (Right value2) = Right (value1 + value2) showSumOrErrorOf :: Float - Float - String showSumOrErrorOf x y = case sumWithError (sqrtWithError x) (sqrtWithError y) of Right value - The value is ++ show value Left error - show . formatErrorMessage $ error == The result of @showSumOrErrorOf (-1) (-2)@ is the string, Error computing the square root of -1: Square roots cannot be taken of negative numbers. Error computing the square root of -2: Square roots cannot be taken of negative numbers. whereas the result of @showSumOrErrorOf (-1) (-1)@ is the string, Error computing the square root of -1: Square roots cannot be taken of negative numbers. Note how the error message only appears once; this is because the process of combining the error messages automatically eliminates all identical headings under the assumption that they came from the same original computation, as was the case here. Currently, the definition of @sumWithError@ is largely boilerplate. Happily, the Haskell community has done a lot of work to identify patterns such as these and to write libraries that allow us to express them concisely. In particular, a standard trick when working with errors like this is to express the calculation as a 'Monad', such as by using the following definition: == sumWithError_2 argument1 argument2 = do value1 - argument1 value2 - argument2 return (value1 + value2) == Or, even more concisely: == sumWithError_3 = liftM2 (+) == Unfortunately though, neither of these definitions have the same semantics as the original @sumWithError@, as using both we get the following error message for @showSumOrErrorOf (-1) (-2)@: == Error computing the square root of -1: Square roots cannot be taken of negative numbers. == That is, we have lost the second of the two error messages. The reason for this is that 'Monad'-style error processing expresses the computation as a sequence, and gives up as soon as it sees any error. In this case of @sumWithError@, however, the evaluation of the second argument can proceed even if there was an error in the first argument. Thus, rather than using a 'Monad' pattern, we use an 'Applicative' pattern: == sumWithError_4 = liftA2 (+) == Now both error messages are displayed. Anyway, I hope that someone other than myself finds this pattern to be helpful. :-) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] New Hackage category: Error Handling
Hey everyone, When I uploaded my new package, error-message, I also went ahead and created a new category: Error Handling. I did this because there are a number of packages related to this issue, so it might be helpful to have them presented together in one place. Thus, if you have or are in the process of writing a package related to this, please consider adding it to this category sometime so that my package doesn't get lonely. :-) Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary and error handling
On Fri, Nov 27, 2009 at 10:36 PM, Mark Lentczner ma...@glyphic.com wrote:
I'm in the same quandary:
Data.Binary from the binary package has no error handling
Data.Serialize from the cereal package uses only strict ByteString
I was going to add error handling to Binary as a weekend project (it isn't
that hard), but when I contacted the developers of binary, I was pointed at
cereal. But as my project can parse multi-megabyte objects off the wire, I
really want lazy ByteString support.
I understand from the cereal creators that lazy ByteStrings are not in the
future of cereal, since they got a big speed boost by going to strict
ByteStrings only.
I understand that Bryan O'Sullivan might have done work on adding errors to
Binary... Bryan? If that's available, can we get it? If not, shall I do the
work to add error handling? It's a long weekend... I've got time!
As an experiment I ported error handling from cereal to binary. It
does work, passes all tests shipped
with binary. Perfomance became worse. According to benchmarks shipped
with binary I observed ~25%
perfomance drop. However when I ported my program I have 40% speedup.
I think it's because I removed
code which work around lack error handling and replaced with error
handling in Get monad
As for strictess concerns. Patch doesn't seem to change strictess from
current state. At least my program
which uses very big inputs works without any changes.
Comments and suggestions are welcome
diff -r 8cb04f000736 src/Data/Binary/Get.hs
--- a/src/Data/Binary/Get.hs Thu Dec 03 00:40:24 2009 +0300
+++ b/src/Data/Binary/Get.hs Fri Dec 04 01:24:19 2009 +0300
@@ -1,5 +1,6 @@
{-# LANGUAGE CPP #-}
{-# OPTIONS_GHC -fglasgow-exts #-}
+{-# LANGUAGE BangPatterns #-}
-- for unboxed shifts
-
@@ -26,6 +27,7 @@
-- * The Get type
Get
, runGet
+, runGetE
, runGetState
-- * Parsing
@@ -103,15 +105,23 @@
data S = S {-# UNPACK #-} !B.ByteString -- current chunk
L.ByteString -- the rest of the input
{-# UNPACK #-} !Int64 -- bytes read
+
+type Failure r = String - Either String (r, S)
+type Success a r = S - a - Either String (r, S)
--- | The Get monad is just a State monad carrying around the input ByteString
--- We treat it as a strict state monad.
-newtype Get a = Get { unGet :: S - (# a, S #) }
+-- | The Get monad is an Exception and State monad.
+newtype Get a = Get { unGet :: forall r. S
+- Failure r
+- Success a r
+- Either String (r, S) }
instance Functor Get where
-fmap f m = Get (\s - case unGet m s of
- (# a, s' #) - (# f a, s' #))
-{-# INLINE fmap #-}
+fmap p m = Get (\s0 f k - unGet m s0 f (\s a - k s (p a)))
+
+instance Monad Get where
+return a = Get (\s0 _ k - k s0 a)
+m = g = Get (\s0 f k - unGet m s0 f (\s a - unGet (g a) s f k))
+fail = failDesc
#ifdef APPLICATIVE_IN_BASE
instance Applicative Get where
@@ -119,29 +129,18 @@
(*) = ap
#endif
--- Definition directly from Control.Monad.State.Strict
-instance Monad Get where
-return a = Get $ \s - (# a, s #)
-{-# INLINE return #-}
-
-m = k = Get $ \s - case unGet m s of
- (# a, s' #) - unGet (k a) s'
-{-# INLINE (=) #-}
-
-fail = failDesc
-
-instance MonadFix Get where
-mfix f = Get $ \s - let (a,s') = case unGet (f a) s of
- (# a', s'' #) - (a',s'')
-in (# a,s' #)
+--instance MonadFix Get where
+--mfix f = Get $ \s - let (a,s') = case unGet (f a) s of
+-- (# a', s'' #) - (a',s'')
+--in (# a,s' #)
get :: Get S
-get = Get $ \s - (# s, s #)
+get = Get (\s0 _ k - k s0 s0)
put :: S - Get ()
-put s = Get $ \_ - (# (), s #)
+put s = Get (\_ _ k - k s ())
--
@@ -176,24 +175,40 @@
(x:xs') - S x (B.LPS xs')
#endif
+finalK :: Success a a
+finalK s a = Right (a, s)
+
+failK :: Failure a
+failK s = Left s
+
-- | Run the Get monad applies a 'get'-based parser on the input ByteString
runGet :: Get a - L.ByteString - a
-runGet m str = case unGet m (initState str) of (# a, _ #) - a
+runGet m str = case unGet m (initState str) failK finalK of
+ Right (a, _) - a
+ Left message - error message
-- | Run the Get monad applies a 'get'-based parser on the input
-- ByteString. Additional to the result of get it returns the number of
-- consumed bytes and the rest of the input.
runGetState :: Get a - L.ByteString - Int64 - (a, L.ByteString, Int64)
runGetState m str off =
-
Re: [Haskell-cafe] Finding HP
It would perhaps be better to have one nice big Download button that takes you to a separate download page. Having a single download link that only points to the Haskell Platform would be a bit of a policy shift. ... but that was *not* what was suggested. The suggestion was to have a single Download button, leading to a *page* of suitably described links, allowing the user to choose whether they only wanted the basics (a choice of compiler/interpreter + cabal), or the whole Platform, or something else. It would be the ideal place to explain what cabal is and how to use hackage to get more libraries than are contained in the platform. It would perhaps reduce the clutter on the front page that some people complained of (although I don't personally think it cluttered). Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Finding HP
malcolm.wallace: The suggestion was to have a single Download button, leading to a *page* of suitably described links, allowing the user to choose whether they only wanted the basics (a choice of compiler/interpreter + cabal), or the whole Platform, or something else. It would be the ideal place to explain what cabal is and how to use hackage to get more libraries than are contained in the platform. It would perhaps reduce the clutter on the front page that some people complained of (although I don't personally think it cluttered). Sounds great! Can someone prepare such a page, please. The wiki should be directly editable. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] SYB looping very, very mysteriously
I have the following program which loops under GHC 6.10.4:
http://www.hpaste.org/fastcgi/hpaste.fcgi/view?id=13561#a13561
{-# LANGUAGE DeriveDataTypeable, FlexibleInstances,
MultiParamTypeClasses, UndecidableInstances #-}
module Main where
import qualified Data.Data as Data
import Data.Typeable (Typeable)
import Happstack.Data.Default
import Data.Generics.SYB.WithClass.Basics
import Data.Generics.SYB.WithClass.Instances ()
data Proposition = Proposition Expression deriving (Show, Data.Data,
Typeable)
data Expression = Conjunction (Maybe Expression) deriving (Show,
Data.Data, Typeable)
-- instance (Sat (ctx [Expression]), Sat (ctx Expression), Sat (ctx
Proposition)) = Data ctx Proposition where
instance Data DefaultD Proposition where
gunfold _ k z c =
case constrIndex c of
1 - k (z Proposition)
instance Default Proposition
constrExpr :: Constr
constrExpr = mkConstr dataTypeExpr Conjuction [] Prefix
dataTypeExpr :: DataType
dataTypeExpr = mkDataType Expression [constrExpr]
instance ( Data ctx [Expression]
, Sat (ctx Expression)
, Sat (ctx (Maybe Expression))) = Data ctx Expression where
{-
instance Data DefaultD Expression where
-}
gunfold _ k z c =
case constrIndex c of
1 - k (z Conjunction)
dataTypeOf _ _ = dataTypeExpr
instance Default Expression
e :: Expression
e = defaultValueD dict
main = print e
I wish to explain the *many* ways in which it is mysterious. If you
load the program into GHCi and evaluate 'e' it will hang. If you
compile the program and run it, it will output loop. This behavior
seems annoying, but not very weird. But, here is where it gets fun:
1. if you load the program into GHCi and eval 'e' it will hang. But,
if you load the program and type, '(defaultValueD dict) :: Expression'
at the prompt, it works fine!
2. if you remove the (Data DefaultD Proposition) instance, it works
fine. (Even though Expression does not refer to Proposition in any way)
3. if you simply change the definition of 'gunfold' in the 'Data ctx
Proposition' instance to, error foo. The application works fine.
That's right, if you change the body of a function that isn't even
being called, evaluating 'e' starts working. (Even though Expression
does not refer to Proposition in any way. And even though that gunfold
instance is never actually called).
4. if you change the constraint on, Data ctx Expression, from (Data
ctx [Expression]) to (Data ctx Expression) it works fine. (Or remove
it all together).
5. if you change 'instance (Data DefaultD Proposition) where' to the
line above it which is commented out, it works fine.
6. if you change the type of Proposition to, data Proposition =
Proposition (Expression, Expression), then it works fine.
So far I have only tested this in GHC 6.10.4.
Any idea what is going on here? I can't imagine how changing the body
of functions that aren't being called would fix things...
- jeremy
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] happstack homepage
Hello, See this thread, http://groups.google.com/group/happs/browse_thread/thread/6e4d6af0109cc649 - jeremy On Dec 3, 2009, at 9:30 AM, Roel van Dijk wrote: I noticed that happstack.com and tutorial.happstack.com are both equal to patch-tag.com. Google's cache has the original pages. Is this the result of some misconfiguration or something else? I want to play with happstack and this is a slight inconvenience. On the other hand, all happstack packages build without problems so I'll build the tutorial locally and work from there. Regards, Roel ___ 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] Is Haskell a Fanatic?
To feed, or not to feed: that is the question: Whether 'tis nobler in the mind to suffer The quips and ramblings of outrageous trolling, Or to take arms against a sea of nonsense, And by opposing end them? Brilliant. Just brilliant. +1 Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is Haskell a Fanatic?
So long as we bastardize the bard, we best bastardize him fully! :) If only we could claim: Though this be madness, yet there is method in 't. Cheers, Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Wikipedia article
As noted before, the Wikipedia article for Haskell is a disorganised mess. http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 earlier this year, dons suggested reorganising it and posted a template on the Haskell wiki: http://haskell.org/haskellwiki/WikipediaArticleDesign I've made a start on a new version of the page: http://en.wikipedia.org/wiki/User:Simonmar/Haskell_%28programming_language%29 I've kept most of the existing information, but reorganised it more or less according to Don's template, and I filled out the overview section. Also I fixed numerous things, but the page still has a long way to go Does anyone mind if I spam the existing Haskell article with this new one, or do people think we should continue editing the sandbox version until it's in better shape? Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Wikipedia article
marlowsd: As noted before, the Wikipedia article for Haskell is a disorganised mess. http://en.wikipedia.org/wiki/Haskell_%28programming_language%29 earlier this year, dons suggested reorganising it and posted a template on the Haskell wiki: http://haskell.org/haskellwiki/WikipediaArticleDesign I've made a start on a new version of the page: http://en.wikipedia.org/wiki/User:Simonmar/Haskell_%28programming_language%29 I've kept most of the existing information, but reorganised it more or less according to Don's template, and I filled out the overview section. Also I fixed numerous things, but the page still has a long way to go Does anyone mind if I spam the existing Haskell article with this new one, or do people think we should continue editing the sandbox version until it's in better shape? Maybe we should make the switch, and move the old page into some historical section. That's more likely to ensure the page gets filled out... Gwern, other wikipedians, thoughts? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implicit newtype unwrapping
Hi,
Am Donnerstag, den 03.12.2009, 22:39 +0100 schrieb Joachim Breitner:
Nice, and close. It seems it does not handle the datatype in arbitrary
positions in the type (as in Foo - ( a - Either Foo ())) - (Foo,
())). But thanks for the pointer. Maybe I should give it a shot.
I started to write a module. My (incomplete!) code looks like this:
=
{-# LANGUAGE PatternGuards #-}
module OpenNewtype (openNewType) where
import Debug.Trace
import Language.Haskell.TH
import Data.Monoid
import qualified Data.Map as M
openNewtype typeName declsQ = do
info - reify typeName
decls - declsQ
tmpName1 - newName x
tmpName2 - newName x
-- Check if the given type is really a simple newtype
case info of
TyConI (NewtypeD _ _ _ (NormalC constr [(NotStrict,ConT
realType)]) _)
- let types = getTypeMap decls
in return $ map (go constr tmpName2 tmpName2
realType types) decls
_ - error $ openNewType can only handle siple newtype
defined types\nArgument was: ++ pprint info
where go constr tmpName1 tmpName2 realType types d = case d of
(ValD (VarP name) _ _) - FunD name [Clause [] (NormalB (wrap
name types)) [d]]
(FunD name _) - FunD name [Clause [] (NormalB (wrap
name types)) [d]]
_ - d
where wrap name types | Just t - M.lookup name types = wrapCo (VarE
name) t
| otherwise = (VarE name)
wrapCo exp (ConT t) | t == typeName =
inject exp
| otherwise =
exp
wrapCo exp (ForallT _ _ t)=
wrapCo exp t
wrapCo exp (VarT _) =
exp
wrapCo exp (TupleT _) =
exp
wrapCo exp (ArrowT) =
exp
wrapCo exp (ListT)=
exp
wrapCo exp (AppT (AppT ArrowT t1) t2) =
LamE [VarP tmpName1] (wrapCo (AppE exp (wrapCon (VarE
tmpName1) t1)) t2)
wrapCon exp (ConT t) | t == typeName =
unwrap exp
| otherwise =
exp
wrapCon exp (ForallT _ _ t)=
wrapCo exp t
wrapCon exp (VarT _) =
exp
wrapCon exp (TupleT _) =
exp
wrapCon exp (ArrowT) =
exp
wrapCon exp (ListT)=
exp
wrapCon exp (AppT (AppT ArrowT t1) t2) =
LamE [VarP tmpName1] (wrapCon (AppE exp (wrapCo (VarE
tmpName1) t1)) t2)
inject :: Exp - Exp
inject e = AppE (ConE constr) e
unwrap :: Exp - Exp
unwrap e = LetE [ValD (ConP constr [VarP tmpName2]) (NormalB e)
[]] (VarE tmpName2)
getTypeMap :: [Dec] - M.Map Name Type
getTypeMap = mconcat . map go
where go (SigD name t) = M.singleton name t
go _ = mempty
=
And the intended usage would be
=
{-# LANGUAGE TemplateHaskell #-}
import OpenNewtype
newtype Foo = Foo Int deriving Show
$(openNewtype ''Foo [d|
nullFoo :: Foo
nullFoo = 0
{-
toFoo :: Int - Foo
toFoo = id
fromFoo :: Foo - Int
fromFoo = id
-}
succFoo :: Foo - Foo
succFoo = succ
addFoo :: Foo - Foo - Foo
addFoo a b = a + b
|] )
main = do
print (succFoo (Foo 1))
=
And indeed, it works for null, succFoo, addFoo. The generated code looks
like this, for example for succfoo:
succFoo :: Main.Foo - Main.Foo
succFoo = \ x[a28u]
- Main.Foo (succFoo (let Main.Foo x[a28v] = x[a28u] in
x[a28v]))
where
succFoo = GHC.Enum.succ
But when I uncommented the definition of toFoo and fromfoo, I got:
Demo.hs:11:9:
Couldn't match expected type `Foo' against inferred type `Int'
In the expression: id
In the definition of `toFoo': toFoo = id
In the second argument of `openNewtype', namely
`[d| nullFoo :: Foo
nullFoo = 0
toFoo :: Int - Foo
toFoo = id
|]'
And just now, after writing half the code, I find out that $( fun
[d|...|] ) runs the type
Re: [Haskell-cafe] Are there standard idioms for lazy, pure error handling?
Duncan Coutts wrote: I've got an open mind on the suggestion to amalgamate the two ways the list could end. I'm not especially in favour of generalising for the sake of generalising, especially if it looses the connection to the notion of annotating your ordinary data structure with extra errors. If I effectively always have to use an Either for the final value then perhaps it does not buy anything and just makes the folds uglier (since it might loose the connection with the ordinary fold). But it could make even that use case simpler so it's worth looking at in a few examples (eg the tar package). These days I view folds as automatically defined by the data type, so I don't see any reason (on those grounds) to want to compare it to lists' foldr as opposed to any other arbitrary catamorphism. One reason to prefer a single basis is that it simplifies the ability to do concatenation and the associated fusion. It still only has one termination point (unlike trees) so it's still possible to do augment fusion. But because there are two bases, concatenation needs to look like this: concat2 :: T a b - (b - T a b) - T a b - T a b Whereas for the version with no Nil, it's just: concat1 :: T a b - (b - T a b) - T a b As for the usage, we'd be comparing these two: concat2 foo handler bar concat1 foo (maybe bar handler) One of the nice things about not having a Nil is that it lets you easily be polymorphic over things ending in () ---a normal list---, (Maybe a) ---a fallible list---, (Either a b) ---your progress type---, etc. Whereas the version that has both Nil and End forces us into the (Maybe a) scenario. A side effect of this is that the (Either a b) option isn't available because we can only construct t=Mx.(x*t)+(1+a+b) not t=Mx.(x*t)+(a+b). -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Beginner's speed problem
Am Donnerstag 03 Dezember 2009 06:52:01 schrieb Aditya M:
Hello
Thanks for all the help!
I only have a couple of questions.
On Thu, Dec 3, 2009 at 03:45, Daniel Fischer daniel.is.fisc...@web.de wrote:
Am Mittwoch 02 Dezember 2009 22:44:01 schrieb Don Stewart:
aditya87:
Hi,
I am trying to solve this problem:
https://www.spoj.pl/problems/LASTDIG/ It is very simple. Given a and
b, return the last digit of a^b. b could be large, so I used
logarithmic exponentiation and
Just to mention it, you can do something much much faster for this
problem. Something in the microsecond range (if IO is fast enough,
millisecond otherwise).
I guess you mean that we can find the cycle that the last digits
follow while multiplying repeatedly by a, and then use that.
Yes. Except there's not much finding to be done, you can pretty much write it
down
immediately.
But I underestimated the slowness of String IO, so it's not gaining you
terribly much
unless you resort to ByteString IO.
As an indication, for files containing 20.9 million, 2.85 million, 25942 (a,b)
pairs
respectively:
ByteString + shortcut: 4.6 seconds, 0.66 seconds, 0.00 seconds
ByteString + modular exponentiation: 49.2 seconds, 6.74 seconds, 0.06 seconds
String + shortcut: 262 seconds, 35.04 seconds, 0.33 seconds
String + modular exponentiation: 303 seconds, 40.73 seconds, 0.38 seconds
(Note: I have tweaked the String IO, using
main = fmap lines getContents = putStr . unlines . (map doit) . tail
and modified doit (returns a String now, is a little stricter, calls words line
only once;
also read - for the base, I use (digitToInt . last), it's much faster than read)
1. With replicateM n getLine or sequence $ take n $ repeat getLine, the
entire input
must be read in before processing can start. Firstly that's slower and secondly
it needs a
lot of memory - more than I have, for the larger files.
2. (putStr . unlines) is faster than mapM_ putStrLn.
It could be tweaked more, but that wouldn't gain nearly as much as switching to
ByteString.)
So with String IO, in either method the overwhelming part of the time is used
for IO (and
read), in comparison, the algorithmic difference pales. With ByteString IO, the
algorithmic difference stands out.
I'll try that next in Haskell!
{-# LANGUAGE BangPatterns #-}
lastdigit :: Int - Int - Int - Int
lastdigit 0 0 _ = 1
lastdigit a b !c | even b = lastdigit ( (a*a) `rem` 10 ) (b
`quot` 2) c
| b == 1 = (a*c) `rem` 10
However,
| otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) (a*c)
This bang pattern (!c) is giving me pattern match errors.
??? without the LANGUAGE pragma, it would give a parse error, so you can't have
forgotten
that. But in
lastdigit :: Int - Int - Int - Int
lastdigit 0 0 _ = 1
lastdigit a b !c
| even b = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) c
| b == 1 = (a*c) `rem` 10
| otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) ((a*c) `rem` 10)
there is simply no possibility for a pattern match error (other than having one
argument
bottom). I'm flabbergasted.
Is its only effect evaluating c instead of plain substitution?
Yes, it keeps c evaluated instead of building a thunk. You can get pretty much
the same
effect by having
lastdigit :: Int - Int - Int - Int
lastdigit 0 0 _ = 1
lastdigit a b c
| even b = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) c
| b == 1 = (a*c) `rem` 10
| otherwise = lastdigit ( (a*a) `rem` 10 ) (b `quot` 2) $! ((a*c) `rem` 10)
using strict application on the last argument when it is modified.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
It would be fantastic to have a little practical real-world challenge (like building a simple music system, or a simple multi-channel sound mixer), and work this out in an imperative language, an object-oriented language, a functional language, and maybe other languages too, like logic languages or constraint languages (does the latter exist?) There are some constraint languages. But I do not know whether they are general purpose (or even Turing complete). I have used ZIMPL, which is a language for specifying mixed integer linear optimization problems (which is somewhat related to constraint programming). Though it would not be useful for a music system. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
David Menendez wrote: Alec Berryman wrote: I don't know of a library to intern strings, but it's not too hard to implement. I couldn't find the code I wrote to do this, but I looked around a bit and this is about what I remember doing: http://www.haskell.org/pipermail/haskell-cafe/2005-June/010335.html For the application I was using, interning strings did provide a significant reduction in memory, but for whatever reason didn't help with speed. I'd use a trie. Edison provides Data.Edison.Assoc.TernaryTrie, and there are a few other trie packages at hackage. One of those: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bytestring-trie also uses ByteStrings instead of Strings. This will further reduce your memory footprint and will improve performance (because of cache consistency, less pointer chasing, and using C's fast string comparison function). I've been meaning to write a ByteString interning library on top of it, but haven't found the time just yet. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Optimization with Strings ?
On Thu, Dec 3, 2009 at 12:21 PM, Alberto G. Corona agocor...@gmail.com wrote: In fact, the correct answer is that pEqualsP should produce an error and qEqualsQ should never terminate ¿¿??? should? or you want to say actually do that so the optimization does is not done? The correct amswer is not the sould you mention, but True (IMHO). So the optimization can be done anyway. No, the correct answer is actually _|_. Returning True would violate referential transparency: p = [1..] Now suppose p == p returned True. Then we can substitute any name for its value, by ref trans. So p == [1..] should also return True. This is reasonable. However, it is possible to prove (outside Haskell, but still rigoroously in terms of its semantics) that [1..] = fix (\xs - 1 : map (+1) xs). So p == fix (1 : map (+1) xs) should also return True. This is getting unreasonable. Such an expectation would seem to require (==) to do a comprehensive proof search. Luke 2009/12/3 Neil Brown nc...@kent.ac.uk Emmanuel CHANTREAU wrote: Le Thu, 3 Dec 2009 13:20:31 +0100, David Virebayre dav.vire+hask...@gmail.com a écrit : It doesn't work this way : Strings are just lists of Chars. Comparison is made recursively, Char by Char. You can have a look at the source to make sure : instance (Eq a) = Eq [a] where [] == [] = True (x:xs) == (y:ys) = x == y xs == ys _xs == _ys = False Hello Thank you David and Bulat for your answers. I don't see the proof you see. Because GHC could store two sames objects juste once and by the definition of == on lists it could deduce that forall x; List x = x==x. GHC have all informations to do this optimization job, because haskell functions definitions are mathematics definitions. Besides any other reasons, Haskell has the error function, and infinite lists. Consider: p :: String p = error Haha! q :: String q = repeat 'a' pEqualsP :: Bool pEqualsP = p == p qEqualsQ :: Bool qEqualsQ = q == q By your rule, pEqualsP and qEqualsQ should be True. In fact, the correct answer is that pEqualsP should produce an error and qEqualsQ should never terminate. Since Strings can contain such errors and infinite lists, you can't know for certain that an object equals itself without checking its entire length, which is what the original definition for equals did anyway. There may be strict data structures for which your optimisation might be applicable, though. Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I miss OO
When OO is about constructing a machine and talking about objects, and FP is about making little algebraic languages, what would C or Pascal be like? In these languages, you don't think about objects, but you don't think about an algebra either? It's been a very long time since I worked with these languages, but as far as I recall, I started thinking about data structures and procedures operating on these data structures, which sounds a look like making ADTs and functions/operations on these... So this sounds odd, because it would mean that C and Pascal are in a sense closer to FP than OO is? You are working with state all the time in C and Pascal. Perhaps a C with a garbage collector would be closer to FP, because you could construct new structures all the time without worrying about memory leaks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
