- Haskell-Cafe - Haskell.org

I need feedback: Create a function which makes a relation between types and functions.
by CESAR FABIAN ORCCON CHIPANA 27 Mar '15

27 Mar '15

Good morning (afternoon, evening) This is one of my proposals. http://cfoch-dev.tumblr.com/post/114756897282/create-a-function-which-makes… I hope you can give me your feedback. Thanks so much. -- ------------------------------------ Fabián Orccón (cfoch) http://cfoch.tumblr.com http://cfoch-art.tumblr.com http://cfoch-dev.tumblr.com

1 0

GSOC 2015 proposal: a standalone functional parser for CommonMark
by Julien Cretel 27 Mar '15

27 Mar '15

Dear Haskell-Cafe, This is very short notice, but here is a link to my proposal for this year's Google Summer of Code: https://gist.github.com/Jubobs/7a9298eeaf02bcefbc35 The goal of the project is to produce a standalone, pure-Haskell library for parsing CommonMark, the updated Markdown specification. Here is a link to the corresponding trac ticket, along with a link to a relevant Google-Groups discussion involving John MacFarlane and Matthew Pickering: https://ghc.haskell.org/trac/summer-of-code/ticket/1660 https://groups.google.com/forum/#!topic/pandoc-discuss/xZrf-dL0ZPs Should you have any comments, suggestions, corrections, etc... before the submission deadline, feel free to chime in. All the best, Julien

1 0

Terra language: Lua+LLVM JIT+multi-stage metaprogramming
by Bulat Ziganshin 27 Mar '15

27 Mar '15

Hello , http://terralang.org/ it doesn't have any relation to haskell, but i found it very interesting - it employs LLVM JIT to produce efficient code on the fly and can save it to .o files, and it's tightly integrated with Lua as metaprogramming language It has predecessors like template haskell, metalua, julia, ocamlp4, but all them lack either convenient multi-stage meta-programming, or efficency of low-level code -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

ListT considered harmful
by Fumiaki Kinoshita 27 Mar '15

27 Mar '15

It is well known that ListT m in transformers is not a monad unless the underlying monad is commutative. The fact that ListT is not a monad transformer is sufficient to remove it from the package, and several packages already defined their own ListT. Oughtn't we deprecate ListT or replace it by a correct one?

4 3

ANNOUNCE: GHC version 7.10.1
by Austin Seipp 27 Mar '15

27 Mar '15

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 7.10.1 ============================================================== The GHC Team is pleased to announce a new major release of GHC. There have been a number of significant changes since the last major release, including: * Several new language features and changes have been implemented: - Applicative is now a superclass of Monad and in the Prelude. - Many prelude combinators have been generalized - Static pointers * GHC now has preliminary and experimental support for DWARF based debugging. * `integer-gmp` has been completely rewritten. * Type-checking plugins can now extend the type checker. * Support for partial type signatures * Many bugfixes and other performance improvements. * Preliminary support for 'backpack' features like signatures. * Typeable is now generated by default for all data types automatically. We've also fixed a handful of issues reported since RC3: - A bug in the call arity analysis that would result in invalid core was fixed (#10176) - A bug in the Win32 package causing it to fail to load was fixed (#10165) - ghc-prim has (correctly) been bumped to version 0.4.0.0, to comply with the PVP. - Several libraries have been bumped to their latest available versions after coordination. The full release notes are here: https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-1… How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: https://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://ghc.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: https://ghc.haskell.org/trac/ghc/wiki/Platforms https://ghc.haskell.org/trac/ghc/wiki/CodeOwners Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: https://ghc.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: https://ghc.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at https://www.haskell.org/mailman/listinfo/glasgow-haskell-users https://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see https://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: https://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: https://www.haskell.org/ghc/reportabug Hashes & Signatures ~~~~~~~~~~~~~~~~~ On https://downloads.haskell.org/~ghc/7.10.1/ you will find a signed copy of the SHA256 hashes for the tarballs, using my GPG key (0F8F 3AA9 9235 C704 ADA0 B419 B942 AEE5 3B58 D86F). -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

Applicative of Applicative
by martin 27 Mar '15

27 Mar '15

Hello all, I've been playing with temporal values, i.e. values which change over time at discrete points in time. I thought it would be good to make it an instance of Applicative and I was pleased with the results. I may be re-inventing some of frp here, but hey. Then I wondered how I would replace one Temporal by another at some point in time. Kind of like switching from summer schedule to winter schedule. Or switching channels on the TV, where each channel is a Temporal Image. It seems that by stacking up Temporals in this way, I could theoretically start with sample values and abstract my way up to a symphony. What is unclear to me is the following: when I have two Temporal Ints, I know what (+) <$> does. It operates on the Ints. But when I have Temporal Temporal Ints, then the function before the <$> would operate on the next level, i.e. it has to be a function which accepts a Temporal. But a Temporal Temporal Int can always be flattened into a Temporal Int. So I may just as well ask to apply a function to the bottom level, namely the Ints. How to I choose how deep down I want to reach? And any other guidance will also be much appreciated. Martin

7 11

Re: [Haskell-cafe] Version constraints and cabal.config files
by Miëtek Bak 26 Mar '15

26 Mar '15

On 2015-03-25, at 12:16, Michael Snoyman <michael(a)fpcomplete.com> wrote: > Trying to understand the problem: currently, with your approach, if the project depends on a library not in the LTS Haskell release, then the cabal-install dependency solver won't be able to find it. Instead, you'd like to be able to use the dependency solver to track down those extra dependencies. Is that correct? > > If so, why not take a multi-pass approach: download the cabal.config from stackage.org (which creates an inclusive snapshot), and then use --dry-run, which will tell you all the packages to be used. You’re correct. However, this will have to be `cabal install --dependencies-only --dry-run`, and not `cabal freeze --dry-run`, because `cabal freeze` always completely ignores any existing version constraints, whether local or global (https://github.com/haskell/cabal/issues/2265) I’m planning to switch away from `cabal freeze` soon, but it’s not going to be a drop-in replacement (https://github.com/mietek/halcyon/issues/52) This is a good moment to carefully consider the meaning of a per-application `cabal.config` file, and whether the `cabal freeze` flavour should be completely replaced by separate constraints files. Perhaps, as mentioned in the original `cabal freeze` proposal, we could also have separate constraints sets for different GHC versions. I’m hoping Cabal developers could chime in on the discussion. -- Miëtek https://mietek.io

4 16

Do we have idiom for lifting a state monad into pair of states?
by Ki Yung Ahn 26 Mar '15

26 Mar '15

Consider you have developed library routines that act on (State s1 a). For some reason, you need more than one state simultaneously. Let's say two side by side for simple example, that is (State (s1,s2) a). To use library functions on one state monad in a two state monad, we need to wrapper that lifts actions of (State s1 a) to (State (s1,s2) a). It is not difficult to write a lifter for such purposes as below. It is kind of like doing liftA in Applicative libarary, but instead of the last argument 'a' but on the fist argument 's' of (State s a). This seems like an idiom that can often come up. So, I tried some searching in some applicative related libraries and monad transformer related libraries but haven't found this idiom yet. If you had a need for idioms like below, what do you call it? Or, is there a way more general way I've missed that makes this a very special case of it. > import Control.Monad.State > import Control.Monad.Error > import Control.Applicative > > -- lift an action over a state into a pair of states > -- > do1st :: State s1 a -> State (s1,s2) a > do1st m1 = do (s1, s2) <- get > let (a, s1') = runState m1 s1 > put (s1',s2) > return a > > do2nd :: State s2 a -> State (s1,s2) a > do2nd m2 = do (s1, s2) <- get > let (a, s2') = runState m2 s2 > put (s1,s2') > return a > > > -- lift an action over a state with error > -- into a pair of states with error > -- > do1 :: Error e => ErrorT e (State s1) a -> ErrorT e (State (s1,s2)) a > do1 m1 = do (s1, s2) <- lift get > let (ma,s1') = (runState . runErrorT) m1 s1 > case ma of > Left e -> throwError e > Right a -> do lift $ put (s1',s2) > return a > > > do2 :: Error e => ErrorT e (State s2) a -> ErrorT e (State (s1,s2)) a > do2 m2 = do (s1, s2) <- lift get > let (ma,s2') = (runState . runErrorT) m2 s2 > case ma of > Left e -> throwError e > Right a -> do lift $ put (s1,s2') > return a

4 5

Re: [Haskell-cafe] Version constraints and cabal.config files
by Miëtek Bak 25 Mar '15

25 Mar '15

On 2015-03-25, at 11:40, Michael Snoyman <michael(a)fpcomplete.com> wrote: > Every Stackage Nightly and LTS Haskell release has a YAML file[1] that provides a lot of information, included the exact versions of packages and package dependencies. The stackage-types[2] package provides the datatypes necessary to parse that YAML file. Putting those two together, it should be possible to write something that looks at a project's list of shallow package dependencies, and construct a list of precisely which package-version combinations are necessary to build the entire project, which I think is what you're saying you get from cabal freeze but not from the current cabal.config on stackage.org. If I understand correctly, the result should be equivalent to configuring `cabal-remote-repo` to point to a particular Stackage snapshot, running `cabal freeze`, and parsing its output. Halcyon already does this — the following command will ignore any constraints declared by the application, and instead use the newest versions of all dependencies available in the specified Cabal repository: ``` $ halcyon install http://github.com/mietek/hello-yesod --ignore-all-constraints --cabal-remote-repo=stackage-lts-latest:http://www.stackage.org/lts ``` However, this means we’re using Stackage in “exclusive” mode. I’d like to support using Stackage in “inclusive” mode, with `cabal-remote-repo` pointing to Hackage, and a Stackage-flavoured `cabal.config`. -- Miëtek https://mietek.io

1 0

Version constraints and cabal.config files
by Miëtek Bak 25 Mar '15

25 Mar '15

On 2015-03-25, at 09:59, Chris Done <chrisdone(a)fpcomplete.com> wrote: >> Halcyon wants a constraints file for a particular app to list all Cabal packages which are the app’s direct or indirect dependencies. > > Why is that? What does it do with the cabal.config file? There are two flavours of `cabal.config` files: (1) `cabal freeze`-flavoured, declaring a complete set of dependencies for a particular application, and (2) the Stackage flavour, declaring a set of packages which are guaranteed to build together. It’s worth noting that the first flavour was originally proposed to be a separate file with a simpler syntax, named `cabal.freeze` (https://github.com/haskell/cabal/issues/1502) Unfortunately, this didn’t make it into cabal-install, due to lack of time (https://github.com/haskell/cabal/pull/1519) Halcyon supports `cabal freeze`-flavoured `cabal.config` files, and also accepts separate constraints files, named `.halcyon/constraints`. The declared version constraints are used to calculate a sandbox hash. When building an application, Halcyon uses the sandbox hash to try and locate a previously-built sandbox archive. If available in local cache or remote storage, this archive is restored, completely side-stepping the need to `cabal install --dependencies-only`. Otherwise, a new sandbox is built, archived, and uploaded to remote storage. Moreover, if a full match for the sandbox hash isn’t located, Halcyon attempts to locate a partial match. Each previously-built sandbox is assigned a score, which reflects the number of required dependencies contained within. Sandboxes with extraneous dependencies are rejected. The highest-scoring partial match is used as a base for building the new sandbox. While inferior to the package-level granularity provided by Nix and proposed for future versions of Cabal, the approach implemented in Halcyon has the benefit of working with regular Cabal packages and repositories, and being used in production since June 2014. -- Miëtek https://mietek.io

1 0