Re: [Haskell-cafe] type variable in class instance
On 11-09-12 08:53, o...@okmij.org wrote: Corentin Dupon wrote about essentially the read-show problem: class (Typeable e) = Event e data Player = Player Int deriving (Typeable) data Message m = Message String deriving (Typeable) instance Event Player instance (Typeable m) = Event (Message m) viewEvent :: (Event e) = e - IO () viewEvent event = do case cast event of Just (Player a) - putStrLn $ show a Nothing - return () case cast event of Just (Message s) - putStrLn $ show s Nothing - return () Indeed the overloaded function cast needs to know the target type -- the type to cast to. In case of Player, the pattern (Player a) uniquely determines the type of the desired value: Player. This is not so for Message: the pattern (Message s) may correspond to the type Message (), Message Int, etc. To avoid the problem, just specify the desired type explicitly I had the same idea, but it doesn't work. Fixing m to () causes the cast to fail for any other type, so viewEvent (Message yes :: Message ()) will work, but viewEvent (Message no :: Message Char) won't. Putting viewEvent in the Event class though, like Ryan suggested, seems to be an elegant solution that stays close to the original source. Cheers, Martijn case cast event of Just (Message s::Message ()) - putStrLn $ show s Nothing - return () (ScopedTypeVariables extension is needed). The exact type of the message doesn't matter, so I chose Message (). BTW, if the set of events is closed, GADTs seem a better fit data Player data Message s data Event e where Player :: Int- Event Player Message :: String - Event (Message s) viewEvent :: Event e - IO () viewEvent (Player a) = putStrLn $ show a viewEvent (Message s) = putStrLn $ show s ___ 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] Fwd: 'let' keyword optional in do notation?
On 09-08-12 10:35, Tillmann Rendel wrote: Hi, Martijn Schrage wrote: Would expanding each let-less binding to a separate let feel more sound to you? That was actually my first idea, but then two declarations at the same level will not be in the same binding group, so do x = y y = 1 would not compile. This would create a difference with all the other places where bindings may appear. But it would be in line with - bindings in the do notation, so maybe it wouldn't feel so wrong. It would absolutely be the easiest solution to implement, since as far as I can see, it requires only a small change to the parser. However, I still think it will be too confusing to have bindings that look the same as everywhere else but have different binding group rules. Especially since there is no reason for it from a semantic point of view (unlike when you mix in a monadic - binding, after which it makes sense to have a new binding group.) Anyhow, I'll submit it as a GHC feature request and see what happens. Cheers, Martijn Schrage -- Oblomov Systems (http://www.oblomov.com) Tillmann ___ 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] 'let' keyword optional in do notation?
Hi cafe, For a while now, I've been wondering why the 'let' keyword in a do block isn't optional. So instead of do ... let x = exp1 y = exp2 z - exp3 ... you could simply write do ... x = exp1 y = exp2 z - exp3 ... Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. The above probably also holds for list/monad comprehensions, but the explicit let has never really bothered me there. Cheers, Martijn Schrage -- Oblomov Systems (http://www.oblomov.com) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'let' keyword optional in do notation?
On 08-08-12 17:27, Ertugrul Söylemez wrote: Vo Minh Thu not...@gmail.com wrote: This is not a parsing problem, but a scoping one: try to run this program: main = do let x = y y = 5 let a = b let b = 6 print (x, y, a, b) Cheers, Thu Martijn has actually covered this question: Where each sequence of let-less bindings is put in a separate binding group. I'm no parsing wizard, but I couldn't come up with any situations in which this would cause ambiguity. To me, the let-less version is easier on the eyes, more consistent with - bindings, and also makes it less of a hassle to move stuff around. To make it more clear, this is the transformation I propose: do ...-- not a let-less binding x1 = exp1 -- \ .. -- only let-less bindings xn = expn -- / ...-- not a let-less binding becomes do ... let x1 = exp1 .. xn = expn ... So main = do x = y y = 5 a = b b = 6 print (x, y, a, b) would put everything in the same binding group and compile successfully. To get Thu's example, you would write main = do x = y y = 5 let a = b let b = 6 print (x, y, a, b) The last let could even be left out. Cheers, Martijn The suggestion seems sound to me, and the additional 'let' can really be annoying in cases where you have a lot of 'let' bindings among very few monadic actions. My current way to deal with this is to move the stuff to separate computations, but it's certainly not a nice solution: myComp = c = f where f x = ... where a = ... b = ... Greets Ertugrul ___ 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] Fwd: 'let' keyword optional in do notation?
On 08-08-12 19:01, Simon Hengel wrote: On Wed, Aug 08, 2012 at 12:22:39PM -0400, David Feuer wrote: Changing scoping rules based on whether things are right next to each other? No thanks. Would expanding each let-less binding to a separate let feel more sound to you? That was actually my first idea, but then two declarations at the same level will not be in the same binding group, so do x = y y = 1 would not compile. This would create a difference with all the other places where bindings may appear. However, having scope depend on things being next to each other (or rather, not having anything in between) is not new. Template Haskell declaration splices already cause separate binding groups for top-level declarations. Moreover, the new scope rule only holds for let-less bindings. If you use explicit lets nothing changes. -- Martijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal install fails due to recent HUnit
Hi Erik, A similar thing happened to me with the GraphViz package. As Duncan explained to me, the problem is that Cabal-1.10.0.0 (and I believe also 1.10.1.0) incorrectly reports an error when conditionals are used in test suites. Upgrading to Cabal-1.10.2.0 (or cabal-install-0.14.0 with Cabal-1.14.0) should fix the problem. Unfortunately, this means your build will not work on a fresh Haskell Platform v2012.2.0.0, until HUnit is patched in the hackage index. Cheers, Martijn Schrage -- Oblomov Systems (http://www.oblomov.com) On 18-07-12 16:26, Erik Hesselink wrote: Hi all, All cabal installs using cabal-install-0.10.2 are currently failing for us. This is due to the cabal file for HUnit-1.2.5.0, which was recently uploaded to hackage. The ouput I'm getting from cabal is just: Reading available packages... Resolving dependencies... cabal: Couldn't read cabal file HUnit/1.2.5.0/HUnit.cabal If I unpack HUnit-1.2.5.0 and call 'cabal configure', I get: cabal: HUnit.cabal:57: The 'type' field is required for test suites. The available test types are: exitcode-stdio-1.0 The relevant lines from the cabal file are: Test-Suite hunit-tests-optimize-0 Type: exitcode-stdio-1.0 These look fine to me. Does anyone have any idea how to go about fixing this (on hackage at least)? Could this package temporarily be removed, to avoid breaking everyone's cabal? Erik ___ 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] Cabal install fails due to recent HUnit
On 18-07-12 17:37, Erik Hesselink wrote: Hi Martijn, Yes, upgrading will obviously fix things (we do use 0.14 on our development machines) Well, to me it wasn't entirely obvious that upgrading to Cabal-1.10.2.0 fixes the problem for cabal-install-0.12, and I still think this is a good solution for most people that use version 2012.2.0.0 of the platform. I'd suggest you ask Duncan to patch the hackage repository, and maybe contact the maintainer of HUnit to prevent future problems. -- Martijn , but we have not set up any infrastructure for building a custom cabal on production servers. We just use the one from the Ubuntu repositories, which uses Cabal 1.10.1.0 on oneiric. So until we upgrade to precise I guess we have a problem. Erik On Wed, Jul 18, 2012 at 5:24 PM, Martijn Schrage mart...@oblomov.com wrote: Hi Erik, A similar thing happened to me with the GraphViz package. As Duncan explained to me, the problem is that Cabal-1.10.0.0 (and I believe also 1.10.1.0) incorrectly reports an error when conditionals are used in test suites. Upgrading to Cabal-1.10.2.0 (or cabal-install-0.14.0 with Cabal-1.14.0) should fix the problem. Unfortunately, this means your build will not work on a fresh Haskell Platform v2012.2.0.0, until HUnit is patched in the hackage index. Cheers, Martijn Schrage -- Oblomov Systems (http://www.oblomov.com) On 18-07-12 16:26, Erik Hesselink wrote: Hi all, All cabal installs using cabal-install-0.10.2 are currently failing for us. This is due to the cabal file for HUnit-1.2.5.0, which was recently uploaded to hackage. The ouput I'm getting from cabal is just: Reading available packages... Resolving dependencies... cabal: Couldn't read cabal file HUnit/1.2.5.0/HUnit.cabal If I unpack HUnit-1.2.5.0 and call 'cabal configure', I get: cabal: HUnit.cabal:57: The 'type' field is required for test suites. The available test types are: exitcode-stdio-1.0 The relevant lines from the cabal file are: Test-Suite hunit-tests-optimize-0 Type: exitcode-stdio-1.0 These look fine to me. Does anyone have any idea how to go about fixing this (on hackage at least)? Could this package temporarily be removed, to avoid breaking everyone's cabal? Erik ___ 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] [ANNAUNCE] ghcjs-0.1.0 Haskell to Javascript compiler
On 02-11-10 18:57, Aaron Gray wrote: On 2 November 2010 14:00, Martijn Schrage mart...@oblomov.com mailto:mart...@oblomov.com wrote: On 01-11-10 22:35, Aaron Gray wrote: Right, FF seems okay now on Vista too. Chrome :- ... It works on Firefox, Chrome and Safari now, both on Windows and Mac. The IE problems seem a bit more subtle, as the script goes into an infinite loop. Great, thanks, I will check it out later when I get some time. Aaron Ok, after a bit of nasty IE Javascript debugging, I got it to work on IE8 as well. This only holds for the example at http://tryout.oblomov.com/ghcjs/ghcjs.html though. The ghcjs sources still need to be updated. Until then, you might run into some other problems using IE when building more fancy examples. -- Martijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNAUNCE] ghcjs-0.1.0 Haskell to Javascript compiler
On 01-11-10 22:35, Aaron Gray wrote: On 1 November 2010 16:04, Martijn Schrage mart...@oblomov.com mailto:mart...@oblomov.com wrote: On 29-10-10 22:20, Aaron Gray wrote: ... What browser are you using, IE8, IE9, FF and Chrome on Windows throw up errors, both locally and to your above code. That's weird, since http://tryout.oblomov.com/ghcjs/ghcjs.html works fine for me with Firefox both on Mac and Windows (XP 7). There is only a small bug that causes a key event to get lost when the Haskell JavaScript modules are loaded. What error messages do you get from Firefox? Right, FF seems okay now on Vista too. Chrome :- ... It works on Firefox, Chrome and Safari now, both on Windows and Mac. The IE problems seem a bit more subtle, as the script goes into an infinite loop. -- Martijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNAUNCE] ghcjs-0.1.0 Haskell to Javascript compiler
On 29-10-10 22:20, Aaron Gray wrote: On 27 October 2010 13:30, Martijn Schrage mart...@oblomov.com mailto:mart...@oblomov.com wrote: On 21-10-10 01:01, Victor Nazarov wrote: This example creates a text field that turns red if it contains any non-digit characters. It is on-line at http://tryout.oblomov.com/ghcjs/ghcjs.html (Note: I only tested it on Firefox on a Mac) All used files are in a zip file at http://tryout.oblomov.com/ghcjs/ghcjs.zip (validate is in Test.hs, the JS monad in JS.hs, and the JavaScript for execHaskell in util.js) What browser are you using, IE8, IE9, FF and Chrome on Windows throw up errors, both locally and to your above code. That's weird, since http://tryout.oblomov.com/ghcjs/ghcjs.html works fine for me with Firefox both on Mac and Windows (XP 7). There is only a small bug that causes a key event to get lost when the Haskell JavaScript modules are loaded. What error messages do you get from Firefox? -- Martijn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [ANNAUNCE] ghcjs-0.1.0 Haskell to Javascript compiler
On 21-10-10 01:01, Victor Nazarov wrote:
I've been working on this for some month and I think now I'm ready to
share the results.
Great stuff! I've been looking for something like this for a long time.
If you add || transport.status == 0 to line 90 of
examples/rts-common.js, it also works on a local file system.
I played around with it a bit to see how easy it was to call JavaScript
from Haskell, and it turned out to be straightforward. With a little
guessing, I constructed a JavaScript representation of a thunk, which
evaluates its string argument as a JavaScript expression and returns the
resulting string to Haskell. This thunk can be passed to the
JavaScript-compiled Haskell function. To pass it around in Haskell and
force its evaluation, I constructed a simple monad.
Now, on your web page, you can do something like:
input type=text onkeyup=execHaskell('validate') id=inputField/
and in a Haskell module:
validate :: JS ()
validate =
do { inputValue - eval document.getElementById('inputField').value
; exec $
document.getElementById('inputField').style.backgroundColor=++
color inputValue
}
where color str = if and (map isDigit str) then 'white' else 'red'
This example creates a text field that turns red if it contains any
non-digit characters. It is on-line at
http://tryout.oblomov.com/ghcjs/ghcjs.html (Note: I only tested it on
Firefox on a Mac)
All used files are in a zip file at
http://tryout.oblomov.com/ghcjs/ghcjs.zip (validate is in Test.hs, the
JS monad in JS.hs, and the JavaScript for execHaskell in util.js)
Cheers,
Martijn Schrage -- Oblomov Systems
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
