- Haskell-Cafe - Haskell.org

Haddock Parse Errors
by Matthew Bromberg 06 Oct '06

06 Oct '06

I am trying to use Haddock for the first time on windows for a reasonably large project. I must be completely clueless because I seem to generate a lot of parse errors that have no reasonable explanation. In some cases it seems like Haddock is white space sensitive requiring the same indentation as my source code. If so, this is not clearly documented. However consider this example: in my matrix library I have this code snippet: ... -- | class instance Rmatrix, real only matrices instance Matrix Rmatrix where -- | tells us if its a submatrix (better to use pattern matching) issub x = case x of Rindx n -> False Rsubindx n -> True ... This generates a parse error on the line -- | class instance Rmatrix, real only matrices at the first s in class. Removing the | from the comment generates a parse error on the instance declaration even though there are no haddock comments that apply to it! The code prior to this looks something like... -- | copy one matrix into another copy :: m -> m -> m copy a b = mio $ do ka <- pushsub a ... and is part of the class declaration itself. I'm not sure why an auto-documentation tool shouldn't be a bit more forgiving vis a vis it's syntax. Maybe flag errors as warnings but keep on going. I run haddock from the command prompt via the command haddock.exe -o docs -v -h matrix.hs

4 6

Having our cake and eating it too
by Michael Shulman 05 Oct '06

05 Oct '06

This proposal is somewhat tongue in cheek, but at least it's amusing, and who knows, it might be good for something. The idea is that one could, in theory, allow both prefix unary minus and right sections of subtraction, with the type-checker deciding which is meant based on the context. Has this been noticed before? Consider the following code snippet, which runs in GHC 6.6 (with the new ability to define postfix operators). > {-# OPTIONS -fglasgow-exts -fallow-undecidable-instances -fallow-overlapping-instances #-} > module Minus where > import TypeCast > class Minus a b where > (<->) :: a -> b > instance (Num a, TypeCast a b) => Minus a b where > (<->) = typeCast . negate > instance (TypeCast a b, Num b, TypeCast b c) => Minus a (b -> c) where > (<->) x y = typeCast ((typeCast x) - y) (TypeCast is the usual one from HList etc.) Loading this in the interpreter, we now have: *Minus> (1 <->) :: Int -1 *Minus> 3 <-> 1 :: Int 2 *Minus> map (<-> 1) [2..5] [1,2,3,4] *Minus> map (1 <->) [2..5] [-1,-2,-3,-4] *Minus> map (<->) [2..5] :: [Int] [-2,-3,-4,-5] *Minus> zipWith (<->) [1,3,5] [1,2,3] [0,1,2] In short, the operator <-> can be used as *either* an infix subtraction operator (which can be sectioned on both sides) or a postfix unary negation operator (which can also be sectioned once). The trick is the same one used for variadic arguments: the type-checker can infer from context whether (1 <->) should return a number or a function, and resolves it accordingly. Thus, if we could figure out a way to define prefix operators, analogous to the way we can now define postfix operators, we could in theory allow prefix unary minus and right sections of subtraction to coexist peacefully. But I haven't had much luck coming up with a non-ugly suggestion for how to do this. I'd be interested to hear if anyone else has ideas, although I doubt any such solution would ever make it into any Haskell standard. (-: It's also unfortunate that we need the explicit type signatures in the interpreter above, but otherwise there would be no context for type-inference based on the return value. As usual, though, this problem would probably hardly ever arise in an actual program, where most values have a known type. (Actually, I still don't understand why a type signature is necessary on 3 <-> 1; anyone care to enlighten me?) Comments? Mike

1 0

collection monads
by tpledger＠ihug.co.nz 05 Oct '06

05 Oct '06

Matthias Fischmann wrote: > another beginners question about monads: given the type > > | data (Ix x) => Permutation x = Permutation [x] > > i wanted to define > > | instance Monad Permutation where > | return xs = Permutation xs > > but of course nothing about the monad class guarantees xs to be of > type list. the monad class seems unsuitable for holding collections, > and i am inclined to not instantiate permutations. > > just to be sure: is there any easy way to do it that i missed? Do you expect the contained type x to change during a sequence of monadic actions? e.g. would you ever use (>>=) at the type 'Permutation Int -> (Int -> Permutation Bool) -> Permutation Bool'? If not, you could separate each permutation into keys and values: data Permutation k v = Permutation [(k, v)] instance (Ix k) => Monad (Permutation k) Regards, Tom

2 1

Searching all the source code of the world
by Stephane Bortzmeyer 05 Oct '06

05 Oct '06

http://www.google.com/codesearch A great tool (which fulfills a different need than Hoogle) if you are looking for a concrete example of use of such or such function. Unfortunately, "lang:haskell" is not recognized (as a workaround, "file:\.hs" is OK). This has already been reported: http://groups.google.com/group/Google-Code-Search/browse_thread/thread/8c9e…

1 0

haskell vim / my coding aids
by Marc Weber 05 Oct '06

05 Oct '06

I've been busy for some days writing this humbled helper scripts for vim: Goto vim -> by Marc Weber http://www.haskell.org/haskellwiki/Libraries_and_tools/Program_development#… If you find it useful and drop me a line I'll be glad to read your feedback. Marc

1 0

how to create new repository on darcs.haskell.org?
by Bulat Ziganshin 05 Oct '06

05 Oct '06

Hello haskell-cafe, i want to make my library available via darcs repository on darcs.haskell.org. how i can arrange it? if it is required, i already have user account on haskell.org server -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

5 5

Mission: To take args from a list... generally
by tpledger＠ihug.co.nz 05 Oct '06

05 Oct '06

Joel Koerwer wrote: > Let's say I want to evaluate a function of type > (a->a->...->a->a), taking the arguments from a > list. If know the function ahead of time, I can > simply wrap it: > > foo a b c d = ... > wrapFoo (a:b:c:d:_) = foo a b c d > > But, as an exercise, I challenged myself to write > a function, multApply :: (a->a->...->a->a) -> [a] > -> a, that automatically does the wrapping for any > such function. This came up a while ago (but with a list of functions of different arities, all being fed one argument). I found Scott Turner's pure Haskell 98 solution very illuminating: http://www.haskell.org/pipermail/haskell-cafe/2000-November/001332.html Regards, Tom

2 1

seeking paper: Computing with lattices: An application of type classes
by Mathew Mills 04 Oct '06

04 Oct '06

I am not sure how to go about getting a copy of this paper. http://citeseer.ist.psu.edu/context/320255/0 I was hoping someone here could give me a pointer.

1 0

throwDynIO ?
by Carlos Pita 04 Oct '06

04 Oct '06

Hi all! I'm a newcomer to haskell programming with a lisp/scheme background. Last week I've been reading a lot about the monadic approach to IO and I should said I'm pretty fascinated about the flexibility it allows. Currently I'm trying to grasp haskell exception handling and although I find it mostly clear I'm a bit confused regarding the lack of a throwDynIO action "paralelling" throwIO, as there are dynamic variants for the other throw functions: throwDyn - throw throwDynTo - throwTo I understand that the same effect could be conjured up by throwIO (DynException (...))) magic. But the lack of symmetry still disturbes me. Am I missing something? Thank you in advance. Regards, Carlos

1 0

[Haskell] open assistant professorship at Utrecht University, Software Technology
by Doaitse Swierstra 04 Oct '06

04 Oct '06

We have an open 5 year position for an assistant professor. Current areas of interest are: - domain specific embedded languages (especially in the form of combinator languages) - programming language design and implementation - generic programming techniques - tools and methods for building complex systems out of a large number of artefacts in a controlled way - program verification - systems for generating informative feedback to users in the case of inconsistencies in specifications - advanced type systems and their implementation - software generation We strongly believe that the functional programming paradigm is an excellent starting point for many new developments in the above mentioned areas. In our research we try to identify real problems, to find solutions for them, to formalise these, and to build tools in order to convey the solutions to the problem holders. Thus we try to combine sound principles for solving real-life problems. Given the increased pressure on our finances cooperation with industry is of growing importance, which will also hold for this position. Further details can be found at: http://www.cs.uu.nl/vacatures/en/62612.html Doaitse Swierstra _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0