[Haskell-cafe] submenu doesn't seem to work properly in wxhaskell
Dear all, The following code doesn't seem to work properly. Either the main entry (m1/mp1) or it's sub menu entry (ms1/mps1) do not seem to propagate the event when pressed. It is possible to make it working by uncomments the lines where the menu commands are registered in the frame. I have the following two questions: 1. Why doesn't the plain code work. Am I missing something or doing something wrong? 2. Doesn't registering eventhandlers in the frame introduce a memory/resource leak, especially in the case of popups? Any suggestions or comments appreciated. Thanks. Kind regards, Maarten Code: imports gui :: IO () gui = do f - frame [ text := Hello world! ] m - menuPane [ text := Menu ] m1 - menuItem m [ text := Menu m1, on command := putStrLn menu m1] -- set f [ on (menu m1) := putStrLn menu m1 ] menuLine m sub - menuPane [text := Sub menu] ms1 - menuItem sub [ text := submenu ms1, on command := putStrLn submenu ms1 ] -- set f [ on (menu ms1) := putStrLn submenu ms1 ] menuSub m sub [ text := Sub ] menuItem m [text := Exit, on command := close f] set f [menuBar := [m], on mouse := mouseEvent f, clientSize := sz 200 200 ] return () mouseEvent f eventMouse = do case eventMouse of MouseRightDown mousePoint _ - doPopup f mousePoint _ - return () doPopup f mousePoint = do m - makePopupMenu f Popup Doesnt' work... menuPopup m mousePoint f objectDelete m makePopupMenu f c t = do mp - menuPane [ text := c ] mp1 - menuItem mp [ text := Popup mp1, on command := putStrLn popup mp1] -- set f [ on (menu mp1) := putStrLn popup mp1 ] menuLine mp sub - menuPane [text := more text] mps1 - menuItem sub [ text := Popup mps1, on command := putStrLn popup mps1] menuSub mp sub [ text := Sub ] -- set f [ on (menu mps1) := putStrLn popup mps1 ] return mp ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: irrefutable patterns for existential types / GADTs
John Meacham wrote: the reason being that id translates internally to id = /\a . \x::a . x since you cannot pull out an appropriate type to pass to id without evaluating the 'irrefutable' pattern, you end up with _|_ instead of 4. basically, allowing irrefutable matching on existentials would expose whether the underlying implementation performs type-erasure. even if an implementation does type erasure like ghc. suddenly odd things occur, like adding an unusned class constraint to a type signature might change the behavior of a program. (since it will suddenly have to pull out a dictionary) So you mean that id = /\a . \x :: a . x is /strict/ in its first argument, i.e. in the /type/ a. So to speak, type erasure is equivalent to strictness in all and every type argument. For an irrefutable existential pattern, the type argument should be lazy, of course. This allows you to pull out an appropriate type, only that it's pulled out only when needed. The point is that const c = /\a . \x :: a . c has no problems of being lazy in its type argument. Strictness in type arguments is of course a consequence of the fact that there is no _|_ type. A systematic way to add irrefutable pattern matches to existentials (or even GADTs) would therefore be the introduction of lazy type arguments (alas introduction of a type _|_). Type erasure then becomes a form of /strictness analysis/. I remember that Wadler's projection based strictness analysis can discover unused values and that's what happens very often with types as they are seldomly calculated with at runtime. So you can erase them by virtue of your strictness analyzer. Thinking further, this would even allow to free type classes from the dictionary approach: an overloaded function like (+) = /\a . \x :: a . \y :: a . x+y performs a case analysis on its type argument and selects the right specialized function. In case where this type is known at compile time, the /inliner/ will select the right specialization. This type based dispatch is more natural for type classes than dictionaries because the latter would in principle allow to supply different dictionaries for one and the same type. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell compiler from a USB Stick?
Hi all. Does anyone know of a Haskell compiler that will run from a USB stick? I think something like Hugs + minimal libraries + WinHugs should be small enough to install onto the stick, but I haven't tested this. That'd be the ideal scenario as I'm teaching Haskell (so won't need complicated libraries) on Windows (so user-friendliness is appreciated; terminals are something to avoid if at all possible). Has this/could this be done? Thanks in advance. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell compiler from a USB Stick?
Hi, I think something like Hugs + minimal libraries + WinHugs should be small enough to install onto the stick, but I haven't tested this. See MinHugs, http://cvs.haskell.org/Hugs/pages/downloading.htm, it should fit on a USB stick easily, just install it to the USB drive and you should be good to go. Its basically exactly what you asked for above - the desire was that students can install it on their home drives if their uni hasn't updated Hugs since 2001. I haven't tested this, and can't since my computer fried my USB stick, but if you have any bug reports either email them to me to the hugs-bugs list. Thinking of what could go wrong, the only thing I can think of is the registry won't exist, which causes WinHugs to start up with its defaults - and should be perfect for you. If this isn't acceptable for some reason, let me know what you need and I am sure it can be worked on. Thanks Neil That'd be the ideal scenario as I'm teaching Haskell (so won't need complicated libraries) on Windows (so user-friendliness is appreciated; terminals are something to avoid if at all possible). Has this/could this be done? Thanks in advance. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] collection monads
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? thanks, matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell compiler from a USB Stick?
Hello David, Tuesday, October 3, 2006, 2:17:33 PM, you wrote: Does anyone know of a Haskell compiler that will run from a USB stick? i'm ôäüùûå sure that both hugs and ghc will work. all that you need is to use full pathname of executable in cmdline, it should find other settings itself. or, you can run winhugs via an shortcut -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Either as a Monad instance
On Oct 3, 2006, at 03:49 , Ross Paterson wrote: On Tue, Oct 03, 2006 at 10:44:49AM +1000, Thomas Conway wrote: I've been [trying to] grapple with the various monads and transformers, and it occurs to me that the standard instance for Either as a monadic type is unnecessarily restrictive. Is there a compelling reason that it is not just instance Monad (Either e) where return = Right (Left e) = f = Left e (Right x) = f = f x abort = Left That is the definition one would expect, but the restriction was added so that the instance could include a definition of fail. It's evidence that including fail in Monad is a wart, IMO. Using strings to represent errors has severe limitations. Yes, having fail in the Monad is a horrible wart. And like some other warts in Haskell it was added to cure the symptom rather than the disease. :( -- Lennart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Either as a Monad instance
On Tue, Oct 03, 2006 at 07:52:54AM -0400, Lennart Augustsson wrote: Yes, having fail in the Monad is a horrible wart. And like some other warts in Haskell it was added to cure the symptom rather than the disease. :( Switching metaphors, what do you see as the disease in this case? (As far as I know, it's there for the translation of pattern match failure in do-expressions.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell compiler from a USB Stick?
Bulat Ziganshin [EMAIL PROTECTED] writes: Hello David, Tuesday, October 3, 2006, 2:17:33 PM, you wrote: Does anyone know of a Haskell compiler that will run from a USB stick? i'm ôäüùûå sure Блым? -- Jón Fairbairn [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Either as a Monad instance
Ross Paterson wrote: On Tue, Oct 03, 2006 at 07:52:54AM -0400, Lennart Augustsson wrote: Yes, having fail in the Monad is a horrible wart. (As far as I know, it's there for the translation of pattern match failure in do-expressions.) I think it would be much less of a wart if the signature for fail was just: fail :: m a because what's the point of the String argument anyway (other than trying to hack a kind of half-baked debug facility into the language)? Regards, 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell compiler from a USB Stick?
Jón == Jón Fairbairn [EMAIL PROTECTED] writes: Jón Bulat Ziganshin [EMAIL PROTECTED] writes: Hello David, Tuesday, October 3, 2006, 2:17:33 PM, you wrote: Does anyone know of a Haskell compiler that will run from a USB stick? i'm ôäüùûå sure Jón Блым? almost %-) Bulat accidently switched keyboard layout to russian :-) -- WBR, Max Vasin. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Mis-understanding something in Haskell interpretation
Hi, I am new to Haskell and am learning Haskell on my own with The Haskell School of Expression. Unfortunately there is no teacher that comes along with the book. I am having a problem with loading an excerise. I get this message from ghci on a :l Shapes.hs Shapes.hs:40:40: Couldn't match `Side' against `Int' Expected type: Side Inferred type: Int In the first argument of `sin', namely `angle' In the second argument of `(*)', namely `(sin angle)' Failed, modules loaded: none. The source is below. Side is types as Float. My assumption was that Haskell would know how to convert the Int to a float and all would be well. I am I mistaken somewhere? The problem is with the last line. Tips would be appreciated. Source Shapes.hs: module Shapes where data Shape = Rectangle Side Side | Ellipse Radius Radius | RtTriangle Side Side | Polygon [Vertex] deriving Show type Radius = Float type Side = Float type Vertex = (Float, Float) type Angle = Float rectangle :: Shape - Shape rectangle (Rectangle width height )= Polygon [(0, 0),(0, height), (width, height), (width, 0)] rtTriangle :: Shape - Shape rtTriangle (RtTriangle width height) = Polygon [(0,0),(0,height), (width, height)] regularPolygon :: Int - Side - Shape regularPolygon totalSides sideLength = let initial = (0.0,0.0) in Polygon (initial : vertices initial 1 totalSides sideLength ) vertices :: Vertex - Int - Int - Side - [Vertex] vertices _ 0 _ _ = [] vertices lastVertex currentSide totalSides length = let currentVertex = vertex lastVertex currentSide totalSides length in currentVertex: vertices currentVertex (totalSides - (currentSide + 1)) totalSides length vertex :: Vertex - Int - Int - Side - Vertex vertex (a ,b) currentSide totalSides length = let angle = 1.0 * (360 / totalSides) * currentSide in ( a + ( length * (sin angle)), b + ( (*) (cos angle) length ) ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mis-understanding something in Haskell interpretation
On 10/3/06, Edward Ing [EMAIL PROTECTED] wrote: The source is below. Side is types as Float. My assumption was that Haskell would know how to convert the Int to a float and all would be well. I am I mistaken somewhere? The problem is with the last line. Yes - Haskell does not automatically promote numeric types. In this case, the following code compiles: vertex :: Vertex - Int - Int - Side - Vertex vertex (a ,b) currentSide totalSides length = let angle = (360 / fromIntegral totalSides) * fromIntegral currentSide in ( a + ( length * (sin angle)), b + ( (*) (cos angle) length ) ) although I'm not sure it's exactly what you want. /g ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mis-understanding something in Haskell interpretation
Hello Edward, Tuesday, October 3, 2006, 9:44:27 PM, you wrote: Couldn't match `Side' against `Int' In the first argument of `sin', namely `angle' The source is below. Side is types as Float. My assumption was that Haskell would know how to convert the Int to a float and all would be well. I am I mistaken somewhere? The problem is with the last line. yes, Haskell don't make automatic conversions because together with bi-directional type inferring it will make a headache. let angle = 1.0 * (360 / totalSides) * currentSide in as Garret said, you should make conversions explicitly, hopefully the 'fromIntegral' function is enough in most cases -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Either as a Monad instance
It all came about because pattern matching failure sometimes cause a do expression to be in MonadZero rather than Monad with the old translation. This gave rise to confusing error messages, it was claimed. This was the disease. -- Lennart On Oct 3, 2006, at 08:28 , Ross Paterson wrote: On Tue, Oct 03, 2006 at 07:52:54AM -0400, Lennart Augustsson wrote: Yes, having fail in the Monad is a horrible wart. And like some other warts in Haskell it was added to cure the symptom rather than the disease. :( Switching metaphors, what do you see as the disease in this case? (As far as I know, it's there for the translation of pattern match failure in do-expressions.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: irrefutable patterns for existential types / GADTs
On Tue, Oct 03, 2006 at 12:10:52PM +0200, [EMAIL PROTECTED] wrote: So you mean that id = /\a . \x :: a . x is /strict/ in its first argument, i.e. in the /type/ a. So to speak, type erasure is equivalent to strictness in all and every type argument. For an irrefutable existential pattern, the type argument should be lazy, of course. This allows you to pull out an appropriate type, only that it's pulled out only when needed. The point is that const c = /\a . \x :: a . c has no problems of being lazy in its type argument. yeah, that is what I mean. however, since we don't have explicit type passing in haskell, reasoning about the lazyness of types would be quite tricky, leading to odd things like changing type signatures (without changing the underlying types) can change the behavior of a program. not to mention the optimizations that would be excluded by having to preserve the strictness in types behavior... worrying about it in values is tricky enough. :) It would actually not be difficult to add lazy types to jhc at all. I just don't see any use for them when dealing with haskell source. but another front end.. (omega or cayenne perhaps?) certainly might make use of them. Strictness in type arguments is of course a consequence of the fact that there is no _|_ type. A systematic way to add irrefutable pattern matches to existentials (or even GADTs) would therefore be the introduction of lazy type arguments (alas introduction of a type _|_). Type erasure then becomes a form of /strictness analysis/. I remember that Wadler's projection based strictness analysis can discover unused values and that's what happens very often with types as they are seldomly calculated with at runtime. So you can erase them by virtue of your strictness analyzer. this is actually exactly what jhc does. it is based on the lambda cube and makes no distinction between types and values, so there is no particular type erasure pass, but a lot of the types happen to be erased by run-time due to standard program transformations. Thinking further, this would even allow to free type classes from the dictionary approach: an overloaded function like (+) = /\a . \x :: a . \y :: a . x+y performs a case analysis on its type argument and selects the right specialized function. In case where this type is known at compile time, the /inliner/ will select the right specialization. This type based dispatch is more natural for type classes than dictionaries because the latter would in principle allow to supply different dictionaries for one and the same type. again, this is precicely how jhc implements type classes. There are numerous benefits, in particular a single scrutinization of a type will determine concrete methods for _every_ class used on that type, in effect you get run-time specialization for free. The huge disadvantage is that it does not play well nice at all with separate compilation, this is an active area of research for me in jhc. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Error building Edison 1.2.0.1
Hi folks, I tried to build edison-1.2.0.1-sources with the command 'make system' but got: *** Exception: Line 10: Unknown field 'hs-source-dirs' I am using GHC 6.4.1. Any idea how to fix this? Thanks, Lyle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] layout monads
Hi All, Next monad query [*] In the 1995 paper Composing Haggis, layout is done using a monad to compose individual elements. To modernize the syntax consider (forgive the operator, but it avoids parentheses): infixl 1 | f | x = f x mylayout = do hbox | do button ok button cancel It was nice, because you didn't need to worry about temporary structures, variable names, and suchlike. In the 1996 version of the paper, this silently changed to mylayout = do o - button ok c - button cancel hbox [o, c] Does anyone know why the change occurred? IMO, the former was much more elegant. Also, assuming you want to use a different underlying monad (e.g. IO), how would you implement a layout monad. FWIW, I'm not actually interested in widgets per se, but in building html pages in such a way that you can specify the style elements/scripts with the code that creates the nodes of the document tree, but serialize them separately. Tom * Maybe we need a [EMAIL PROTECTED] list. On second thoughts, no, because it would kill off the other mailingl lists. ;-) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error building Edison 1.2.0.1
On Tuesday 03 October 2006 22:00, Lyle Kopnicky wrote: Hi folks, I tried to build edison-1.2.0.1-sources with the command 'make system' but got: *** Exception: Line 10: Unknown field 'hs-source-dirs' I am using GHC 6.4.1. Any idea how to fix this? You are probably using an older version of Cabal. You can either upgrade Cabal or, from the Edison README*: This version of edison builds correctly with Cabal version 1.1.4, which is shipped with GHC 6.4.2. To build on earlier versions, it should suffice to: s/UndecidableInstances/AllowUndecidableInstances/ s/Hs-Source-Dirs:/Hs-Source-Dir:/ in the .cabal files. The 'hs-source-dir' cabal directive was depreciated in 1.1.4, but perhaps I should have waited a bit longer to change it. OTOH, there isn't any good way to deal with the change in the undecidable instances flag, since it was outright changed. G. *grumble* incompatible changes in minor releases *grumble*. (*) Further, g... in the above, I've fixed several embarrasing typos in the text of the README. Thanks, Lyle -- Rob Dockins Talk softly and drive a Sherman tank. Laugh hard, it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Error building Edison 1.2.0.1
Robert Dockins wrote: On Tuesday 03 October 2006 22:00, Lyle Kopnicky wrote: Hi folks, I tried to build edison-1.2.0.1-sources with the command 'make system' but got: *** Exception: Line 10: Unknown field 'hs-source-dirs' I am using GHC 6.4.1. Any idea how to fix this? You are probably using an older version of Cabal. You can either upgrade Cabal or, from the Edison README*: This version of edison builds correctly with Cabal version 1.1.4, which is shipped with GHC 6.4.2. To build on earlier versions, it should suffice to: s/UndecidableInstances/AllowUndecidableInstances/ s/Hs-Source-Dirs:/Hs-Source-Dir:/ in the .cabal files. The 'hs-source-dir' cabal directive was depreciated in 1.1.4, but perhaps I should have waited a bit longer to change it. OTOH, there isn't any good way to deal with the change in the undecidable instances flag, since it was outright changed. G. *grumble* incompatible changes in minor releases *grumble*. (*) Further, g... in the above, I've fixed several embarrasing typos in the text of the README. Oh, OK, thanks! Well, now I'm running GHC 6.5.20060924, and getting the error mentioned in my previous message. - Lyle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
