- Haskell-Cafe - Haskell.org

DiffTime in Data.Time
by Chad Scherrer 03 Oct '06

03 Oct '06

I'm trying to use Data.Time, and I'm totally confused. DiffTime is abstract, and I don't see anything that maps into it. How do I construct one? I would like to then use the result to create a value of type UTCTime, but it seems (currently) like this might be easier. Thanks, -- Chad Scherrer "Time flies like an arrow; fruit flies like a banana" -- Groucho Marx

2 2

oddity with profiling
by Matthias Fischmann 02 Oct '06

02 Oct '06

hi, i have been staring at a strange profile for a while now, and was wondering whether anybody could give me a hint. (using ghc.6.4. i know i should upgrade, but has the profiler changed after that in particular?) almost all time / memory costs occurs in a CAF cost center. as far as i understand, this means that the evaluation only takes place once each time i run the program, and doesn't depend on the input. Q1. why should one distinguish time spent in top-level constants from time spent in functions? (my program is basically a top-level constant that calls a function i am trying to understand with constant toy arguments.) curiously, the costs inherited by the CAF cost center and caused elsewhere do not show anywhere else, although i am pretty sure the call stack doesn't leave my code for another few levels. Q2. how can i learn which parts of my code causes the CAF cost centers to bloat? and what does it mean if the 100% inherited costs do not show in any other item in the cost center stack in my profile? user manual yields further confusion: | The cost of evaluating any expression in your program is attributed to | a cost-centre stack using the following rules: | | * If the expression is part of the one-off costs of evaluating the | enclosing top-level definition, then costs are attributed to the stack | of lexically enclosing SCC annotations on top of the special CAF | cost-centre. how can an expression be part of the one-off cost of anything? does the second part mean that the SCC annotations are on top of the special CAF cost-center? which is the special CAF cost-center? what does being on top of that mean? sorry, maybe i am just tired... :-/ | * Otherwise, costs are attributed to the stack of | lexically-enclosing SCC annotations, appended to the cost-centre stack | in effect at the call site of the current top-level | definition[7]. Notice that this is a recursive definition. | | * Time spent in foreign code (see Chapter 8, Foreign function | interface (FFI) ) is always attributed to the cost centre in force at | the Haskell call-site of the foreign function. thanks, matthias

1 0

How can I redirect stdout?
by Matthew Bromberg 02 Oct '06

02 Oct '06

I'm reposting this in it's own new thread since I think it involves a general issue beyond exporting Haskell DLLs. I am having some problems with GHCs stdout when a Haskell program is called from a windows program. As I noted earlier I am calling some Haskell code from C as a bridge to being able to ultimately call Haskell from Matlab 6.5. The Haskell code is compiled into a .DLL file on a windows machine. Matlab calls some C code which then calls the Haskell code. As soon as it gets into the Haskell code I get this run time error in ghcDLL.dll <stdout>: hPutChars: invalid argument (Bad File Descriptor) The Haskell code seems to work correctly if called from a stand-alone C program. Moreover, if I scrub all print statements from the Haskell code, it appears to run correctly from Matlab. Matlab does not properly redirect stdout so any printf calls from the C code simply fail to print. However Haskell's behavior is to halt after generating a runtime error. The C code used to generate the Haskell .dll is of course mingw gcc, but the C code used to create my Matlab mex file is Microsoft VC++ 6.0. I tried to redirect stdout using freopen() in C, but that never seems to work with Microsoft. At any rate it certainly doesn't effect Haskells use of stdout. I think in general for windows programs there is no stdout defined, whereas it's always defined for console programs. My question is, is there some way I can redirect stdout from inside Haskell so that all output is sent to a file? Is there an equivalent of freopen() in Haskell that works?

3 2

Problematic irrefutable pattern matching of existentials
by oleg＠pobox.com 02 Oct '06

02 Oct '06

I have come to realize that irrefutable pattern matching of existentials may indeed be problematic. Let us consider the following existential data type > data FE = forall a. Typeable a => Foo a > | forall a. Typeable a => Bar a The following tests type and run (the latter raising the expected exception). > test1 = case (Foo ()) of Foo x -> show $ typeOf x > test2 = case (Bar True) of Foo x -> show $ typeOf x Let us suppose that irrefutable pattern matching of existentials is allowed. What would be the value of the expression case (Bar True) of ~(Foo x) -> show $ typeOf x then? Hopefully not "Bool". One might say that the expression ought to bottom out. However, what reason one may give for that outcome? The only binding in the above expression is of 'x', whose value is never demanded. Indeed, "show $ typeOf (undefined :: ())" yields the non-bottom value "()". One may claim that the existential pattern match also binds an implicit dictionary argument, which is demanded above. That explanation is quite unsatisfactory, because it breaks the abstraction of type classes. The dictionary passing is merely an _implementation technique_ for type classes. Furthermore, it is not the only implementation technique: JHC and Chameleon, for example, use intensional type analysis to implement typeclasses. On a different note, Conor McBride wrote: > It isn't necessary to perform > constructor discrimination when it's statically known that exactly one > constructor is possible, so those patterns can always be made > irrefutable, with matching replaced by projection. that is, in essence, the idea behind `Tagless Staged Interpreters for Typed Languages' Pasalic, Taha, Sheard: ICFP02 It is well-written paper, with an excellent introduction and motivation. Incidentally, one can write their tagless staged interpreter in Haskell as it is. No dependent types are necessary.

3 2

Re: [Haskell-cafe] cumulative sum
by Chad Scherrer 02 Oct '06

02 Oct '06

Tamas, try scanl (+) 0 for the cumulative sum >From there the zipWith idea you mentioned seems like the way to go. -Chad > Hi, > > I have two lists, p and lambda (both are finite). I would like to > calculate > > 1) the cumulative sum of lambda, ie if > > lambda = [lambda1,lambda2,lambda3,...] > > then > > csum lambda = [lambda1,lambda1+lambda2,lambda1+lambda2+lambda3,...] > > 2) the cumulative sum of p*lambda (multiplication elementwise) > > Once I know how to do the first, I know how to do the second I guess > (doing the multiplication using zipWith to get the p*lambda list, but > I would be interested in any other suggestions). Currently I take and > sum, but then I am calculating the same sums many times. > > Thanks, > > Tamas

2 1

cumulative sum
by Tamas K Papp 02 Oct '06

02 Oct '06

Hi, I have two lists, p and lambda (both are finite). I would like to calculate 1) the cumulative sum of lambda, ie if lambda = [lambda1,lambda2,lambda3,...] then csum lambda = [lambda1,lambda1+lambda2,lambda1+lambda2+lambda3,...] 2) the cumulative sum of p*lambda (multiplication elementwise) Once I know how to do the first, I know how to do the second I guess (doing the multiplication using zipWith to get the p*lambda list, but I would be interested in any other suggestions). Currently I take and sum, but then I am calculating the same sums many times. Thanks, Tamas

2 1

non lazy io
by Matt Roberts 02 Oct '06

02 Oct '06

I would like a non-lazy alternative to readFile is there such a thing in the libraries? matt r

3 3

variadic functions and typeCast
by Michael Shulman 02 Oct '06

02 Oct '06

Hi all, I am writing, for my own amusement, a more general version of the trick to implement variadic functions in Haskell outlined at http://okmij.org/ftp/Haskell/vararg-fn.lhs. (If someone else has done this already, please point me to it!) Code is attached at the end of the message. My question concerns the use of `typeCast', which is defined as follows: class TypeCast x y | x -> y, y -> x where typeCast :: x -> y instance TypeCast x x where typeCast = id This is taken from the paper "Strongly typed heterogeneous collections" by Oleg Kiselyov, Ralf Lammel, and Keean Schupke. As observed there, the TypeCast instance declaration must occur in a separate module; otherwise the compiler is too eager about type simplification. (I also get the same errors if VarArg is interpreted by GHCi, even if TypeCast is in a separate module.) I think I understand the reason for this, but I find it a little surprising; it wasn't clear to me from the documentation that fundeps introduce a new dependence on module boundaries. Anyway, my main question about typeCast is this: why is it needed here at all? If I omit it entirely, the code compiles fine, but then using it gives error messages like the following: Prelude VarArg> build 'h' 'i' :: String <interactive>:1:0: No instances for (VarFold [a] [a] [Char], VarAccum Char [a]) arising from use of `build' at <interactive>:1:0-4 ... I don't understand why the type-checker is unable to infer that the type variable `a' should be specialized to `Char' here, since the only available instance of VarFold whose third type is [Char] has the first type also being [Char]. I've given the compiler all the type hints I can think of. Can someone explain this to me? I should say that if I add a functional dependency "l -> a" to the class VarAccum, then this particular example works. However, I have other examples in mind for which l doesn't functionally determine a, so I don't want to do that. And I don't see why it's necessary. Here's the code: class VarAccum a l where accum :: a -> l -> l class VarFold b l r where varFold :: (l -> b) -> l -> r instance (TypeCast b c) => VarFold b l c where varFold f xs = typeCast (f xs) instance (VarFold b l r, VarAccum a l) => VarFold b l (a -> r) where varFold f xs x = varFold f (accum x xs) -- This is the type of variadic functions from lots of As to a B. type a :--> b = forall r. (VarFold b [a] r) => r infixr 0 :--> instance VarAccum a [a] where accum x xs = (x:xs) varArg :: forall a b. ([a] -> b) -> (a :--> b) varArg f = varFold (f . reverse) ([] :: [a]) build :: forall a. a :--> [a] build = varArg (id :: [a] -> [a]) Thanks! Mike

4 8

Re: [Haskell] Replacing and improving pattern guards with PMC syntax
by Brandon Moore 02 Oct '06

02 Oct '06

kahl(a)cas.mcmaster.ca wrote: ... > So far I never considered it important to devise a concrete syntax for PMC, > but triggered by the current pattern guards thread on haskell-prime, > I now try to give a PMC syntax that blends well with Haskell. I think with some alterations your syntax would blend even better. In particular, it would be really nice to have a backwards-compatible syntax. I have designed a slightly different syntax with that goal in mind, which is described in the rest of this message. > One of my gripes with Haskell pattern matching is > that the anonymous variant, namely case expressions, > has an application to an argument built in, > and therefore does not by itself produce a function. > > However, lambda-abstraction already allows single-alternativepattern matching, so I propose to relax this to multi-alternative > pattern matching: >> length = \ >> [] -> 0 >> x : xs -> 1 + length xs I'm with you here. Extending lambda to introduce a layout group of alternatives makes sense even without the rest of the changes to matching. This isn't completely backwards-compatible, but it's pretty close. While we're at it, why not have the identifier of a top level definition introduce a layout group of alternatives, rather than requiring the name to be repeated all the time. How about take 0 _ = [] _ [] = [] n (x:xs) = x : take (pred n) ns > (Lists of alternatives correspond to the ``matchings'' of PMC, > and concatenation of those lists (using ``;'' or layout) corresponds > to matching alternative in PMC. > ``\ m'' then corresponds to ``{| m |}'' in PMC. > ) > > For multi-argument pattern matching, > I propose to allow nested matchings: >> zip = \ >> x : xs -> y : ys -> (x,y) : zip xs ys >> _ -> _ -> [] This deviates from the current syntax of multi-argument lambda, and introduces overloading on ->. Perhaps -> could be reserved for "match and lift", and whitespace could separate several alternatives: zip = \ (x:xs) (y:ys) -> (x,y) : zip xs ys _ _ -> [] There is some tension in the current between argument lists which allow several arguments and require parentheses around constructor applications to delimit patterns, and case expression which match only one item, but without grouping. If we are trying to unify things, perhaps case could be extended to support matching several values together, perhaps separating expressions with commas in the head and using the syntax of a lambda for the cases. Perhaps '=' in function declarations vs. "->" for other matching could also be simplified somehow. I don't have any ideas here. >> take' = \ >> 0 -> _ -> [] >> n -> { [] -> [] >> ; x : xs -> x : take (pred n) xs >> } I'm not sure how to handle a case like this. Introducing layout at whitespace seems a bit excessive, but requiring explicit separators looks a bit heavy on punctuation next to the current grammar, where only records (and perhaps Maybe the '\' could be reiterated to introduce the layout group: take' = \ 0 _ -> [] n \[] -> [] (x:x) -> x : take (pred n) xs > > Pattern guards now can be seen as a special case of > alternatives-level argument application > (``argument supply'' $\righttriangle$ in PMC). > I find it useful to write the argument first, as in PMC. > > I see two options of writing argument supply in Haskell: > either using new keywords, giving rise to the syntax production > > alt -> match exp with alts Maybe reuse "case", unless a new keyword is needed to avoid confusion. > or using a keyword infix operator: > > alt -> exp |> alts > > (Using this kind of argument supply instead of pattern guards > also has the advantage that multiple alternatives become possible.) I'm not using -> to separate patterns, but some leading symbol is required to separate the last pattern from the expression. I like '|' from the current syntax, selected with hopes of incorporating and extending the current guard syntax. I'm pretty sure incorporating the existing guard syntax will require that the grammar keep track whether the last "bit" of the matching was a pattern or a guard (just like currently | switches from patterns separated by whitespace to a list of guards separated by commas). Pattern guards can be translated to matching plus argument supply, so argument supply needs to be part of the primitive matching syntax. I like the suggestion alt | exp |> alts It would be unambiguous but require unbounded lookahead to allow a case to begin with argument supply: foo :: [Int] -> [Int] foo = \lookup env v |> (Just r) [] -> [r] Given argument supply, we can sugar in the existing guard syntax by allowing alt | guard, guards, exp |> alts and alt | guards -> expr The sequence "->\" will transition from guards back to matching more arguments. It might be nice to abbreviate that to '\'. Guards can be eliminated with the translations alt | exp, guards ... ==> alt | exp |> True |guards alt | exp -> expr ==> alt | exp |> True -> expr alt | pat <- exp, guards ==> alt | exp |> {pat | guards ... } alt | pat <- exp -> expr ==> alt | exp |> pat -> expr > > I start with Simon Peyton Jones' standard example: > >> clunky env v1 v2 | Just r1 <- lookup env v1 >> , Just r2 <- lookup env v2 = r1 + r2 >> | otherwise = v1 + v2 I'd like to accepts this unchanged. I think the treatment of guards above will work. > This could now be written using either ``match _ with _'': > >> clunky env v1 v2 = \ >> match lookup env v1 with >> Just r1 -> match lookup env v2 with >> Just r2 -> r1 + r2 >> v1 + v2 > > or infix ``_ |> _'': > >> clunky env v1 v2 = \ >> lookup env v1 |> Just r1 -> >> lookup env v2 |> Just r2 -> r1 + r2 >> v1 + v2 Because I'm using space to separate patterns, I would require parentheses (or the pat <- exp sugar) clunky env v1 v2 | lookup env v1 |> (Just r1) , lookup env v2 |> (Just r2) -> r1 + r2 > Boolean guards are matches against True: >> take = \ >> 0 -> _ -> [] >> n -> match n > 0 with >> True -> >> { [] -> [] >> ; x : xs -> x : take (pred n) xs >> } >> _ -> error "take: negative argument" take = \ 0 _ -> [] n | n > 0 \[] -> [] (x:xs) -> x : take (pred n) ns This syntax has a pretty nice pronunciation, reading | as "such that", a comma as an "and" (between guards), and both space between patterns or '\' after a guard as "and" or "and then" (either way, introducing a pattern for another argument). This PMC stuff seems like a description/semantics for pattern matching. Hopefully my attempts at backwards-compatible syntax help people give the semantics a deeper look. Brandon

1 0

How would you replace a field in a CSV file?
by tpledger＠ihug.co.nz 02 Oct '06

02 Oct '06

Hi Pete. For such a small self-contained task, I don't think Haskell is any better than Python. Haskell would come into its own if you wanted some assurance about type safety, and/or were taking on a task large enough to warrant the use of records (and hence record update notation). Regards, Tom

3 2