December 2009 - Haskell-Cafe

Re: [Haskell-cafe] Implicit newtype unwrapping
by John D. Earle 03 Dec '09

03 Dec '09

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.

1 0

On the Meaning of Haskell 8
by John D. Earle 03 Dec '09

03 Dec '09

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.

1 0

Haddock Secrets?
by Gregory Crosswhite 03 Dec '09

03 Dec '09

Hey everyone, 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! I am doing this on OSX Snow Leopard with GHC 6.10.4 and Haddock 2.5. Thanks, Greg

2 1

Re: [Haskell] Interesting experiences of test automation in Haskell? Automation of Software Test 2010
by Tom Hawkins 03 Dec '09

03 Dec '09

On Fri, Nov 27, 2009 at 9:30 PM, John Hughes <rjmh(a)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 = 40000 pass: stateTransitionTest cycles = 75000 pass: swashCmdInBootstrapTest cycles = 40000 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: pumpSpeedAboveRangeLDisengagementTest cycles = 35000 pass: pumpSpeedAboveRangeHDisengagementTest cycles = 35000 pass: accumOverPressureBoundaryDisengagementTest cycles = 35000 pass: accumOverPressureAboveRangeDisengagementTest cycles = 35000 pass: filterPressureBelowRangeDisengagementTest cycles = 35000 pass: filterPressureAboveRangeDisengagementTest cycles = 35000 pass: 5VSupplyBelowRangeDisengagementTest cycles = 35000 pass: 5VSupplyAboveRangeDisengagementTest cycles = 35000 pass: 12VSupplyBelowRangeDisengagementTest cycles = 35000 pass: 12VSupplyAboveRangeDisengagementTest cycles = 35000 pass: stuckEngagedDisengagementTest cycles = 35000 pass: stuckOilLevelDisengagementTest cycles = 35000 pass: clutchdisengagementFaultTest cycles = 40000 pass: clutchSensorMiscompareFault cycles = 40000 pass: clutchSensorMiscompareFaultAbovePumpSpeedandabsRangeTest cycles = 40000 pass: clutchSensorMiscompareFaultAbovePumpSpeedandBelowabsRangeTest cycles = 40000 pass: clutchSensorMiscompareFaultBoundaryTest cycles = 40000 pass: clutchSensorMiscompareFaultAboveRangeTest cycles = 40000 pass: unexpectedDisengagementTest cycles = 40000 pass: failedEngagementAttemptsTest cycles = 40000 pass: fanOffTest cycles = 30000 pass: evuTest cycles = 30000 pass: swashCalTest cycles = 40000 pass: seedKey32Test1 cycles = 100 pass: seedKey32Test2 cycles = 100 pass: seedKey32Test3 cycles = 100 pass: seedKey32Test4 cycles = 100 pass: seedKey32Test5 cycles = 100 pass: seedKey32Test6 cycles = 100 pass: seedKey32Test7 cycles = 100 Total Passing Tests : 90 / 90 Total Simulation Cycles : 2650700 Total Function Coverage : 102 / 102 GREEN LIGHT > > So how about it? It would be great to see some Haskell papers at the > workshop! Deadline 20 January. > > John Hughes > > PS Check out the ICSE web site for information on the location: > http://www.sbs.co.za/ICSE2010/ > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell > >

1 0

Existencial Types
by rodrigo.bonifacio 02 Dec '09

02 Dec '09

4 6

O(n) algorithm for determining subset
by Michael Mossey 02 Dec '09

02 Dec '09

Can someone tell me if this is correct. I'm guessing that if I represent two sets of integers by Word32 (where ith bit set means i is in the set), then an algorithm to determine if x is a subset of y would go something like (y - x) == (y `exclusiveOr` x)

7 11

Type synonym family inside type class
by Martijn van Steenbergen 02 Dec '09

02 Dec '09

Hello, I have a type family and a type class: > type family ErrorAlg (f :: (* -> *) -> * -> *) e ix :: * > class MkErrorAlg f where > mkErrorAlg :: ErrorAlg f e a -> f (K0 a) ix -> Either e a Instances for these two really go hand in hand, so I thought I would move the type family into the type class. However, this causes GHC to complain about the type variables that are bound on the LHS of the type synonym: > Not in scope: type variable `e' > Not in scope: type variable `ix' In function types, using new type variables (i.e. type variables not bound by the type class header) implicitly means universal quantification over these variables. Why is this disallowed in type families inside type classes? Thanks, Martijn.

3 3

Ord k => Data.Set.Set k -> (k->v) -> Data.Map.Map k v
by Matthias Görgens 02 Dec '09

02 Dec '09

I feel that Data.Set and Data.Map should be working together more closely. For example you can already get the keyset of a Map, but the `other way' is not built-in. I mean a function with a signature like Ord k => Data.Set.Set k -> (k->v) -> Data.Map.Map k v You can implement it in O(n): > assoc :: (a->b) -> [a] -> [(a,b)] > assoc f = map (\x -> (x, f x)) > mapToMap :: Ord k => (k -> v) -> Data.Set.Set k -> Data.Map.Map k v > mapToMap f = Data.Map.fromAscList . assoc f . Data.Set.toAscList The name assoc alludes to the assoc-lists of Lisp.

1 0

Building network package on Windows
by Iavor Diatchki 02 Dec '09

02 Dec '09

Hi, I have been trying to build the package "network" from hackage (version 2.2.1.3) on Windows Vista, and I could really use some help. Building on the command line, or under cygwin completely failed (command line due to cabal not being able to execute something---possibly configure---although it would not say; cygwin first due to lack of gcc, which is tested but, apparently, the outcome ignored, and after gcc was installed some incompatibility with the header files which were detected but reported unusable). I managed to build the library under MinGW with msys without serious obstacles. I can also build my package against the result and all is well. Unfortunately, if I try to use my package to build an executable application I get a linker error, reporting a missing symbol during linking: C:\Users\diatchki\AppData\Roaming\cabal\network-2.2.1.3\ghc-6.10.3/libHSnetwork-2.2.1.3.a(Socket.o):fake:(.text+0xb014): undefined reference to `getnameinfo' collect2: ld returned 1 exit status Now, "getnameinfo" is present in the header files, and it is also defined in the library ws2_32.a which is being passed to GHC so I am not sure what is going on. Any ideas? Searching the web suggests that the problem may be somehow related to the standard calling conventions but I don't really understand. Also, if I understand correctly, this functionality is related to IPv6 support, which I do not need at the moment, so it would be great if it could be easily disabled in some way. Any ideas, suggestion, workarounds, etc. would be greatly appreciated, -Iavor PS: I am using GHC 6.10.3

5 9

KiCS (Curry to Haskell interpreter) problem
by Bernd Brassel 02 Dec '09

02 Dec '09

> I am playing around with KiCS and I have a strange problem, when I > evaluate a goal the variable bindings are not displayed, I see only > the value of the expression. The idea is, that you decide yourself which bindings you want to see. For example, you write (let x free in (not x,x)) to get (True,False) More? (False,True) More? No more solutions > I would have contacted the author but his email in not in the haskell > cabal file. Thanks for the hint. I have added my mail now and will do another update in a few weeks. Meanwhile, anyone interested in the system can contact me directly under "bbr at informatik.uni-kiel.de" Thanks for your interest in kics! Bernd

1 0