December 2007 - Haskell-Cafe

Re: [Haskell-cafe] Re: Wikipedia on first-class object
by Miguel Mitrofanov 28 Dec '07

28 Dec '07

> Right, so when I say to GHCi: > Prelude> take 5 [1..] > and it says: > [1,2,3,4,5] > then it really has computed the entirety of the infinite sequence > [1..], and not some approximation? Of course not! In fact, it doesn't even compute the value "1". It just juggles with the bytes somehow, so that it seems that it computes the whole sequence and then applies "take 5". But does it really matter if it computes 5 integers, or 10, or the whole sequence, at least if we are not concerned about performance? > Perhaps it is better to say that in a lazy language both > approximations and maximal values (least upper bounds of a chain) are > interesting. Well, that depends of your notion of interesting.

3 2

Re: [Haskell-cafe] Re: Wikipedia on first-class object
by Miguel Mitrofanov 28 Dec '07

28 Dec '07

> >> It sounds like a limit. xn --> x for n --> :-) > > > > Yeah, that's right. > If xn is monotone, then I only have to worry when it is not bounded, right > ? Sorry, don't understand what you mean. Yes, the monotone sequence has a limit. No, it's not necessarily maximal. > >> [1 .. ] and x=1:x are maximal ? > Can you give me some examples of non maximal ones ? let x = x+1 in x Or even let x = x in x In both cases, (_|_) is the least fixed point, and is non-maximal.

1 0

Re: [Haskell-cafe] Re: Wikipedia on first-class object
by Miguel Mitrofanov 28 Dec '07

28 Dec '07

> Questions: > The fact that Haskell functions are monotone continuous functions on > pointed complete partial orders imply this ? > - every domain in Haskell is a "pointed complete partial order", including > domains of functions ? Right. > - the "structure" of a domain is preserved in the result when you apply a > Haskell function to it ? Right, if your "structure" means "complete partial order". Note that (_|_) (the least element in this order) is not necessarily preserved. > - every domain can be enumerated ? Ehm... No. Well, it depends on what you mean by "enumeration".

2 1

Dynamic typing of polymorphic functions
by Alfonso Acosta 27 Dec '07

27 Dec '07

Hi all, As some of you might remember I'm working on a EDSL which models process networks (A process can simply be viewed as a box which has a number of input and output signals and makes computations over them). A simple example of the processes implemented is MapSY, which is similar to Haskell's well-known map function. It takes a signal and a processing function as arguments and applies that function the signal. Following Lava's approach, a specifically designed Signal type hides and "secretly" forwards the structure of the network. Such structure is logically an untyped graph. For that reason, the processing functions associated to the different processes are kept in Dynamic form. A very simplified implementation could be: ------ import Data.Typeable import Data.Dynamic -- the phantom type parameter makes signal typing consistent newtype Signal a = Signal PrimSignal newtype PrimSignal = PrimSignal (Proc (PrimSignal)) data Proc input = MapSY Dynamic -- The processing function input -- The process input -- the rest of the processes are omitted eval :: Proc Dynamic -> Dynamic -- evaluates the output of a process for one input eval (MapSY dynF dynIn) = dynApp dynF dynIn -- the map process constructor mapSY :: (Typeable a, Typeable b) => (a -> b) -> Signal a -> Signal b mapSY f (Signal primSig) = Signal (PrimSignal (MapSY (toDyn f) primSig)) ----- OK, If you managed to read until this point, you might have noticed that, due to the monomorphism restriction implied by Data.Typeable, it is impossible to build polymorphic processes. The approach works nicely for monomorphic processes though: add1 :: Signal Int -> Signal Int add1 = mapSY ((+1) :: Int -> Int) mapSndInt :: Signal (Int, Int) -> Signal Int mapSndInt = mapSY (snd :: (Int, Int) -> Int) But it does not work for building polymorphic processes. The following process would be really useful but its compilation obviously fails: mapSnd :: Signal (a, a) -> Signal a mapSnd = mapSY snd Could not deduce (Typeable a) from the context () arising from a use of `mapSY' Possible fix: add (Typeable a) to the context of the type signature for `mapSnd' Again, due to the monomorphism restriction of the Typeable class, the compiler's suggestion of adding a Typeable context didn't work. (Well, strangely enough, adding the "Typeable a" constraint hushed GHC but an error was instead triggered at runtime). I must admit I'm totally stuck with this problem. My two options are: 1) Forcing the user to define mapSnd & friends for each combination of types (which can hardly be considered an acceptable solution) 2) Think of a change in the internal representation of signals which made polymorphic processes possible. Polymorphic processes don't have to be necessarily definable by the user. They should be happy enough with a few polymorphic primitives (mapSnd would be one of them). * Maybe an implementation of unsafe dynamics using unsafeCoerce which allowed applying polymorphic functions to monomorphic values for specific safe cases? I would really appreciate any suggestions or remarks regarding my problem/design. Thanks in advance, Alfonso Acosta

3 3

ambiguous types although 'asTypeOf'
by Henning Thielemann 27 Dec '07

27 Dec '07

I thought I understand monomorphism restriction. But it seems, I don't. I have boilt down my problem to the following test. Don't try to make any sense of it, it is just the smallest code I could come up with. test :: (Integral a, RealFrac a) => a test = let c = undefined in asTypeOf (round c) c When compiling I get: Compiling StorableInstance ( src/StorableInstance.hs, interpreted ) src/StorableInstance.hs:38:17: Warning: Defaulting the following constraint(s) to type `Double' `RealFrac a' arising from use of `round' at src/StorableInstance.hs:38:17-21 In the first argument of `asTypeOf', namely `(round c)' In the definition of `test1': test1 = let c = undefined in asTypeOf (round c) c

3 3

A Foldable binary search tree
by Brad Larsen 27 Dec '07

27 Dec '07

Mainly for pedagogical purposes, I'm writing a BST. The elements in a BST need to be ordered, so I define the new data type like this: data (Ord a) => BST a = Empty | BST (BST a) a (BST a) After some hacking and some reading, I came across Data.Foldable, and think it would be neat to make BST Foldable: instance Foldable BST where foldr f s Empty = s foldr f s (BST l v r) = foldr f (f v (foldr f s r)) l However, ghc tells me ``Could not deduce (Ord a) from the context (Foldable BST) arising from use of `BST' at bst.hs:19:13-21'', which is the second line of the foldr definition. If I remove the (Ord a) context from the BST data definition, ghc accepts my code. However, I'd like to keep that context. How does one do this? Thanks! Brad Larsen P.S. Does that definition of foldr look reasonable, i.e. is it associating in the ``right'' order for a binary tree?

4 6

DSL question -- was: New slogan for haskell.org
by Steve Lihn 27 Dec '07

27 Dec '07

Thanks for the explanation on DSL. It helped me understand how Haskell works compared to other popular languages out there. It is a programming methodology change. Or what is called paradigm change on how to design a software with Haskell. Haskell has its general-purpose features. Yet its strength is the ability and ease of defining DSL by utilizing the higher order \"stuff\" (like type class, composite function, monads, and arrows), which to say the least, can be quite abstract and challenging. I do come aross a question while reading the DSL page on Wikipedia. http://en.wikipedia.org/wiki/Domain-specific_programming_language In the Disadvantage section (near the end), there is an item -- hard or impossible to debug. Can anybody explain why or what it means? And how does it apply to Haskell? -- steve On 12/11/07, Brandon S. Allbery KF8NH <allbery(a)ece.cmu.edu> wrote: > > > * Domain Specific Language (who needs it? other than academics and > > Wall Streeter?) > > DSELs can be thought of as a programming methodology; as such, it has > wide applicability, but most programmers don\'t think that way. Tcl > was originally positioned as a \"DSEL enabler\" (write composable > functions in C, tie them together in Tcl), but most programmers > \"don\'t get it\" and so don\'t tend to use it as such. More recently, > Lua seems to be using a similar philosophy with a little more success > --- but mainly by limiting it to something which most programmers can > deal with. Also compare how Perl and Python monoliths have replaced > the original Unix philosophy in which the shell is a DSEL enabler > (composing single-function programs like \"cat\" and \"sort\"). > > When it comes down to it, Haskell\'s strengths are only realizeable if > you approach programming problems in a different way from most common > languages. It\'s a fairly big leap, and arguably Haskell won\'t > compete well in the mainstream until more programmers have made that > leap. >

6 7

CAF's in Haskell
by Neil Mitchell 27 Dec '07

27 Dec '07

Hi, Are CAF's specified in the Haskell report? I couldn't find them mentioned. If not, why do all Haskell compilers support them? Is there some paper which persuaded everyone they were a good idea, or some reference I could look up? Thanks Neil

6 7

Fwd: Re: [Haskell-cafe] Wikipedia on first-class object
by Cristian Baboi 27 Dec '07

27 Dec '07

------- Forwarded message ------- From: "Cristian Baboi" <cristi(a)ot.onrc.ro> To: "Yitzchak Gale" <gale(a)sefer.org> Cc: Subject: Re: [Haskell-cafe] Wikipedia on first-class object Date: Thu, 27 Dec 2007 12:21:44 +0200 I think I found the answer to why functions cannot be written to files. This is by design. Haskell must be free. Enabling writing functions to files, might make it ilegal in some countries. :-) On Thu, 27 Dec 2007 11:10:21 +0200, Yitzchak Gale <gale(a)sefer.org> wrote: > Like any type, only certain operations make > sense on functions. Strings can be compared to each > other for equality and written to a disk, and you > can take the logarithm of a float, but none of those > operations make sense for functions. In particular, > two functions are equal only if they produce > the same value for every input, and in general it is > impossible for a computer to check that. > > -Yitz > > > ________ Information from NOD32 ________ > This message was checked by NOD32 Antivirus System for Linux Mail > Servers. > part000.txt - is OK > http://www.eset.com ________ Information from NOD32 ________ This message was checked by NOD32 Antivirus System for Linux Mail Servers. part000.txt - is OK http://www.eset.com

2 1

Comments on reading two ints off Bytestring
by Paulo J. Matos 27 Dec '07

27 Dec '07

Hello all, It is either too difficult to get two integers of a bytestring, in which case something should be done to ease the process or I should learn much more Haskell. I guess the latter is the correct guess. I have a bytestring containing two naturals. I was to get them as efficiently as possible. Here's my code: parseHeader :: BS.ByteString -> (Int, Int) parseHeader bs = let first = BS.readInt $ BS.dropWhile (not . isDigit) bs in if(isNothing first) then error "Couldn't find first natural." else let second = BS.readInt $ BS.dropWhile (not . isDigit) $ snd $ fromJust first in if(isNothing second) then error "Couldn't find second natural." else (fst $ fromJust first, fst $ fromJust second) This seems to work: > parseHeader $ BS.pack "hello 252 359" (252,359) Is there a better way? Cheers, -- Paulo Jorge Matos - pocm at soton.ac.uk http://www.personal.soton.ac.uk/pocm PhD Student @ ECS University of Southampton, UK

9 15