- Haskell-Cafe - Haskell.org

Need help to get GTK bindings working
by mgross＠dorsai.org 19 Aug '01

19 Aug '01

I've got ghc5 running, have downloaded all the documented bits and pieces for the GTK bindings, done the compiles, modifed the package.conf file (probably incorrectly, since I haven't been able to find complete documentation on the contents of that file), and am having a variety of difficulties--like reported missing exports (which aren't missing from the .hi file), etc. Would some kind soul out there be willing to do a bit of hand holding off list to get this thing working? After the job is done, we can post the results as instructions for others to follow. Thanks in advance. Murray Gross mgross(a)dorsai.org

2 1

Re: Subtyping
by Ashley Yakeley 19 Aug '01

19 Aug '01

At 2001-08-18 17:29, Mansour Al-Mutairi wrote: >data SomeObject2 = SO SomeObject | SomeReal Double ... >same2 :: SomeObject2 -> SomeObject2 -> Bool >same2 (SomeReal a) (SomeReal b) = a == b >same2 x y = same x y This won't help you if you already have modules that use 'SomeObject' and 'same'. In OOP you can extend a 'Base' class in module M1 with a 'Derived' class in module M2. M1 knows nothing about 'Derived', and yet code in M1 that manipulates 'Base' objects will be able to handle 'Derived' objects, since every 'Derived' object is also a 'Base' (upcasting). Furthermore it is possible for M2 to determine whether a 'Base' object from a function or structure in M1 is also a 'Derived' object and use it appropriately (downcasting). You can't do this in Haskell (or O'Haskell for that matter), though you could with extensible data-types: module M1 where data Base = _ foo :: Base -> Integer foo _ = 0 module M2 where data Derived = MyDerived Int Char data Base |= DerivedBase Derived foo (DerivedBase (MyDerived i _)) = i upcast :: Derived -> Base upcast = DerivedBase downcast :: Base -> Maybe Derived downcast (DerivedBase d) = Just d downcast _ = Nothing -- Ashley Yakeley, Seattle WA

1 0

Re: Subtyping
by Ashley Yakeley 19 Aug '01

19 Aug '01

At 2001-08-18 06:15, Marcin 'Qrczak' Kowalczyk wrote: >Later additions to the function would have to be restricted to match >at least one constructor defined in the current module, to make the >combined definition independent of the order of additions - modules >are by nature unordered. Agreed. >And something more - this is not enough for >unambiguous definition: > -- Base definition > foo :: SomeObject -> SomeObject -> Int > foo _ _ = 0 > -- Module 1 > foo (SomeInt a) _ = 1 > -- Module 2 > foo _ (SomeString a) = 2 > -- Which argument is evaluated as the first? > -- What is called for foo (SomeInt 0) (SomeString "")? The first argument would take priority. So Haskell would assemble these cases in this order: foo (SomeInt a) _ = 1 foo _ (SomeString a) = 2 foo _ _ = 0 If Module 2 included Module 1, it could do this: -- Module 2 foo _ (SomeString a) = 2 foo (SomeInt a) (SomeString a) = 2 In which case, the cases would be assembled in this order: foo (SomeInt a) (SomeString a) = 2 foo (SomeInt a) _ = 1 foo _ (SomeString a) = 2 foo _ _ = 0 -- Ashley Yakeley, Seattle WA

1 0

Re: Subtyping
by Marcin 'Qrczak' Kowalczyk 18 Aug '01

18 Aug '01

Sat, 18 Aug 2001 01:05:17 -0700, Ashley Yakeley <ashley(a)semantic.org> pisze: > One possible solution would be to extend Haskell with "open" > algebraic data types. > This seems to me straightforward, but perhaps not very useful unless > there's a way of declaring "generic" functions on these types that > can be extended somehow later: Indeed. Later additions to the function would have to be restricted to match at least one constructor defined in the current module, to make the combined definition independent of the order of additions - modules are by nature unordered. And something more - this is not enough for unambiguous definition: -- Base definition foo :: SomeObject -> SomeObject -> Int foo _ _ = 0 -- Module 1 foo (SomeInt a) _ = 1 -- Module 2 foo _ (SomeString a) = 2 -- Which argument is evaluated as the first? -- What is called for foo (SomeInt 0) (SomeString "")? > But would this sort of thing solve your problem? Yes, although now I think that this use would be equivalent to using Dynamic, only with a prettier syntax. There is a particular case which could make use of extensible functions and can't be simulated with Dynamic, but I would use a different solution anyway (the same as I would use now with Dynamic) - for speed. The situation is as follows: The interpreted language (BTW, designed and implemented purely for fun, no serious external reason) introduces the concept of type in the standard library. A type is represented as a symbol (term without arguments). Unique symbols are born by calling a builtin function, and obtaining bindings is generally associated with executing some code (like value bindings in ML). How a type is determined: - Function is called with a distinguished argument (Type) and is supposed to return its type. - Terms have types depending on their symbol, looked up in a dictionary. - Integers and strings have types Integer_t, String_t. Type are used to look up definitions of generic functions in dictionaries, usually depending on the first argument. There is also a dictionary of supertypes, so e.g. equality on Bool_t uses the implementation of equality on Term_t if not defined directly. Suppose that arbitrary foreign Haskell objects would be included in values, wrapped as Dynamic. How to determine the type of such an object? It's trivial to return a generic Haskell_t, but there is no way to make further classification otherwise than invoking foreign functions checking for particular Haskell types in sequence (the functions would have to be registered somehow). With open algebraic types it can be done. Just define a generic function for returning the type, and populate its definition in modules providing particular foreign object types. Fortunately it can be done better than both solutions and it's compatible with Dynamic. Just include a representation of type in the value, along with Dynamic holding the actual object. Since most actions on such object would begin with determining its type, it's good to have it ready instead of looking it up in a dictionary. It requires foresight that checking types of foreign objects will be needed, but well, I indeed know now that it's needed. And it's enough. Since type is used for classification to the granularity equivalent to Haskell types sitting inside the Dynamic, further dispatching can be done in the language proper, looking up the type in dictionaries, as for all its generic functions, and they will usually assume a concrete Haskell type inside the Dynamic. It happens that the language uses open algebraic types itself, only without static typechecking. All algebraic types are open: one can always register more symbols for a particular type, or produce functions which return such type for a Type request (it can be considered lying about their types). But expect that registering something non-standard as a Bool_t and passing it to functions expecting a Bool_t will usually surprise these functions and many of them will refuse to work. There is a continuum between making new types and using open algebraic types. Constructors for exceptions are born as other terms with unique symbols. You can either register them under a generic Exception_t type or give them new types; it doesn't matter for how they are caught if all these types use the same generic pattern matching implementation for Term_t. Either way you can implement patterns which perform matching in any fancy way (e.g. look up in a hierarchy of exception symbols they maintain). -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Subtyping
by Ashley Yakeley 18 Aug '01

18 Aug '01

At 2001-08-14 03:46, Marcin 'Qrczak' Kowalczyk wrote (on the Libraries list): >> I've noticed that the more I use Haskell, the less I miss >> subtyping... classes and "data" unions are almost always sufficient. > >They are sometimes a better match than subtyping (e.g. parametrizing >a gcd algorithm by a type) and sometimes they are not capable at all >(e.g. heterogeneous collections when the set of possible types is >open). I'm a big fan of Haskell's typing and I'm not a fan of OOP, >but Haskell is sometimes not as expressible as the OO way. One possible solution would be to extend Haskell with "open" algebraic data types. For instance: data SomeObject = SomeInt Int | SomeString String | _ ...later... data SomeObject |= SomeReal Double The "_" would mark a data type as 'open', and the "|=" syntax would be used to extend it in another module. This seems to me straightforward, but perhaps not very useful unless there's a way of declaring "generic" functions on these types that can be extended somehow later: same :: SomeObject -> SomeObject -> Bool same (SomeInt a) (SomeInt b) = a == b same (SomeString a) (SomeString b) = a == b same _ _ = False ...later... same (SomeReal a) (SomeReal b) = a == b -- this case needs to be "inserted" somehow But would this sort of thing solve your problem? -- Ashley Yakeley, Seattle WA

1 0

Emacs
by Mark Carroll 18 Aug '01

18 Aug '01

Is it just me, or does haskell-indent-mode sometimes have some surprising ideas about how much to indent? That Haskell modes exist at all is wonderful. (-: -- Mark

1 0

Re: Deep confusion about monads
by Mark Carroll 18 Aug '01

18 Aug '01

Gosh, thank you everybody! Let me try to summarise where I am, given all the help. haskell-cafe is an okay place to ask this stuff. (-: I should also check out the wiki too; it looked a bit scary to use last time I looked, but it seems to have relevant stuff. It's a pity that the mailing list archives aren't more easily searched; maybe applying google to them would work. Part of my confusion was due to a usual problem with teaching. People come in to a lesson with preconceived ideas X, the teacher tells them stuff Y, and instead of coming out of the lesson thinking Y, they come out thinking f(X,Y), because the teacher didn't tell them not-X. It's instructional to ask children where they think trees' mass comes from as they grow, after a lesson on the subject. I originally thought that "IO a" meant "an a whose value may depend on some IO that was done", as if that data were tainted by other data it touched which stemmed from IO actions. Instead, "IO a" it appears to mean "some IO action you can do that will give an a", and you can only do stuff with the "a" within an "IO-aware" context. A Haskell program is an IO action. I got the idea of tainted data from Perl, which is a security aid to help you ensure that any data drawn from outside your program has to be approved by you before your program can use it to affect other things outside your program. Try to keep most code functional, even if this means that your monadic code uses very complex referentially-transparent helper functions. I hadn't bumped into Theo Norvell's monad tutorial yet. I'm guessing that it's the one at http://www.engr.mun.ca/~theo/Misc/haskell_and_monads.htm ? I'll take a look. There is a concept of being in the IO monad. My current concept of "A >>= B" is that it helps let B into the monad that A's in. This is how 'head' is let in by readFile "/etc/hosts" >>= (return . head) I find fmap deeply strange, though, because I don't really understand functors. People pointed me towards fmap, and I figured from IO's instance of Functor that fmap head $ readFile "/etc/hosts" also works, so I plan to learn a little category theory to help find out why this makes sense. (Someone also taught me how to use $. (-:) >>= actually has the type (Monad m) => m a -> (a -> m b) -> m b That makes some sense. I get >> and the syntactic sugar of 'do' looks fairly simple so I'll probably start using that more once I'm happy with the translation between that and >>= All the best, Mark

1 0

RE: Namespace clashes
by brk＠jenkon.com 17 Aug '01

17 Aug '01

> -----Original Message----- > From: Mark Carroll [SMTP:mark@chaos.x-philes.com] > Sent: Wednesday, August 15, 2001 10:11 PM > To: haskell-cafe(a)haskell.org > Subject: Namespace clashes > > When I use Haskell, I'm still tripping over reserved words; lately I tried > to use 'type' as a data field name, for example, and was somewhat > irritated to note that I can't. (Can I?) What gives me the willies is that > [Bryn Keller] Personally, I don't mind this sort of thing and I find the import capabilities in Haskell sufficient for most purposes. However, I'm new enough to Haskell that I sometimes have a hard time figuring out what I've done wrong from the error messages. Here's one such: func x = do data <- readFile x return data Where the problem is that I've mistakenly used the reserved word 'data' for a name binding. Here's the error message I get for that: scratch.hs:3: Empty 'do' construct But I'm learning. :-)

2 1

Deep confusion about monads
by Mark Carroll 17 Aug '01

17 Aug '01

Let me know if I'm bugging you guys too much. It'd be great if I had someone close at hand who knew more about Haskell than I do, but unfortunately I don't. Are there any fora that are especially for people to help novices, or is haskell-cafe the best fit? I decided I ought to learn more about monads, so I've been trying to do simple IO. However, I'm running into really basic problems that I haven't managed to solve with the three monad tutorials I've read so far! First, given an IO String, I don't seem to be able to take the head of it to get an IO Char. I'm guessing that the IO monad is quite unlike the simple 'tainting' I first imagined; I reall do seem to have to treat it as an abstract polymorphic type. Worse, I can't work out how to write a IO String -> IO Char version of head; I can't make my (x:xs) match an IO String! Better would be if I could somehow write an IO String -> IO Char wrapper for head. I'm also confused as to why I can write: readFile "/tmp/foo" >>= putStr to print out the contents of a file but, in ghci, let x = readFile "/tmp/foo" putStr x ...doesn't work. Then again, I'm also confused by the way that Simon Thompson's book says that, (>>=) :: IO a -> (a -> IO a) -> IO a which I think might be a misprint for, (>>=) :: IO a -> (a -> IO b) -> IO b ...? I'm not sure if I've explained enough of my confusion that a succinct, helpful response not mentioned in what I've read so far can be easily given. I guess that my problem is that I had initially imagined that the prefix 'IO' appears as a magical tainting of any data that could depend on the result of some IO action. However, I'm coming to the conclusion that I'm quite wrong in this. I'd like to be able to manipulate IO Strings as if they were just strings that I can't forget came from IO, but I'm guessing now that things aren't that simple - they really are quite different to strings, yet I want to avoid resorting to unsafePerformIO. The really annoying thing is that all the monad examples I've read so far have made perfect sense to me. (-: What I'm really hoping is that a simple answer as to how best to arrange my IO String -> IO Char (or IO [a] -> IO a) version of head will somehow resolve a lot of my confusion. For instance, maybe I have to somehow write an 'action' version of head that I apply with the help of >>= ? -- Mark

4 6

Re: Deep confusion about monads
by Ashley Yakeley 17 Aug '01

17 Aug '01

At 2001-08-16 16:30, I wrote: >>(>>=) :: IO a -> (a -> IO b) -> IO b > >This one is correct. Whoops! No it's not. It should be: (>>=) :: (Monad m) => m a -> (a -> m b) -> m b The other two are however special cases of this type. -- Ashley Yakeley, Seattle WA

1 0