- Haskell-Cafe - Haskell.org

do ghci
by Greg Fitzgerald 12 Oct '06

12 Oct '06

Just curious, why does ghci run in the context of a 'do'? This tripped me up when I first started learning Haskell. It's fine once you know what's going on, but why the restriction? Why can't I write the code below without 'let' and ':module'? > two = 1 + 1 > import Data.List > cols = transpose [[1,2,3], [4,5,6]] Thanks, Greg

2 1

Quantifying Partial Type Annotations
by Philippa Cowderoy 12 Oct '06

12 Oct '06

I've done a bit more thinking about partial type annotations (as proposed on the Haskell' list), and I have a somewhat more concrete proposals for some of the extensions to them that perhaps also makes more sense of the original basic idea as well. I'm sending it to the Cafe this time as it's a bit early to consider this for standardisation. I'd like to propose a new quantifier for type variables, which for now I'll call unknown[1] - correspondingly I'll talk about "unknown-quantified variables" and probably "unknown variables" where it's not ambiguous. Unknown quantifiers will never be introduced by the typechecker without a corresponding annotation - only propagated inwards. Whereas universal type variables must not accumulate additional constraints during typechecking (and in a traditional Hindley-Milner implementation only become universally quantified during a generalisation step), unknown type variables can - indeed this is their raison d'etre. Furthermore, they are never propagated 'outwards' - either the variable is constrained sufficiently that it can be replaced with a monotype or, having otherwise finished typechecking the corresponding term, the unknown quantifier is replaced with a forall. For example: add' :: unknown x. x -> x -> x add' = (+) add'' :: unknown x. x -> x -> x add'' x y = (x::Int) + (y::Int) will typecheck, resulting in these types when the identifiers are used: add' :: forall x. Num x => x -> x -> x add'' :: Int -> Int -> Int It's probably also sensible to allow "wildcard" variables written _, generated fresh and implicitly unknown-quantified much as universal variables are now. Type synonyms seem to present an interesting question though - it seems to me most sensible to hang on to the quantification at top-level and generalise it only as we finish type-checking a module, rather than copying out the quantifier anew each time. Any comments? The amount of thinking I've done about interactions with rank-n variables is limited - I guess we'd need to prohibit unifying with type variables that're of smaller scope than the unknown variable? I'm don't think I can see any other worrying issues there. Unknown variables in method declarations seem... meaningless to me, they're not proper existentials and I don't think there's a sane meaning for them that isn't a kludge for associated types instead. I don't think they belong in instances for similar reasons. Incidentally, I think there's also a cute use case in .hs-boot files, where an unknown-quantified variable could be used to tie some knots in a manner similar to the way recursive bindings are checked now. If so, I have an interesting use for this. [1] Other names that have occurred to me are "solve" (as in "solve for x"), and "meta" (by analogy to metavariables in the typechecker - because by the time we've finished checking the annotated term we'll have removed the quantifier), but unknown seems by far the strongest to me. No doubt someone'll suggest a far better name shortly after I post this! -- flippa(a)flippac.org There is no magic bullet. There are, however, plenty of bullets that magically home in on feet when not used in exactly the right circumstances.

3 2

Yet Another Haskell Tutorial Question
by Bill Mill 12 Oct '06

12 Oct '06

I've been working through the "Yet Anther Haskell Tutorial" at http://www.cs.utah.edu/~hal/docs/daume02yaht.pdf , and I've gotten up to Excercise 4.6. It says: === YAHT === Write a datatype Tuple which can hold one, two, three or four elements, depending on the constructor (that is, there should be four constructors, one for each number of arguments). Also provide functions tuple1 through tuple4 which take a tuple and return Just the value in that position, or Nothing if the number is invalid (i.e., you ask for the tuple4 on a tuple holding only two elements). === /YAHT === I've got a brute-force answer, but I'm sure that there's a better way, and I can't find it. The code I've currently got is at http://paste.lisp.org/display/27806 . Anybody want to point me in the right direction? Thanks Bill Mill bill.mill at gmail.com

3 3

ghc 6.2.2 seems to ignore -package when there's a -prof option
by Seth Gordon 12 Oct '06

12 Oct '06

I have a program using HSQL that I'm trying to profile. When I do ghc program.hs -package hsql -o program it compiles fine, but when I do ghc -prof -auto-all program.hs -package hsql -o program I get error messages saying "failed to load interface for `Database.HSQL'" and so forth, the same way I do if I leave off the -package argument entirely. How can I work around this?

2 1

Trying to understand HList / hMapOut
by Matthias Fischmann 11 Oct '06

11 Oct '06

Hello, I am using a heterogenous list as in [1] all elements of which are of a given class C. I am awed by the beauty of the code (HList, not mine :-). Here is what I am trying doing: import HListPrelude data T = T Int class C a where foo :: a -> Int instance C T where foo (T i) = i class HList l => CList l instance CList HNil instance (C c, CList cs) => CList (HCons c cs) Since foo maps all class members to Int, hMapOut should be a straight-forward way to produce homogenous Int lists from heterogenous CLists: test :: (CList l) => l -> [Int] test = hMapOut foo That would be too easy, though... ghci (6.4) sez: /home/fis/tmp/Main.hs:16:7: Could not deduce (HMapOut (a -> Int) l Int) from the context (CList l) arising from use of `hMapOut' at /home/fis/tmp/Main.hs:16:7-13 Probable fix: add (HMapOut (a -> Int) l Int) to the type signature(s) for `test' or add an instance declaration for (HMapOut (a -> Int) l Int) In the definition of `test': test = hMapOut foo hugs (version 20050308) sez: ERROR "/home/fis/esim/HList/FakePrelude.hs":113 - Overlapping instances for class "Show" *** This instance : Show (HSucc a) *** Overlaps with : Show (HSucc HZero) *** Common instance : Show (HSucc HZero) (oops? should i upgrade, or is there a switch that i missed?) I am trying to understand the ghci error message, which looks like I might have missed a point. It seems like I should make it more obvious to ghc that CLists actually consist of values of type C. Is that a good guess? But how do I actually do it? I have unsuccessfully to extend the context to (HMapOut (a -> Int) l Int, CList l) or even to (C a, HMapOut (a -> Int) l Int, CList l) and I can't see any reason why the instance declarations of HMap in HListPrelude shouldn't cover my code. I am feeling a little stuck again... thanks, Matthias [1] http://homepages.cwi.nl/~ralf/HList/

3 7

windows file locking
by Stefan Aeschbacher 11 Oct '06

11 Oct '06

Hi I need to open a file and keep it open for writing (a log file). Another process has to read from this file. On windows the second process (e.g. tail -f) can not open the file. How can I open a file without this locking? regards Stefan

4 4

Vertical tabs in source code and other obscure chars
by Brian Hulley 11 Oct '06

11 Oct '06

Hi, In the Haskell98 report at http://haskell.org/onlinereport/lexemes.html section 2.2 has the rule: whitechar -> newline | vertab | space | tab | uniWhite Does anyone know what a vertical tab is supposed to do? Is there any reason to allow them as whitespace? (Does anyone in the universe actually use them?) Thanks, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com

2 2

Re: Haskell-Cafe Digest, Vol 38, Issue 22
by Kirsten Chevalier 11 Oct '06

11 Oct '06

On 10/11/06, haskell-cafe-request(a)haskell.org <haskell-cafe-request(a)haskell.org> wrote: > Meanwhile, if you want to use External Core, but can't because it > doesn't work properly for you, don't be afraid to yell. (E.g. File a > Trac bug report.) I don't want to promise an immediate fix, but the > more people that use it the keener we are to get it done. > I did file a bug on this nine months ago: http://hackage.haskell.org/trac/ghc/ticket/670 but haven't had a chance to work on it. Cheers, Kirsten -- Kirsten Chevalier * chevalier(a)alum.wellesley.edu * Often in error, never in doubt "That's the thing about people who think they hate computers. What they really hate is lousy programmers."-- Larry Niven and Jerry Pournelle

1 0

GHC Core still supported?
by Jim Apple 11 Oct '06

11 Oct '06

In http://www.haskell.org/ghc/dist/current/docs/users_guide/ext-core.html , I see two notes that I can't verify: 1. I don't see any CORE pragma on http://www.haskell.org/ghc/dist/current/docs/users_guide/pragmas.html 2. Using GHC 6.5.20060920, I compile module Core where data Foo = Bar with -fext-core to get %module main:Core %data main:Core.Foo = {Bar}; I then compile the resulting hcr file with no flags to get <no location info>: 1: Parse error : %data main:Core.Foo = {Bar}; Jim

3 2

Multiple stages in Template Haskell
by Lyle Kopnicky 11 Oct '06

11 Oct '06

Hi folks, I noticed that in Template Haskell, you can only have one level of splicing or quasi-quoting. E.g., you can't write: $(zipN ($(sel 2 3) ("zip level",3,()))) ['a'..'Z'] [1..] (words "now is the time") Because you can't have a splice inside a splice. But wouldn't it be handy to use all these macros when defining other macros? This would be like stages in MetaML, which have no such limitation. But all the stages but the last one would be evaluated at compile time. The compiler would look for the deepest level of nested splices and evaluate it first. On the other hand, I can understand why you wouldn't include splices and quasi-quotes in the Language.Haskell.TH.Syntax - programmers could write functions that dynamically created arbitrarily (even infinitely) nested splices - so it would be undecidable where to start. I'm wondering if there's some reason this restriction is imposed. Is it particularly difficult to implement, or are there more theoretical problems? Does that mean I'm volunteering? ;) - Lyle

2 1