May 2007 - Haskell-Cafe

negate and -
by Maurício 17 May '07

17 May '07

Hi, Haskell language reference says the special - operator translates to negate. However, this: (+ negate 5) 5 works but this: (+ -5) 5 is not valid. Why? Thanks, Maurício

2 1

haskell quiry
by ashutosh dimri 17 May '07

17 May '07

Thanks a lot Mr. jules now the code is working perfectly for higher values , the problem was with ord .

1 0

haskell quiry
by ashutosh dimri 17 May '07

17 May '07

I have written a code to convert hexadecimal numbers into base 10 number but its working only for 32 bits and I need it to work upto 160 bits , code is given below. please help. --its a program to convert hexadecimal numbers into base 10 numbers import Char -- the function "func" takes a list of strings in hexadecimal and convert -- it to a list of corresponding numbers in decimal format -- func "eefba12" = [14,14,15,11,10,1,2] func [] = [] func (x:xs) |(ord x > 57) = ((ord x)-87):func xs |otherwise = ((ord x)-48):func xs -- (mul.func) function takes a hexadecimal number and convert it to base 10 but its working only for 32 bits -- whereas haskell supports calculations much higher than 32 bits..... -- mul.func $ "ee" = 238 -- mul.func $ "e23e" = 57918 mul xs = mul1 xs ((length xs)-1) mul1 (x:xs) 0 = x mul1 (x:xs) n = (x*16^n)+ mul1 xs (n-1)

2 1

ANNOUNCE: Dimensional 0.4 -- Statically checked physical dimensions
by Björn Buckwalter 17 May '07

17 May '07

Dear all, I am pleased to announce version 0.4 of Dimensional (working name). Dimensional is a library providing data types for performing arithmetic with physical quantities and units. Information about the physical dimensions of the quantities/units is embedded in their types and the validity of operations is verified by the type checker at compile time. The boxing and unboxing of numerical values as quantities is done by multiplication and division with units. The library is designed to, as far as is practical, enforce/encourage best practices [1] of unit usage. Since the previous formal announcement [2] (version 0.1) Dimensional has gone through several structural and stylistic improvements but usage remains fundamentally unchanged. Noteworthy changes are a vastly solidified 'NumType' module, a complete(?) set of elementary functions and a 'Prelude'-replacement for users' convenience. There is also an experimental 'Extensible' module supporting user-defined dimensions. Additional structural changes and additions (primarily of units) are planned and the library will continue to have an unstable API until the 1.0 release. However, apart from module reshuffling no changes are anticipated that would break user code. Additional information and code is available from the project web site [3]. Thank you, Bjorn Buckwalter [1] http://physics.nist.gov/Pubs/SP811/ [2] http://www.haskell.org/pipermail/haskell/2006-December/018993.html [3] http://code.google.com/p/dimensional/

1 0

CUFP website
by Cyril Schmidt 17 May '07

17 May '07

I noticed recently that the website of CUFP conference (Commercial Uses of Function Programming), which used to be at http://www.galois.com/cufp, is not accessible anymore. Does anybody know where it moved? Cyril

3 2

quiry
by ashutosh dimri 16 May '07

16 May '07

how to convert a hexadecimal into base 10 integer using haskell . I have written a code but its not working for large values , please help

4 3

Books on Haskell
by PR Stanley 16 May '07

16 May '07

Hi, Is Graham Hutton's book on Haskell Programming a good text for FP beginners? Paul

2 1

problem with implicit parameter
by Eric 16 May '07

16 May '07

Hi there, I've written the following program putchr = putChar ?d main = do { c <- getChar ; putchr with ?d = c} which I try to compile with ghc --make -fimplicit-params myprogram However I keep getting the following error: myprogram.hs:5:17: parse error on input `=' What's wrong? E.

3 2

Re: ANNOUNCE: Harpy -- run-time code generation library
by apfelmus 16 May '07

16 May '07

[Relocated to haskell-cafe] Dirk Kleeblatt wrote: > apfelmus wrote: >> Note that even currently, your operations cannot be strict in the >> address a label refers to because this may be determined later than the >> first use of the label. In other words, your example code >> >> fac = do > [...] >> (1) jmp loopTest > [...] >> (2) loopTest @@ cmp ecx (0 :: Word32) > [...] >> already shows that the function jmp that generates a jmp-instruction may >> not be strict in the position it jumps to as the address behind loopTest >> is only known later at line (2). > > When generating code for (1), the label loopTest is used as an index > into a map, to see whether there's a code position associated with it. > If it is, the code position is used to compute the jump offset for the > jmp instruction, if not (as in this example), a dummy value is placed in > the code buffer, and Harpy remembers this position to be patched later > on. At (2), the label is defined, and this leads to patching all > instructions that have been emitted before this definition. > > So, yes, the code position is only used after the definition of the > label. But the "look up in a map"-part makes the jmp operation strict in > the label parameter. Ah, I slowly get what you mean. In short, the point is that you're reinventing lazy evaluation because you're writing directly to a memory buffer and writing a raw _|_ is impossible. So, you invent a scheme to delay the evaluation of the _|_ until they are defined. With raw writing, we indeed have the strictness writeByte buf _|_ = _|_ which implies jmp _|_ = _|_ I thought that you'd simply store the instructions in a list/monoid like the Builder-Monoid from Data.Binary with the effect that jmp _|_ /= _|_ as monadic action although it stores _|_ as instruction. Lazy evaluation then takes care of filling the _|_-instructions with content in times of need. Here's an illustration with a fictional robodog toy assembly language import Control.Monad.RWS type Address = Int data Dogcode = Bark | Bite | Jump Address data CodeGen a = RWS () [Dogcode] Address a emitDogcode :: Dogcode -> CodeGen Address emitDogcode c = x <- get tell c put (x+1) return x jump :: Label -> CodeGen Address jump = emitDogcode . Jump bark, bite :: CodeGen Address bark = emitDogcode Bark bite = emitDogcode Bite generateDogCode :: CodeGen a -> CodeBuffer generateDogCode c = let (_,instructionCount, code) = runRWST c () 0 in ... whatever to do with a list of instructions ... Now, you magically get recursive do-notation without lifting a finger because RWS is already an instance of MonadFix. For example, the following works out of the box pluto :: CodeGen Address pluto = mdo bark jump loop bite loop <- bark bark jump loop (The return value of type Address encapsulated in the monad is the line number of the last instruction of pluto.) If you really want to directly write to a memory buffer, I think that you can still use lazy evaluation to fill in the _|_ by emitting a "jump PATCHME" dummy instruction and build a stack (f.i. of type [Address]) of addresses. The stack takes the role of the map you currently use, I think that a stack is enough. The addresses therein may well be _|_. After having written all instructions into the buffer, all the _|_ are resolved and you can patch the "PATCHME"s in a second pass over the buffer. However, because of omnipresent lazy evaluation, it is unclear whether "directly" writing to a buffer instead of first building a monoid does give a speed/space advantage. So, your current approach may well be slower than a naïve "first (difference) list, then raw memory" approach. > We could omit the map, and just remember where to patch the code, but > then we'd need to call explicitly some function after code generation > that does the patching. We had implemented this, but found the current > solution easier to use, since backpatching is completely automatic and > hidden from the user. Huh, I thought that runCodeGen would do an additional backpatch pass as transparently? >> I also think that having liftIO in the CodeGen-monad is plain wrong. I >> mean, CodeGen is a monad that generates code without any execution >> taking place. The execution part is already handled by runCodeGen. >> Having liftIO means that arbitrary Haskell programs can be intertwined >> with assembly generation and I doubt that you want that. > > Feel free to doubt, but this is exactly what we want. :-) > > Also, note that runCodeGen runs the code _generation_, executing the > generated code is done _within_ the CodeGen monad via the functions > generated by callDecl (or the predefined functions in the Harpy.Call > module). This is even more intertwined, but intentional. Huh? That means that code gets executed during it's own generation? But why do you mix separate concerns? I don't see what use this is besides being an opportunity to mess up. > Of course, again a different design is possible, making runCodeGen > return a binary code object, that can be called from the IO monad. But > then, the user has to care about releasing code buffers, and not to have > unevaluated closures having code pointers to already released run-time > generated code. Huh, why does the user have to care? Shouldn't wrapping the raw memory block into a Foreign.ForeignPtr do the job? Regards, apfelmus

2 2

Type class help please
by Adrian Hey 16 May '07

16 May '07

Hello, Here's a simple module I'm playing about with.. {-# OPTIONS_GHC -fglasgow-exts #-} module Test(GT(..)) where -- GT class -- class Ord key => GT map key | map -> key where assocsAscending :: map a -> [(key,a)] -- Just 1 of many methods -- Instances of GT are instances of Eq -- instance (GT map key, Eq a) => Eq (map a) where map1 == map2 = assocsAscending map1 == assocsAscending map2 When I compile it I get this error.. Test.hs:9:0: Variable occurs more often in a constraint than in the instance head in the constraint: GT map key (Use -fallow-undecidable-instances to permit this) In the instance declaration for `Eq (map a)' But I can't see any problem here. If map and key are collectively instances of GT, and the fundep in GT fixes the type of key if type of map is known, and GT class has Ord constraint on key (and IIRC Ord class has an Eq constraint so key is a known instance of Eq), then why is this undecidable? Anyway, if I compile with -fallow-undecidable-instances I get this error instead.. Test.hs:10:16: Overlapping instances for Eq [(key, a)] arising from use of `==' at Test.hs:10:16-59 Matching instances: instance (Eq a) => Eq [a] -- Defined in GHC.Base instance (GT map key, Eq a) => Eq (map a) -- Defined at Test.hs:9:0 In the expression: (assocsAscending map1) == (assocsAscending map2) In the definition of `==': == map1 map2 = (assocsAscending map1) == (assocsAscending map2) In the definition for method `==' .. but I don't understand what that means (or to be more precise, what it seems to be saying makes no sense to me, so it's probably saying something else :-) How can my new instance overlap with the old (ghc) instance unless [] is also an instance of GT for some key type (which it isn't). Could someone explain? If I try making key a type arg of map (with no -fallow-undecidable-instances ).. {-# OPTIONS_GHC -fglasgow-exts #-} module Test(GT(..)) where -- GT class -- class Ord key => GT map key | map -> key where assocsAscending :: map key a -> [(key,a)] -- key is type arg of map -- Instances of GT are instances of Eq -- instance (GT map key, Eq a) => Eq (map key a) where map1 == map2 = assocsAscending map1 == assocsAscending map2 .. then I don't get the first error "Variable occurs more often in a constraint than in the instance head". But I still get the second ("Overlapping instances.."). But I don't really want to do this anyway as it as AFAICS it defeats the object of using the fundep in GT class. I also don't really understand why this second form should be decidable (presumably), whereas the first isn't. What extra information does the second provide that isn't already provided by the fundep in the first? If I also use the -fallow-overlapping-instances flag then both forms of this module compile, but with the warning.. Warning: orphan instances: instance [overlap ok] base:GHC.Base.Eq [.] = $f1 I'd be grateful if someone could take the time to explain what's going on here and (if possible) what I can or should do to get this code to compile (preferably without using undecidable or overlapping anything). Thanks -- Adrian Hey

2 2