- Haskell-Cafe - Haskell.org

manage effects in a DSL
by Corentin Dupont 28 Jan '14

28 Jan '14

Hi Haskell-Caféists! I have a small DSL for a game. Some instructions have effects (change the game state), some not. -> In short, my question is: how can I semantically separate instructions with effect from the others? i.e. how can I mark down and track those effects? Here is a simplified version of the DSL I use. First some boilerplate: > {-# LANGUAGE GADTs #-} > import Control.Monad > import Control.Monad.State > import Control.Monad.Free This is the DSL: > data Exp a where > ReadAccount :: Exp Int > WriteAccount :: Exp Int -> Exp () > SetVictory :: Exp Bool -> Exp () > OnTimer :: Exp () -> Exp () > Return :: a -> Exp a > Bind :: Exp a -> (a -> Exp b) -> Exp b It can read and write to an account (belonging to the state of the game), set a victory condition, and trigger some event every minute. > instance Monad Exp where > return = Return > (>>=) = Bind > instance Functor Exp where > fmap f e = Bind e $ Return . f With that you can write: > victoryRule :: Exp () > victoryRule = SetVictory $ do > m <- ReadAccount > return (m > 100) "victoryRule" sets the victory condition to be: "if there is more than 100 gold in the account, you win." This is the game state: > data Game = Game { bankAccount :: Int, > victory :: Exp Bool, > timerEvent :: Exp ()} The evaluation of "Exp" can be: > eval :: Exp a -> State Game a > eval (SetVictory v) = modify (\g -> g{victory = v}) > eval ReadAccount = get >>= return . bankAccount > eval _ = undefined -- etc. If you evaluate "victoryRule", you change the Game state by setting the victory field. Then, each time you will evaluate the victory field, you will know if you won or not (depending on your account...). This is all well and good, but imagine if you write: > victoryRule' :: Exp () > victoryRule' = SetVictory $ do > m <- ReadAccount > WriteAccount (return $ m + 1) > return (m > 100) Ho no! Now each time a player is refreshing his screen (on the web interface), the victory condition is re-evaluated to be displayed again, and the bank account is increased by 1! This is not what we want. We should allow only effect-less (pure) instructions in the victory field, like readAccount, but not WriteAccount. How would you do that? I tried with the Free monad to delimit those effects. I re-write each primitives, marking them with the special type "Effect", when needed. > type Effect = Free Exp > -- readAccount remain the same: it has no effect > readAccount :: Exp Int > readAccount = ReadAccount > --writeAccount is marked as having an effect > writeAccount :: Exp Int -> Effect (Exp ()) > writeAccount ei = Pure $ WriteAccount ei > --onTimer is able to trigger an effect every minute > onTimer :: Effect (Exp ()) -> Effect (Exp ()) > onTimer e = Pure $ OnTimer $ iter join e > --victoryRule can be re-written like this, note that effects are rejected now > victoryRule'' :: Effect (Exp ()) > victoryRule'' = Pure $ SetVictory $ do > m <- readAccount > --writeAccount (return $ m + 1) --will be rejected at compile time (good)! > return (m > 100) > --increase my bank account by 1 every minute > myTimer :: Effect (Exp ()) > myTimer = onTimer $ do > m <- lift readAccount > writeAccount (return $ m + 1) I don't know if I got it right at all... How does it sound? It only bothers me that in this context "Pure" really means "Impure" :) Do you think of any other solution? Cheers, Corentin

4 5

Munich Haskell Meeting
by Heinrich Hördegen 28 Jan '14

28 Jan '14

Dear all, I hope that you had good start into 2014. Munich's Haskell enthusiasts (or other declarative languages) meet for their first get-together in 2014 on Thu, 30th of January at 19h30 at Cafe Puck. If you plan to join, please go here and hit the button: http://www.haskell-munich.de/dates With my best wishes for this year, Heinrich

1 0

[ANN]: arb-fft 0.1, Fast Fourier transform library
by Ian Ross 27 Jan '14

27 Jan '14

Dear Cafe, I'm happy to announce the first release of arb-fft, a pure Haskell FFT implementation for arbitrary length vectors: http://hackage.haskell.org/package/arb-fft This is probably more of pedagogical interest than anything else, since there's a long series of blog articles describing the development of the package, indexed at http://skybluetrades.net/haskell-fft-index.html The package has some interesting features beyond the usual "textbook" powers-of-two FFT algorithm. In particular, it uses a mixed-radix decomposition of composite input lengths, uses Rader's algorithm for large prime factors and has an empirical benchmarking scheme using Criterion for FFT plan selection. The performance of arb-fft is within a factor of 10 of FFTW for most input sizes, which isn't too bad for a pure Haskell with only a relatively limited amount of work done on optimisation. Commentary is very welcome, as are offers to help with any of the tasks listed in the last blog article: http://skybluetrades.net/blog/posts/2014/01/27/data-analysis-fft-14.html Hackage: http://hackage.haskell.org/package/arb-fft GitHub: https://github.com/ian-ross/arb-fft Blog article index: http://skybluetrades.net/haskell-fft-index.html -- Ian Ross Tel: +43(0)6804451378 ian(a)skybluetrades.net www.skybluetrades.net

3 2

Announcement - HGamer3D release candidate 0.3.0
by Peter Althainz 27 Jan '14

27 Jan '14

Dear All, I'm happy to announce HGamer3D, version 0.3.0 as a release candidate on Github. Please look here: http://www.hgamer3d.org and https://github.com/urs-of-the-backwoods/HGamer3D . The new version features: - Linux ! (in addition to Windows) - HBind tool to generate and administrate bindings Of course I would be largely interested in feedback for the final release of 0.3.0. Best regards Peter Althainz

1 0

Target Selection in HaRe
by AlanKim Zimmerman 27 Jan '14

27 Jan '14

The Haskell Refactorer now makes use of the GHC API to load and typecheck the code to be refactored. It uses ghc-mod internally to identify a project cabal file, and extract the targets in it. The current code attempts to load all the targets into the module graph, to make sure that when a project is refactored the ancillary parts such as tests and benchmarks are refactored too, e.g. when renaming a function. The problem is that GHC is unable to load more than one main file. I am trying to decide on the best way of resolving this in terms of a user of HaRe, where it should 'just work' most of the time. The actual refactoring is done by calling the HaRe executable with command line arguments. Options that seem viable are 1. require the names of the target(s) to be loaded to be passed in as command line arguments. This means the IDE integration is going to have to provide a way of deciding the scope of the refactoring. 2. Create a config file that lives in the project directory and specifies the targets to be loaded 3. Try to build up a union of the module graph for all the targets, excluding all main modules. The problem with this is that it then becomes difficult to refactor a main module. 4. A different option, or blend of the above.e.g. load the union but specify the specific main module. Does anyone have any preferences in terms of this? Alan

2 4

Haddock changes pushed upstream
by Mateusz Kowalczyk 27 Jan '14

27 Jan '14

Hi all, As some of you might know, I hacked on Haddock over summer as part of GSOC. After some tedious fighting with GHC validation process and help of the guys on ghc-devs, the changes were finally pushed upstream couple of hours ago. While I'm waiting for the maintainer to make a call on the official release, you can already get the changes if you compile GHC HEAD. For those not so eager about compiling HEAD, 7.8 should be coming out the changes will be in that. You can read the brief changelog at [1] and the updated documentation at [2]. We were careful to not make changes to any existing syntax that would result in a large amount of packages breaking. If you're a package maintainer, here are some things to consider: * If your documentation looks fine how it is now, you're probably fine. Read the changelog[1] as it mentions some issues that were fixed. Amongst others, Haddock will now link qualified function names properly so that's something to look out for. * none of your documentation should get parse failures: any previously-failing documentation should now be displayed. This means that if you have parse failures, now is the time to go and fix them up or your documentation probably won't look pretty. On an upside, this means that we won't have whole Hackage packages missing documentation due to a minor mistake in one of the comments. * You no longer need to break up lists of the same type with newlines. Previously you'd get two lists merged on a single line in an incoherent mess. Now it'll be rendered properly. I know that even GHC documentation is guilty of this mistake. * You can now escape the markup properly. Before, you were very limited on how the markup could be escaped. For example, <<foo ba\>r>> would result in a parse failure. * Bold markup added. The syntax is two underscores around what you want bold. Note, we still do not support multi-line markup. It's possible but it's a design choice not to support it. * You previously have gotten a document coverage report. We now have --print-missing-docs flag which will also tell you where the undocumented entities are: ``` ✓ misaki shana % haddock -h -U F.hs --print-missing-docs -o . Haddock coverage: 33% ( 2 / 6) in 'F' Missing documentation for: Baz (F.hs:5) Bar (F.hs:6) Foo (F.hs:7) add ``` * You can now nest paragraphs inside of lists. For most people this simply means that you can now have multiple levels of lists. We allow arbitrary nesting depth. The rules are: 4 spaces of indentation, new paragraphs have to be preceded by an empty line. ``` 1. Foo 1. Nested inside of Foo 2. Another thing inside of Foo >>> example inside of Foo example result 2. Back after Foo ``` * You can now have headings inside of your documentation rather than only for splitting up sections of your module. Example usage: ``` = Heading level one >>> some code example hello == Heading level two * Hello Haddock! ``` Up to 6 ‘=’s are currently supported. LaTeX back-end only honours up to three ‘=’s but it is not an error to have >3, they'll simply be treated as 3. * You can now display enabled module extensions in the generated documentation with {-# OPTIONS_HADDOCK show-extensions #-}. * Picture syntax now documented. * You can now have the title attribute for your hyperlinks. The syntax is <link title> I think that about covers it all. Perhaps I will write a more visual guide to the new changes but please don't hold your breath! Feel free to ask questions. If you have bugs to report or features to ask for, please head to the Haddock Trac[3]. [1]: http://www.haskell.org/haddock/CHANGES.txt [2]: http://www.haskell.org/haddock/doc/html/ [3]: http://trac.haskell.org/haddock -- Mateusz K.

5 9

hoogle - find functions as arrows?
by Gregory Guthrie 27 Jan '14

27 Jan '14

I was surprised that a Hoogle search for: (a -> b) -> (a -> c) -> a -> (b, c) No results found Didn't find this: (&&&)<http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Ar…> :: Arrow a => a b c -> a b c' -> a b (c, c')<http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Ar…> Since functions are arrows; yes? I suppose I can see why it might not, but it seems that it would be nice if it did.

1 0

evaluating CAFs at compile time
by Evan Laforge 27 Jan '14

27 Jan '14

So I have a large CAF which is expensive to generate. Theoretically it should be possible to totally evaluate at compile time, resulting in a bunch of constructor calls, ideally totally de-thunked and in the read-only segment of the binary. In the absence of a "eval at compile time" pragma, it seemed like TH should be able to do this, and searching haskell-cafe I turned up an old post by Wren where he is doing basically that, and eventually discovered the Lift class in http://hackage.haskell.org/package/template-haskell-2.8.0.0/docs/Language-H… However, if I understand Lift correctly (and not really understanding much of TH), you need to create instances for every type you wish to generate, which seems like it would be a pain. Even if they can be automatically derived, it would spread TH dependency gunk throughout the whole program. Is this true? Is there a library that does the equivalent of a "eval at compile time" pragma? (Wren's proposed QAF library seems to have never made it to hackage, but maybe given Lift and the proper instances it turns out to be trivial.) Would it be possible or desirable for an actual pragma that wouldn't introduce a TH dependency? Also, I assume it would produce a giant set of constructor applications which ghc would then optimize as well as it can... but it seems like that might not include full strictness, since even 'x = (4, undefined)' is obliged to not diverge as long as you don't look at the snd field, so even a large literal expression is actually unevaluated code if there are some non-strict data types in there. And... is it actually possible for ghc to do clever optimization with constant values, i.e. lay them out fully evaluated in read-only memory? I know that something like 'x = "abc" ++ "def"' will wind up as 'unpackCString# "abcdef"', but I'm curious what happens to more complicated data structures. Strictness seems to make a difference, e.g. with nonstrict fields the core has separate bindings for the contained values, while with strict ones the values get inlined directly into the consumer of the data type and the constructor is nowhere to be seen. But if the type is recursive (data X = X Int (Maybe X)), then we wind up with CAFs applying it, though they have lots of provocative flags that indicate ghc knows it's dealing with constructors: Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=True, ConLike=True, WorkFree=False, Expandable=True, Guidance=IF_ARGS [] 10 30}] I assume it still can't hoist the undefined to the entire expression though, because of non-strictness. I would think that if all data types are strict, then it could transform 'caf = X 42 (StrictJust (X 24 undefined))' to 'caf = undefined', but that doesn't seem to happen either. Tangentially, I've noticed that the 'unpackCString# "abcdef"' optimization is limited to String, replacing it with Text produces "abc" + giant wodge of code that is presumably appending "def" at runtime. I'm sure I've seen some discussions around here about wanting to optimize string literals to 'Text 0 len (giant chunk of binary data)', but I don't think they talked about possible compile time evaluation... presumably it could also solve that problem?

4 8

Arithmetic overflow
by Rob Leslie 24 Jan '14

24 Jan '14

Greetings, I have a question about arithmetic overflow in Haskell -- actually, probably specifically in GHC. It’s my understanding from the Haskell 2010 Language Report that “The results of exceptional conditions (such as overflow or underflow) on the fixed-precision numeric types [e.g. Int] are undefined; an implementation may choose error (⊥, semantically), a truncated value, or a special value such as infinity, indefinite, etc.” In the documentation for Data.Int from the current release of the Haskell Platform, I read that “All arithmetic is performed modulo 2^n, where n is the number of bits in the type.” However, there seems to be at least one exception to this promise, namely: λ> (minBound :: Int) `quot` (-1) *** Exception: arithmetic overflow Is this a bug? More specifically, is it intended to be safe to rely on the modulo arithmetic behavior of GHC in spite of the Language Report? And if so, should the above witnessed behavior still be expected? Thanks, -- Rob Leslie rob(a)mars.org

2 2

Re: [Haskell-cafe] Why is the Show instance of Text not used by showTerm?
by JP Moresmau 24 Jan '14

24 Jan '14

Karl, thanks, but the flag is set to True... And setting it to False doesn't change the output. I'll continue my investigations! JP On Fri, Jan 24, 2014 at 6:12 PM, Karl Voelker <karl(a)karlv.net> wrote: > On Fri, Jan 24, 2014, at 07:38 AM, JP Moresmau wrote: > > Hello cafe, I'm continuing my adventures with the GHC API. I'm following > the code given at > http://www.haskell.org/haskellwiki/GHC/As_a_library#Running_interactive_sta… run statements like in GHCi, but the behavior sometimes puzzles me. > > If I load a simple module: > > module Test where > import qualified Data.Text as T > > And then run the statement T.pack \"test\", I expect to see "test" back. > But I get Data.Text.Internal.Text _ 0 4. If I run "show $ T.Pack \"test\"" > I get the expected result. Text _ 0 4 seems to be the output of the > showText debugging function in Data.Text, that I don't see used in the Show > instance. And looking at the GHC code (Debugger.hs) it does perform a show > of the expression given. Why doesn't it work? What subtlety am I missing? > > > The example you linked to calls showTerm ( > http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/src/Debugger.html…) > which seems to have two different paths depending on the > Opt_PrintEvldWithShow dynflag. One path appears to use show, and the other > does not. > > -Karl > -- JP Moresmau http://jpmoresmau.blogspot.com/

1 1