From dxld at darkboxed.org Mon Aug 1 19:04:16 2016 From: dxld at darkboxed.org (Daniel =?iso-8859-1?Q?Gr=F6ber?=) Date: Mon, 1 Aug 2016 21:04:16 +0200 Subject: [Haskell-cafe] [ANN] ghc-mod-5.6.0.0: Supporting GHC 8.0 and Cabal 1.24 Message-ID: <20160801190416.GA10330@Eli.lan> I'm pleased to announce the release of ghc-mod 5.6.0.0! What's new? =========== * Support for GHC 8.0 and Cabal 1.24 Nothing too spectacular to report here, just regular maintenance work. * Type Contexts fixed Thanks to @Lierdakil `ghc-mod type` now finally displays type (class) constraints in most cases. This has been on the TODO list for a very long while now, going back to at least GHC 7.8. GHC's API just doesn't have a nice, simple, way for doing this and we had to resort to manually walking the typechecked AST while collecting constraints in various places. * Various bug fixes and smaller improvements From the change log: * Merge #737, `map-file` caching issues * Merge #767, Add `browse` option to show symbol "parents" * Fix #438, Case splitting not working * Fix #790, Don't try to use 'cabal' or 'stack' when it's not installed What is ghc-mod? ================ ghc-mod is both a back-end program for enhancing editors and other development environments with support for Haskell as well as a library for abstracting the black magic incantations required to use the GHC API in various environments, especially Cabal and Stack projects. The library is used by projects like HaRe[1], and haskell-ide-engine[2] Getting ghc-mod =============== GitHub: https://github.com/DanielG/ghc-mod Hackage: http://hackage.haskell.org/package/ghc-mod Editor frontends: - Emacs (native): https://github.com/DanielG/ghc-mod https://github.com/iquiw/company-ghc - Vim: https://github.com/eagletmt/ghcmod-vim https://github.com/eagletmt/neco-ghc - Atom: https://github.com/atom-haskell/ide-haskell Known issues ============ For issues other than the ones mentioned below visit our issue tracker: https://github.com/DanielG/ghc-mod/issues Frequently reported issues -------------------------- ghc-mod once compiled is bound to one version of GHC since we link against the GHC API library. This used to not be a very big problem but since Stack made it exceedingly easy for users to use more than one version of GHC without even knowing the number of problems in this area has exploded. We are tracing the issue in the following issue: https://github.com/DanielG/ghc-mod/issues/615 (Support switching GHC versions without recompiling ghc-mod) If you do notice any other problems please report them: https://github.com/DanielG/ghc-mod/issues/new ---- [1]: https://github.com/alanz/HaRe [2]: https://github.com/haskell/haskell-ide-engine -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From claude at mathr.co.uk Mon Aug 1 19:57:36 2016 From: claude at mathr.co.uk (Claude Heiland-Allen) Date: Mon, 1 Aug 2016 20:57:36 +0100 Subject: [Haskell-cafe] [ANN] hgmp-0.1.0.0 Message-ID: <583e90ea-a250-9525-28d7-fc6f7991cb0f@mathr.co.uk> Hi all, hgmp 0.1.0.0 is released! [0] hgmp is a Haskell interface to GMP[1] (for GHC with the default integer-gmp implementation of Integer). Contains type definitions and marshalling functions, to be able to write FFI bindings using Haskell's Integer and Rational types. Function bindings may come in a future version. A simple example illustrating binding to GMP's next probable-prime function: {-# LANGUAGE ForeignFunctionInterface #-} import Foreign.Ptr (Ptr(..)) import Numeric.GMP.Types (MPZ) import Numeric.GMP.Utils (withInInteger, withOutInteger_) import System.IO.Unsafe (unsafePerformIO) foreign import ccall safe "__gmpz_nextprime" mpz_nextprime :: Ptr MPZ -> Ptr MPZ -> IO () nextPrime :: Integer -> Integer nextPrime n = unsafePerformIO $ withOutInteger_ $ \rop -> withInInteger n $ \op -> mpz_nextprime rop op You can cabal install (or otherwise get it) from Hackage[2], or get (or browse[3]) the freshest sources from git: git clone https://code.mathr.co.uk/hgmp.git Any and all feedback welcome! I'm sure there are some things that could be improved, and ideas for future versions will be appreciated too. [0] https://mathr.co.uk/blog/2016-08-01_hgmp_0_1_0_0_released.html [1] https://gmplib.org/ [2] http://hackage.haskell.org/package/hgmp [3] https://code.mathr.co.uk/hgmp Thanks, Claude -- https://mathr.co.uk From claude at mathr.co.uk Mon Aug 1 20:48:17 2016 From: claude at mathr.co.uk (Claude Heiland-Allen) Date: Mon, 1 Aug 2016 21:48:17 +0100 Subject: [Haskell-cafe] [ANN] hgmp-0.1.0.0 In-Reply-To: References: <583e90ea-a250-9525-28d7-fc6f7991cb0f@mathr.co.uk> Message-ID: <1928cf43-78e2-beb9-b0b2-ea41a922b2ef@mathr.co.uk> Hi Sergey, café, On 01/08/16 21:13, Sergey Bushnyak wrote: > Nice work! How it differs from > https://hackage.haskell.org/package/integer-gmp ? Good question! integer-gmp is a binding of enough of GMP to make implementing Integer possible. It is very low level in the GHC package heirarchy, so trying to make it provide high level code is painful, if not impossible. It exposes the bare minimum of functionality to let most of Integer be implemented by the base package. hgmp uses the public integer-gmp internal details (also ghc-prim for the lower level stuff like copying byte arrays to/from Haskell heap / foreign memory) to expose helpers using Integer and Rational for interacting with foreign code that expects mpz_t and mpq_t data structures. So the package heirarchy is something like this diagram (fixed width font recommended): hgmp -- Integer and Rational FFI helpers for libgmp API / | \ | | base -- Integer numeric instances, the standard Prelude, etc | | | : | integer-gmp -- bindings for Integer implementation (bare minimum) | | / ghc-prim -- very low level compiler specifics hgmp eventually should also contain bindings to the functions in GMP, I'm considering the best way to go about it. My current thought is to generate raw and higher-level bindings semi-automatically from the C API header file gmp.h - any other suggestions? Claude > On 08/01/2016 10:57 PM, Claude Heiland-Allen wrote: >> Hi all, >> >> hgmp 0.1.0.0 is released! [0] >> >> hgmp is a Haskell interface to GMP[1] (for GHC with the default >> integer-gmp implementation of Integer). Contains type definitions and >> marshalling functions, to be able to write FFI bindings using >> Haskell's Integer and Rational types. Function bindings may come in a >> future version. >> >> A simple example illustrating binding to GMP's next probable-prime >> function: >> >> {-# LANGUAGE ForeignFunctionInterface #-} >> >> import Foreign.Ptr (Ptr(..)) >> import Numeric.GMP.Types (MPZ) >> import Numeric.GMP.Utils (withInInteger, withOutInteger_) >> import System.IO.Unsafe (unsafePerformIO) >> >> foreign import ccall safe "__gmpz_nextprime" >> mpz_nextprime :: Ptr MPZ -> Ptr MPZ -> IO () >> >> nextPrime :: Integer -> Integer >> nextPrime n = >> unsafePerformIO $ >> withOutInteger_ $ \rop -> >> withInInteger n $ \op -> >> mpz_nextprime rop op >> >> You can cabal install (or otherwise get it) from Hackage[2], or get >> (or browse[3]) the freshest sources from git: >> >> git clone https://code.mathr.co.uk/hgmp.git >> >> Any and all feedback welcome! I'm sure there are some things that >> could be improved, and ideas for future versions will be appreciated too. >> >> [0] https://mathr.co.uk/blog/2016-08-01_hgmp_0_1_0_0_released.html >> [1] https://gmplib.org/ >> [2] http://hackage.haskell.org/package/hgmp >> [3] https://code.mathr.co.uk/hgmp >> >> Thanks, >> >> >> Claude > -- https://mathr.co.uk From ezyang at mit.edu Mon Aug 1 21:03:35 2016 From: ezyang at mit.edu (Edward Z. Yang) Date: Mon, 01 Aug 2016 14:03:35 -0700 Subject: [Haskell-cafe] FINAL CALL FOR TALKS (Aug 8 deadline): Haskell Implementors Workshop 2016, Sep 24, Nara Message-ID: <1470085297-sup-7909@sabre> Deadline is in a week! Submit your talks! Call for Contributions ACM SIGPLAN Haskell Implementors' Workshop http://haskell.org/haskellwiki/HaskellImplementorsWorkshop/2016 Nara, Japan, 24 September, 2016 Co-located with ICFP 2016 http://www.icfpconference.org/icfp2016/ Important dates --------------- Proposal Deadline: Monday, 8 August, 2016 Notification: Monday, 22 August, 2016 Workshop: Saturday, 24 September, 2016 The 8th Haskell Implementors' Workshop is to be held alongside ICFP 2016 this year in Nara. It is a forum for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure, to share their work and discuss future directions and collaborations with others. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings; the workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks. Scope and target audience ------------------------- It is important to distinguish the Haskell Implementors' Workshop from the Haskell Symposium which is also co-located with ICFP 2016. The Haskell Symposium is for the publication of Haskell-related research. In contrast, the Haskell Implementors' Workshop will have no proceedings -- although we will aim to make talk videos, slides and presented data available with the consent of the speakers. In the Haskell Implementors' Workshop, we hope to study the underlying technology. We want to bring together anyone interested in the nitty-gritty details behind turning plain-text source code into a deployed product. Having said that, members of the wider Haskell community are more than welcome to attend the workshop -- we need your feedback to keep the Haskell ecosystem thriving. The scope covers any of the following topics. There may be some topics that people feel we've missed, so by all means submit a proposal even if it doesn't fit exactly into one of these buckets: * Compilation techniques * Language features and extensions * Type system implementation * Concurrency and parallelism: language design and implementation * Performance, optimisation and benchmarking * Virtual machines and run-time systems * Libraries and tools for development or deployment Talks ----- At this stage we would like to invite proposals from potential speakers for talks and demonstrations. We are aiming for 20 minute talks with 10 minutes for questions and changeovers. We want to hear from people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. Please submit a talk title and abstract of no more than 300 words. Submissions should be made via HotCRP. The website is: https://icfp-hiw16.hotcrp.com/ We will also have a lightning talks session which will be organised on the day. These talks will be 5-10 minutes, depending on available time. Suggested topics for lightning talks are to present a single idea, a work-in-progress project, a problem to intrigue and perplex Haskell implementors, or simply to ask for feedback and collaborators. Organisers --- End forwarded message --- From yallop at gmail.com Tue Aug 2 08:35:44 2016 From: yallop at gmail.com (Jeremy Yallop) Date: Tue, 2 Aug 2016 09:35:44 +0100 Subject: [Haskell-cafe] PEPM 2017 Second Call for Papers Message-ID: SECOND CALL FOR PAPERS Workshop on PARTIAL EVALUATION AND PROGRAM MANIPULATION (PEPM 2017) NEWS: Keynote talk by Neil Jones, DIKU (see below). http://conf.researchr.org/home/PEPM-2017 Paris, France, January 16th - 17th, 2017 (co-located with POPL 2017) PEPM is the premier forum for discussion of semantics-based program manipulation. The first ACM SIGPLAN PEPM symposium took place in 1991, and meetings have been held in affiliation with POPL every year since 2006. PEPM 2017 will be based on a broad interpretation of semantics-based program manipulation, reflecting the expanded scope of PEPM in recent years beyond the traditionally covered areas of partial evaluation and specialization. Specifically, PEPM 2017 will include practical applications of program transformations such as refactoring tools, and practical implementation techniques such as rule-based transformation systems. In addition, the scope of PEPM covers manipulation and transformations of program and system representations such as structural and semantic models that occur in the context of model-driven development. In order to maintain the dynamic and interactive nature of PEPM and to encourage participation by practitioners, we also solicit submissions of short papers, including tool demonstrations, and of posters. Scope ----- Topics of interest for PEPM 2017 include, but are not limited to: * Program and model manipulation techniques such as: supercompilation, partial evaluation, fusion, on-the-fly program adaptation, active libraries, program inversion, slicing, symbolic execution, refactoring, decompilation, and obfuscation. * Program analysis techniques that are used to drive program/model manipulation such as: abstract interpretation, termination checking, binding-time analysis, constraint solving, type systems, automated testing and test case generation. * Techniques that treat programs/models as data objects including metaprogramming, generative programming, embedded domain-specific languages, program synthesis by sketching and inductive programming, staged computation, and model-driven program generation and transformation. * Application of the above techniques including case studies of program manipulation in real-world (industrial, open-source) projects and software development processes, descriptions of robust tools capable of effectively handling realistic applications, benchmarking. Examples of application domains include legacy program understanding and transformation, DSL implementations, visual languages and end-user programming, scientific computing, middleware frameworks and infrastructure needed for distributed and web-based applications, embedded and resource-limited computation, and security. This list of categories is not exhaustive, and we encourage submissions describing applications of semantics-based program manipulation techniques in new domains. If you have a question as to whether a potential submission is within the scope of the workshop, please contact the programme chairs. Submission categories and guidelines ------------------------------------ Three kinds of submissions will be accepted: Regular Research Papers, Short Papers and Posters. * Regular Research Papers should describe new results, and will be judged on originality, correctness, significance and clarity. Regular research papers must not exceed 12 pages in ACM Proceedings style (including appendix). * Short Papers may include tool demonstrations and presentations of exciting if not fully polished research, and of interesting academic, industrial and open-source applications that are new or unfamiliar. Short papers must not exceed 6 pages in ACM Proceedings style (including appendix). * Posters should describe work relevant to the PEPM community, and must not exceed 2 pages in ACM Proceedings style. We invite poster submissions that present early work not yet ready for submission to a conference or journal, identify new research problems, showcase tools and technologies developed by the author(s), or describe student research projects. At least one author of each accepted contribution must attend the workshop and present the work. In the case of tool demonstration papers, a live demonstration of the described tool is expected. Suggested topics, evaluation criteria, and writing guidelines for both research tool demonstration papers will be made available on the PEPM 2017 web site. Student participants with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses and other support. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page. Publication and special issue ----------------------------- All accepted papers, short papers and posters included, will appear in formal proceedings published by ACM Press. Accepted papers will be included in the ACM Digital Library. Authors of selected papers from PEPM 2016 and PEPM 2017 will also be invited to expand their papers for publication in a special issue of the journal Computer Languages, Systems and Structures (COMLAN, Elsevier). Keynote ------- Neil Jones (DIKU) will give the PEPM keynote talk, titled Compiling Untyped Lambda Calculus to Lower-level Code by Game Semantics and Partial Evaluation Best paper award ---------------- PEPM 2017 continues the tradition of a Best Paper award. The winner will be announced at the workshop. Submission ---------- Papers should be submitted electronically via HotCRP. https://pepm17.hotcrp.com/ Authors using LaTeX to prepare their submissions should use the new improved SIGPLAN proceedings style, and specifically the sigplanconf.cls 9pt template. Important Dates --------------- For Regular Research Papers and Short Papers: * Abstract submission : Tuesday 13th September 2016 * Paper submission : Friday 16th September 2016 * Author notification : Monday 24th October 2016 * Camera ready : Monday 28th November 2016 For Posters: * Poster submission : Sunday 30th October 2016 * Author notification : Friday 10th November 2016 * Camera ready : Monday 28th November 2016 PEPM workshop: * Workshop : Monday 16th - Tuesday 17th January 2017 The proceedings will be published 2 weeks pre-conference. AUTHORS TAKE NOTE: The official publication date is the date the proceedings are made available in the ACM Digital Library. This date may be up to two weeks prior to the first day of your conference. The official publication date affects the deadline for any patent filings related to published work. (For those rare conferences whose proceedings are published in the ACM Digital Library after the conference is over, the official publication date remains the first day of the conference.). PEPM'17 Programme Committee --------------------------- Elvira Albert (Complutense University of Madrid, Spain) Don Batory (University of Texas at Austin, USA) Martin Berger (University of Sussex, UK) Sebastian Erdweg (TU Delft, Netherlands) Andrew Farmer (Facebook, USA) Matthew Flatt (University of Utah, USA) John Gallagher (Roskilde University, Denmark) Robert Glück (DIKU, Denmark) Jurriaan Hage (Utrecht University, Netherlands) Zhenjiang Hu (National Institute of Informatics, Japan) Yukiyoshi Kameyama (University of Tsukuba, Japan) Ilya Klyuchnikov (Facebook, UK) Huiqing Li (EE, UK) Annie Liu (Stony Brook University, USA) Markus Püschel (ETH Zurich, Switzerland) Ryosuke SATO (University of Tokyo, Japan) Sven-Bodo Scholz (Heriot-Watt University, UK) Ulrik Schultz (co-chair) (University of Southern Denmark) Ilya Sergey (University College London, UK) Chung-chieh Shan (Indiana University, USA) Tijs van der Storm (Centrum Wiskunde & Informatica, Netherlands) Jeremy Yallop (co-chair) (University of Cambridge, UK) From breitner at kit.edu Tue Aug 2 12:17:09 2016 From: breitner at kit.edu (Joachim Breitner) Date: Tue, 02 Aug 2016 08:17:09 -0400 Subject: [Haskell-cafe] Haskell in Leipzig 2016: Call for Participation Message-ID: <1470140229.3408.30.camel@kit.edu>                              Haskell in Leipzig                             September 14-15, 2016                             HTKW Leipzig, Germany                          http://hal2016.haskell.org/ We have received many interesting submissions for HAL and were able to assemble a great program, which you can find here: http://hal2016.haskell.org/program.html Abstracts and final schedule will be added soonish™. As you can see, we have an interesting program spanning from practical, real-word uses of Haskell over data structures and libraries to game- and music programming. Besides the 12 talks, there are three tutorials to attend. As a special treat, on the evening of September 14, Anton Kholomiov will give a live music coding performance! If you are interested in attending, please head over to  http://nfa.imn.htwk-leipzig.de/LDEC2016/registration/ and follow the instructions. HAL is cheap, and even cheaper for students, and yet cheaper if you pay by the early registration deadline of August 15¹ Also check out the other two conferences of LDEC (WLP and WLFP), and if you like them, make it a week full of functional programming! Thanks, Joachim Breitner on behalf of the program committee ¹ Note that the early registration deadline is for the money, so make    sure you allow for the bank to transfer it in time. -- Dr. rer. nat. Joachim Breitner Wissenschaftlicher Mitarbeiter http://pp.ipd.kit.edu/~breitner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From bertram.felgenhauer at googlemail.com Tue Aug 2 12:30:58 2016 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Tue, 2 Aug 2016 14:30:58 +0200 Subject: [Haskell-cafe] ANN: haskell-src-exts-simple In-Reply-To: <20160731174037.GC25770@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <20160731174037.GC25770@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: <20160802123058.GD11995@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Bertram Felgenhauer via Haskell-Cafe wrote: > I've just released haskell-src-exts-simple 1.18.0.0 on hackage [1]. > (This is the first release. The first two components of the version > follow haskell-src-exts.) I have released version 1.18.0.1 which adds support for ghc-7.8, with a caveat: Because support for explicitly bidirectional patterns is not available, the constructors of the `Literal` type only work as patterns in ghc-7.8; there are separate functions for construction f `Literal` values. In later ghc versions, the constructors can be used for constructing values as well. Cheers, Bertram P.S. I fogot to update the changelog in this release; this will be fixed with the next release. From julesmazur at gmail.com Tue Aug 2 20:55:53 2016 From: julesmazur at gmail.com (Jules Mazur) Date: Tue, 02 Aug 2016 20:55:53 +0000 Subject: [Haskell-cafe] What's the state of programming on the Xeon Phi with Haskell? Message-ID: I recently gained access to a Xeon Phi (Knights Corner edition, a bit dated but useful to play around with), and I'm interested in using Haskell to program for the Phi platform. Sadly, the only lead I've got about working with both technologies is a 2014 paper by Liu, et al. at Intel Research (available via [this site](https://www.researchgate.net/publication/262310691_The_Intel_Labs_Haskell_Research_Compiler)). In a 3-month-old [Reddit thread](https://www.reddit.com/r/haskell/comments/4hokvy/is_there_any_way_to_get_my_hands_on_intels/d2rmkzz), one of the authors mentions that the compiler may be released at a future date, but implied that it will likely have some degree of instability. Are there any libraries or compilers, or even extensions or modifications for GHC or other existing compilers, that allow compilation for the Xeon Phi? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gurudev.devanla at gmail.com Wed Aug 3 04:40:03 2016 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Tue, 2 Aug 2016 21:40:03 -0700 Subject: [Haskell-cafe] Design Question - Functions taking 'subtype' like arguments but has to be restricted to one type In-Reply-To: <614e9096-57a1-21da-7e75-a0ffc8d977cf@gmail.com> References: <8ed829cc-3f7b-407d-a1cb-fd66785ac60a@googlegroups.com> <614e9096-57a1-21da-7e75-a0ffc8d977cf@gmail.com> Message-ID: @Marlin Thank you for the example. Looks very interesting. Initially, when I was modelling this problem, I did consider Phanton types. But, you do provide a nice extension using type classes. Here are the obstacles/discomfort I faced while I took the Phantom Polymorphism approach: 1. With the definition of Basket c, how do I create a type such as Cart = [Basket]. The only way to create such a cart is Cart c = [Basket c]. But, that ties the Cart to one definition of Basket. Is there a way around this? I might be missing something simple. 2. In your approach or in the approach suggested by others, ultimately, I end up handling the 'Frozen' type during run-time. There is no way from stopping somene write code that calls update's on Frozen. (For example while mapping..). Is that understanding correct? Does this approach give me any more power than the previous approaches? The one power is that we stop the user from being able to construct the Frozen type, and we leave it to the compiler to return that type based on the inference. Correct? Is there any other power. Thank you for the help. Just with this thread, I have learnt more than 3 different ways of modelling approaches for this kind of a problem! On Sun, Jul 31, 2016 at 11:41 AM, MarLinn via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > This sounds like a perfect opportunity to use phantom types. I'll be using > it's DataKind-enhanced variant for added beauty. > > -- An Item that can be of two types, one whose value can be changed, one > whose value are frozen once created > data Item = FreeToChange {freeToChangeCount:: Int} > | CannotChange {frozenCount:: Int} > > I assume all items are equal apart from their changeability. Not that it's > necessary, but it makes the demonstration simpler. If changeable and > unchangeable items have differing structure you may need additional tools > like smart constructors. Accordingly, my items have the type > > data PlainItem = PlainItem { count :: Int } > > Changeability will be added on top: > > data Changeability = Changeable | Unchangeable > > data Item (c :: Changeability) = Item { plainItem :: PlainItem } > > Why separate *Item* and *PlainItem*? One second, please. > > -- The item is part of a basket > data Basket = Basket { name:: String, item::Item } > > data Basket c = Basket { name :: String, item :: Item c } -- No kind signature necessary. Thanks, solver. > > > Therefore, valid operation are: > > 1. I can create an Basket with either FreeToChange item or CannotChange > item. > > > The new *Basket* constructor can do that by default. > > 2. I can update the count for FreeToChange item in the Basket > > changeItem :: (PlainItem -> PlainItem) -> Item 'Changeable -> Item 'Changeable > > changeItem f (Item i) = Item (f i) > > changeBasket :: (PlainItem -> PlainItem) -> Basket 'Changeable -> Basket 'Changeable > > changeBasket f basket at Basket{..} = basket { item = changeItem f item } > > > And that's why *PlainItem* was separated, so we can have a simple type > signature here. You might worry that it was exposed, but it will not give > anyone access to a frozen basket. And of course you are free to further > restrict access to it. And as we're speaking about freezing, that's > extremely simple as well. > > freezeItem :: Item c -> Item 'Unchangeable > > freezeItem (Item i) = Item i > > freezeBasket :: Basket c -> Basket 'Unchangeable > > freezeBasket basket at Basket{..} = basket { item = freezeItem item } > > > You later mention that you might want to map updates only over some of the > baskets in a cart. That's not hard either. As an example, here's a way to > implement a function that updates changeable baskets while ignoring > unchangeable ones: > > class MaybeUpdateBasket c where > updateBasket :: (PlainItem -> PlainItem) -> Basket c -> Basket c > instance MaybeUpdateBasket 'Changeable where > updateBasket = changeBasket > instance MaybeUpdateBasket 'Unchangeable where > updateBasket _ = id > > Just *map* it over your cart as always. > > If you want more complicated things (eg. you want a cart to freeze once > any bucket freezes) you just have to expand the ideas here. You may need > MultiParamTypeClasses and FunctionalDependencies, but the basic ideas are > the same. > > Cheers. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch.howard at zoho.com Wed Aug 3 04:54:36 2016 From: ch.howard at zoho.com (Christopher Howard) Date: Tue, 2 Aug 2016 20:54:36 -0800 Subject: [Haskell-cafe] memory usage: general questions Message-ID: <57A1790C.1010104@zoho.com> Hi. I've spent the last few days reading about strictness, non-strictness, laziness, thunks, and persistence, and to be honest I'm still in a bit of a fog. A few questions, which I hope might help me out: Supposing I have an expression f (f (f b))) where f :: B -> B and B is some ginormous persistent data structure. and f is an "updating" function outputting some modified copy version of it's argument So, a few questions: 1) Supposing that f does not short-circuit: Is it correct to say that it is definitely advantageous (from a memory usage perspective) for f to be a strict function? Or is this heavily dependent on whether or not b contains unevaluated data structures (e.g., a list)? 2) As far as the overall peak size of our memory graph: How will it be affected by the size of b, if f is non-strict? and if f is strict? 3) Are the "overwritten" portions of each B (i.e., those parts of the persistent data we no are no longer needed) guaranteed to be pushed out of memory at any particular point? Is this something we know will (might?) happen as soon as the GC is run? Or does it happen right when each f is applied to it's argument? -- https://qlfiles.net To protect my privacy, please use PGP encryption. It's free and easy to use! My public key ID is 0x340EA95A (pgp.mit.edu). From anselm.scholl at tu-harburg.de Wed Aug 3 08:06:18 2016 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Wed, 3 Aug 2016 10:06:18 +0200 Subject: [Haskell-cafe] memory usage: general questions In-Reply-To: <57A1790C.1010104@zoho.com> References: <57A1790C.1010104@zoho.com> Message-ID: <76e26246-fa8a-b281-18da-95fb403f5f7d@tu-harburg.de> On 08/03/2016 06:54 AM, Christopher Howard wrote: > Hi. I've spent the last few days reading about strictness, > non-strictness, laziness, thunks, and persistence, and to be honest I'm > still in a bit of a fog. A few questions, which I hope might help me out: > > Supposing I have an expression > > f (f (f b))) > > where f :: B -> B > and B is some ginormous persistent data structure. > and f is an "updating" function outputting some modified copy version of > it's argument > > So, a few questions: > > 1) Supposing that f does not short-circuit: Is it correct to say that it > is definitely advantageous (from a memory usage perspective) for f to be > a strict function? Or is this heavily dependent on whether or not b > contains unevaluated data structures (e.g., a list)? I would say, this depends a little bit on the structure of B and how much f forces of it. Suppose B looks like this: data StrictList a = Cons a !(StrictList a) | Nil data B = B Int !Int [Float] (StrictList Double) Now lets consider some variations of f: f (B a b c d) = B (a + 1) (b - 1) (2.5 : c) (Cons (fromIntegral a) d) This version would only be strict in the outer constructor and would create a B with two fields set to values and 2 to thunks. The first field is a lazy Int, thus we can not blindly evaluate it, as it could be _|_. Thus, we create a thunk for (a + 1), which will cost about 3 words (function pointer and two for each argument) plus 2 words for the second argument of (+), although the compiler may be able to optimize that away to a statically allocated version (at least the garbage collector recognizes small integers and replaces them with references to statically allocated ones). The second field is strict and depends on a strict value, thus it will just be computed and stored. If -O or -funbox-small-strict-fields is set, it should get unpacked to an unboxed Int#, removing any indirection via pointers. The next field is lazy again, but we only construct values. Thus, we can construct them directly and store the result in the field. The tail of the list may still be lazy. The forth field contains a spine-strict list, although the field is not marked strict, so forcing it would force the whole list. However, elements of the list are not strict. So we get a thunk for (fromIntegral a) (as a was lazy, we can not just compute this) and another thunk for the constructor, which forces d (if the first element of the list is evaluated, the whole list is evaluated, so Cons has to evaluate d). So is this version of f strict? It is strict in the outer layer, but we can of course make a stricter version: f (B !a !b !c !d) = ... (or f (B a b c d) = a `seq` b `seq` ...) Now f would first evaluate the contents of each field of B. Thus, we would avoid to create a space leak in the first argument of B, if we repeatedly apply f. The second field was already strict, so nothing changes in this case. The third field is a lazy list, thus we only evalute the head of the list (which may be a thunk forcing additional values) before constructing our result for this field. The last field would now force the entire StrictList, which could increase memory usage a lot (especially if a part of it was a thunk of the form replicate 500 1.0. The next time the StrictList is forced, it will stop after the first Cons cell, as this being evaluated means the whole list is evaluated. As a was already evaluated, the compiler might be able to see that it can compute (fromIntegral a) earlier. This should take about the same amount of work as constructing a closure, but I don't know whether GHC does something like this today. So the second version of f is a lot stricter, could create less thunks, but force additional elements which would increase memory usage. Which one is better? It depends on the use case. As you mentioned, if you have a list or something similar to a list and consume it incrementally, you only want to force the elements when you get to them. However, any accumulator you carry during this should probably be strict. Similar, if you construct a list, it could be beneficial to force an element before constructing the cons-cell, at least for small types like Int, and when you know that forcing them can not yield _|_. In the end it depends heavily on your concrete problem. > > 2) As far as the overall peak size of our memory graph: How will it be > affected by the size of b, if f is non-strict? and if f is strict? If f is not strict, it can produce a B without forcing its argument. If it just uses the argument without evaluating it, it can only store it inside the B it constructs, so B seems to be something like a list or tree. Or it can call a function on it, but store the thunk of the function call in the result, so the argument is only forced if this thunk is forced. So if f is not strict, it has to increase the memory usage (or throw the argument away, but this does not seem sensible in this case). If it is strict, it can extract the relevant fields and produce a result, maybe dropping the last reference to the argument and making it eligible for GC. > > 3) Are the "overwritten" portions of each B (i.e., those parts of the > persistent data we no are no longer needed) guaranteed to be pushed out > of memory at any particular point? Is this something we know will > (might?) happen as soon as the GC is run? Or does it happen right when > each f is applied to it's argument? > Nothing is overwritten. Instead, a new version of B is allocated and the old one is collected after the last reference is dropped. Maybe this is best visible if you consider (f b, g b). Overwriting parts of b in f would change the argument to g. Thus, a copy has to be produced. It would be valid if the compiler could prove that only one reference exists and this is passed to f, but first this proof could be difficult and second a separate version of f would have to be compiled. This may even reduce performance, as the GC is exploiting the fact that most data structures are immutable (although thunks are mutable as they are overwritten by their result). Thus, such an optimization could hurt the GC, which would result in a global slowdown, further reducing any gains from overwriting the contents of the argument. Additionally, GCs are quite cheep if not much data is alive. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From alan.zimm at gmail.com Wed Aug 3 11:20:25 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 3 Aug 2016 13:20:25 +0200 Subject: [Haskell-cafe] [ANN] HaRe 0.8.3.0 Released Message-ID: Now that ghc-mod 5.6.0.0 is out, I have been able to release HaRe for GHC 8.0.1 There are no functional changes, this release just adds support for GHC 8.0.1. Just a heads up for anyone who is interested, my plans for the near future are 1. Complete adding default annotations to ghc-exactprint. This will allow pretty printing a GHC AST that has been generated via some process other than parsing source, by adding annotations to it. 2. Return to haskell-ide-engine The initial focus will be on enabling the remote ghci mode into it. In general, my focus is on improving the tooling experience around GHC. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at googlemail.com Wed Aug 3 14:58:28 2016 From: monkleyon at googlemail.com (MarLinn) Date: Wed, 3 Aug 2016 16:58:28 +0200 Subject: [Haskell-cafe] Design Question - Functions taking 'subtype' like arguments but has to be restricted to one type In-Reply-To: References: <8ed829cc-3f7b-407d-a1cb-fd66785ac60a@googlegroups.com> <614e9096-57a1-21da-7e75-a0ffc8d977cf@gmail.com> Message-ID: An HTML attachment was scrubbed... URL: From mitchellwrosen at gmail.com Wed Aug 3 15:42:29 2016 From: mitchellwrosen at gmail.com (Mitchell Rosen) Date: Wed, 3 Aug 2016 08:42:29 -0700 (PDT) Subject: [Haskell-cafe] Measuring allocations with 'weigh' - what about thunks? Message-ID: weigh (https://www.fpcomplete.com/blog/2016/05/weigh-package) is a library measures how much allocation evaluating a function causes. It's basically a nice interface to GHC.Stats.getGCStats. Here is an example that measures *\n -> n+1*: import Weigh main :: IO () main = mainWith (func "+1" plusOne 5) plusOne :: Int -> Int plusOne = \n -> n + 1 which prints Case Bytes GCs Check +1 16 0 OK when run (64 bit machine; allocating 1 Int = 16 bytes). So my question is, what about the thunk allocated by *(+)*? My rough understanding of the heap is this: Code Heap ---- ---- 1 1 1 1 1 plusOne 1 +-------+----------+----+ +----+---+ | THUNK | reserved | --|--> | I# | 5 | +-------+----------+----+ +----+---+ 1 1 1 1 1 deepseq it +-------+----------+----+ +----+---+ | IND | | --|--> | I# | 5 | +-------+-----|----+----+ +----+---+ | 1 1 `------------> +----+---+ | I# | 6 | +----+---+ 1 1 GC +----+---+ | I# | 6 | +----+---+ So haven't we allocated 5 bytes, not two? Three for the GC'd thunk, and two for the new Int? Any clarification or pointers (heh) to some GHC reading would be greatly appreciated! Thanks, Mitchell -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Wed Aug 3 20:41:28 2016 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Wed, 3 Aug 2016 13:41:28 -0700 Subject: [Haskell-cafe] [Job] Formal Tech is hiring Message-ID: Hello, Formal Tech, a Galois spin-off, is looking for a mid to senior level engineer to work on CyberChaff ( https://formal.tech/products/cyberchaff/). Applicants should be proficient in Haskell and at least one other programming language. This is a full time position with benefits. If you are interested, please send your resume to careers at formal.tech Cheers, -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch.howard at zoho.com Thu Aug 4 01:51:01 2016 From: ch.howard at zoho.com (Christopher Howard) Date: Wed, 3 Aug 2016 17:51:01 -0800 Subject: [Haskell-cafe] memory usage: general questions In-Reply-To: <76e26246-fa8a-b281-18da-95fb403f5f7d@tu-harburg.de> References: <57A1790C.1010104@zoho.com> <76e26246-fa8a-b281-18da-95fb403f5f7d@tu-harburg.de> Message-ID: <57A29F85.8060100@zoho.com> On 08/03/2016 12:06 AM, Jonas Scholl wrote: >> >> 3) Are the "overwritten" portions of each B (i.e., those parts of the >> persistent data we no are no longer needed) guaranteed to be pushed out >> of memory at any particular point? Is this something we know will >> (might?) happen as soon as the GC is run? Or does it happen right when >> each f is applied to it's argument? >> > > Nothing is overwritten. Instead, a new version of B is allocated and the > old one is collected after the last reference is dropped. Maybe this is > best visible if you consider (f b, g b). Overwriting parts of b in f > would change the argument to g. Thus, a copy has to be produced. It > would be valid if the compiler could prove that only one reference > exists and this is passed to f, but first this proof could be difficult > and second a separate version of f would have to be compiled. This may > even reduce performance, as the GC is exploiting the fact that most data > structures are immutable (although thunks are mutable as they are > overwritten by their result). Thus, such an optimization could hurt the > GC, which would result in a global slowdown, further reducing any gains > from overwriting the contents of the argument. Additionally, GCs are > quite cheep if not much data is alive. > > Thank you for the thorough and interesting response to my first two questions. I am hoping I might get additional clarification on this third question. Please forgive the use of the term "overwritten". Of course, the data structures are immutable. However, I was of the understanding that, through the use of persistent data structures, it was not necessary for the entire data structure to copied, if only part of the structure changes. Suppose I have a list data structure possessing millions of nodes and occupying 100MB of memory. And then suppose that the update function "drops" (speaking metaphorically!) two nodes off the front of the original list, and then prepends a new node to the front of that. Most of the original listed can be reused, since the new list can simply point to it after the first node. But what about those two nodes that were "dropped" from the list, and never used by anything else in the program. My question was: will they immediately be deallocated in memory right after the application of the update function? Or are they cleaned up later by the GC? And can we be sure that it will be on the next run of the GC, or could they be hanging around it memory for a while, depending on other factors? -- https://qlfiles.net To protect my privacy, please use PGP encryption. It's free and easy to use! My public key ID is 0x340EA95A (pgp.mit.edu). From harendra.kumar at gmail.com Thu Aug 4 02:00:43 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Thu, 4 Aug 2016 07:30:43 +0530 Subject: [Haskell-cafe] ANN: unicode-transforms-0.1.0.1 (unicode normalization) Message-ID: This is for those who want unicode normalization but do not want a dependency on the heavyweight icu libraries. It has the same API as the text-icu package. It is based on the utf8proc C implementation. https://hackage.haskell.org/package/unicode-transforms https://github.com/harendra-kumar/unicode-transforms A pure Haskell implementation is a work in progress, it works for the NFD normalization form as of now. I could make it perform better than the current utf8proc C implementation and it even beats the ICU implementation in one of the benchmarks. I intend to finish it when I find time to work on it again. Contributions are welcome! -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Thu Aug 4 02:45:49 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Thu, 4 Aug 2016 14:45:49 +1200 Subject: [Haskell-cafe] memory usage: general questions In-Reply-To: <57A29F85.8060100@zoho.com> References: <57A1790C.1010104@zoho.com> <76e26246-fa8a-b281-18da-95fb403f5f7d@tu-harburg.de> <57A29F85.8060100@zoho.com> Message-ID: On 4/08/16 1:51 PM, Christopher Howard wrote: > Please forgive the use of the term "overwritten". Of course, the data > structures are immutable. However, I was of the understanding that, > through the use of persistent data structures, it was not necessary for > the entire data structure to copied, if only part of the structure changes. > > Suppose I have a list data structure possessing millions of nodes and > occupying 100MB of memory. And then suppose that the update function > "drops" (speaking metaphorically!) two nodes off the front of the > original list, and then prepends a new node to the front of that. Most > of the original listed can be reused, since the new list can simply > point to it after the first node. But what about those two nodes that > were "dropped" from the list, and never used by anything else in the > program. My question was: will they immediately be deallocated in memory > right after the application of the update function? You can't tell. It depends on the implementation and the language. There is a Haskell-like language called Clean in which f :: (*x *x -> *x) *[!x!] -> *[!x!] f g [! x : [! y : zs !]!] = [g x y : zs] ([!x!] is both value and spine strict; [ _ : _ ] is cons, *t means unique) would allow the compiler to cannibalise one of the "dropped" nodes for the new node. Which if any versions of the Clean compiler actually do this I can't recall; I believe the 1.x compilers didn't but maybe 2.x ones do. This relies on the "uniqueness types" of Clean. Haskell is more interested in larger-scale improvements like deforestation. > Or are they cleaned up later by the GC? Modulo hand waving, yes. > And can we be sure that it will be on the next run > of the GC, What does that even mean? When you have "generational" collectors possibly using different strategies in different generations? When you have incremental collectors? When you have concurrent collectors? before the collector > or could they be hanging around it memory for a while, > depending on other factors? Well, when "the" garbage collector "runs" depends on other factors, so those are not exclusive alternatives. If you think about traditional reference counting (which is not a silly thing to do in a Haskell context, because there are some truly impressive hybrid reference counting GCs these days), lazy decrementing meant that if a chunk of data became garbage, *part* of it could be reclaimed promptly, but the contents would only incremently be freed as a side effect of allocation. Memory management is a complex business, and depending on exactly what a language's run-time does is risky. > From maydwell at gmail.com Thu Aug 4 06:13:11 2016 From: maydwell at gmail.com (Lyndon Maydwell) Date: Thu, 4 Aug 2016 16:13:11 +1000 Subject: [Haskell-cafe] [ANN] Compose :: Melbourne 2016 Speakers! Message-ID: Hello Everyone! In case you haven't heard, Compose :: Melbourne (the new sister-conference of Compose) has now announced its program of presentations for the first day: http://www.composeconference.org/2016-melbourne/day-one-program/ Compose is a conference for functional programmers, focused on technologies such as Haskell, Scala, Clojure, OCaml, F#, SML and others. Compose :: Melbourne will run on the 29th and 30th of August (this month!) We're excited to have a wide range of talks on a diverse selection of topics including an opening keynote by Manuel M.T. Chakravarty (the author of Haskell for Mac). There will be a single track of 10 speakers from Melbourne, Australia, and around the world! ## Unconference and Workshops The second day of the conference will take the form of an unconference. The day will also feature a collection of organised, as well as spontaneous workshops including introductions to Haskell and Purescript: http://www.composeconference.org/2016-melbourne/unconference/ ## Financial Assistance If you need help attending Compose :: Melbourne, then contact us. We have put in place a financial-assistance plan: http://www.composeconference.org/2016-melbourne/assistance/ ## Volunteering As Compose :: Melbourne will be running in just a few short weeks, we're currently looking for volunteers to help assist with running the workshops on day-two. If you feel like lending a hand, then don't hesitate to get in touch! ## Sponsorship If you, or your organisation wishes to lend assistance to Compose :: Melbourne, we are accepting sponsorship. If you want to learn more, then please view our sponsorship-prospectus: https://github.com/composeconference/Compose-Melbourne/wiki/Sponsorship-Tiers ## Getting in Touch To get in touch with the organisers of Compose :: Melbourne, then email the committee at . For more information, see the home-page of Compose Conference: http://www.composeconference.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From heraldhoi at gmail.com Thu Aug 4 07:36:35 2016 From: heraldhoi at gmail.com (Geraldus) Date: Thu, 04 Aug 2016 07:36:35 +0000 Subject: [Haskell-cafe] Design Question - Functions taking 'subtype' like arguments but has to be restricted to one type In-Reply-To: References: <8ed829cc-3f7b-407d-a1cb-fd66785ac60a@googlegroups.com> <614e9096-57a1-21da-7e75-a0ffc8d977cf@gmail.com> Message-ID: Please excuse me an off-topic question, *MarLinn* can you say what apostrophe means in `Item 'Changeable`? ср, 3 авг. 2016 г. в 20:00, MarLinn via Haskell-Cafe < haskell-cafe at haskell.org>: > I'll try to address the questions in the reverse order. > > > Does this approach give me any more power than the previous approaches? > The one power is that we stop the user from being able to construct the > Frozen type, and we leave it to the compiler to return that type based on > the inference. Correct? Is there any other power. > > The main power lies in the minimalism. You don't need special handling of > an *Either* or manual tracking because the types do everything you need. > > > In your approach or in the approach suggested by others, ultimately, I end > up handling the 'Frozen' type during run-time. > > Actually, not really. That's the beauty of phantom types: It's almost > exclusively a development-time tool that vanishes once the program is > compiled. You can't handle the Frozen type during run-time because it will > have been dropped - unless you use tricks to keep it, of course. It might > feel like you're dealing with the type, but it's all in your head. > > > There is no way from stopping somene write code that calls update's on > Frozen. (For example while mapping..). Is that understanding correct? > > Here's my *Item* type again for reference: > > data Item (c :: Changeability) = Item { plainItem :: PlainItem } > > If you don't export the *Item* constructor, you have full control over > who gets to do what with your items. If your only exported update function > is > > changeItem :: (PlainItem -> PlainItem) -> Item 'Changeable -> Item 'Changeable > > then only non-frozen items can be changed, as the type signature says. Of > course you have to be careful, e.g. you wouldn't want to export a function > like > > asChangableItem :: PlainItem -> Item 'Changeable > > because then somebody could "unfreeze" items. But as long as you watch > your types and exports, you should be fine. (apart from unsafe casting and > the like, naturally) > > 1. With the definition of Basket c, how do I create a type such as > > Cart = [Basket]. The only way to create such a cart is Cart c = [Basket > c]. But, that ties the Cart to one definition of Basket. Is there a way > around this? I might be missing something simple. > > That depends. How does a cart behave, depending on the changeability of > its contents? > > - > > *If a cart with any frozen value behaves differently from a cart with > only changeable baskets* then add a phantom type to the cart as well. > Control the channels into it and have the cart type change depending on > what you insert. > - > > *If all carts behave the same and contents don't matter* just store > *PlainBasket*s, i.e. a *Basket* without the annotation. > - > > *If you want to be able to map over baskets in a cart while handling > frozen ones** differently*, then you need both run-time information > about basket changeability and a way to share functions between the two > different types. The canonical way to share a function between types is a > class: > > class IsBasket b > instance IsBasket (Basket c) > type Cart = (IsBasket b) => [b] -- not a good definition, but you get the point > > Now *Basket*s can share functions but behave differently. Of course > once you need such a class anyway you could ask why you would not want to > use it exclusively instead of the phantom types. It's a matter of taste, I > guess. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Thu Aug 4 07:40:26 2016 From: hesselink at gmail.com (Erik Hesselink) Date: Thu, 4 Aug 2016 09:40:26 +0200 Subject: [Haskell-cafe] Design Question - Functions taking 'subtype' like arguments but has to be restricted to one type In-Reply-To: References: <8ed829cc-3f7b-407d-a1cb-fd66785ac60a@googlegroups.com> <614e9096-57a1-21da-7e75-a0ffc8d977cf@gmail.com> Message-ID: It's a data constructor promoted to be a type. Similarly the type can be promoted to become a kind. See also [1]. Erik [1] https://downloads.haskell.org/~ghc/7.10.3/docs/html/users_guide/promotion.html On 4 August 2016 at 09:36, Geraldus wrote: > Please excuse me an off-topic question, MarLinn can you say what apostrophe > means in `Item 'Changeable`? > > ср, 3 авг. 2016 г. в 20:00, MarLinn via Haskell-Cafe > : >> >> I'll try to address the questions in the reverse order. >> >> >> Does this approach give me any more power than the previous approaches? >> The one power is that we stop the user from being able to construct the >> Frozen type, and we leave it to the compiler to return that type based on >> the inference. Correct? Is there any other power. >> >> The main power lies in the minimalism. You don't need special handling of >> an Either or manual tracking because the types do everything you need. >> >> >> In your approach or in the approach suggested by others, ultimately, I end >> up handling the 'Frozen' type during run-time. >> >> Actually, not really. That's the beauty of phantom types: It's almost >> exclusively a development-time tool that vanishes once the program is >> compiled. You can't handle the Frozen type during run-time because it will >> have been dropped - unless you use tricks to keep it, of course. It might >> feel like you're dealing with the type, but it's all in your head. >> >> >> There is no way from stopping somene write code that calls update's on >> Frozen. (For example while mapping..). Is that understanding correct? >> >> Here's my Item type again for reference: >> >> data Item (c :: Changeability) = Item { plainItem :: PlainItem } >> >> If you don't export the Item constructor, you have full control over who >> gets to do what with your items. If your only exported update function is >> >> changeItem :: (PlainItem -> PlainItem) -> Item 'Changeable -> Item >> 'Changeable >> >> then only non-frozen items can be changed, as the type signature says. Of >> course you have to be careful, e.g. you wouldn't want to export a function >> like >> >> asChangableItem :: PlainItem -> Item 'Changeable >> >> because then somebody could "unfreeze" items. But as long as you watch >> your types and exports, you should be fine. (apart from unsafe casting and >> the like, naturally) >> >> >> 1. With the definition of Basket c, how do I create a type such as >> >> Cart = [Basket]. The only way to create such a cart is Cart c = [Basket >> c]. But, that ties the Cart to one definition of Basket. Is there a way >> around this? I might be missing something simple. >> >> That depends. How does a cart behave, depending on the changeability of >> its contents? >> >> If a cart with any frozen value behaves differently from a cart with only >> changeable baskets then add a phantom type to the cart as well. Control the >> channels into it and have the cart type change depending on what you insert. >> >> If all carts behave the same and contents don't matter just store >> PlainBaskets, i.e. a Basket without the annotation. >> >> If you want to be able to map over baskets in a cart while handling frozen >> ones differently, then you need both run-time information about basket >> changeability and a way to share functions between the two different types. >> The canonical way to share a function between types is a class: >> >> class IsBasket b >> instance IsBasket (Basket c) >> type Cart = (IsBasket b) => [b] -- not a good definition, but you get >> the point >> >> Now Baskets can share functions but behave differently. Of course once you >> need such a class anyway you could ask why you would not want to use it >> exclusively instead of the phantom types. It's a matter of taste, I guess. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From corentin.dupont at gmail.com Thu Aug 4 10:16:51 2016 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Thu, 4 Aug 2016 12:16:51 +0200 Subject: [Haskell-cafe] Views of data types Message-ID: Hi guys, I have a typeclass like that: class Signal s where type SignalData s :: * The idea is that when some signal "s" fires, it returns a data of type (SignalData s). This is all fine except when I instantiate the class with: data Input a = Input [(a, String)] instance Signal (Input a) type SignalData (Input a) = a The concrete type of Input a is not known, so its difficult to store in lists, to serialize... So I need to create a "view" for the it: class (Signal s, Signal v) => SignalView s v where view :: s -> v data InputView = InputView [(Int, String)] instance Signal InputView type SignalData InputView = Int instance SignalView (Input a) InputView view (Input as) = InputView (zip [0…] (snd <$> as)) Is this a common pattern? I'm not sure I get it right... -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu Aug 4 11:23:19 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 4 Aug 2016 12:23:19 +0100 Subject: [Haskell-cafe] Views of data types In-Reply-To: References: Message-ID: <20160804112319.GE18591@weber> On Thu, Aug 04, 2016 at 12:16:51PM +0200, Corentin Dupont wrote: > class Signal s where > type SignalData s :: * > > The idea is that when some signal "s" fires, it returns a data of type > (SignalData s). This is all fine except when I instantiate the class > with: > > data Input a = Input [(a, String)] > > instance Signal (Input a) > type SignalData (Input a) = a > > The concrete type of Input a is not known, so its difficult to store in > lists, to serialize... So I need to create a "view" for the it: > > class (Signal s, Signal v) => SignalView s v where > view :: s -> v > > data InputView = InputView [(Int, String)] > > instance Signal InputView > type SignalData InputView = Int > > instance SignalView (Input a) InputView > view (Input as) = InputView (zip [0…] (snd <$> as)) > > Is this a common pattern? > I'm not sure I get it right... Why not just write a function 'Input a -> Input Int' and serialise the result? From info at jonkri.org Thu Aug 4 20:15:06 2016 From: info at jonkri.org (Jon Kristensen) Date: Thu, 4 Aug 2016 22:15:06 +0200 Subject: [Haskell-cafe] Suggestions for an empirical master thesis Message-ID: <6018c63e-b60f-6002-ed22-c46276056d9e@jonkri.org> Hi, everyone! I'm looking for a master thesis topic that is empirical in nature (like, statistics, hypothesis testing, etc.). The work could involve analyzing either package metadata (Cabal information), code (AST), and/or data from some other source, possibly comparing similar data from some non-Haskell domain. As an example, one idea that was suggested to me was to look at usage aggregation, or like, how much of a given package another package is actually using (which could be relevant in any orphan-instance discussion). From an academic standpoint, it would be good to pick a metric that can be validated in some way. Thank you! Best, Jon From msuzen at gmail.com Fri Aug 5 12:28:39 2016 From: msuzen at gmail.com (Suzen, Mehmet) Date: Fri, 5 Aug 2016 13:28:39 +0100 Subject: [Haskell-cafe] Suggestions for an empirical master thesis In-Reply-To: <6018c63e-b60f-6002-ed22-c46276056d9e@jonkri.org> References: <6018c63e-b60f-6002-ed22-c46276056d9e@jonkri.org> Message-ID: Jon, Why don't you do some graph analysis on the entire hackage using the metadata? Build a graph and analyse its statistical properties. Best, -m On 4 August 2016 at 21:15, Jon Kristensen wrote: > Hi, everyone! > > I'm looking for a master thesis topic that is empirical in nature (like, > statistics, hypothesis testing, etc.). > > The work could involve analyzing either package metadata (Cabal > information), code (AST), and/or data from some other source, possibly > comparing similar data from some non-Haskell domain. > > As an example, one idea that was suggested to me was to look at usage > aggregation, or like, how much of a given package another package is > actually using (which could be relevant in any orphan-instance discussion). > > From an academic standpoint, it would be good to pick a metric that can be > validated in some way. > > Thank you! > > Best, > Jon > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From ruben.astud at gmail.com Fri Aug 5 18:49:21 2016 From: ruben.astud at gmail.com (Ruben Astudillo) Date: Fri, 5 Aug 2016 14:49:21 -0400 Subject: [Haskell-cafe] a wiki in yesod package Message-ID: <0fa6956b-0432-c923-9bc9-159a95787990@gmail.com> Hi all I've been looking for a package or helpful material to do a wiki based on yesod. I seen the example on the book[1] and thought maybe somebody published something. by the way: which is the mailing list of yesod? the haskell-web is really silent. [1]: http://www.yesodweb.com/book/wiki-chat-example -- -- Ruben Astudillo From gurudev.devanla at gmail.com Sat Aug 6 03:39:45 2016 From: gurudev.devanla at gmail.com (Guru Devanla) Date: Fri, 5 Aug 2016 20:39:45 -0700 Subject: [Haskell-cafe] Design Question - Functions taking 'subtype' like arguments but has to be restricted to one type In-Reply-To: References: <8ed829cc-3f7b-407d-a1cb-fd66785ac60a@googlegroups.com> <614e9096-57a1-21da-7e75-a0ffc8d977cf@gmail.com> Message-ID: On Wed, Aug 3, 2016 at 7:58 AM, MarLinn via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > *If all carts behave the same and contents don't matter* just store > *PlainBasket*s, i.e. a *Basket* without the annotation. @MarLinn, Can you clarify the quoted statement. If I were to make store PlainBaskets in the Cart, where would be annotating the Item as Changeble/Unchangable? The way I understand this, you will have to pass their phatom type all the way from the top to the innermost field where it is required. Would the design still hold, if we just declare Baskets of Plain types? I appreciate your response, so far your design make sense. But, I am afraid I am not able to extend it to higher container types. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at jonkri.org Sat Aug 6 11:16:23 2016 From: info at jonkri.org (Jon Kristensen) Date: Sat, 6 Aug 2016 13:16:23 +0200 Subject: [Haskell-cafe] Suggestions for an empirical master thesis In-Reply-To: References: <6018c63e-b60f-6002-ed22-c46276056d9e@jonkri.org> Message-ID: Hi, Mehmet! Thank you for your suggestion! I think that I will need to describe some concrete goals, and provide some evidence from literature that the area includes, or is related to, particular scientific and engineering challenges. I will take a look at related papers about this, but any thoughts on it would be welcome! Best, Jon On 08/05/2016 02:28 PM, Suzen, Mehmet wrote: > Jon, > > Why don't you do some graph analysis on the entire hackage using the > metadata? Build a graph and analyse its statistical properties. > > Best, > -m > > On 4 August 2016 at 21:15, Jon Kristensen wrote: >> Hi, everyone! >> >> I'm looking for a master thesis topic that is empirical in nature (like, >> statistics, hypothesis testing, etc.). >> >> The work could involve analyzing either package metadata (Cabal >> information), code (AST), and/or data from some other source, possibly >> comparing similar data from some non-Haskell domain. >> >> As an example, one idea that was suggested to me was to look at usage >> aggregation, or like, how much of a given package another package is >> actually using (which could be relevant in any orphan-instance discussion). >> >> From an academic standpoint, it would be good to pick a metric that can be >> validated in some way. >> >> Thank you! >> >> Best, >> Jon >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. From damian.nadales at gmail.com Sat Aug 6 11:37:20 2016 From: damian.nadales at gmail.com (Damian Nadales) Date: Sat, 6 Aug 2016 13:37:20 +0200 Subject: [Haskell-cafe] Suggestions for an empirical master thesis In-Reply-To: <6018c63e-b60f-6002-ed22-c46276056d9e@jonkri.org> References: <6018c63e-b60f-6002-ed22-c46276056d9e@jonkri.org> Message-ID: Hi Jon, Allow me to brainstorm with you. I don't know what is done in the context of code metrics for Haskell programs, but you could try to find correlations (of their lack thereof) between metrics such as (cyclomatic complexity, fan-in/fan-out) and bugs. For this you could use the Github repositories. The number of bugs would have to be normalized using the numbers of users of a project (maybe measured in number of downloads). Just an idea... On Thu, Aug 4, 2016 at 10:15 PM, Jon Kristensen wrote: > Hi, everyone! > > I'm looking for a master thesis topic that is empirical in nature (like, > statistics, hypothesis testing, etc.). > > The work could involve analyzing either package metadata (Cabal > information), code (AST), and/or data from some other source, possibly > comparing similar data from some non-Haskell domain. > > As an example, one idea that was suggested to me was to look at usage > aggregation, or like, how much of a given package another package is > actually using (which could be relevant in any orphan-instance discussion). > > From an academic standpoint, it would be good to pick a metric that can be > validated in some way. > > Thank you! > > Best, > Jon > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at googlemail.com Sat Aug 6 14:23:00 2016 From: monkleyon at googlemail.com (MarLinn) Date: Sat, 6 Aug 2016 16:23:00 +0200 Subject: [Haskell-cafe] Design Question - Functions taking 'subtype' like arguments but has to be restricted to one type In-Reply-To: References: <8ed829cc-3f7b-407d-a1cb-fd66785ac60a@googlegroups.com> <614e9096-57a1-21da-7e75-a0ffc8d977cf@gmail.com> Message-ID: <73a5a0ed-cd0a-a84b-416a-e134329a01d5@gmail.com> > /If all carts behave the same and contents don't matter/ just > store /PlainBasket/s, i.e. a /Basket/ without the annotation. > > Can you clarify the quoted statement. If I were to make store > PlainBaskets in the Cart, where would be annotating the Item as > Changeble/Unchangable? Well /contents don't matter, /so there is no annotation once you enter a cart. -- A/PlainBasket/ is to a/Basket/ as a/PlainItem/ is to an/Item./ data PlainBasket = PlainBasket { plainBasketName :: String, plainBasketItem :: PlainItem } data Basket c = Basket { basketName :: String, basketItem :: Item c } newtype Cart = Cart [PlainBasket] addBasketToCart :: Basket c -> Cart -> Cart addBasketToCart Basket{..} (Cart cart) = Cart $ newPlainBasket:cart where newPlainBasket = PlainBasket { plainBasketName = basketName , plainBasketItem = plainItem basketItem } The newtype protects your cart from arbitrary changes, so frozen baskets are still protected. But the annotations are discarded. So naturally, you can not recover changeability and you shouldn't allow arbitrary mapping. If you need one of these, this is not the right option. It really depends on what you actually need. Of course you could add a changeability field to /PlainBasket/s and thus store the information at runtime again. But Theodores /Either/-approach or variations of the class I propose in my the third option are more elegant forms of that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From borgauf at gmail.com Sat Aug 6 20:53:18 2016 From: borgauf at gmail.com (Lawrence Bottorff) Date: Sat, 6 Aug 2016 16:53:18 -0400 Subject: [Haskell-cafe] Comparable Haskell text(s) to "ML for the Working Programmer"? Message-ID: Is there a book or books that cover as much, as well as the Lawrence Paulson "ML for the Working Programmer (2nd ed)" for Haskell? What I'd like in Haskell form is pretty much exactly what Paulson covers in his brilliant book. LB -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian.only at gmail.com Sat Aug 6 21:11:27 2016 From: damian.only at gmail.com (Damian) Date: Sat, 6 Aug 2016 23:11:27 +0200 Subject: [Haskell-cafe] Comparable Haskell text(s) to "ML for the Working Programmer"? In-Reply-To: References: Message-ID: Can you enumerate which features you liked about that book, and which topics it covered? Op 6 aug. 2016 22:53 schreef "Lawrence Bottorff" : > Is there a book or books that cover as much, as well as the Lawrence > Paulson "ML for the Working Programmer (2nd ed)" for Haskell? What I'd like > in Haskell form is pretty much exactly what Paulson covers in his brilliant > book. > > LB > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From targen at gmail.com Sat Aug 6 21:11:34 2016 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Sat, 6 Aug 2016 17:11:34 -0400 Subject: [Haskell-cafe] a wiki in yesod package In-Reply-To: <0fa6956b-0432-c923-9bc9-159a95787990@gmail.com> References: <0fa6956b-0432-c923-9bc9-159a95787990@gmail.com> Message-ID: On Fri, Aug 5, 2016 at 2:49 PM, Ruben Astudillo wrote: > by the way: which is the mailing list of yesod? the haskell-web is really > silent. Try here: https://groups.google.com/d/forum/yesodweb From stephen.tetley at gmail.com Sat Aug 6 21:35:48 2016 From: stephen.tetley at gmail.com (Stephen Tetley) Date: Sat, 6 Aug 2016 22:35:48 +0100 Subject: [Haskell-cafe] Comparable Haskell text(s) to "ML for the Working Programmer"? In-Reply-To: References: Message-ID: ML for the Working Programmer is roughly equivalent of SICP but uses SML instead of Scheme. It also covers most (?) of the SML language whereas SICP is not really a book about (MIT-) Scheme. The closest Haskell equivalent might be the second edition of Graham Hutton's Programming in Haskell from what I've seen of the press release and table of contents. The first edition was very much a short and readable introduction to functional programming in Haskell (not covering all of the Haskell language). It looks the second edition takes a significantly deeper look at Haskell the language. On 6 August 2016 at 22:11, Damian wrote: > Can you enumerate which features you liked about that book, and which > topics it covered? > > > Op 6 aug. 2016 22:53 schreef "Lawrence Bottorff" : >> >> Is there a book or books that cover as much, as well as the Lawrence >> Paulson "ML for the Working Programmer (2nd ed)" for Haskell? What I'd like >> in Haskell form is pretty much exactly what Paulson covers in his brilliant >> book. >> >> LB >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From doug at cs.dartmouth.edu Sat Aug 6 23:15:49 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 06 Aug 2016 19:15:49 -0400 Subject: [Haskell-cafe] Suggestions for an empirical master thesis Message-ID: <201608062315.u76NFnHt016926@coolidge.cs.Dartmouth.EDU> > >The number of bugs would have to be normalized using the numbers of users of a project (maybe measured in number of downloads). From doug at cs.dartmouth.edu Sat Aug 6 23:22:13 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Sat, 06 Aug 2016 19:22:13 -0400 Subject: [Haskell-cafe] Suggestions for an empirical master thesis Message-ID: <201608062322.u76NMDai016935@coolidge.cs.Dartmouth.EDU> >The number of bugs would have to be normalized using the numbers of users of a project (maybe measured in number of downloads). Do you expect more bugs for frequently downloaded packages, or fewer downloads for packages with many bug reports or bug rate diminishing with downloads? It's a slippery topic. Doug From damian.nadales at gmail.com Sun Aug 7 07:06:31 2016 From: damian.nadales at gmail.com (Damian Nadales) Date: Sun, 7 Aug 2016 09:06:31 +0200 Subject: [Haskell-cafe] Suggestions for an empirical master thesis In-Reply-To: <201608062322.u76NMDai016935@coolidge.cs.Dartmouth.EDU> References: <201608062322.u76NMDai016935@coolidge.cs.Dartmouth.EDU> Message-ID: On Sun, Aug 7, 2016 at 1:22 AM, Doug McIlroy wrote: > > > >The number of bugs would have to be normalized using the > numbers of users of a project (maybe measured in number of downloads). > > Do you expect more bugs for frequently downloaded packages, > or fewer downloads for packages with many bug reports > or bug rate diminishing with downloads? It's a slippery > topic. > The question is whether code metrics could serve as a proxy for code-quality/sustainability. I didn't suggest to look for associations between downloads and bug-reports, but use the number of users as an extra variable in the model (to normalize the data). So if we assume that all the other variables remain the same, does code with better metrics exhibit better quality features in practice? > > Doug > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From adam at bergmark.nl Sun Aug 7 12:42:59 2016 From: adam at bergmark.nl (Adam Bergmark) Date: Sun, 7 Aug 2016 14:42:59 +0200 Subject: [Haskell-cafe] [ANN] aeson 1.0.0.0 Message-ID: Hi haskellers, I'm happy to announce that aeson v1.0.0.0 is now available on hackage! While 0.11.x was mostly regression fixes 1.x adds a lot of improvements that had been in the pipeline for a long time. We decided to move to 1.x since there are a lot of changes. Fortunately most of them are backwards-compatible so hopefully migration will be simple for you. Still, we recommend reading the changelog (https://github.com/bos/aeson/blob/master/changelog.md#1000) Thanks to all contributors of this release: * Adam Bergmark * Andrew Martin * Artyom * Ewout * Matthías Páll Gissurarson * Oleg Grenrus * Ryan Scott * lyxia Regards, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Sun Aug 7 19:20:09 2016 From: danburton.email at gmail.com (Dan Burton) Date: Sun, 7 Aug 2016 12:20:09 -0700 Subject: [Haskell-cafe] [ANN] aeson 1.0.0.0 In-Reply-To: References: Message-ID: Congrats on the release! It's always nice to see libraries move past version 0.*. -- Dan Burton On Sun, Aug 7, 2016 at 5:42 AM, Adam Bergmark wrote: > Hi haskellers, > > I'm happy to announce that aeson v1.0.0.0 is now available on hackage! > > While 0.11.x was mostly regression fixes 1.x adds a lot of > improvements that had been in the pipeline for a long time. > > We decided to move to 1.x since there are a lot of > changes. Fortunately most of them are backwards-compatible so > hopefully migration will be simple for you. Still, we recommend reading > the > changelog (https://github.com/bos/aeson/blob/master/changelog.md#1000) > > Thanks to all contributors of this release: > * Adam Bergmark > * Andrew Martin > * Artyom > * Ewout > * Matthías Páll Gissurarson > * Oleg Grenrus > * Ryan Scott > * lyxia > > Regards, > Adam > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at jonkri.org Mon Aug 8 11:59:03 2016 From: info at jonkri.org (Jon Kristensen) Date: Mon, 8 Aug 2016 13:59:03 +0200 Subject: [Haskell-cafe] Suggestions for an empirical master thesis In-Reply-To: References: <201608062322.u76NMDai016935@coolidge.cs.Dartmouth.EDU> Message-ID: That's interesting! Thank you very much! Best, Jon On 08/07/2016 09:06 AM, Damian Nadales wrote: > On Sun, Aug 7, 2016 at 1:22 AM, Doug McIlroy wrote: >> >>> The number of bugs would have to be normalized using the >> numbers of users of a project (maybe measured in number of downloads). >> >> Do you expect more bugs for frequently downloaded packages, >> or fewer downloads for packages with many bug reports >> or bug rate diminishing with downloads? It's a slippery >> topic. >> > The question is whether code metrics could serve as a proxy for > code-quality/sustainability. I didn't suggest to look for associations > between downloads and bug-reports, but use the number of users as an > extra variable in the model (to normalize the data). So if we assume > that all the other variables remain the same, does code with better > metrics exhibit better quality features in practice? > > >> Doug >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From code at funwithsoftware.org Tue Aug 9 15:04:56 2016 From: code at funwithsoftware.org (Patrick Pelletier) Date: Tue, 9 Aug 2016 08:04:56 -0700 Subject: [Haskell-cafe] [ANN] normalization-insensitive-2.0 Message-ID: normalization-insensitive is identical to case-insensitive, except it is insensitive to Unicode normalization, rather than case. The module Data.Unicode.NormalizationInsensitive provides the NI type constructor which can be parameterized by a string-like type like: String, ByteString, Text, etc.. Comparisons of values of the resulting type will be insensitive to normalization. https://hackage.haskell.org/package/normalization-insensitive https://github.com/ppelleti/normalization-insensitive I created this to solve a problem I was running into comparing filenames on Mac OS X. Because Mac OS X converts all filenames to Normalization Form D, the filenames I read back from disk were different than the filenames I had written to disk. This package solved the problem very neatly. Under the hood, normalization-insensitive uses the unicode-transforms package, which Harendra Kumar announced a few days ago on haskell-cafe. This avoids having to pull in any heavyweight dependencies like ICU. Thanks to Bas van Dijk for writing case-insensitive, upon which normalization-insensitive is based. And thanks for Harendra Kumar for reviewing normalization-insensitive and providing feedback, as well as writing unicode-transforms. Although this is the first release of normalization-insensitive, the version number is 2.0 to avoid any confusion with the version numbers of case-insensitive. --Patrick From ollie at ocharles.org.uk Wed Aug 10 17:18:05 2016 From: ollie at ocharles.org.uk (Oliver Charles) Date: Wed, 10 Aug 2016 17:18:05 +0000 Subject: [Haskell-cafe] C call blocking indefinitely/behaving differently when called from Haskell Message-ID: Hi all, I'm trying to interface with a Basler USB3 camera from a Haskell application, but I'm experiencing some difficulty. The camera comes with a C++ library that makes it fairly straight forward. The following code can be used to acquire a camera source: PylonAutoInitTerm pylon; CInstantCamera camera( CTlFactory::GetInstance().CreateFirstDevice()); camera.RegisterConfiguration( (CConfigurationEventHandler*) NULL, RegistrationMode_ReplaceAll, Cleanup_None); cout << "Using device " << camera.GetDeviceInfo().GetModelName() << endl; Using the inline-c and inline-c-cpp libraries, I am trying to perform this same call from a Haskell executable. I have the following: {-# LANGUAGE QuasiQuotes, TemplateHaskell #-} import qualified Language.C.Inline as C import qualified Language.C.Inline.Cpp as C C.context C.cppCtx C.include "pylon/PylonIncludes.h" C.include "iostream" C.using "namespace Pylon"; C.using "namespace std"; main :: IO () main = [C.block| void { PylonAutoInitTerm pylon; CInstantCamera camera( CTlFactory::GetInstance().CreateFirstDevice()); camera.RegisterConfiguration( (CConfigurationEventHandler*) NULL, RegistrationMode_ReplaceAll, Cleanup_None); cout << "Using device " << camera.GetDeviceInfo().GetModelName() << endl; }|] However, when the resulting executable is ran, it hangs - failing to print "Using device". inline-c generates a Test.cpp file, which contains #include "pylon/PylonIncludes.h" #include "iostream" using namespace Pylon; using namespace std; extern "C" { void inline_c_Main_0_e23f0c6a0bc10367be76252744bf4e6c74493314() { PylonAutoInitTerm pylon; CInstantCamera camera( CTlFactory::GetInstance().CreateFirstDevice()); camera.RegisterConfiguration( (CConfigurationEventHandler*) NULL, RegistrationMode_ReplaceAll, Cleanup_None); cout << "Using device " << camera.GetDeviceInfo().GetModelName() << endl; } } If I modify this exact file, I can turn it into something that can be run, by simply adding: int main() { inline_c_Main_0_e23f0c6a0bc10367be76252744bf4e6c74493314(); } At this point, I can now compile that very C++ code with G++ and run it: [nix-shell:~/work/circuithub/receiving-station]$ g++ Test.cpp -I/home/ollie/work/circuithub/receiving-station/pylon5/include -L/home/ollie/work/circuithub/receiving-station/pylon5/lib64 -Wl,-E -lpylonbase -lpylonu tility -lGenApi_gcc_v3_0_Basler_pylon_v5_0 -lGCBase_gcc_v3_0_Basler_pylon_v5_0 -Wl,--enable-new-dtags -Wl,-rpath,/home/ollie/work/circuithub/receiving-station/pylon5/lib64 [nix-shell:~/work/circuithub/receiving-station]$ ./a.out GetDeviceDiscoveryInfo: bFunctionClass = 14, bFunctionSubClass = 3, bFunctionProtocol = 0. Device is not an U3V device. GetDeviceDiscoveryInfo: bFunctionClass = 14, bFunctionSubClass = 3, bFunctionProtocol = 0. Device is not an U3V device. Using device acA3800-14um So as we can see, the C++ code is not the problem. Does anyone know why I don't see the same behaviour from my Haskell application? I imagine there might be some thread trickery happening behind the scenes, but I don't know what to even begin looking for. Thanks, let me know if you need any more information. - Ollie -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Thu Aug 11 04:37:57 2016 From: anthony_clayden at clear.net.nz (=?UTF-8?B?QW50aG9ueSBDbGF5ZGVu?=) Date: Thu, 11 Aug 2016 07:37:57 +0300 Subject: [Haskell-cafe] =?utf-8?q?library_for_set_of_heterogeneous_values?= =?utf-8?q?=3F?= Message-ID: <1470890276.638665871@f25.my.com> I have a (let's call it) database of heterogeneous records. They're not Haskell records, but anonymous/extensible type-labelled rows. (Could be tuples, could be HLists, could be Lens-like, could be something fancier.) There's a small number (dozens) of distinct row types, each with a large number (thousands) of rows. The variety of row-types is not predictable in advance. And indeed a row might 'morph' over time with fields added/removed. So the obvious answer of putting the lot into a giant HList (each element of the list being a row) isn't going to scale. I could have a type-indexed HList in which each element is a Set of homogeneous rows. But performance still suffers from scanning along the list to find the right type index. Is there something better? On hackage there's two packages called HSet, neither giving very much help about their suitability: * `hset` (lower case) [AlekseyUymanov] seems isomorphic to a type-indexed HList.       ie Must be unique type in each element (could be a Set type, I guess) * `HSet` (upper case) [athanclark] "Faux heterogeneous sets" seems a lot meatier      why the "Faux"?      built over hashtables in the ST monad. Has anybody used these? Can give guidance on what they can and can't? Bonus questions: Given a filter specifying a restriction on (some) fields of rows, I want to get a heterog subset: * all rows with at least those fields, matching those restrictions. * the restriction might be merely "has field labelled L". GIven a candidate row for insertion, I want first to scan for quasi-duplicates: * any existing row with a subset of the given fields, and the same value at those fields. * any existing row with a superset of the given fields, and the same value at those fields in common. * ignore records with only a partial overlap of fields. One possible data structure: a "vertical store". Give each row a Globally Unique Id. Have a separate set for each possible field, where the set elements are field value (key) to set of GUId -- records with that value. Then I have a different bonus question: * how to retrieve all field values for a given GUId? Thanks AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jake.waksbaum at gmail.com Thu Aug 11 07:03:55 2016 From: jake.waksbaum at gmail.com (Jake) Date: Thu, 11 Aug 2016 03:03:55 -0400 Subject: [Haskell-cafe] Read lines of a file into a Vector In-Reply-To: References: Message-ID: I want to write a function that will read the contents of a file and return a Vector of its lines: readLines :: Handle -> IO (Vector String) I have an implementation that works but seems to naive and inefficient to me because it reads the entire file contents, *then *splits it into lines, and *then* converts it to a Vector from a list. readLines h = fromList . lines <$> hGetContents h I would like to a) use hGetLine and continue until I get an isEOFError and b) read directly into a Vector instead of a list. I started something using Data.Vector.unfoldr but I the presence of the IO monad around my String was causing issues I couldn't figure out how to solve. I'd also be curious to see how to do either one of these things separately and I assume they'd each help make my program more efficient on their own. Or, maybe my implementation is not as terrible as I thought because some laziness/fusion/optimization magic is happening behind the scenes? Thanks, Jake Waksbaum -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Thu Aug 11 07:27:14 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 11 Aug 2016 10:27:14 +0300 Subject: [Haskell-cafe] Read lines of a file into a Vector In-Reply-To: References: Message-ID: Thanks to the lazy IO, deforestration and fusion framework in `Vector`, readLines h = fromList . lines <$> hGetContents h shouldn’t create intermediate lists or/and read the whole file at once into memory. - Oleg > On 11 Aug 2016, at 10:03, Jake wrote: > > I want to write a function that will read the contents of a file and return a Vector of its lines: > > readLines :: Handle -> IO (Vector String) > > I have an implementation that works but seems to naive and inefficient to me because it reads the entire file contents, then splits it into lines, and then converts it to a Vector from a list. > > readLines h = fromList . lines <$> hGetContents h > > I would like to a) use hGetLine and continue until I get an isEOFError and b) read directly into a Vector instead of a list. I started something using Data.Vector.unfoldr but I the presence of the IO monad around my String was causing issues I couldn't figure out how to solve. > > I'd also be curious to see how to do either one of these things separately and I assume they'd each help make my program more efficient on their own. Or, maybe my implementation is not as terrible as I thought because some laziness/fusion/optimization magic is happening behind the scenes? > > Thanks, > Jake Waksbaum > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From tdammers at gmail.com Thu Aug 11 17:57:35 2016 From: tdammers at gmail.com (Tobias Dammers) Date: Thu, 11 Aug 2016 19:57:35 +0200 Subject: [Haskell-cafe] Read lines of a file into a Vector In-Reply-To: References: Message-ID: If I'm not mistaken, lazy lists and lazy IO alone make this a reasonably efficient implementation; even without further optimizations, the intermediate lists would most likely never reside in memory all at once. On Aug 11, 2016 9:27 AM, "Oleg Grenrus" wrote: > Thanks to the lazy IO, deforestration and fusion framework in `Vector`, > > readLines h = fromList . lines <$> hGetContents h > > shouldn’t create intermediate lists or/and read the whole file at once > into memory. > > - Oleg > > > On 11 Aug 2016, at 10:03, Jake wrote: > > I want to write a function that will read the contents of a file and > return a Vector of its lines: > > readLines :: Handle -> IO (Vector String) > > I have an implementation that works but seems to naive and inefficient to > me because it reads the entire file contents, *then *splits it into > lines, and *then* converts it to a Vector from a list. > > readLines h = fromList . lines <$> hGetContents h > > I would like to a) use hGetLine and continue until I get an isEOFError and > b) read directly into a Vector instead of a list. I started something using > Data.Vector.unfoldr but I the presence of the IO monad around my String was > causing issues I couldn't figure out how to solve. > > I'd also be curious to see how to do either one of these things separately > and I assume they'd each help make my program more efficient on their own. > Or, maybe my implementation is not as terrible as I thought because some > laziness/fusion/optimization magic is happening behind the scenes? > > Thanks, > Jake Waksbaum > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Thu Aug 11 18:58:27 2016 From: david.feuer at gmail.com (David Feuer) Date: Thu, 11 Aug 2016 14:58:27 -0400 Subject: [Haskell-cafe] library for set of heterogeneous values? In-Reply-To: <1470890276.638665871@f25.my.com> References: <1470890276.638665871@f25.my.com> Message-ID: I don't know if they're at all suitable for your purposes, but you should look (at least for inspiration) at both vinyl and dependent-map. On Thu, Aug 11, 2016 at 12:37 AM, Anthony Clayden wrote: > I have a (let's call it) database of heterogeneous records. > > They're not Haskell records, but anonymous/extensible type-labelled rows. > (Could be tuples, could be HLists, could be Lens-like, could be something > fancier.) > > There's a small number (dozens) of distinct row types, each with a large > number (thousands) of rows. The variety of row-types is not predictable in > advance. And indeed a row might 'morph' over time with fields added/removed. > > So the obvious answer of putting the lot into a giant HList (each element of > the list being a row) isn't going to scale. I could have a type-indexed > HList in which each element is a Set of homogeneous rows. But performance > still suffers from scanning along the list to find the right type index. > > Is there something better? On hackage there's two packages called HSet, > neither giving very much help about their suitability: > > * `hset` (lower case) [AlekseyUymanov] seems isomorphic to a type-indexed > HList. > ie Must be unique type in each element (could be a Set type, I guess) > > * `HSet` (upper case) [athanclark] "Faux heterogeneous sets" seems a lot > meatier > why the "Faux"? > built over hashtables in the ST monad. > > Has anybody used these? Can give guidance on what they can and can't? > > Bonus questions: > > Given a filter specifying a restriction on (some) fields of rows, I want to > get a heterog subset: > * all rows with at least those fields, matching those restrictions. > * the restriction might be merely "has field labelled L". > > GIven a candidate row for insertion, I want first to scan for > quasi-duplicates: > * any existing row with a subset of the given fields, and the same value at > those fields. > * any existing row with a superset of the given fields, and the same value > at those fields in common. > * ignore records with only a partial overlap of fields. > > One possible data structure: a "vertical store". > Give each row a Globally Unique Id. > Have a separate set for each possible field, > where the set elements are field value (key) to set of GUId -- records with > that value. > > Then I have a different bonus question: > * how to retrieve all field values for a given GUId? > > > Thanks > AntC > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From anthony_clayden at clear.net.nz Fri Aug 12 00:17:50 2016 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Fri, 12 Aug 2016 12:17:50 +1200 Subject: [Haskell-cafe] library for set of heterogeneous values? Message-ID: <57ad15ae.20e.7427.993@clear.net.nz> > I don't know if they're at all suitable for your purposes, > but you should look (at least for inspiration) at both > vinyl and dependent-map. Thanks David, vinyl is a record 'solution', not a set-of-records repository Really there's now too many bewildering choices for records; representing the records is not the difficult part. dependent-map, and vault [Heinrich Apfelmus,thank you Sergei for the suggestion] seem to be (key, value) stores so I'm not seeing how I 'query'/filter the values (the whole records) if I don't already know the keys for those records. Contrast that with Data.Set [*], you could stream the contents to a list and filter. (Which would be horribly inefficient for my purposes.) [*] Data.Set seems to have been swallowed into the new collections library, which is not currently maintained :-( AntC From ch.howard at zoho.com Fri Aug 12 05:12:29 2016 From: ch.howard at zoho.com (Christopher Howard) Date: Thu, 11 Aug 2016 21:12:29 -0800 Subject: [Haskell-cafe] When you don't want to restrict the type of array... Message-ID: <57AD5ABD.3060204@zoho.com> Hi. I recently learned how to use Haskell IArrays and MArrays, and they are quite convenient. I find myself often using some type of MArray for performance reasons, but also some IArray type for array data that is static in a set of computations. Then I started wanting to use arrays inside other kinds of data types, and so quickly ran into the question: what do you do if you want a data type to contain an array, but you don't know in advance what array type you'll be working with (immutable vs. mutible, boxed vs. unboxed). My exploration of this question led to discovering something called GADTs, which allowed me to do definitions like so data Surface a where ISurface :: IArray a e => (a Int Vertex) -> (a Int Face) -> Surface a MSurface :: MArray a e m => (a Int Vertex) -> (a Int Face) -> Surface a Am I heading down the right track here, or is there some better approach? -- https://qlfiles.net My PGP public key ID is 0x340EA95A (pgp.mit.edu). From chpatrick at gmail.com Fri Aug 12 08:35:24 2016 From: chpatrick at gmail.com (Patrick Chilton) Date: Fri, 12 Aug 2016 10:35:24 +0200 Subject: [Haskell-cafe] When you don't want to restrict the type of array... In-Reply-To: <57AD5ABD.3060204@zoho.com> References: <57AD5ABD.3060204@zoho.com> Message-ID: First of all, the current standard for arrays is the vector package, array is pretty obsolete. Secondly, are you sure you want your functions to take both immutable and mutable arrays? You could just make them take immutable ones, and convert using (unsafe)freeze/thaw beforehand. Also, since you know that you'll only be storing Face and Vertex, you might as well make an Unbox (or Storable) instance for them and use Unboxed (or Storable) vectors. Then you end up with: import qualified Data.Vector.Unboxed as VU data Surface = Surface { vertices :: VU.Vector Vertex, faces :: VU.Vector Face } render :: Surface -> IO () etc. On Fri, Aug 12, 2016 at 7:12 AM, Christopher Howard wrote: > Hi. I recently learned how to use Haskell IArrays and MArrays, and they > are quite convenient. I find myself often using some type of MArray for > performance reasons, but also some IArray type for array data that is > static in a set of computations. > > Then I started wanting to use arrays inside other kinds of data types, > and so quickly ran into the question: what do you do if you want a data > type to contain an array, but you don't know in advance what array type > you'll be working with (immutable vs. mutible, boxed vs. unboxed). > > My exploration of this question led to discovering something called > GADTs, which allowed me to do definitions like so > > data Surface a where > ISurface :: IArray a e => (a Int Vertex) -> (a Int Face) -> Surface a > MSurface :: MArray a e m => (a Int Vertex) -> (a Int Face) -> Surface a > > Am I heading down the right track here, or is there some better approach? > > -- > https://qlfiles.net > My PGP public key ID is 0x340EA95A (pgp.mit.edu). > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Fri Aug 12 13:35:33 2016 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 12 Aug 2016 09:35:33 -0400 Subject: [Haskell-cafe] =?utf-8?q?Hac_=CF=86=3A_a_Haskell_Exchange_in_Phil?= =?utf-8?b?YWRlbHBoaWEsIE9jdCAyMeKAkzIz?= Message-ID: <183295BF-B2E3-414B-A097-F2CF3ADA258F@cs.brynmawr.edu> Hac Phi, a yearly weekend of Haskell in Philadelphia, will take place Oct. 21–23, 2016, at the University of Pennsylvania. Hac Phi is a gathering of hackers and Haskell enthusiasts. Come bring a project you’re working on or offer to help someone else on a project of theirs. Come give a talk if you’ve got something to share. Come to learn something new. What do we mean by a “Haskell Exchange”? Less pressurized than a hackathon, more informal than a conference, bigger than a meetup – Hac Phi is a weekend where academics, professionals, and hobbyists can all meet, mingle, hack on each others’ projects, and generally have a good time. (And it’s not to be confused with *the* Haskell eXchange, an entirely different event.) All the details are on [the wiki page](https://wiki.haskell.org/Hac_Phi); please [register online](https://goo.gl/forms/XXTxKFYAryVTjlgo2 ) if you’re coming. We hope to see you there! —The Hac φ team Antal Spector-Zabusky Kenny Foner -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.brown5374 at gmail.com Fri Aug 12 14:43:18 2016 From: james.brown5374 at gmail.com (James Brown) Date: Fri, 12 Aug 2016 10:43:18 -0400 Subject: [Haskell-cafe] Need an example of new type constructor with zero data constructors Message-ID: In the Haskell report 2010, a data declaration has the format of: For a new type, there could be zero or more data constructors. What's the use case for a new type that has zero data constructor? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhenahan at me.com Fri Aug 12 14:52:41 2016 From: jhenahan at me.com (Jack Henahan) Date: Fri, 12 Aug 2016 10:52:41 -0400 Subject: [Haskell-cafe] Need an example of new type constructor with zero data constructors In-Reply-To: References: Message-ID: I haven't used Void enough to really be able to answer this, so here are some links to information about the empty type. https://wiki.haskell.org/Empty_type https://hackage.haskell.org/package/void http://stackoverflow.com/questions/14131856/whats-the-absurd-function-in-data-void-useful-for Hope that helps. James Brown writes: > In the Haskell report 2010, a data declaration has the format of: > > > > For a new type, there could be zero or more data constructors. What's the > use case for a new type that has zero data constructor? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From adam at bergmark.nl Fri Aug 12 14:54:24 2016 From: adam at bergmark.nl (Adam Bergmark) Date: Fri, 12 Aug 2016 16:54:24 +0200 Subject: [Haskell-cafe] Need an example of new type constructor with zero data constructors In-Reply-To: References: Message-ID: What you posted is the format for data declarations, not newtypes. Newtypes are required to have exactly one constructor: newtype [context =>] simpletype = newconstr [deriving] Adam On Fri, Aug 12, 2016 at 4:43 PM, James Brown wrote: > In the Haskell report 2010, a data declaration has the format of: > > > > > For a new type, there could be zero or more data constructors. What's the > use case for a new type that has zero data constructor? > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhenahan at me.com Fri Aug 12 14:59:46 2016 From: jhenahan at me.com (Jack Henahan) Date: Fri, 12 Aug 2016 10:59:46 -0400 Subject: [Haskell-cafe] Need an example of new type constructor with zero data constructors In-Reply-To: References: Message-ID: I think they mean "new type" to mean a data declaration, rather than a newtype. I had to read it a few times before it clicked for me. Just a confusion in terminology. Adam Bergmark writes: > What you posted is the format for data declarations, not newtypes. Newtypes > are required to have exactly one constructor: > > newtype [context =>] simpletype = newconstr [deriving] > > > Adam > > On Fri, Aug 12, 2016 at 4:43 PM, James Brown > wrote: > >> In the Haskell report 2010, a data declaration has the format of: >> >> >> >> >> For a new type, there could be zero or more data constructors. What's the >> use case for a new type that has zero data constructor? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From yashin.sergey at gmail.com Fri Aug 12 15:08:29 2016 From: yashin.sergey at gmail.com (Sergey N. Yashin) Date: Fri, 12 Aug 2016 08:08:29 -0700 (PDT) Subject: [Haskell-cafe] Need an example of new type constructor with zero data constructors In-Reply-To: References: Message-ID: For zero data constructors you need to use only EmptyDataDecls extension. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.brown5374 at gmail.com Fri Aug 12 15:16:16 2016 From: james.brown5374 at gmail.com (James Brown) Date: Fri, 12 Aug 2016 11:16:16 -0400 Subject: [Haskell-cafe] Need an example of new type constructor with zero data constructors In-Reply-To: References: Message-ID: What's the purpose to allow data declarations with no constructors? On Fri, Aug 12, 2016 at 11:08 AM, Sergey N. Yashin wrote: > For zero data constructors you need to use only EmptyDataDecls > extension. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yashin.sergey at gmail.com Fri Aug 12 15:25:25 2016 From: yashin.sergey at gmail.com (Sergey N. Yashin) Date: Fri, 12 Aug 2016 08:25:25 -0700 (PDT) Subject: [Haskell-cafe] Need an example of new type constructor with zero data constructors In-Reply-To: References: Message-ID: <1dd786c7-c518-4968-b04d-60b909401fd0@googlegroups.com> For example empty data declarations, *Fst *and *Snd *in the code bellow: {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE EmptyDataDecls #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} module Main where data Fst data Snd data F a b = F b deriving Show data S a b = S b deriving Show class TupleVal a where val :: a b -> b instance a ~ Fst => TupleVal (F a) where val (F v) = v instance a ~ Fst => TupleVal (S a) where val (S v) = v class TupleOps (a :: * -> * -> *) b c where type FST a b c type SND a b c tfst :: a b c -> FST a b c tsnd :: a b c -> SND a b c instance (b ~ F b' b'', b' ~ Fst, c ~ S c' c'', c' ~ Snd) => TupleOps (,) b c where type FST (,) b c = b type SND (,) b c = c tfst = fst tsnd = snd instance TupleOps F b (c1, c2) where type FST F b (c1, c2) = c1 type SND F b (c1, c2) = c2 tfst (F (v1, v2)) = v1 tsnd (F (v1, v2)) = v2 instance TupleOps S b (c1, c2) where type FST S b (c1, c2) = c1 type SND S b (c1, c2) = c2 tfst (S (v1, v2)) = v1 tsnd (S (v1, v2)) = v2 type First a = F Fst a type Second a = S Snd a type a @@ b = (First a, Second b) type family a :=: b where Fst :=: b = Fst' b Snd :=: b = Snd' b infixr 1 :=: type family Fst' a where Fst' (a, b) = a Fst' (First a) = Fst' a Fst' (Second a) = Fst' a type family Snd' a where Snd' (a, b) = b Snd' (First a) = Snd' a Snd' (Second a) = Snd' a (@@) :: a -> b -> a @@ b a @@ b = (F a, S b) tpl1 :: Int @@ String tpl1 = 1 @@ "hello" tpl2 :: Snd :=: String @@ String tpl2 = tsnd ("hello" @@ "world") tpl3 :: Snd :=: String @@ String tpl3 = tsnd ("hello" @@ "world") tpl4 :: Int @@ String tpl4 = 1 @@ "hello" tpl5 :: Snd :=: String @@ (String @@ String) tpl5 = tsnd ("hello" @@ ("hello" @@ "world")) tpl6 :: Snd :=: Fst :=: Snd :=: (String @@ String) @@ ((String @@ String) @@ String) tpl6 = tsnd . tfst . tsnd $ ("world1" @@ "hello2") @@ (("hello3" @@ "world5") @@ "world4") main :: IO () main = do print tpl4 print tpl3 print tpl2 print tpl6 пятница, 12 августа 2016 г., 18:16:18 UTC+3 пользователь James Brown написал: > > What's the purpose to allow data declarations with no constructors? > > On Fri, Aug 12, 2016 at 11:08 AM, Sergey N. Yashin > wrote: > >> For zero data constructors you need to use only EmptyDataDecls >> extension. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michaelburge at pobox.com Fri Aug 12 15:28:27 2016 From: michaelburge at pobox.com (Michael Burge) Date: Fri, 12 Aug 2016 08:28:27 -0700 Subject: [Haskell-cafe] Need an example of new type constructor with zero data constructors In-Reply-To: References: Message-ID: One use is when you want an open sum type rather than a closed one. For example, you might want users of your library to add their own 'constructors'. Then, they serve a purpose similar to a constructor that takes no arguments: {-# LANGUAGE EmptyDataDecls #-} class Color a where rgb :: a -> (Int, Int, Int) data Red data Green data Blue instance Color Red where rgb _ = (255, 0, 0) instance Color Green where rgb _ = (0, 255, 0) instance Color Blue where rgb _ = (0, 0, 255) data ColorADT = Color_Red | Color_Green | Color_Blue rgb_adt Color_Red = (255, 0, 0) rgb_adt Color_Green = (0, 255, 0) rgb_adt Color_Blue = (0, 0, 255) On Fri, Aug 12, 2016 at 8:16 AM, James Brown wrote: > What's the purpose to allow data declarations with no constructors? > > On Fri, Aug 12, 2016 at 11:08 AM, Sergey N. Yashin < > yashin.sergey at gmail.com> wrote: > >> For zero data constructors you need to use only EmptyDataDecls >> extension. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Fri Aug 12 16:28:09 2016 From: amindfv at gmail.com (amindfv at gmail.com) Date: Fri, 12 Aug 2016 12:28:09 -0400 Subject: [Haskell-cafe] Need an example of new type constructor with zero data constructors In-Reply-To: References: Message-ID: Another use: class Foo a e | a -> e where foo :: a -> Either e a instance Foo Int Void where foo :: Int -> Either Void Int foo x = Right (x + 1) Even though it's an "Either", we're saying we will never (ignoring bottom) return a "Left" value. Tom > El 12 ago 2016, a las 11:28, Michael Burge escribió: > > One use is when you want an open sum type rather than a closed one. For example, you might want users of your library to add their own 'constructors'. Then, they serve a purpose similar to a constructor that takes no arguments: > > {-# LANGUAGE EmptyDataDecls #-} > > class Color a where > rgb :: a -> (Int, Int, Int) > > data Red > data Green > data Blue > > instance Color Red where > rgb _ = (255, 0, 0) > > instance Color Green where > rgb _ = (0, 255, 0) > > instance Color Blue where > rgb _ = (0, 0, 255) > > data ColorADT = Color_Red | Color_Green | Color_Blue > rgb_adt Color_Red = (255, 0, 0) > rgb_adt Color_Green = (0, 255, 0) > rgb_adt Color_Blue = (0, 0, 255) > > >> On Fri, Aug 12, 2016 at 8:16 AM, James Brown wrote: >> What's the purpose to allow data declarations with no constructors? >> >>> On Fri, Aug 12, 2016 at 11:08 AM, Sergey N. Yashin wrote: >>> For zero data constructors you need to use only EmptyDataDecls extension. >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at googlemail.com Fri Aug 12 19:58:52 2016 From: monkleyon at googlemail.com (MarLinn) Date: Fri, 12 Aug 2016 21:58:52 +0200 Subject: [Haskell-cafe] Which is the most "hackable" compiler? Message-ID: <2bc73278-430a-bcf7-527c-5b0b385cf82e@gmail.com> So I have some crazy ideas for language extensions/reinterpretations and ways I might try to implement them. But ghc is a complex beast and my crazy ideas have too many interrelationships for a noob like me to try to bold them onto it. After all, I have never worked on ghc - or any compiler for that matter. I did look at the code, but I reckon maybe I should gather some experience first before diving into that one. It would be even worse to offload my ideas onto someone else before I at least tried them and got some feedback. No fun for anyone. But of course I don't want to start from scratch. As fun as that could be, there's no need to reinvent all the wheels just for a different axle. And I hear rumors that there are other Haskell compilers out there, even if most of them live in the shadow/slipstream of their brother. Alas, I don't have any idea what their statuses and philosophies are. So maybe you can help me here: Have you experienced any of the alternative compilers as especially easy for a newcomer to pick up and play around with? If it helps, I would be satisfied with plain Haskell2010 or even Haskell 98, although some GADT and/or TypeFamilies code to butcher would be nice, too. The ideas are mostly about larger scale structures like whole functions. One representative example idea is "Could it help the implementation - and does it even make sense - to view a module as just a weirdly written zero parameter type class?" As I said: crazy ideas. I'm thankful for any thoughts and ideas. MarLinn From sergey.bushnyak at sigrlami.eu Sat Aug 13 06:51:12 2016 From: sergey.bushnyak at sigrlami.eu (Sergey Bushnyak) Date: Sat, 13 Aug 2016 09:51:12 +0300 Subject: [Haskell-cafe] Which is the most "hackable" compiler? In-Reply-To: <2bc73278-430a-bcf7-527c-5b0b385cf82e@gmail.com> References: <2bc73278-430a-bcf7-527c-5b0b385cf82e@gmail.com> Message-ID: <31dd183e-7d5c-d2b7-e013-d80852729a73@sigrlami.eu> You should go for a long run with GHC, it has most advanced extension system and you'll be able to integrate your extensions with existing codebase if they come out successful. If you still want to work with hackablel compiler look at jhc https://github.com/jimcrayne/jhc and it's fork ajhc https://github.com/ajhc/ajhc they are very low-level but codebase very small and you can grasp whole system very quickly to start hacking On 08/12/2016 10:58 PM, MarLinn via Haskell-Cafe wrote: > So I have some crazy ideas for language extensions/reinterpretations > and ways I might try to implement them. But ghc is a complex beast and > my crazy ideas have too many interrelationships for a noob like me to > try to bold them onto it. After all, I have never worked on ghc - or > any compiler for that matter. I did look at the code, but I reckon > maybe I should gather some experience first before diving into that > one. It would be even worse to offload my ideas onto someone else > before I at least tried them and got some feedback. No fun for anyone. > > But of course I don't want to start from scratch. As fun as that could > be, there's no need to reinvent all the wheels just for a different > axle. And I hear rumors that there are other Haskell compilers out > there, even if most of them live in the shadow/slipstream of their > brother. Alas, I don't have any idea what their statuses and > philosophies are. > > So maybe you can help me here: Have you experienced any of the > alternative compilers as especially easy for a newcomer to pick up and > play around with? If it helps, I would be satisfied with plain > Haskell2010 or even Haskell 98, although some GADT and/or TypeFamilies > code to butcher would be nice, too. The ideas are mostly about larger > scale structures like whole functions. One representative example idea > is "Could it help the implementation - and does it even make sense - > to view a module as just a weirdly written zero parameter type class?" > As I said: crazy ideas. > > I'm thankful for any thoughts and ideas. > > > MarLinn > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From dburke.gw at gmail.com Sat Aug 13 07:06:00 2016 From: dburke.gw at gmail.com (Doug Burke) Date: Sat, 13 Aug 2016 07:06:00 +0000 Subject: [Haskell-cafe] library for set of heterogeneous values? In-Reply-To: <57ad15ae.20e.7427.993@clear.net.nz> References: <57ad15ae.20e.7427.993@clear.net.nz> Message-ID: Frames - http://acowley.github.io/Frames/ - is built on top of vinyl and provides one way to access data either as an array of structures or a structures of arrays. I'm on my phone (hence the use of top posting) so I can't productively check whether it allows the kind of filtering you were asking for. Doug On Fri, Aug 12, 2016, 01:18 Anthony Clayden wrote: > > I don't know if they're at all suitable for your purposes, > > but you should look (at least for inspiration) at both > > vinyl and dependent-map. > > Thanks David, > > vinyl is a record 'solution', not a set-of-records > repository > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregmainland at gmail.com Sat Aug 13 19:17:13 2016 From: gregmainland at gmail.com (Greg Horn) Date: Sat, 13 Aug 2016 19:17:13 +0000 Subject: [Haskell-cafe] (job) haskell software engineer for autopilot/simulation environment Message-ID: We are a small, fast moving R&D group in Kitty Hawk writing autopilots in Haskell and code-generating to C. The ground station and simulation environment are written almost entirely in Haskell, and are mostly open-source. We are currently flight testing a few different novel vehicles. We're looking for an experienced software engineer familiar with simulation and control of dynamic systems, real-time systems, robotics, or similar. The role is initially to support and expand the existing simulation and control infrastructure, but will be flexible based on your interests and expertise. If this is interesting to you, please see the full description at: https://jobs.lever.co/kittyhawk.aero/89a6630b-4210-4a4a-89d8-936d458f6c8a?lever-source=HaskellCafe Best regards, Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From benl at ouroborus.net Sun Aug 14 00:20:00 2016 From: benl at ouroborus.net (Ben Lippmeier) Date: Sun, 14 Aug 2016 10:20:00 +1000 Subject: [Haskell-cafe] Which is the most "hackable" compiler? In-Reply-To: <2bc73278-430a-bcf7-527c-5b0b385cf82e@gmail.com> References: <2bc73278-430a-bcf7-527c-5b0b385cf82e@gmail.com> Message-ID: > On 13 Aug 2016, at 5:58 AM, MarLinn via Haskell-Cafe wrote: > > So maybe you can help me here: Have you experienced any of the alternative compilers as especially easy for a newcomer to pick up and play around with? If it helps, I would be satisfied with plain Haskell2010 or even Haskell 98, although some GADT and/or TypeFamilies code to butcher would be nice, too. The ideas are mostly about larger scale structures like whole functions. You might want to check out DDC [1]. It’s still in a pre-alpha state, but what it does have is a working external core language. You could write your own front end that produces System-F, then have DDC compile that. The individual compiler passes are also fairly well separated, so it’s easy to change. > One representative example idea is "Could it help the implementation - and does it even make sense - to view a module as just a weirdly written zero parameter type class?" As I said: crazy ideas. This is perfectly reasonable. I think Agda does something similar. Ben. [1] http://disciple.ouroborus.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sun Aug 14 02:53:39 2016 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sat, 13 Aug 2016 22:53:39 -0400 Subject: [Haskell-cafe] Which is the most "hackable" compiler? In-Reply-To: References: <2bc73278-430a-bcf7-527c-5b0b385cf82e@gmail.com> Message-ID: GHC compiler plugins may also be what you're looking for. Also, does ghc not compile core files anymore? It used to; you can always use an older ghc version. Tom > El 13 ago 2016, a las 20:20, Ben Lippmeier escribió: > > > > >> On 13 Aug 2016, at 5:58 AM, MarLinn via Haskell-Cafe wrote: >> >> So maybe you can help me here: Have you experienced any of the alternative compilers as especially easy for a newcomer to pick up and play around with? If it helps, I would be satisfied with plain Haskell2010 or even Haskell 98, although some GADT and/or TypeFamilies code to butcher would be nice, too. The ideas are mostly about larger scale structures like whole functions. > > You might want to check out DDC [1]. It’s still in a pre-alpha state, but what it does have is a working external core language. You could write your own front end that produces System-F, then have DDC compile that. The individual compiler passes are also fairly well separated, so it’s easy to change. > > >> One representative example idea is "Could it help the implementation - and does it even make sense - to view a module as just a weirdly written zero parameter type class?" As I said: crazy ideas. > > This is perfectly reasonable. I think Agda does something similar. > > Ben. > > > [1] http://disciple.ouroborus.net/ > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From benl at ouroborus.net Sun Aug 14 03:06:42 2016 From: benl at ouroborus.net (Ben Lippmeier) Date: Sun, 14 Aug 2016 13:06:42 +1000 Subject: [Haskell-cafe] Which is the most "hackable" compiler? In-Reply-To: References: <2bc73278-430a-bcf7-527c-5b0b385cf82e@gmail.com> Message-ID: > On 14 Aug 2016, at 12:53 PM, amindfv at gmail.com wrote: > > GHC compiler plugins may also be what you're looking for. > > Also, does ghc not compile core files anymore? It used to; you can always use an older ghc version. IIRC GHC once could produce external core files, but it was never able to parse them back. The support rotted, so it was removed a few years ago. The way GHC is engineered makes it difficult/impossible for core-to-core plugins to introduce names into the core file that were not already present. Plugins can *rearrange* code that contains existing identifiers, but once the front-end type checker/desugarer is finished there isn’t an easy way to load more interface files to get at other names of things. This was the state of GHC in 2013 when I was working on the Repa plugin [1], it might have changed since then. Ben. [1] https://hackage.haskell.org/package/repa-plugin -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Sun Aug 14 03:10:15 2016 From: will.yager at gmail.com (William Yager) Date: Sat, 13 Aug 2016 20:10:15 -0700 Subject: [Haskell-cafe] The relationship between F-algebras and the Free Monad Message-ID: Hello all, I recently read the article "Understanding F-algebras"[1], which goes over the usage of F-algebras for e.g. evaluating ASTs. This article goes over how 1. Data.Fix creates the initial F-algebra over a functor f. 2. We can express our AST as a non-recursive functor instead of a recursive type 3. We can express our evaluator as an Algebra (of the type `f a -> a`, where f is the type of our AST and `a` is the Algebra's carrier type, i.e. our result type) 4. We can express terms in our language as members of the type `Fix AST` (i.e. the initial F-algebra over our AST). 5. By using a catamorphism over our evaluator algebra, we can easily construct an efficient evaluator. As a brief example of these principles, see the following program (using DeriveFunctor): data AST a = Lit Int | Add a a deriving Functor -- data Fix f = Fix (f (Fix f)) -- defined in Data.Fix type AST' = Fix AST program :: AST' program = Fix $ Add (Fix $ Lit 5) (Fix $ Lit 4) alg :: AST Int -> Int alg (Lit i) = i alg (Add l r) = l + r eval :: AST' -> Int eval = Data.Fix.cata alg main = print $ eval program This is super cool! One thing that stood out to me is that there are a number of similarities here with the usage of the Free Monad. In particular, see "Why free monads matter" [2]. This article is doing basically the exact same thing. You express your AST as a non-recursive functor parametrized over the type of subterms. However, instead of making your terms of type `Fix AST`, they are of type `Free AST a`. Now, the recursive constructor for Free is almost identical to the constructor for Fix, except of course the additional type parameter `a`. However, both types are of the form `data T = R (f T)`. Free simply has the additional `Pure` constructor as well. So obviously, there is some sort of relationship here. However, I don't have a good enough grasp on these concepts for the relationship to make itself fully apparent. Some things I've noticed: Operations on `Fix AST` terminate because the AST type has leaf constructors without recursion. So a catamorphism over an evaluation algebra can plausibly terminate because eventually it will hit a leaf node and the evaluation will stop. On the other hand, operations on `Free AST a` can also terminate because you might run into a `Pure` constructor. The difference being that `Pure` is a part of the wrapper type (Free) and not the wrapped type (AST). A practical question I have is: Can we use the Free Monad to write AST terms using `do` notation (useful for DSLs) and then use the elegant catamorphism evaluator trick (or something similar) to evaluate our ASTs? Or does evaluating the Free Monad require something more general due to the Pure constructor? It looks like `Control.Monad.Free.iter` might be equivalent to `Data.Fix.cata`, but I'm not sure. It looks like a rough translation works in this case: data AST a = Add a a deriving Functor -- No more "Const" type AST' a = Free AST a program :: AST' Int program = Free $ Add (Pure 5) (Pure 4) alg :: AST Int -> Int alg (Add l r) = l + r eval :: AST' Int -> Int eval = Control.Monad.Free.iter alg main = print $ eval program So, intuitively, it seems like Free lets us do basically the same thing as Fix but with the evaluation result present as the last argument of the expression type. Sorry for being a bit rambly, and I may also be completely off base here, so correct me if I'm not making any sense. Cheers, Will [1] https://www.schoolofhaskell.com/user/bartosz/understanding-algebras [2] http://www.haskellforall.com/2012/06/you-could-have-invented-free-monads.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Sun Aug 14 10:52:57 2016 From: anthony_clayden at clear.net.nz (=?UTF-8?B?QW50aG9ueSBDbGF5ZGVu?=) Date: Sun, 14 Aug 2016 13:52:57 +0300 Subject: [Haskell-cafe] =?utf-8?q?Data=2ESet_optimisations_=5Bwas=3A__libr?= =?utf-8?q?ary_for_set_of_heterogeneous_values=3F=5D?= In-Reply-To: References: <1470890276.638665871@f25.my.com> Message-ID: <1471171977.697413830@f13.my.com> Firstly, to correct myself: > Contrast that with Data.Set [*], you could stream the contents to a list and filter. > (Which would be horribly inefficient for my purposes.)  Thank you Libraries team. Data.Set seems to have been seriously revamped since I last looked, and now includes a 'proper' filter function. (It used to stream the Set to a List; filter the List; build a new Set.) > [*] Data.Set seems to have been swallowed into the new collections library, > which is not currently maintained  Uhh. That was a dead link (of ~10 years ago, but Google still took me to it). Data.Set is in the **containers** library supported on hackage. But I have some q's about the optimisations: The hedge-union algorithm seems to have been taken out, as inefficient. (per treeowl on github). But the code on hackage still uses hedge?? So the docos are out of date. (And quite a bit of commentary on StackOverflow.)  Was it really not more efficient? The Set data type's constructors got reordered (Bin is now first, Tip is second). On grounds it "improves the benchmark by up to 10%". Are you sure it makes that much difference? Are you sure it makes any difference at all? The culprit seems to be pattern matching. It makes me feel there's something seriously wrong with GHC's code generator. (And the semantics of ADTs is that the first constructor is ordered first if you go `deriving (Ord)`. So there's usually a design reason driving the ordering of constructors -- eg Nothing ordered before Just; [] ordered before (:), which makes String ordering do the right thing.) Set is a purely functional data structure, no in-situ updating of nodes, no pointer semantics unlike imperative/low-level implementations of balanced binary trees. That means Tips (empty end-points) genuinely get allocated/built and accessed and garbaged on insert -- or does all that strictness annotation/INLINing alter that? Contrast that in an imperative/low-level model they'd be null pointers, nothing allocated. Note the number of Tips is equal the number of values in the tree, + 1. Would it save construction/destruction/access overhead to have three extra constructors? | both sub-trees are empty  | left (only) is empty | right (only) is empty If it's true per above that each constructor adds a performance penalty just doing the pattern matching, I guess the answer is 'no' :-( Thanks AntC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Aug 14 12:05:36 2016 From: david.feuer at gmail.com (David Feuer) Date: Sun, 14 Aug 2016 08:05:36 -0400 Subject: [Haskell-cafe] Data.Set optimisations [was: library for set of heterogeneous values?] In-Reply-To: <1471171977.697413830@f13.my.com> References: <1470890276.638665871@f25.my.com> <1471171977.697413830@f13.my.com> Message-ID: I don't really think we need to bring *two* mailing lists into this. I'm treeowl. The hedge algorithms were usually slower on benchmarks and never much faster. Their theoretical performance has never been understood well. Divide and conquer is fast, and its theoretical performance bound is now understood to be good. The new code is not on Hackage because I haven't made a release yet. containers doesn't usually release a major version more than once a year. This year it may get two, but there's no need to rush. The Tip constructor is not allocated over and over. Nullary constructors of any given type are shared. So there's just one Tip somewhere. GHC's pointer tagging means that the pointers to Tip are almost never followed. Pattern matching on a Tip value ends up just inspecting the two (32-bit) or three (64-bit) tag bits on the pointer to it. Yes, constructor order makes a difference, weird as that seems. When GHC desugars a pattern match, it always reorders the case branches into constructor order. Sometimes this is obviously good; certain large case expressions are turned into jump tables. Sometimes this is not so good. One of my predecessors (probably Milan Straka, but I'm not sure) ran a lot of benchmarks and picked the constructor order that was usually best. Milan Straka wrote a paper that, among other things, recommended adding an additional singleton constructor. I don't actually know why he didn't do that; I can try to ask him. It's possible that it made some things better and others worse. On Aug 14, 2016 6:52 AM, "Anthony Clayden" wrote: > Firstly, to correct myself: > > > Contrast that with Data.Set [*], you could stream the contents to a list > and filter. > > (Which would be horribly inefficient for my purposes.) > > Thank you Libraries team. Data.Set seems to have been seriously revamped > since I last looked, and now includes a 'proper' filter function. (It used > to stream the Set to a List; filter the List; build a new Set.) > > > [*] Data.Set seems to have been swallowed into the new collections > library, > > which is not currently maintained > > Uhh. That was a dead link (of ~10 years ago, but Google still took me to > it). Data.Set is in the **containers** library supported on hackage. > > But I have some q's about the optimisations: > The hedge-union algorithm seems to have been taken out, as inefficient. > (per treeowl on github). But the code on hackage still uses hedge?? > So the docos are out of date. (And quite a bit of commentary on > StackOverflow.) > Was it really not more efficient? > > The Set data type's constructors got reordered (Bin is now first, Tip is > second). > On grounds it "improves the benchmark by up to 10%". > Are you sure it makes that much difference? > Are you sure it makes any difference at all? > The culprit seems to be pattern matching. It makes me feel there's > something seriously wrong with GHC's code generator. > (And the semantics of ADTs is that the first constructor is ordered first > if you go `deriving (Ord)`. So there's usually a design reason driving the > ordering of constructors -- eg Nothing ordered before Just; [] ordered > before (:), which makes String ordering do the right thing.) > > Set is a purely functional data structure, no in-situ updating of nodes, > no pointer semantics > unlike imperative/low-level implementations of balanced binary trees. > That means Tips (empty end-points) genuinely get allocated/built and > accessed and garbaged on insert -- or does all that strictness > annotation/INLINing alter that? > > Contrast that in an imperative/low-level model they'd be null pointers, > nothing allocated. > Note the number of Tips is equal the number of values in the tree, + 1. > Would it save construction/destruction/access overhead to have three > extra constructors? > | both sub-trees are empty > | left (only) is empty > | right (only) is empty > > If it's true per above that each constructor adds a performance penalty > just doing the pattern matching, I guess the answer is 'no' :-( > > Thanks > AntC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.brown5374 at gmail.com Sun Aug 14 13:32:18 2016 From: james.brown5374 at gmail.com (James Brown) Date: Sun, 14 Aug 2016 09:32:18 -0400 Subject: [Haskell-cafe] Function and pattern bindings Message-ID: I am reading Haskell report 2010 and I can't understand the differences between function bindings and pattern bindings. Can anyone explain the differences? ​​​​​​​ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-08-14 at 9.27.21 AM.png Type: image/png Size: 174615 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-08-14 at 9.27.39 AM.png Type: image/png Size: 243854 bytes Desc: not available URL: From adam at bergmark.nl Sun Aug 14 13:39:32 2016 From: adam at bergmark.nl (Adam Bergmark) Date: Sun, 14 Aug 2016 15:39:32 +0200 Subject: [Haskell-cafe] Function and pattern bindings In-Reply-To: References: Message-ID: Hi James, I think the difference they want to convey is that a function binding names an identifier and can contain several patterns, e.g. `foo [x] y = x + y` whereas a pattern binding is just one pattern, e.g. `[x]` or `y` in the earlier example. Function bindings can be desugared to case expressions with patterns. Adam On Sun, Aug 14, 2016 at 3:32 PM, James Brown wrote: > I am reading Haskell report 2010 and I can't understand the differences > between function bindings and pattern bindings. Can anyone explain the > differences? > > ​​​​​​​ > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at schmong.org Sun Aug 14 19:30:36 2016 From: michael at schmong.org (Michael Litchard) Date: Sun, 14 Aug 2016 12:30:36 -0700 Subject: [Haskell-cafe] Twitter coding kata Message-ID: I've been told that there is a twitter feed that gives out little haskell exercises. Can't find it. Anyone know about it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From damian.only at gmail.com Sun Aug 14 19:42:07 2016 From: damian.only at gmail.com (Damian) Date: Sun, 14 Aug 2016 21:42:07 +0200 Subject: [Haskell-cafe] Twitter coding kata In-Reply-To: References: Message-ID: I don't know about the feed, but a while ago I was playing with some exercises at exercism.io. Maybe you'd find it interesting. Regards, Damian Op 14 aug. 2016 21:30 schreef "Michael Litchard" : I've been told that there is a twitter feed that gives out little haskell exercises. Can't find it. Anyone know about it? _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sun Aug 14 19:48:26 2016 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sun, 14 Aug 2016 15:48:26 -0400 Subject: [Haskell-cafe] Proposal: Rational read Message-ID: <09BFF725-AE27-4F99-BB44-750BEB03B73F@gmail.com> Is there a reason to not allow '.' as a separator for Rational's Read instance, so that both "1%2" and "0.5" can be read? Tom From brodyberg at gmail.com Sun Aug 14 19:48:24 2016 From: brodyberg at gmail.com (Brody Berg) Date: Sun, 14 Aug 2016 12:48:24 -0700 Subject: [Haskell-cafe] Twitter coding kata In-Reply-To: References: Message-ID: @1HaskellADay On Sunday, August 14, 2016, Damian wrote: > I don't know about the feed, but a while ago I was playing with some > exercises at exercism.io. Maybe you'd find it interesting. > > Regards, > Damian > > Op 14 aug. 2016 21:30 schreef "Michael Litchard" >: > > I've been told that there is a twitter feed that gives out little haskell > exercises. Can't find it. Anyone know about it? > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at schmong.org Sun Aug 14 19:50:46 2016 From: michael at schmong.org (Michael Litchard) Date: Sun, 14 Aug 2016 12:50:46 -0700 Subject: [Haskell-cafe] Twitter coding kata In-Reply-To: References: Message-ID: That's it. Thanks. On Sun, Aug 14, 2016 at 12:48 PM, Brody Berg wrote: > @1HaskellADay > > > On Sunday, August 14, 2016, Damian wrote: > >> I don't know about the feed, but a while ago I was playing with some >> exercises at exercism.io. Maybe you'd find it interesting. >> >> Regards, >> Damian >> >> Op 14 aug. 2016 21:30 schreef "Michael Litchard" : >> >> I've been told that there is a twitter feed that gives out little haskell >> exercises. Can't find it. Anyone know about it? >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Sun Aug 14 20:00:34 2016 From: sean.leather at gmail.com (Sean Leather) Date: Sun, 14 Aug 2016 22:00:34 +0200 Subject: [Haskell-cafe] Proposal: Rational read In-Reply-To: <09BFF725-AE27-4F99-BB44-750BEB03B73F@gmail.com> References: <09BFF725-AE27-4F99-BB44-750BEB03B73F@gmail.com> Message-ID: Hi Tom, On Sun, Aug 14, 2016 at 9:48 PM, Tom wrote: > Is there a reason to not allow '.' as a separator for Rational's Read > instance, so that both "1%2" and "0.5" can be read? > While it would make read :: String -> Rational more convenient, I'm not sure it would be a good idea to have read accept input that will never be produced by show :: Rational -> String. As an alternative, you can use readFloat [1] in Numeric. Regards, Sean [1] https://hackage.haskell.org/package/base-4.9.0.0/docs/Numeric.html#v:readFloat -------------- next part -------------- An HTML attachment was scrubbed... URL: From hesselink at gmail.com Sun Aug 14 21:01:31 2016 From: hesselink at gmail.com (Erik Hesselink) Date: Sun, 14 Aug 2016 17:01:31 -0400 Subject: [Haskell-cafe] Proposal: Rational read In-Reply-To: References: <09BFF725-AE27-4F99-BB44-750BEB03B73F@gmail.com> Message-ID: On 14 August 2016 at 16:00, Sean Leather wrote: > On Sun, Aug 14, 2016 at 9:48 PM, Tom wrote: >> >> Is there a reason to not allow '.' as a separator for Rational's Read >> instance, so that both "1%2" and "0.5" can be read? > > While it would make read :: String -> Rational more convenient, I'm not sure > it would be a good idea to have read accept input that will never be > produced by show :: Rational -> String. This already happens everywhere, right? For example, if you have a Foo { bar :: Int, baz :: String } with the derived read instance, this works: read "Foo{bar=0x01, baz = \"h\101llo\"}" :: Foo Erik From sean.leather at gmail.com Sun Aug 14 21:28:14 2016 From: sean.leather at gmail.com (Sean Leather) Date: Sun, 14 Aug 2016 23:28:14 +0200 Subject: [Haskell-cafe] Proposal: Rational read In-Reply-To: References: <09BFF725-AE27-4F99-BB44-750BEB03B73F@gmail.com> Message-ID: Hi Erik, On Sun, Aug 14, 2016 at 11:01 PM, Erik Hesselink wrote: > On 14 August 2016 at 16:00, Sean Leather wrote: > > On Sun, Aug 14, 2016 at 9:48 PM, Tom wrote: > >> > >> Is there a reason to not allow '.' as a separator for Rational's Read > >> instance, so that both "1%2" and "0.5" can be read? > > > > While it would make read :: String -> Rational more convenient, I'm not > sure > > it would be a good idea to have read accept input that will never be > > produced by show :: Rational -> String. > > This already happens everywhere, right? For example, if you have a Foo > { bar :: Int, baz :: String } with the derived read instance, this > works: > > read "Foo{bar=0x01, baz = \"h\101llo\"}" :: Foo > True. I'm not sure how far down the decimal/scientific notation parsing hole you'd want to take the Ratio Read instance. Anyway, my point was that there is an existing alternative that doesn't require changing the instance and is not that inconvenient. Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanuki at gmail.com Sun Aug 14 22:18:55 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Sun, 14 Aug 2016 15:18:55 -0700 Subject: [Haskell-cafe] Twitter coding kata In-Reply-To: References: Message-ID: +1 for exercism.io, but cool to know about this too! On Aug 14, 2016 12:50 PM, "Michael Litchard" wrote: > That's it. Thanks. > > On Sun, Aug 14, 2016 at 12:48 PM, Brody Berg wrote: > >> @1HaskellADay >> >> >> On Sunday, August 14, 2016, Damian wrote: >> >>> I don't know about the feed, but a while ago I was playing with some >>> exercises at exercism.io. Maybe you'd find it interesting. >>> >>> Regards, >>> Damian >>> >>> Op 14 aug. 2016 21:30 schreef "Michael Litchard" : >>> >>> I've been told that there is a twitter feed that gives out little >>> haskell exercises. Can't find it. Anyone know about it? >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >>> >>> > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sun Aug 14 22:54:24 2016 From: david.feuer at gmail.com (David Feuer) Date: Sun, 14 Aug 2016 18:54:24 -0400 Subject: [Haskell-cafe] Proposal: Rational read In-Reply-To: References: <09BFF725-AE27-4F99-BB44-750BEB03B73F@gmail.com> Message-ID: Since decimal notation is defined in terms of fromRational, it seems a bit strange that the notation doesn't work for read::String->Rational. I'd be in favor of allowing it. I wouldn't expect too severe a performance penalty. On Aug 14, 2016 5:28 PM, "Sean Leather" wrote: > Hi Erik, > > On Sun, Aug 14, 2016 at 11:01 PM, Erik Hesselink wrote: > >> On 14 August 2016 at 16:00, Sean Leather wrote: >> > On Sun, Aug 14, 2016 at 9:48 PM, Tom wrote: >> >> >> >> Is there a reason to not allow '.' as a separator for Rational's Read >> >> instance, so that both "1%2" and "0.5" can be read? >> > >> > While it would make read :: String -> Rational more convenient, I'm not >> sure >> > it would be a good idea to have read accept input that will never be >> > produced by show :: Rational -> String. >> >> This already happens everywhere, right? For example, if you have a Foo >> { bar :: Int, baz :: String } with the derived read instance, this >> works: >> >> read "Foo{bar=0x01, baz = \"h\101llo\"}" :: Foo >> > > True. I'm not sure how far down the decimal/scientific notation parsing > hole you'd want to take the Ratio Read instance. Anyway, my point was that > there is an existing alternative that doesn't require changing the instance > and is not that inconvenient. > > Regards, > Sean > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From capn.freako at gmail.com Mon Aug 15 03:04:10 2016 From: capn.freako at gmail.com (David Banas) Date: Sun, 14 Aug 2016 20:04:10 -0700 Subject: [Haskell-cafe] Unable to correctly infer function type, via pattern matching? Message-ID: <52240EDC-6759-4689-A337-DFDC9D2EF55C@gmail.com> Hi all, I wonder if anyone can help me find my error, in this code: It’s note clear to me why x :: a is an error, except that maybe the type of f is not being correctly inferred? Am I, maybe, not allowed to use pattern matching, on the right side of ‘=‘? Thanks, -db data Stream a = Cons a (Stream a) newtype StreamMap a b = SM (Stream a -> Stream b) instance Arrow StreamMap where pure f = SM g where g (Cons x xs) = Cons (f x) (g xs) SM f >>> SM g = SM (g . f) first (SM g) = SM h -- h :: Stream (a, c) -> Stream (b, c) where h :: Stream (a, c) -> Stream (b, c) h (Cons (x, y) zs) = Cons ((f x), y) (h zs) g :: Stream a -> Stream b g (Cons x xs) = Cons (f x) (g xs) Couldn't match expected type ‘b1’ with actual type ‘a’ ‘a’ is a rigid type variable bound by the type signature for g :: interactive:IHaskell152.Stream a -> interactive:IHaskell152.Stream b1 at :10:17 ‘b1’ is a rigid type variable bound by the type signature for g :: interactive:IHaskell152.Stream a -> interactive:IHaskell152.Stream b1 at :10:17 Relevant bindings include xs :: interactive:IHaskell152.Stream a (bound at :11:27) x :: a (bound at :11:20) g :: interactive:IHaskell152.Stream a -> interactive:IHaskell152.Stream b1 (bound at :11:12) In the first argument of ‘f’, namely ‘x’ In the first argument of ‘IHaskell152.Cons’, namely ‘(f x)’ -------------- next part -------------- An HTML attachment was scrubbed... URL: From amos.robinson at gmail.com Mon Aug 15 03:29:50 2016 From: amos.robinson at gmail.com (Amos Robinson) Date: Mon, 15 Aug 2016 03:29:50 +0000 Subject: [Haskell-cafe] Unable to correctly infer function type, via pattern matching? In-Reply-To: <52240EDC-6759-4689-A337-DFDC9D2EF55C@gmail.com> References: <52240EDC-6759-4689-A337-DFDC9D2EF55C@gmail.com> Message-ID: Hi, I think the problem is that when you give functions in where clauses type signatures, type parameters like "a" are bound by forall. So the "a" in h is a different one to in "g". You might have more luck if you enable -XScopedTypeVariables , and give a top-level type signature explicitly binding a and b: "forall a b. Stream a -> …" On Mon, 15 Aug 2016 at 13:04 David Banas wrote: > Hi all, > > I wonder if anyone can help me find my error, in this code: > > It’s note clear to me why x :: a is an error, except that maybe the type > of f is not being correctly inferred? > Am I, maybe, not allowed to use pattern matching, on the right side of ‘=‘? > > Thanks, > -db > > > data Stream a = Cons a (Stream a) > > newtype StreamMap a b = SM (Stream a -> Stream b) > > instance Arrow StreamMap where > pure f = SM g > where g (Cons x xs) = Cons (f x) (g xs) > SM f >>> SM g = SM (g . f) > first (SM g) = SM h -- h :: Stream (a, c) -> Stream (b, c) > where h :: Stream (a, c) -> Stream (b, c) > h (Cons (x, y) zs) = Cons ((f x), y) (h zs) > g :: Stream a -> Stream b > g (Cons x xs) = Cons (f x) (g xs) > > > Couldn't match expected type ‘b1’ with actual type ‘a’ > ‘a’ is a rigid type variable bound by the type signature for g :: > interactive:IHaskell152.Stream a -> interactive:IHaskell152.Stream b1 at > :10:17 > ‘b1’ is a rigid type variable bound by the type signature for g :: > interactive:IHaskell152.Stream a -> interactive:IHaskell152.Stream b1 at > :10:17 > Relevant bindings include > xs :: interactive:IHaskell152.Stream a (bound at :11:27) > x :: a (bound at :11:20) > g :: interactive:IHaskell152.Stream a -> interactive:IHaskell152.Stream b1 > (bound at :11:12) > In the first argument of ‘f’, namely ‘x’ > In the first argument of ‘IHaskell152.Cons’, namely ‘(f x)’ > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Mon Aug 15 08:15:20 2016 From: anthony_clayden at clear.net.nz (=?UTF-8?B?QW50aG9ueSBDbGF5ZGVu?=) Date: Mon, 15 Aug 2016 11:15:20 +0300 Subject: [Haskell-cafe] =?utf-8?q?Data=2ESet_optimisations_=5Bwas=3A__libr?= =?utf-8?q?ary_for_set_of_heterogeneous_values=3F=5D?= In-Reply-To: References: <1470890276.638665871@f25.my.com> <1471171977.697413830@f13.my.com> Message-ID: <1471248920.855526301@f13.my.com> Thanks David, > Yes, constructor order makes a difference, weird as that seems. When GHC desugars a pattern  match, it always reorders the case branches into constructor order. Sometimes this is obviously good; certain large case expressions are turned into jump tables. Sometimes this is not so good.  One of my predecessors (probably Milan Straka, but I'm not sure) ran a lot of benchmarks and picked the constructor order that was usually best. Yes it was Milan [1], [2] refers to [3], which has the explanation. (And yes it seems weird.) "indirect jumps are particularly expensive on a modern processor architecture, because they fox the branch prediction hardware, leading to a stall of 10 or more cycles depending on the length of the pipeline." [Introduction. The paper goes on to estimate a penalty around 7 to 9 % in general GHC code.] Milan benchmarked a penalty around 10% for Data.Set. The prediction hardware doesn't seem very clever: it "predicts" any test-and-jump will not jump but will barrel on through the straight-line code. GHC's test is for the constructor not being the first in the decl. So the optimal straight-line code comes from declaring first your most likely constructor. That seems to me worrying for case/constructor branching code in general. Do we pay that cost for every pattern-match on a list or a Maybe, for example? Their definitions in the Prelude put the constructors in the 'wrong' order. (Although presumably those two get optimised to smithereens.) > Milan Straka wrote a paper [that's 2] that, among other things, recommended adding an additional singleton constructor. I don't actually know why he didn't do that; I can try to ask him. It's possible that it made some things better and others worse. Performance seemed somewhat better for certain functions. (And none were worse.) OTOH you would pay a penalty of another indirect jump. So perhaps the extra code complexity just wasn't worth it. Perhaps the combination of pointer tagging and inlining the recursive call wrung the best performance out of it. (Inlining works, despite recursion, because every 'visible' function has a helper `go` that isn't inlined.) [1] The performance of Haskell CONTAINERS package, Haskell Symposium 2010, Milan Straka [2] Adams' Trees Revisited, 2011, Milan Straka [3] Faster Laziness Using Dynamic Pointer Tagging, ICFP 2007, Simon M, Alexey Y, Simon PJ AntC >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Mon Aug 15 10:01:57 2016 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Mon, 15 Aug 2016 22:01:57 +1200 Subject: [Haskell-cafe] library for set of heterogeneous values? Message-ID: <57b19315.39b.574a.2218@clear.net.nz> > Frames - http://acowley.github.io/Frames/ - is built on > top of vinyl and provides one way to access data either as > an array of structures or a structures of arrays. Thanks Doug, Nice ability to define column types on the fly, and interpret them from incoming CSV. Yes and treat as structure of arrays. AFAICT Frames keeps each set of records distinct; and wants each set to be same type/same columns and types. So there's no heterogeneous repository. > whether it allows the kind of filtering you were asking for. There's standard filtering features you'd get with Set or List. I'm not seeing any ability to match/join across different datasets. That is, you'd have to write your own code. AntC From nicola.gigante at gmail.com Mon Aug 15 10:35:17 2016 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Mon, 15 Aug 2016 12:35:17 +0200 Subject: [Haskell-cafe] C call blocking indefinitely/behaving differently when called from Haskell In-Reply-To: References: Message-ID: > Il giorno 10 ago 2016, alle ore 19:18, Oliver Charles ha scritto: > > Hi all, Hi, > > I'm trying to interface with a Basler USB3 camera from a Haskell application, but I'm experiencing some difficulty. The camera comes with a C++ library that makes it fairly straight forward. The following code can be used to acquire a camera source: > > > PylonAutoInitTerm pylon; > CInstantCamera camera( CTlFactory::GetInstance().CreateFirstDevice()); > camera.RegisterConfiguration( (CConfigurationEventHandler*) NULL, RegistrationMode_ReplaceAll, Cleanup_None); > cout << "Using device " << camera.GetDeviceInfo().GetModelName() << endl; > > > Using the inline-c and inline-c-cpp libraries, I am trying to perform this same call from a Haskell executable. I have the following: > > > {-# LANGUAGE QuasiQuotes, TemplateHaskell #-} > > import qualified Language.C.Inline as C > import qualified Language.C.Inline.Cpp as C > > C.context C.cppCtx > > C.include "pylon/PylonIncludes.h" > C.include "iostream" > > C.using "namespace Pylon"; > C.using "namespace std"; > > main :: IO () > main = > [C.block| void { > PylonAutoInitTerm pylon; > > CInstantCamera camera( CTlFactory::GetInstance().CreateFirstDevice()); > camera.RegisterConfiguration( (CConfigurationEventHandler*) NULL, RegistrationMode_ReplaceAll, Cleanup_None); > cout << "Using device " << camera.GetDeviceInfo().GetModelName() << endl; > }|] > > > However, when the resulting executable is ran, it hangs - failing to print "Using device". > > > inline-c generates a Test.cpp file, which contains > > > #include "pylon/PylonIncludes.h" > > #include "iostream" > > using namespace Pylon; > > using namespace std; > > extern "C" { > void inline_c_Main_0_e23f0c6a0bc10367be76252744bf4e6c74493314() { > > PylonAutoInitTerm pylon; > > CInstantCamera camera( CTlFactory::GetInstance().CreateFirstDevice()); > camera.RegisterConfiguration( (CConfigurationEventHandler*) NULL, RegistrationMode_ReplaceAll, Cleanup_None); > cout << "Using device " << camera.GetDeviceInfo().GetModelName() << endl; > > } > > } > > > If I modify this exact file, I can turn it into something that can be run, by simply adding: > > > int main() { > inline_c_Main_0_e23f0c6a0bc10367be76252744bf4e6c74493314(); > } > > > At this point, I can now compile that very C++ code with G++ and run it: > > > [nix-shell:~/work/circuithub/receiving-station]$ g++ Test.cpp -I/home/ollie/work/circuithub/receiving-station/pylon5/include -L/home/ollie/work/circuithub/receiving-station/pylon5/lib64 -Wl,-E -lpylonbase -lpylonu > tility -lGenApi_gcc_v3_0_Basler_pylon_v5_0 -lGCBase_gcc_v3_0_Basler_pylon_v5_0 -Wl,--enable-new-dtags -Wl,-rpath,/home/ollie/work/circuithub/receiving-station/pylon5/lib64 > > [nix-shell:~/work/circuithub/receiving-station]$ ./a.out > GetDeviceDiscoveryInfo: bFunctionClass = 14, bFunctionSubClass = 3, bFunctionProtocol = 0. Device is not an U3V device. > GetDeviceDiscoveryInfo: bFunctionClass = 14, bFunctionSubClass = 3, bFunctionProtocol = 0. Device is not an U3V device. > Using device acA3800-14um > > > So as we can see, the C++ code is not the problem. > > Does anyone know why I don't see the same behaviour from my Haskell application? I imagine there might be some thread trickery happening behind the scenes, but I don't know what to even begin looking for. > > Thanks, let me know if you need any more information. the first step I would suggest you is to separate each single function call to the library interlacing them with print statements to see where exactly the hang happens. Then, I’ve never used inline-c-cpp before: which kind of FFI call is C.block supposed to generate? I mean a ‘safe’ call or an ‘unsafe’ call? > > - Ollie Regards, Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Mon Aug 15 12:39:25 2016 From: michael at orlitzky.com (Michael Orlitzky) Date: Mon, 15 Aug 2016 08:39:25 -0400 Subject: [Haskell-cafe] Proposal: Rational read In-Reply-To: References: <09BFF725-AE27-4F99-BB44-750BEB03B73F@gmail.com> Message-ID: On 08/14/2016 06:54 PM, David Feuer wrote: > Since decimal notation is defined in terms of fromRational, it seems a > bit strange that the notation doesn't work for read::String->Rational. > I'd be in favor of allowing it. I wouldn't expect too severe a > performance penalty. > One potential gotcha: ghci> read (show (1/3)) == (1/3) True ghci> read (show (1/3 :: Float)) == (1/3) False When does it work? Is it platform-dependent? From benno.fuenfstueck at gmail.com Mon Aug 15 13:04:17 2016 From: benno.fuenfstueck at gmail.com (=?UTF-8?B?QmVubm8gRsO8bmZzdMO8Y2s=?=) Date: Mon, 15 Aug 2016 13:04:17 +0000 Subject: [Haskell-cafe] Proposal: Rational read In-Reply-To: References: <09BFF725-AE27-4F99-BB44-750BEB03B73F@gmail.com> Message-ID: Michael Orlitzky schrieb am Mo., 15. Aug. 2016 um 14:48 Uhr: > On 08/14/2016 06:54 PM, David Feuer wrote: > > Since decimal notation is defined in terms of fromRational, it seems a > > bit strange that the notation doesn't work for read::String->Rational. > > I'd be in favor of allowing it. I wouldn't expect too severe a > > performance penalty. > > > > One potential gotcha: > > ghci> read (show (1/3)) == (1/3) > True > ghci> read (show (1/3 :: Float)) == (1/3) > False > > When does it work? Is it platform-dependent? > Well, you are showing 1/3 as a Float and reading it as a Double, which of course won't work since the String represents a Float and not a Double. The following does work: λ: read (show (1/3 :: Float)) == ((1/3) :: Float) True -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Aug 15 13:26:23 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 15 Aug 2016 14:26:23 +0100 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling Message-ID: <20160815132623.GA13523@weber> Here's a program with an odd error message (GHC 8.0.1): data A a = A a deriving Eq data B = B main :: IO () main = print (A B == A B) test/main.hs:5:15: error: • No instance for (Eq B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B) I get an error about Eq B even though it's Eq A that is manifestly required at the call site. This error is odder when A and B are defined far away from the use of '=='. This is even odder: data A a = A a data B = B instance Ord a => Eq (A a) where main :: IO () main = print (A B == A B) test/main.hs:7:15: error: • No instance for (Ord B) arising from a use of ‘==’ • In the first argument of ‘print’, namely ‘(A B == A B)’ In the expression: print (A B == A B) In an equation for ‘main’: main = print (A B == A B) Now not only is the type puzzling (B instead of A) but the *class* is puzzling (Ord instead of Eq). This occurred to me in practice because 'Data.Graph.Inductive.PatriciaTree.Gr' has '(Eq a, Ord b) => Eq (Gr a b)'. It would have been a lot more helpful to see * No instance for (Ord B) * arising from (Eq A) * arising from the use of '==' Does anyone agree with me that GHC should produce the full trace when it fails to resolve instances rather than just the proximal failure? Tom From damian.nadales at gmail.com Mon Aug 15 13:33:23 2016 From: damian.nadales at gmail.com (Damian Nadales) Date: Mon, 15 Aug 2016 15:33:23 +0200 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: <20160815132623.GA13523@weber> References: <20160815132623.GA13523@weber> Message-ID: On Mon, Aug 15, 2016 at 3:26 PM, Tom Ellis wrote: > Here's a program with an odd error message (GHC 8.0.1): > > data A a = A a deriving Eq > data B = B > > main :: IO () > main = print (A B == A B) > > test/main.hs:5:15: error: > • No instance for (Eq B) arising from a use of ‘==’ > • In the first argument of ‘print’, namely ‘(A B == A B)’ > In the expression: print (A B == A B) > In an equation for ‘main’: main = print (A B == A B) > I would expect this error, since B does not implement equality. Maybe you're expecting Haskell to automatically derive an Eq B instance, but that is not the behavior I would want, since data definitions could implicitly define instances for other data types. Is there any reason why you don't define: data B = B deriving Eq? > I get an error about Eq B even though it's Eq A that is manifestly required > at the call site. This error is odder when A and B are defined far away > from the use of '=='. > > This is even odder: > > data A a = A a > data B = B > > instance Ord a => Eq (A a) where > > main :: IO () > main = print (A B == A B) > > test/main.hs:7:15: error: > • No instance for (Ord B) arising from a use of ‘==’ > • In the first argument of ‘print’, namely ‘(A B == A B)’ > In the expression: print (A B == A B) > In an equation for ‘main’: main = print (A B == A B) > > Now not only is the type puzzling (B instead of A) but the *class* is > puzzling (Ord instead of Eq). This occurred to me in practice because > 'Data.Graph.Inductive.PatriciaTree.Gr' has '(Eq a, Ord b) => Eq (Gr a b)'. > > It would have been a lot more helpful to see > > * No instance for (Ord B) > * arising from (Eq A) > * arising from the use of '==' > > Does anyone agree with me that GHC should produce the full trace when it > fails to resolve instances rather than just the proximal failure? > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Aug 15 13:35:15 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 15 Aug 2016 14:35:15 +0100 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: References: <20160815132623.GA13523@weber> Message-ID: <20160815133515.GB13523@weber> On Mon, Aug 15, 2016 at 03:33:23PM +0200, Damian Nadales wrote: > On Mon, Aug 15, 2016 at 3:26 PM, Tom Ellis > wrote: > > Here's a program with an odd error message (GHC 8.0.1): > > > > data A a = A a deriving Eq > > data B = B > > > > main :: IO () > > main = print (A B == A B) > > > > test/main.hs:5:15: error: > > • No instance for (Eq B) arising from a use of ‘==’ > > • In the first argument of ‘print’, namely ‘(A B == A B)’ > > In the expression: print (A B == A B) > > In an equation for ‘main’: main = print (A B == A B) > > I would expect this error, since B does not implement equality. Maybe > you're expecting Haskell to automatically derive an Eq B instance, but > that is not the behavior I would want, since data definitions could > implicitly define instances for other data types. > > Is there any reason why you don't define: > data B = B deriving Eq? My complaint is about the confusing error message, not the failure to type check. From fa-ml at ariis.it Mon Aug 15 13:38:45 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Mon, 15 Aug 2016 15:38:45 +0200 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: <20160815133515.GB13523@weber> References: <20160815132623.GA13523@weber> <20160815133515.GB13523@weber> Message-ID: <20160815133845.GA8602@casa.casa> On Mon, Aug 15, 2016 at 02:35:15PM +0100, Tom Ellis wrote: > My complaint is about the confusing error message, not the failure to > type check. For reference, feeding that program to Hugs (which I usually find a bit better in terms of error reporting) leads to: ERROR "prova.hs":5 - Instance of Eq B required for definition of main Slightly clearer but not much. I don't have UHC handy to test its error messages! From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Aug 15 13:48:58 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 15 Aug 2016 14:48:58 +0100 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: <20160815133845.GA8602@casa.casa> References: <20160815132623.GA13523@weber> <20160815133515.GB13523@weber> <20160815133845.GA8602@casa.casa> Message-ID: <20160815134858.GC13523@weber> On Mon, Aug 15, 2016 at 03:38:45PM +0200, Francesco Ariis wrote: > On Mon, Aug 15, 2016 at 02:35:15PM +0100, Tom Ellis wrote: > > My complaint is about the confusing error message, not the failure to > > type check. > > For reference, feeding that program to Hugs (which I usually > find a bit better in terms of error reporting) leads to: > > ERROR "prova.hs":5 - Instance of Eq B required for definition of main > > Slightly clearer but not much. I don't have UHC handy to test > its error messages! I find that message equally puzzling. It seems to me that the most helpful message would have to mention that Eq B is required to satisfy Eq A. From fa-ml at ariis.it Mon Aug 15 13:51:33 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Mon, 15 Aug 2016 15:51:33 +0200 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: <20160815134858.GC13523@weber> References: <20160815132623.GA13523@weber> <20160815133515.GB13523@weber> <20160815133845.GA8602@casa.casa> <20160815134858.GC13523@weber> Message-ID: <20160815135133.GA9393@casa.casa> On Mon, Aug 15, 2016 at 02:48:58PM +0100, Tom Ellis wrote: > I find that message equally puzzling. It seems to me that the most > helpful message > would have to mention that Eq B is required to > satisfy Eq A. Time to file a feature request then! :) https://ghc.haskell.org/trac/ghc/wiki/ReportABug From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Aug 15 14:00:14 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 15 Aug 2016 15:00:14 +0100 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: <20160815135133.GA9393@casa.casa> References: <20160815132623.GA13523@weber> <20160815133515.GB13523@weber> <20160815133845.GA8602@casa.casa> <20160815134858.GC13523@weber> <20160815135133.GA9393@casa.casa> Message-ID: <20160815140014.GD13523@weber> On Mon, Aug 15, 2016 at 03:51:33PM +0200, Francesco Ariis wrote: > On Mon, Aug 15, 2016 at 02:48:58PM +0100, Tom Ellis wrote: > > I find that message equally puzzling. It seems to me that the most > > helpful message > would have to mention that Eq B is required to > > satisfy Eq A. > > Time to file a feature request then! :) > https://ghc.haskell.org/trac/ghc/wiki/ReportABug I shall if I get some confirmation that this is a sane thing to want! From malcolm.wallace at me.com Mon Aug 15 14:40:46 2016 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Mon, 15 Aug 2016 15:40:46 +0100 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: <20160815140014.GD13523@weber> References: <20160815132623.GA13523@weber> <20160815133515.GB13523@weber> <20160815133845.GA8602@casa.casa> <20160815134858.GC13523@weber> <20160815135133.GA9393@casa.casa> <20160815140014.GD13523@weber> Message-ID: <5A836805-FDB0-4258-8EC7-243573B7F90A@me.com> I have to say that I don't find the original error message confusing at all. It points directly to the missing instance, namely Eq B. If you add an instance for Eq B, the program will work. It is no surprise that the instance Eq A is not mentioned, because there is a perfectly valid instance for it already, and it contains no error. The /expression/ pointed to by the error message has A values in it, but the error message is correctly steering you away from considering the As, and telling you to consider the Bs instead. Regards, Malcolm On 15 Aug 2016, at 15:00, Tom Ellis wrote: > On Mon, Aug 15, 2016 at 03:51:33PM +0200, Francesco Ariis wrote: >> On Mon, Aug 15, 2016 at 02:48:58PM +0100, Tom Ellis wrote: >>> I find that message equally puzzling. It seems to me that the most >>> helpful message > would have to mention that Eq B is required to >>> satisfy Eq A. >> >> Time to file a feature request then! :) >> https://ghc.haskell.org/trac/ghc/wiki/ReportABug > > I shall if I get some confirmation that this is a sane thing to want! > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Aug 15 14:50:03 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 15 Aug 2016 15:50:03 +0100 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: <5A836805-FDB0-4258-8EC7-243573B7F90A@me.com> References: <20160815132623.GA13523@weber> <20160815133515.GB13523@weber> <20160815133845.GA8602@casa.casa> <20160815134858.GC13523@weber> <20160815135133.GA9393@casa.casa> <20160815140014.GD13523@weber> <5A836805-FDB0-4258-8EC7-243573B7F90A@me.com> Message-ID: <20160815145003.GE13523@weber> On Mon, Aug 15, 2016 at 03:40:46PM +0100, Malcolm Wallace wrote: > It is no surprise that the instance Eq A is not mentioned, because there > is a perfectly valid instance for it already, and it contains no error. I disagree. There is no valid instance for Eq (A B), because all that the compiler knows is that 'Eq B => Eq (A B)', and there is no 'Eq B'. There are two separate issues here. 1. The reason the compilation fails is that there is no instance 'Eq (A B)'. 2. The reason there is no instance 'Eq (A B)' is that there is no instance 'Eq B'. In my opinion it would be most helpful to the user to mention both 1 and 2. In fact it's likely to be very confusing if you don't mention both of them! Tom From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Mon Aug 15 14:58:04 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Mon, 15 Aug 2016 15:58:04 +0100 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: <20160815145003.GE13523@weber> References: <20160815132623.GA13523@weber> <20160815133515.GB13523@weber> <20160815133845.GA8602@casa.casa> <20160815134858.GC13523@weber> <20160815135133.GA9393@casa.casa> <20160815140014.GD13523@weber> <5A836805-FDB0-4258-8EC7-243573B7F90A@me.com> <20160815145003.GE13523@weber> Message-ID: <20160815145804.GF13523@weber> On Mon, Aug 15, 2016 at 03:50:03PM +0100, Tom Ellis wrote: > On Mon, Aug 15, 2016 at 03:40:46PM +0100, Malcolm Wallace wrote: > > It is no surprise that the instance Eq A is not mentioned, because there > > is a perfectly valid instance for it already, and it contains no error. > > I disagree. > > There is no valid instance for Eq (A B), because all that the compiler knows > is that 'Eq B => Eq (A B)', and there is no 'Eq B'. > > There are two separate issues here. > > 1. The reason the compilation fails is that there is no instance 'Eq (A B)'. > > 2. The reason there is no instance 'Eq (A B)' is that there is no instance > 'Eq B'. > > In my opinion it would be most helpful to the user to mention both 1 and 2. > In fact it's likely to be very confusing if you don't mention both of them! By the way, I agree with the spirit of this: > It points directly to the missing instance, namely Eq B. If you add an > instance for Eq B, the program will work ... the error message is > correctly steering you away from considering the As, and telling you to > consider the Bs instead. but I don't see why the compiler shouldn't be even *more* helpful in its steering and explain how and why it came to need 'Eq B'. Tom From michael at orlitzky.com Mon Aug 15 15:09:52 2016 From: michael at orlitzky.com (Michael Orlitzky) Date: Mon, 15 Aug 2016 11:09:52 -0400 Subject: [Haskell-cafe] Proposal: Rational read In-Reply-To: References: <09BFF725-AE27-4F99-BB44-750BEB03B73F@gmail.com> Message-ID: On 08/15/2016 09:04 AM, Benno Fünfstück wrote: > > Well, you are showing 1/3 as a Float and reading it as a Double, which > of course won't work since the String represents a Float and not a > Double. The following does work: > Sorry, unclear example. We have a choice to make for how to read in decimal strings that could also represent Floats or Doubles. I'm worried about the resulting confusion from whatever choice we make. Read/Show are supposed to be machine-readable, and representing a Rational as a decimal (the same way a Float is represented) gives away some type-safety. This is the same argument I would make against having (read "1.0" :: Integer) return 1. Suppose that this is what the rational read instance would do... ghci> let ratread :: String -> Rational; ratread s = realToFrac (read s :: Double) :: Rational We're compatible with the Fractional/Show instance for Float/Double: ghci> fromRational $ ratread (show (0.33333334 :: Float)) :: Float 0.33333334 ghci> fromRational $ ratread (show (0.33333334 :: Double)) :: Double 0.33333334 But obviously things will go wrong for rationals themselves, when they don't fit into a Double. The other choice we could make is to take "0.33333334", multiply it by ten-to-the-whatever, and then make that the denominator (over ten-to-the-whatever). That's probably a better choice, but then you have other inconsistencies... ghci> 0.33333334 :: Rational 16666667 % 50000000 ghci> toRational (0.33333334 :: Float) 11184811 % 33554432 Namely, that that's not how the Float itself is converted into a Rational. Basically, beware of confusing the hell out of everyone in order to avoid an explicit type conversion. From bertram.felgenhauer at googlemail.com Mon Aug 15 17:07:58 2016 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Mon, 15 Aug 2016 19:07:58 +0200 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: <20160815145003.GE13523@weber> References: <20160815132623.GA13523@weber> <20160815133515.GB13523@weber> <20160815133845.GA8602@casa.casa> <20160815134858.GC13523@weber> <20160815135133.GA9393@casa.casa> <20160815140014.GD13523@weber> <5A836805-FDB0-4258-8EC7-243573B7F90A@me.com> <20160815145003.GE13523@weber> Message-ID: <20160815170758.dv2cgw3m4tfft276@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Tom Ellis wrote: > On Mon, Aug 15, 2016 at 03:40:46PM +0100, Malcolm Wallace wrote: > > It is no surprise that the instance Eq A is not mentioned, because there > > is a perfectly valid instance for it already, and it contains no error. > > I disagree. > > There is no valid instance for Eq (A B), because all that the compiler knows > is that 'Eq B => Eq (A B)', and there is no 'Eq B'. > > There are two separate issues here. > > 1. The reason the compilation fails is that there is no instance 'Eq (A B)'. > > 2. The reason there is no instance 'Eq (A B)' is that there is no instance > 'Eq B'. I believe the the missing Eq instance for B is the more useful bit of information of these two, but I wouldn't mind an explanation of the simplification steps that the compiler made to discover it. I'm a bit worried though that such an explanation may be very long, and I expect that it's not trivial to extract this information from ghc's constraint based type checker. (In principle, -ddump-tc-trace prints all this information, but it's far too verbose and cluttered by ghc internal identifiers.) Cheers, Bertram From david.feuer at gmail.com Mon Aug 15 17:26:26 2016 From: david.feuer at gmail.com (David Feuer) Date: Mon, 15 Aug 2016 13:26:26 -0400 Subject: [Haskell-cafe] Typeclass resolution errors quite puzzling In-Reply-To: <20160815145003.GE13523@weber> References: <20160815132623.GA13523@weber> <20160815133515.GB13523@weber> <20160815133845.GA8602@casa.casa> <20160815134858.GC13523@weber> <20160815135133.GA9393@casa.casa> <20160815140014.GD13523@weber> <5A836805-FDB0-4258-8EC7-243573B7F90A@me.com> <20160815145003.GE13523@weber> Message-ID: For what it's worth, I also think it would be really useful to get a trace of the constraint simplification when there's a resolution failure. Unification could make some bits hard to understand, but anything would be better than nothing. On Aug 15, 2016 10:50 AM, "Tom Ellis" < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Mon, Aug 15, 2016 at 03:40:46PM +0100, Malcolm Wallace wrote: > > It is no surprise that the instance Eq A is not mentioned, because there > > is a perfectly valid instance for it already, and it contains no error. > > I disagree. > > There is no valid instance for Eq (A B), because all that the compiler > knows > is that 'Eq B => Eq (A B)', and there is no 'Eq B'. > > There are two separate issues here. > > 1. The reason the compilation fails is that there is no instance 'Eq (A > B)'. > > 2. The reason there is no instance 'Eq (A B)' is that there is no instance > 'Eq B'. > > In my opinion it would be most helpful to the user to mention both 1 and 2. > In fact it's likely to be very confusing if you don't mention both of them! > > Tom > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From olf at aatal-apotheke.de Mon Aug 15 20:48:14 2016 From: olf at aatal-apotheke.de (Olaf Klinke) Date: Mon, 15 Aug 2016 22:48:14 +0200 (CEST) Subject: [Haskell-cafe] The relationship between F-algebras and the Free Monad Message-ID: Dear Will, I used to think of the extra parameter "a" in Free f a as the type of variables in the terms. So in short, while Fix f gives you the closed terms of your AST, Free f a gives you open terms with variables of type a. Indeed the equations Fix f = f (Fix f) Free f a = Pure a | Free (f (Free f a)) are related: Let Var a f x = Var a | App (f x) Then Free f a = Fix (Var a f) Hence the free monad is the fixed point of the functor f where you first sneak in free variables of type a. Moreover, given a function from variables to closed terms, you can turn an open term to a closed term (see below). Your exercise: Implement the below using catamorphisms and so on. -- Olaf newtype Fix f = Fix (f (Fix f)) data Free f a = Pure a | Free (f (Free f a)) data Var a f x = Var a | App (f x) -- tofree.tofix = id -- tofix.tofree = id tofree :: Functor f => Free f a -> Fix (Var a f) tofree (Pure a) = Fix (Var a) tofree (Free fx) = Fix (App (fmap tofree fx)) tofix :: Functor f => Fix (Var a f) -> Free f a tofix (Fix (Var a)) = Pure a tofix (Fix (App fx)) = Free (fmap tofix fx) close :: Functor f => (a -> Fix f) -> Free f a -> Fix f close evaluate (Pure a) = evaluate a close evaluate (Free fx) = Fix (fmap (close evaluate) fx) From monkleyon at googlemail.com Mon Aug 15 23:20:47 2016 From: monkleyon at googlemail.com (MarLinn) Date: Tue, 16 Aug 2016 01:20:47 +0200 Subject: [Haskell-cafe] Which is the most "hackable" compiler? In-Reply-To: References: <2bc73278-430a-bcf7-527c-5b0b385cf82e@gmail.com> Message-ID: <7f1e42eb-1b97-5d5c-a4fb-433e5c834bb7@gmail.com> Thank you all very much for your tips! @Ben > You might want to check out DDC [1]. It’s still in a pre-alpha state, > but what it does have is a working external core language. You could > write your own front end that produces System-F, then have DDC compile > that. The individual compiler passes are also fairly well separated, > so it’s easy to change. DDC looks like quite interesting, but I don't think it is what I am looking for. For one thing the first parsing step is something I would prefer to "steal" wholesale, and I would also like to avoid messing with the type system where I'm not abusing it. On the other hand the claim that its purpose is to "investigate program transformation" sounds promising and I love how the code is littered with comments. So I will definitely look at it more closely, even if it's only to learn some tricks. @Sergey > If you still want to work with hackablel compiler look at jhc > https://github.com/jimcrayne/jhc and it's fork ajhc > https://github.com/ajhc/ajhc JHC immediately got my +1 because they have a rough diagram of the core transformations (http://repetae.net/computer/jhc/big-picture.pdf). It's far from perfect, but as a visual learner I love such stuff and would like other complex programs to offer something similar. It also looks like there might be some shared code between JHC and UHC? Speaking of the latter, that one looks well documented, too. So both might be a good place to start. @Tom > GHC compiler plugins may also be what you're looking for. Funnily enough GHC plugins are one of the reasons I'm shying away from GHC at the moment. Not that it's a bad idea, especially for optimizations. But focusing so much on one core structure (no pun intended) leads to a lot of dependencies on that structure and makes it hard to change it. At the same time I don't think such a linear pipeline approach is necessarily the best one. Say we want to implement a prolog-like sublanguage, makros, or even externalized typesystems at some point, as other languages are doing. (with makros serving as a core tool to keep all these kitchen sinks optional) The easiest approach would be to create separate branching paths in the compiler. Which in turn might be implemented by a DAG of independent transformer modules with separate pre- and postconditions, flexible intermediate types and semi-automatic dependency resolution. In other words tight integration with a powerful build system. That doesn't sound like something I will be able to offer, but I think it would be a good idea to at least experiment with approaches that might lead in that direction instead of relying on one core highway. Which lead me to the conclusion... @Sergey > You should go for a long run with GHC, it has most advanced extension > system and you'll be able to integrate your extensions with existing > codebase if they come out successful. ...that while that is certainly "the one true way to go" later, it's not the place I want to start at. Sorry, GHC. You will still be my build tool of choice, though. So for now my takeaway is that I will start by looking at UHC and JHC as possible places to start. DDC might be able to contribute parts or ideas. And if everything is too complicated I might just rip out parts from different projects and throw together my own minimalistic frankencompiler. So again, thanks for your contributions. It will probably take a long time for any significant results, but I'll keep you posted. Cheers, MarLinn From joe at myrtlesoftware.com Tue Aug 16 11:34:39 2016 From: joe at myrtlesoftware.com (Joe Hermaszewski) Date: Tue, 16 Aug 2016 12:34:39 +0100 Subject: [Haskell-cafe] Haskell Job In Cambridge UK Working On Compilers, Machine Learning And Computer Vision! Message-ID: <1471347279.894418.696724393.79F45F9F@webmail.messagingengine.com> We have a Haskell job opening in Cambridge, UK. Please see https://www.myrtlesoftware.com/vacancies/ Here is a video of the computer vision algorithms running in hardware we have produced using Haskell: https://www.myrtlesoftware.com/case-studies/fpga/ Myrtle is currently working as part of the UK government’s autonomous vehicles program and we are looking to hire more Haskell developers to join our expanding team. You will be working directly on our technology that translates high-level signal processing code into efficient hardware designs. Applicants should have a deep understanding of Haskell, modern compiler technology and should be familiar with git and CI based development. We are targeting GPU and FPGA backends so experience with either of these would be advantageous although we’re happy to consider strong developers without direct experience of these two areas. Similarly, a familiarity with an HDL, such as VHDL or Verilog, would be viewed positively but is not essential. Applicants should send a resume and covering email, stating your suitability for this role, to jobs at myrtlesoftware.com Myrtle is a software company based in Cambridge UK with a long history of working at the forefront of computer graphics and compiler technology. We are best known for having helped produce computer generated images for over twenty major Hollywood movies including the Transformers franchise. Myrtle’s clients have included NYSE and NASDAQ listed companies in LA, Vancouver and London. Closing date for applications 5pm, 27th August 2016 From doug at cs.dartmouth.edu Tue Aug 16 14:16:32 2016 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 16 Aug 2016 10:16:32 -0400 Subject: [Haskell-cafe] Proposal: Rational read Message-ID: <201608161416.u7GEGWGA064387@tahoe.cs.Dartmouth.EDU> It has been suggested that (read "0.5" :: Rational) need not work because (show (0.5::Rational)) will never yield the string "0.5". In contrast, (read "1" :: Double) does work, even though (show (1::Double)) will never yield the string "1". The inconsistency is stark. Doug From jeremy.gibbons at cs.ox.ac.uk Tue Aug 16 14:34:06 2016 From: jeremy.gibbons at cs.ox.ac.uk (Jeremy Gibbons) Date: Tue, 16 Aug 2016 15:34:06 +0100 Subject: [Haskell-cafe] Help! Haskell Platform install broke System.Random.TF Message-ID: <61C5B7A2-BF70-40CD-982C-947D6179665E@cs.ox.ac.uk> I've just installed GHC 8.0.1, and it seems that my QuickCheck is now broken. I'm presuming that these two facts are connected. I have a trivially small QuickCheck example: > import Test.QuickCheck > prop_PlusAssociative :: Integer -> Integer -> Integer -> Bool > prop_PlusAssociative x y z = (x+y)+z == x+(y+z) This loads fine, but when I try to test the property I get a mysterious error: jg$ ghci quickcheck.lhs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( quickcheck.lhs, interpreted ) Ok, modules loaded: Main. *Main> quickCheck prop_PlusAssociative can't load .so/.DLL for: /Library/Haskell/ghc-7.10.2-x86_64/lib/tf-random-0.5/libHStf-random-0.5-926BwEbiHzi7pBkp4dTxOe-ghc7.10.2.dylib (dlopen(/Library/Haskell/ghc-7.10.2-x86_64/lib/tf-random-0.5/libHStf-random-0.5-926BwEbiHzi7pBkp4dTxOe-ghc7.10.2.dylib, 5): Library not loaded: @rpath/libHSrandom-1.1-1z8Ujelqc6aKgvPnbRUKkP-ghc7.10.2.dylib Referenced from: /Library/Haskell/ghc-7.10.2-x86_64/lib/tf-random-0.5/libHStf-random-0.5-926BwEbiHzi7pBkp4dTxOe-ghc7.10.2.dylib Reason: image not found) I don't think it's anything to do with QuickCheck itself; I get the same error just trying to use the System.Random.TF library directly: jg$ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help Prelude> import System.Random.TF.Gen Prelude System.Random.TF.Gen> seedTFGen (1,1,1,1) can't load .so/.DLL for: /Library/Haskell/ghc-7.10.2-x86_64/lib/tf-random-0.5/libHStf-random-0.5-926BwEbiHzi7pBkp4dTxOe-ghc7.10.2.dylib (dlopen(/Library/Haskell/ghc-7.10.2-x86_64/lib/tf-random-0.5/libHStf-random-0.5-926BwEbiHzi7pBkp4dTxOe-ghc7.10.2.dylib, 5): Library not loaded: @rpath/libHSrandom-1.1-1z8Ujelqc6aKgvPnbRUKkP-ghc7.10.2.dylib Referenced from: /Library/Haskell/ghc-7.10.2-x86_64/lib/tf-random-0.5/libHStf-random-0.5-926BwEbiHzi7pBkp4dTxOe-ghc7.10.2.dylib Reason: image not found) The "7.10.2" is because I deactivated 8.0.1, then installed 7.10.3, then uninstalled both, then uninstalled all GHCs and deleted /Library/Haskell and reinstalled GHC 7.10.2 (my last working version) from what I hoped would be a clean slate. All to no avail. However, I do appear still to have a ghc-7.4.2, overlooked by uninstall-hs; and that does work fine - apparently not using the same System.Random.TF library. Can anyone suggest what I'm doing wrong, and more importantly, how to fix it? Jeremy Jeremy.Gibbons at cs.ox.ac.uk Oxford University Department of Computer Science, Wolfson Building, Parks Road, Oxford OX1 3QD, UK. +44 1865 283521 http://www.cs.ox.ac.uk/people/jeremy.gibbons/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bos at serpentine.com Tue Aug 16 16:44:18 2016 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue, 16 Aug 2016 09:44:18 -0700 Subject: [Haskell-cafe] [ANN] aeson 1.0.0.0 In-Reply-To: References: Message-ID: On Sun, Aug 7, 2016 at 5:42 AM, Adam Bergmark wrote: > I'm happy to announce that aeson v1.0.0.0 is now available on hackage! > Nice work, Adam and team. Thanks for taking this on! -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Aug 16 16:48:59 2016 From: david.feuer at gmail.com (David Feuer) Date: Tue, 16 Aug 2016 12:48:59 -0400 Subject: [Haskell-cafe] Proposal: Rational read In-Reply-To: References: <09BFF725-AE27-4F99-BB44-750BEB03B73F@gmail.com> Message-ID: That choice has already been made, with a different conclusion, in the Haskell numeric syntax. In Haskell syntax, decimal syntax is interpreted via fromRational *already*. In source, I can write 3.796::Rational and get a good result, without any conversion from Double anywhere--it just puts 3796/1000 into lowest terms as it should. I see no particular reason to do otherwise here. In either case, we need to read digits, building an integer, until we get to a non-digit. Only what happens next depends on the notation. Either notation should work for any Fractional type, as it does in Haskell syntax. On Aug 15, 2016 11:09 AM, "Michael Orlitzky" wrote: > On 08/15/2016 09:04 AM, Benno Fünfstück wrote: > > > > Well, you are showing 1/3 as a Float and reading it as a Double, which > > of course won't work since the String represents a Float and not a > > Double. The following does work: > > > > Sorry, unclear example. We have a choice to make for how to read in > decimal strings that could also represent Floats or Doubles. I'm worried > about the resulting confusion from whatever choice we make. > > Read/Show are supposed to be machine-readable, and representing a > Rational as a decimal (the same way a Float is represented) gives away > some type-safety. This is the same argument I would make against having > (read "1.0" :: Integer) return 1. > > Suppose that this is what the rational read instance would do... > > ghci> let ratread :: String -> Rational; > ratread s = realToFrac (read s :: Double) :: Rational > > We're compatible with the Fractional/Show instance for Float/Double: > > ghci> fromRational $ ratread (show (0.33333334 :: Float)) :: Float > 0.33333334 > ghci> fromRational $ ratread (show (0.33333334 :: Double)) :: Double > 0.33333334 > > But obviously things will go wrong for rationals themselves, when they > don't fit into a Double. The other choice we could make is to take > "0.33333334", multiply it by ten-to-the-whatever, and then make that the > denominator (over ten-to-the-whatever). That's probably a better choice, > but then you have other inconsistencies... > > ghci> 0.33333334 :: Rational > 16666667 % 50000000 > ghci> toRational (0.33333334 :: Float) > 11184811 % 33554432 > > Namely, that that's not how the Float itself is converted into a > Rational. Basically, beware of confusing the hell out of everyone in > order to avoid an explicit type conversion. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From corentin.dupont at gmail.com Tue Aug 16 18:21:31 2016 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Tue, 16 Aug 2016 20:21:31 +0200 Subject: [Haskell-cafe] =?utf-8?q?=28no_subject=29?= Message-ID: Hi guys, is there some library with a Monad (+Applicative, Functor...) instance of the following type: data Todo a b = Todo [a] | Done b Thanks! Corentin -------------- next part -------------- An HTML attachment was scrubbed... URL: From kane at kane.cx Tue Aug 16 18:23:52 2016 From: kane at kane.cx (David Kraeutmann) Date: Tue, 16 Aug 2016 20:23:52 +0200 Subject: [Haskell-cafe] (no subject) In-Reply-To: References: Message-ID: This looks functionally identical to type Todo a b = Either [a] b, and Either has a Monad instance. On 8/16/2016 8:21 PM, Corentin Dupont wrote: > Hi guys, > is there some library with a Monad (+Applicative, Functor...) instance of > the following type: > > data Todo a b = Todo [a] | Done b > > Thanks! > Corentin > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4291 bytes Desc: S/MIME Cryptographic Signature URL: From fa-ml at ariis.it Tue Aug 16 18:21:40 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Tue, 16 Aug 2016 20:21:40 +0200 Subject: [Haskell-cafe] Todo monad In-Reply-To: References: Message-ID: <20160816182140.GA7998@casa.casa> On Tue, Aug 16, 2016 at 08:21:31PM +0200, Corentin Dupont wrote: > Hi guys, > is there some library with a Monad (+Applicative, Functor...) instance of > the following type: > > data Todo a b = Todo [a] | Done b What is the general idea behind the "todo monad"? As an unrepented procrastinator, I might learn something useful. From mihai.maruseac at gmail.com Tue Aug 16 18:35:04 2016 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Tue, 16 Aug 2016 14:35:04 -0400 Subject: [Haskell-cafe] Todo monad In-Reply-To: <20160816182140.GA7998@casa.casa> References: <20160816182140.GA7998@casa.casa> Message-ID: You could say that yak shaving is bind, you just get more stuff on the "todo list". On Tue, Aug 16, 2016 at 2:21 PM, Francesco Ariis wrote: > On Tue, Aug 16, 2016 at 08:21:31PM +0200, Corentin Dupont wrote: >> Hi guys, >> is there some library with a Monad (+Applicative, Functor...) instance of >> the following type: >> >> data Todo a b = Todo [a] | Done b > > What is the general idea behind the "todo monad"? As an unrepented > procrastinator, I might learn something useful. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya From julesmazur at gmail.com Tue Aug 16 18:41:27 2016 From: julesmazur at gmail.com (Jules Mazur) Date: Tue, 16 Aug 2016 18:41:27 +0000 Subject: [Haskell-cafe] Todo monad In-Reply-To: <20160816182140.GA7998@casa.casa> References: <20160816182140.GA7998@casa.casa> Message-ID: <6c9mca3x5afaxwl7jqkj0dp61-0@mailer.nylas.com> Honest question -- why use this over e.g. a callback function? The point of this structure, as I understand it, would be to establish the status of asynchronous computations being performed from `[a]`; it follows that this status would be used to execute a follow-up computation. Jules On Aug 16 2016, at 2:27 pm, Francesco Ariis wrote: > On Tue, Aug 16, 2016 at 08:21:31PM +0200, Corentin Dupont wrote: > Hi guys, > is there some library with a Monad (+Applicative, Functor...) instance of > the following type: > > data Todo a b = Todo [a] | Done b > > What is the general idea behind the "todo monad"? As an unrepented procrastinator, I might learn something useful. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kane at kane.cx Tue Aug 16 21:12:30 2016 From: kane at kane.cx (David Kraeutmann) Date: Tue, 16 Aug 2016 23:12:30 +0200 Subject: [Haskell-cafe] (no subject) In-Reply-To: References: Message-ID: <80023ba7-19d0-0788-a5b9-90522b9a0197@kane.cx> I went from the assumption that he just wants something like instance Monad (Todo a) and that implies that b is the type inside of the monad. On 08/16/2016 08:23 PM, David Kraeutmann wrote: > This looks functionally identical to type Todo a b = Either [a] b, and Either has a Monad instance. > On 8/16/2016 8:21 PM, Corentin Dupont wrote: >> Hi guys, >> is there some library with a Monad (+Applicative, Functor...) instance of >> the following type: >> >> data Todo a b = Todo [a] | Done b >> >> Thanks! >> Corentin >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From kane at kane.cx Tue Aug 16 21:25:31 2016 From: kane at kane.cx (David Kraeutmann) Date: Tue, 16 Aug 2016 23:25:31 +0200 Subject: [Haskell-cafe] (no subject) In-Reply-To: <80023ba7-19d0-0788-a5b9-90522b9a0197@kane.cx> References: <80023ba7-19d0-0788-a5b9-90522b9a0197@kane.cx> Message-ID: <96bdb2e7-4d43-9e65-73b8-83fae92756b9@kane.cx> This was in reply to Theodore's message: > I have a hunch that the desired behavior is Either b [a], tho. (Or possibly [Either b a]?) On 08/16/2016 11:12 PM, David Kraeutmann wrote: > I went from the assumption that he just wants something like > > instance Monad (Todo a) > > and that implies that b is the type inside of the monad. > > > On 08/16/2016 08:23 PM, David Kraeutmann wrote: >> This looks functionally identical to type Todo a b = Either [a] b, and Either has a Monad instance. >> On 8/16/2016 8:21 PM, Corentin Dupont wrote: >>> Hi guys, >>> is there some library with a Monad (+Applicative, Functor...) instance of >>> the following type: >>> >>> data Todo a b = Todo [a] | Done b >>> >>> Thanks! >>> Corentin >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From corentin.dupont at gmail.com Tue Aug 16 21:56:08 2016 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Tue, 16 Aug 2016 23:56:08 +0200 Subject: [Haskell-cafe] (no subject) In-Reply-To: <80023ba7-19d0-0788-a5b9-90522b9a0197@kane.cx> References: <80023ba7-19d0-0788-a5b9-90522b9a0197@kane.cx> Message-ID: That, right, just to clarify, my instances are like that: instance Applicative (Todo a) where pure = Done Todo as <*> Todo bs = Todo $ as ++ bs Todo as <*> _ = Todo as Done f <*> r = fmap f r instance Monad (Todo a) where return = Done Todo as >>= _ = Todo as Done a >>= f = f a It's basically accumulating on the Todos. Either [a] b does not fit because it does not accumulate on the a's. On Tue, Aug 16, 2016 at 11:12 PM, David Kraeutmann wrote: > I went from the assumption that he just wants something like > > instance Monad (Todo a) > > and that implies that b is the type inside of the monad. > > > On 08/16/2016 08:23 PM, David Kraeutmann wrote: > > This looks functionally identical to type Todo a b = Either [a] b, and > Either has a Monad instance. > > On 8/16/2016 8:21 PM, Corentin Dupont wrote: > >> Hi guys, > >> is there some library with a Monad (+Applicative, Functor...) instance > of > >> the following type: > >> > >> data Todo a b = Todo [a] | Done b > >> > >> Thanks! > >> Corentin > >> > >> > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> To (un)subscribe, modify options or view archives go to: > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> Only members subscribed via the mailman list are allowed to post. > >> > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lambda.fairy at gmail.com Tue Aug 16 22:59:46 2016 From: lambda.fairy at gmail.com (Chris Wong) Date: Wed, 17 Aug 2016 10:59:46 +1200 Subject: [Haskell-cafe] (no subject) In-Reply-To: References: <80023ba7-19d0-0788-a5b9-90522b9a0197@kane.cx> Message-ID: Hi Corentin, That's called the "Validation applicative". I'm on my phone so I can't link, but that phrase should give you a starting point. Note that your type actually has no valid Monad instance that is consistent with the Applicative. That's because while the Applicative accumulates data, the Monad throws it away every time. Chris On Aug 17, 2016 09:56, "Corentin Dupont" wrote: > That, right, just to clarify, my instances are like that: > > instance Applicative (Todo a) where > pure = Done > Todo as <*> Todo bs = Todo $ as ++ bs > Todo as <*> _ = Todo as > Done f <*> r = fmap f r > > instance Monad (Todo a) where > return = Done > Todo as >>= _ = Todo as > Done a >>= f = f a > > > It's basically accumulating on the Todos. Either [a] b does not fit > because it does not accumulate on the a's. > > > On Tue, Aug 16, 2016 at 11:12 PM, David Kraeutmann wrote: > >> I went from the assumption that he just wants something like >> >> instance Monad (Todo a) >> >> and that implies that b is the type inside of the monad. >> >> >> On 08/16/2016 08:23 PM, David Kraeutmann wrote: >> > This looks functionally identical to type Todo a b = Either [a] b, and >> Either has a Monad instance. >> > On 8/16/2016 8:21 PM, Corentin Dupont wrote: >> >> Hi guys, >> >> is there some library with a Monad (+Applicative, Functor...) instance >> of >> >> the following type: >> >> >> >> data Todo a b = Todo [a] | Done b >> >> >> >> Thanks! >> >> Corentin >> >> >> >> >> >> >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> To (un)subscribe, modify options or view archives go to: >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> Only members subscribed via the mailman list are allowed to post. >> >> >> > >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Aug 16 23:04:49 2016 From: david.feuer at gmail.com (David Feuer) Date: Tue, 16 Aug 2016 19:04:49 -0400 Subject: [Haskell-cafe] (no subject) In-Reply-To: References: <80023ba7-19d0-0788-a5b9-90522b9a0197@kane.cx> Message-ID: Your Monad instance does not correspond to your Applicative instance as required by the class laws. Your Monad instance never appends the way the Applicative one does. And there's no way to make it do so. I don't think you've defined your type the way you really want. But without many details about how you wish to use it, it's hard to say how to fix the problem. On Aug 16, 2016 5:56 PM, "Corentin Dupont" wrote: > That, right, just to clarify, my instances are like that: > > instance Applicative (Todo a) where > pure = Done > Todo as <*> Todo bs = Todo $ as ++ bs > Todo as <*> _ = Todo as > Done f <*> r = fmap f r > > instance Monad (Todo a) where > return = Done > Todo as >>= _ = Todo as > Done a >>= f = f a > > > It's basically accumulating on the Todos. Either [a] b does not fit > because it does not accumulate on the a's. > > > On Tue, Aug 16, 2016 at 11:12 PM, David Kraeutmann wrote: > >> I went from the assumption that he just wants something like >> >> instance Monad (Todo a) >> >> and that implies that b is the type inside of the monad. >> >> >> On 08/16/2016 08:23 PM, David Kraeutmann wrote: >> > This looks functionally identical to type Todo a b = Either [a] b, and >> Either has a Monad instance. >> > On 8/16/2016 8:21 PM, Corentin Dupont wrote: >> >> Hi guys, >> >> is there some library with a Monad (+Applicative, Functor...) instance >> of >> >> the following type: >> >> >> >> data Todo a b = Todo [a] | Done b >> >> >> >> Thanks! >> >> Corentin >> >> >> >> >> >> >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> To (un)subscribe, modify options or view archives go to: >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> Only members subscribed via the mailman list are allowed to post. >> >> >> > >> > >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > To (un)subscribe, modify options or view archives go to: >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From li-yao.xia at ens.fr Tue Aug 16 21:26:41 2016 From: li-yao.xia at ens.fr (Li-yao Xia) Date: Tue, 16 Aug 2016 23:26:41 +0200 Subject: [Haskell-cafe] [ANN] generic-random-0.2.0.0 Message-ID: <37dbb3af-395b-9c5c-14b8-4271af0f7790@ens.fr> Hello, This library aims to derive random generators for ADTs. The previous and first release was an implementation of Boltzmann generators, in response to this blogpost by Brent Yorgey. https://byorgey.wordpress.com/2016/03/23/boltzmann-sampling-for-generic-arbitrary-instances/ It's nice to look at, but it is an opinionated choice about the resulting probability distribution which is not always suitable. In this release, using GHC.Generics, Generic.Random.Generic wraps common boilerplate to define "arbitrary" in particular, hiding from you long chains of the following: Constructor <$> arbitrary <*> arbitrary <*> arbitrary as well as frequency [(n1, C1 <$> arbitrary), (n2, C2 <$> arbitrary), ...] leaving just the weights [n1, n2, ...] for you to specify. data Tree a = Leaf a | Node (Tree a) (Tree a) deriving Generic instance Arbitrary a => Arbitrary (Tree a) where arbitrary = genericArbitraryFrequency [9, 8] -- equivalent to -- > arbitrary = frequency -- > [ (9, Leaf <$> arbitrary) -- > , (8, Node <$> arbitrary <*> arbitrary) -- > ] It comes with a simple opt-in strategy to bound the size of generated data, especially convenient for recursive data types. Indeed, even for a simple binary tree, the naive generator obtained by producing a leaf half of the times, and an inner node the other half, with two recursively generated children, results in a random tree of *infinite* expected size (though the tree is still "almost surely" finite). There is no theoretical reason the library uses two flavors of generics for different tasks. There are trade-offs, but I can't see impassable obstacles to use one in place of the other. If I had to be consistent now I'd choose GHC.Generics, though I was not fluent enough in that flavor at the time when I wrote the Data part. Property-based testing is the main application I have in mind for this library. Nevertheless, I welcome ideas, questions and suggestions from any domain or of general nature. Github: https://github.com/lysxia/generic-random Hackage: http://hackage.haskell.org/package/generic-random Li-yao From eyeinsky9 at gmail.com Wed Aug 17 06:01:28 2016 From: eyeinsky9 at gmail.com (eyeinsky .) Date: Wed, 17 Aug 2016 08:01:28 +0200 Subject: [Haskell-cafe] Todo monad In-Reply-To: <20160816182140.GA7998@casa.casa> References: <20160816182140.GA7998@casa.casa> Message-ID: For sure you need to be able to add stuff to the todo list ;) On Aug 16, 2016 8:27 PM, "Francesco Ariis" wrote: > On Tue, Aug 16, 2016 at 08:21:31PM +0200, Corentin Dupont wrote: > > Hi guys, > > is there some library with a Monad (+Applicative, Functor...) instance of > > the following type: > > > > data Todo a b = Todo [a] | Done b > > What is the general idea behind the "todo monad"? As an unrepented > procrastinator, I might learn something useful. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From christiaan.baaij at gmail.com Wed Aug 17 13:11:25 2016 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Wed, 17 Aug 2016 15:11:25 +0200 Subject: [Haskell-cafe] [ANN] ghc-typelits-knownnat-0.2: Solving GHCs KnownNat constraints Message-ID: <57B4627D.4070502@gmail.com> Hi, If you have ever worked with `GHC.TypeLits`, then you have probably encountered an error very similar to: > • Could not deduce (KnownNat (n + 2)) > arising from a use of ‘natVal’ > from the context: KnownNat n i.e. where GHC cannot infer a `KnownNat (n+2)` constraint, even though a `KnownNat n` constraint is already given. Enter http://hackage.haskell.org/package/ghc-typelits-knownnat A type-checker plugin that can automatically derive "complex" KnownNat constraints from simpler ones. To use it, you simply add the {-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-} pragma to the top of your file. If you want to know more, you can also check out the corresponding blog posts: http://qbaylogic.com/blog/2016/08/10/solving-knownnat-constraints-plugin.html http://qbaylogic.com/blog/2016/08/17/solving-knownnat-custom-operations.html Regards, Christiaan From ekmett at gmail.com Wed Aug 17 13:52:39 2016 From: ekmett at gmail.com (Edward Kmett) Date: Wed, 17 Aug 2016 09:52:39 -0400 Subject: [Haskell-cafe] [ANN] ghc-typelits-knownnat-0.2: Solving GHCs KnownNat constraints In-Reply-To: <57B4627D.4070502@gmail.com> References: <57B4627D.4070502@gmail.com> Message-ID: I have to admit that is a heck of a lot easier to use than what I have: https://github.com/ekmett/constraints/blob/master/src/Data/Constraint/Nat.hs =) -Edward On Wed, Aug 17, 2016 at 9:11 AM, Christiaan Baaij < christiaan.baaij at gmail.com> wrote: > Hi, > > If you have ever worked with `GHC.TypeLits`, then you have probably > encountered an error very similar to: > > > • Could not deduce (KnownNat (n + 2)) > > arising from a use of ‘natVal’ > > from the context: KnownNat n > > i.e. where GHC cannot infer a `KnownNat (n+2)` constraint, even though a > `KnownNat n` constraint is already given. > > Enter http://hackage.haskell.org/package/ghc-typelits-knownnat > A type-checker plugin that can automatically derive "complex" KnownNat > constraints from simpler ones. > > To use it, you simply add the > > {-# OPTIONS_GHC -fplugin GHC.TypeLits.KnownNat.Solver #-} > > pragma to the top of your file. > > If you want to know more, you can also check out the corresponding blog > posts: > > http://qbaylogic.com/blog/2016/08/10/solving-knownnat-constr > aints-plugin.html > http://qbaylogic.com/blog/2016/08/17/solving-knownnat-custom > -operations.html > > Regards, > > Christiaan > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From i.caught.air at gmail.com Wed Aug 17 17:43:38 2016 From: i.caught.air at gmail.com (Alex Belanger) Date: Wed, 17 Aug 2016 13:43:38 -0400 Subject: [Haskell-cafe] Proposal: (.:) operator in base. Message-ID: Hi, Some of you might be familiar with (.:) = (.) . (.). It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d It allows the composition of two functions, the first one, accepting one operand, and the second, two operands. This appears to be a very common pattern, referenced a bit everywhere, almost always defined on lambdabot and found in multiple codebases in the wild. I'd like the know the general sentiment about this operator, as well as how its inclusion in base, probably Data.Function, would be perceived before I actually try to make it happen. Cheers, Alex (nitrix). -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.yager at gmail.com Wed Aug 17 17:50:51 2016 From: will.yager at gmail.com (Will Yager) Date: Wed, 17 Aug 2016 10:50:51 -0700 Subject: [Haskell-cafe] [ANN] ghc-typelits-knownnat-0.2: Solving GHCs KnownNat constraints In-Reply-To: <57B4627D.4070502@gmail.com> References: <57B4627D.4070502@gmail.com> Message-ID: <80214087-AEF8-417C-A5BE-4BB204A528D3@gmail.com> Ah. I believe I have run into such issues with Clash, requiring me to add extraneous constraints over the results of addition. I assume this is the motivating use case here? Great work on this and Typelits-natnormalise! Will > On Aug 17, 2016, at 06:11, Christiaan Baaij wrote: > If you have ever worked with `GHC.TypeLits`, then you have probably encountered an error very similar to: > > > • Could not deduce (KnownNat (n + 2)) > > arising from a use of ‘natVal’ > > from the context: KnownNat n > From christiaan.baaij at gmail.com Wed Aug 17 18:56:30 2016 From: christiaan.baaij at gmail.com (Christiaan Baaij) Date: Wed, 17 Aug 2016 20:56:30 +0200 Subject: [Haskell-cafe] [ANN] ghc-typelits-knownnat-0.2: Solving GHCs KnownNat constraints In-Reply-To: <80214087-AEF8-417C-A5BE-4BB204A528D3@gmail.com> References: <57B4627D.4070502@gmail.com> <80214087-AEF8-417C-A5BE-4BB204A528D3@gmail.com> Message-ID: Yes, clash is the motivating use case. I wanted to simplify the API of the prelude for the upcoming 1.0 release. Especially to reduce monstrosities such as this: http://hackage.haskell.org/package/clash-prelude-0.10.11/docs/CLaSH-Sized-Fixed.html#t:ENumSFixedC Cheers, Christiaan > On 17 Aug 2016, at 19:50, Will Yager wrote: > > Ah. I believe I have run into such issues with Clash, requiring me to add extraneous constraints over the results of addition. I assume this is the motivating use case here? > > Great work on this and Typelits-natnormalise! > > Will > >>> On Aug 17, 2016, at 06:11, Christiaan Baaij wrote: >> >> If you have ever worked with `GHC.TypeLits`, then you have probably encountered an error very similar to: >> >>> • Could not deduce (KnownNat (n + 2)) >>> arising from a use of ‘natVal’ >>> from the context: KnownNat n >> From tonymorris at gmail.com Wed Aug 17 21:14:53 2016 From: tonymorris at gmail.com (Tony Morris) Date: Thu, 18 Aug 2016 07:14:53 +1000 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: Message-ID: You'd generalise it to: fmap . fmap :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b) And then, would you do the same for Traversable, Foldable and Applicative? On 18/08/16 03:43, Alex Belanger wrote: > Hi, > > Some of you might be familiar with (.:) = (.) . (.). > > It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d > > It allows the composition of two functions, the first one, accepting > one operand, and the second, two operands. > > This appears to be a very common pattern, referenced a bit everywhere, > almost always defined on lambdabot and found in multiple codebases in > the wild. > > I'd like the know the general sentiment about this operator, as well > as how its inclusion in base, probably Data.Function, would be > perceived before I actually try to make it happen. > > Cheers, > Alex (nitrix). > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From kiss.csongor.kiss at gmail.com Wed Aug 17 21:39:35 2016 From: kiss.csongor.kiss at gmail.com (Csongor Kiss) Date: Wed, 17 Aug 2016 22:39:35 +0100 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: Message-ID: Can you provide a bit more detail on why you think (fmap . fmap) captures the concept behind (.) . (.) ?  It certainly does generalise it in one way - and I do get how, but is it the *right* generalisation? Or does it just coincide with (-> e)’s fmap being defined as (.), and in fact we would prefer to generalise the composition aspect, in which case Category would be a more ‘obvious’ place to look? On 17 August 2016 at 22:15:56, Tony Morris (tonymorris at gmail.com) wrote: You'd generalise it to: fmap . fmap :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b) And then, would you do the same for Traversable, Foldable and Applicative? On 18/08/16 03:43, Alex Belanger wrote: Hi, Some of you might be familiar with (.:) = (.) . (.). It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d It allows the composition of two functions, the first one, accepting one operand, and the second, two operands. This appears to be a very common pattern, referenced a bit everywhere, almost always defined on lambdabot and found in multiple codebases in the wild. I'd like the know the general sentiment about this operator, as well as how its inclusion in base, probably Data.Function, would be perceived before I actually try to make it happen. Cheers, Alex (nitrix). _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kiss.csongor.kiss at gmail.com Wed Aug 17 21:45:15 2016 From: kiss.csongor.kiss at gmail.com (Csongor Kiss) Date: Wed, 17 Aug 2016 22:45:15 +0100 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: Message-ID: Of course I meant to write ((->) e) On 17 August 2016 at 22:39:36, Csongor Kiss (kiss.csongor.kiss at gmail.com) wrote: Can you provide a bit more detail on why you think (fmap . fmap) captures the concept behind (.) . (.) ?  It certainly does generalise it in one way - and I do get how, but is it the *right* generalisation? Or does it just coincide with (-> e)’s fmap being defined as (.), and in fact we would prefer to generalise the composition aspect, in which case Category would be a more ‘obvious’ place to look? On 17 August 2016 at 22:15:56, Tony Morris (tonymorris at gmail.com) wrote: You'd generalise it to: fmap . fmap :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b) And then, would you do the same for Traversable, Foldable and Applicative? On 18/08/16 03:43, Alex Belanger wrote: Hi, Some of you might be familiar with (.:) = (.) . (.). It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d It allows the composition of two functions, the first one, accepting one operand, and the second, two operands. This appears to be a very common pattern, referenced a bit everywhere, almost always defined on lambdabot and found in multiple codebases in the wild. I'd like the know the general sentiment about this operator, as well as how its inclusion in base, probably Data.Function, would be perceived before I actually try to make it happen. Cheers, Alex (nitrix). _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at googlemail.com Wed Aug 17 23:53:40 2016 From: monkleyon at googlemail.com (MarLinn) Date: Thu, 18 Aug 2016 01:53:40 +0200 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: Message-ID: > Some of you might be familiar with (.:) = (.) . (.). > > It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d First of all, I always called it "dot". Don't know where I picked that one up, though. (.:) looks like it could conflict with some lens or something. Would need checking. Also, which version? This simple one? Or the Category one? (.).(.) :: (Category cat) => cat c d -> (a -> cat b c) -> a -> cat b d I know little about Category Theory, but throwing together some random words I collected over time that looks like... a "contravariant bind in the monad of endocategories", maybe? I just invented that and it's almost certainly meaningless gibberish, but knowing our community it might well be that /there's a lib for that/. Also, why is h = f .: g == (f .) . g not good enough? So many questions, so much bikeshedding to do, so little time... -------------- next part -------------- An HTML attachment was scrubbed... URL: From i.caught.air at gmail.com Thu Aug 18 02:08:29 2016 From: i.caught.air at gmail.com (Alex Belanger) Date: Wed, 17 Aug 2016 22:08:29 -0400 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: Message-ID: Considering this would be in Data.Function along (.) and ($), I do not think generalizing it is the goal. The aim should be to keep it for functions only... or at least, that's how I've seen (.:) used so far. I'm all ears though. This is already getting interesting. On Wed, Aug 17, 2016 at 7:53 PM, MarLinn via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > > Some of you might be familiar with (.:) = (.) . (.). > > It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d > > > First of all, I always called it "dot". Don't know where I picked that one > up, though. (.:) looks like it could conflict with some lens or something. > Would need checking. > > Also, which version? This simple one? Or the Category one? > > (.).(.) :: (Category cat) => cat c d -> (a -> cat b c) -> a -> cat b d > > I know little about Category Theory, but throwing together some random > words I collected over time that looks like... a "contravariant bind in the > monad of endocategories", maybe? I just invented that and it's almost > certainly meaningless gibberish, but knowing our community it might well be > that *there's a lib for that*. > Also, why is > > h = f .: g == (f .) . g > > not good enough? > > So many questions, so much bikeshedding to do, so little time... > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From trebla at vex.net Thu Aug 18 04:22:44 2016 From: trebla at vex.net (Albert Y. C. Lai) Date: Thu, 18 Aug 2016 00:22:44 -0400 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: Message-ID: <5fb77c10-9bf4-d5ed-5e5c-ffe3eb17173f@vex.net> (.:) is already used in both aeson and cassava. And not for (.) . (.) From oleg.grenrus at iki.fi Thu Aug 18 04:43:29 2016 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Thu, 18 Aug 2016 07:43:29 +0300 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: <5fb77c10-9bf4-d5ed-5e5c-ffe3eb17173f@vex.net> References: <5fb77c10-9bf4-d5ed-5e5c-ffe3eb17173f@vex.net> Message-ID: <755C4813-76E9-4EBA-B45B-F4FA5849A33F@iki.fi> Aeson (and cassava) use is very isolated. FWIW (.=) is in aeson (and other serialising libs) and lens, and do totally different things. I never needed both in the same module. Bikeshedding: if (.:) goes to base, why not also (.:.) and (.::) and … I’m -1, there is `composition` package [1], and I rather see base shrink, not grow. - Oleg - [1] http://hackage.haskell.org/package/composition-1.0.2.1/docs/Data-Composition.html > On 18 Aug 2016, at 07:22, Albert Y. C. Lai wrote: > > (.:) is already used in both aeson and cassava. And not for (.) . (.) > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cepete02 at gmail.com Thu Aug 18 12:03:21 2016 From: cepete02 at gmail.com (Carl Petersen) Date: Thu, 18 Aug 2016 05:03:21 -0700 (PDT) Subject: [Haskell-cafe] Rewrite without parenthesis Message-ID: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> How do you rewrite head (tail [1,2,3]) without parenthesis. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Thu Aug 18 12:14:26 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 18 Aug 2016 14:14:26 +0200 Subject: [Haskell-cafe] Rewrite without parenthesis In-Reply-To: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> References: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> Message-ID: <20160818121426.GA13136@casa.casa> On Thu, Aug 18, 2016 at 05:03:21AM -0700, Carl Petersen wrote: > How do you rewrite head (tail [1,2,3]) without parenthesis. Hello Carl, simply λ> tail [1,2,3] [2,3] will do! Haskell is not a Lisp, no need to wrap expressions around (). From fa-ml at ariis.it Thu Aug 18 12:23:50 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 18 Aug 2016 14:23:50 +0200 Subject: [Haskell-cafe] Rewrite without parenthesis In-Reply-To: <20160818121426.GA13136@casa.casa> References: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> <20160818121426.GA13136@casa.casa> Message-ID: <20160818122350.GA13393@casa.casa> On Thu, Aug 18, 2016 at 02:14:26PM +0200, Francesco Ariis wrote: > Hello Carl, simply > > λ> tail [1,2,3] > [2,3] > > will do! Haskell is not a Lisp, no need to wrap expressions > around (). And you want to do away with pesky square brackets: λ> tail $ enumFromTo 1 3 [2,3] From tanuki at gmail.com Thu Aug 18 12:29:34 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Thu, 18 Aug 2016 05:29:34 -0700 Subject: [Haskell-cafe] Rewrite without parenthesis In-Reply-To: <20160818121426.GA13136@casa.casa> References: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> <20160818121426.GA13136@casa.casa> Message-ID: Francesco, you missed a piece. 'head' is part of the expression. :) What Carl is looking for is one or the other of these: head $ tail [1,2,3] -- or -- head . tail $ [1,2,3] The first one is shorter and fine for inlining, but I generally prefer the second form... it helps intuition about eta reduction, refactoring, and additional composition. On Aug 18, 2016 5:19 AM, "Francesco Ariis" wrote: > On Thu, Aug 18, 2016 at 05:03:21AM -0700, Carl Petersen wrote: > > How do you rewrite head (tail [1,2,3]) without parenthesis. > > Hello Carl, simply > > λ> tail [1,2,3] > [2,3] > > will do! Haskell is not a Lisp, no need to wrap expressions > around (). > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.Berecz at gmail.com Thu Aug 18 12:31:57 2016 From: daniel.Berecz at gmail.com (Daniel Berecz) Date: Thu, 18 Aug 2016 12:31:57 +0000 Subject: [Haskell-cafe] Rewrite without parenthesis In-Reply-To: <20160818121426.GA13136@casa.casa> References: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> <20160818121426.GA13136@casa.casa> Message-ID: Hi, Do you want to apply tail and then head on the list? If so, you can write: head $ tail [1, 2, 3] Besides the dollar opeartor there is a dot (.) operator. You can read more here: http://stackoverflow.com/questions/940382/haskell-difference-between-dot-and-dollar-sign Regards, Daniel On Thu, Aug 18, 2016 at 2:19 PM Francesco Ariis wrote: > On Thu, Aug 18, 2016 at 05:03:21AM -0700, Carl Petersen wrote: > > How do you rewrite head (tail [1,2,3]) without parenthesis. > > Hello Carl, simply > > λ> tail [1,2,3] > [2,3] > > will do! Haskell is not a Lisp, no need to wrap expressions > around (). > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Thu Aug 18 12:28:08 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 18 Aug 2016 14:28:08 +0200 Subject: [Haskell-cafe] Rewrite without parenthesis In-Reply-To: References: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> <20160818121426.GA13136@casa.casa> Message-ID: <20160818122808.GA13602@casa.casa> On Thu, Aug 18, 2016 at 05:29:34AM -0700, Theodore Lief Gannon wrote: > Francesco, you missed a piece. 'head' is part of the expression. :) What > Carl is looking for is one or the other of these: > > head $ tail [1,2,3] > -- or -- > head . tail $ [1,2,3] > > The first one is shorter and fine for inlining, but I generally prefer the > second form... it helps intuition about eta reduction, refactoring, and > additional composition. Welp, silly me! :P From wim.vanderbauwhede at gmail.com Thu Aug 18 12:45:38 2016 From: wim.vanderbauwhede at gmail.com (Wim Vanderbauwhede) Date: Thu, 18 Aug 2016 13:45:38 +0100 Subject: [Haskell-cafe] New online course "Functional Programming in Haskell" starts 19 Sept Message-ID: We have created an introductory six-week online course (MOOC) on "Functional Programming in Haskell". The course will start on 19 September and is entirely free. We think it's a great way to get started with Haskell! https://www.futurelearn.com/courses/functional-programming-haskell The course is developed at Glasgow university's School of Computing Science and hosted by FutureLearn Enjoy! Wim Vanderbauwhede & Jeremy Singer @HaskellMOOC -------------- next part -------------- An HTML attachment was scrubbed... URL: From cepete02 at gmail.com Thu Aug 18 14:53:31 2016 From: cepete02 at gmail.com (Carl Petersen) Date: Thu, 18 Aug 2016 07:53:31 -0700 (PDT) Subject: [Haskell-cafe] Rewrite without parenthesis In-Reply-To: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> References: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> Message-ID: Thanks everyone for the quick responses. Greatly appreciated. On Thursday, August 18, 2016 at 7:03:22 AM UTC-5, Carl Petersen wrote: > > How do you rewrite head (tail [1,2,3]) without parenthesis. > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eleventynine at gmail.com Thu Aug 18 21:57:26 2016 From: eleventynine at gmail.com (Mike Ledger) Date: Fri, 19 Aug 2016 07:57:26 +1000 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: Message-ID: (Forgot reply all) ---------- Forwarded message ---------- From: "Mike Ledger" Date: 18 Aug 2016 7:52 AM Subject: Re: [Haskell-cafe] Proposal: (.:) operator in base. To: "Csongor Kiss" Cc: IMO: I've never seen a compelling use of this; I think it decreases clarity, and barely shaves off any characters from equivalent "pointful" expressions. On Thu, Aug 18, 2016 at 7:45 AM, Csongor Kiss wrote: > Of course I meant to write ((->) e) > > On 17 August 2016 at 22:39:36, Csongor Kiss (kiss.csongor.kiss at gmail.com) > wrote: > > Can you provide a bit more detail on why you think (fmap . fmap) captures > the concept behind (.) . (.) ? > It certainly does generalise it in one way - and I do get how, but is it > the *right* generalisation? > > Or does it just coincide with (-> e)’s fmap being defined as (.), and in > fact we would prefer to > generalise the composition aspect, in which case Category would be a more > ‘obvious’ place to look? > > On 17 August 2016 at 22:15:56, Tony Morris (tonymorris at gmail.com) wrote: > > You'd generalise it to: > > fmap . fmap :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b) > > And then, would you do the same for Traversable, Foldable and Applicative? > > On 18/08/16 03:43, Alex Belanger wrote: > > Hi, > > Some of you might be familiar with (.:) = (.) . (.). > > It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d > > It allows the composition of two functions, the first one, accepting one > operand, and the second, two operands. > > This appears to be a very common pattern, referenced a bit everywhere, > almost always defined on lambdabot and found in multiple codebases in the > wild. > > I'd like the know the general sentiment about this operator, as well as > how its inclusion in base, probably Data.Function, would be perceived > before I actually try to make it happen. > > Cheers, > Alex (nitrix). > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > ------------------------------ > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Thu Aug 18 22:26:35 2016 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Fri, 19 Aug 2016 08:26:35 +1000 Subject: [Haskell-cafe] Rewrite without parenthesis In-Reply-To: References: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> <20160818121426.GA13136@casa.casa> Message-ID: On 18 August 2016 at 22:29, Theodore Lief Gannon wrote: > Francesco, you missed a piece. 'head' is part of the expression. :) What > Carl is looking for is one or the other of these: > > head $ tail [1,2,3] > -- or -- > head . tail $ [1,2,3] Or for this specific use case, [1,2,3] !! 1 ==> (!!1) [1,2,3] > > The first one is shorter and fine for inlining, but I generally prefer the > second form... it helps intuition about eta reduction, refactoring, and > additional composition. > > > On Aug 18, 2016 5:19 AM, "Francesco Ariis" wrote: >> >> On Thu, Aug 18, 2016 at 05:03:21AM -0700, Carl Petersen wrote: >> > How do you rewrite head (tail [1,2,3]) without parenthesis. >> >> Hello Carl, simply >> >> λ> tail [1,2,3] >> [2,3] >> >> will do! Haskell is not a Lisp, no need to wrap expressions >> around (). >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From ok at cs.otago.ac.nz Fri Aug 19 00:46:55 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 19 Aug 2016 12:46:55 +1200 Subject: [Haskell-cafe] Rewrite without parenthesis In-Reply-To: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> References: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> Message-ID: <1e21ff5d-e010-7988-b6f6-6a16f7b769f2@cs.otago.ac.nz> On 19/08/16 12:03 AM, Carl Petersen wrote: > How do you rewrite head (tail [1,2,3]) without parenthesis. s/parenthesis/parentheses/ There are several ways to do this, including [1,2,3] !! 1. The more important question is "why"? From handongwinter at didichuxing.com Fri Aug 19 07:27:59 2016 From: handongwinter at didichuxing.com (=?utf-8?B?6Z+p5YasKOWfuuehgOW5s+WPsOmDqCk=?=) Date: Fri, 19 Aug 2016 07:27:59 +0000 Subject: [Haskell-cafe] [ANN] mysql-haskell 0.2.0.0 Message-ID: Hi all, I'm happy to announce mysql-haskell, a pure haskell mysql driver, is now available on package: https://github.com/winterland1989/mysql-haskell https://github.com/winterland1989/mysql-haskell The github page lists the motivation for creating this library, which are * prepared statment and binary protocol support. * better concurrency. * replication protocol support. All these targets are met. This release also includes quite complete tests and benchmarks, we think it’s stable enough to be used for pre-production environment, please fetch the code and testing, issues and bugs report are welcomed! Regards, Winterland at DIDI GROUP -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander at plaimi.net Fri Aug 19 13:08:39 2016 From: alexander at plaimi.net (Alexander Berntsen) Date: Fri, 19 Aug 2016 15:08:39 +0200 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: Message-ID: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 18/08/16 23:57, Mike Ledger wrote: > IMO: I've never seen a compelling use of this; I think it decreases > clarity, and barely shaves off any characters from equivalent "pointful" > expressions. I think it quite compelling. An example: asSeconds :: Hour h -> Minute m -> Second s -> Second t - -- | asSeconds take some 'TimeUnit's and convert them to 'Second's. asSeconds h m s = MkSecond $ 3600 * timeVal h + 60 * timeVal m + timeVal s hmsToDiffTime :: Hour h -> Minute m -> Second s -> DiffTime - -- | 'hmsToDiffTime' converts time of day in hours, minutes and seconds to the - -- time from midnight as a 'DiffTime'. hmsToDiffTime = (secondsToDiffTime . timeVal) .:. asSeconds As for putting it in base -- meh. I use the composition package, or define it myself. So I agree with Oleg; -1. - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXtwTXAAoJENQqWdRUGk8BP/UQAIcKzqVRhkVs0qtFDneTpSIi jLPPXMELbMnQe/ZQH2c5SaVM4+eDJIky33FEzrh9FWMeDftz1QFrsC+pPq+5/Esw U3h1HJrAJKl+zZ/bC1GQj9ObWKNROj3jEEt9pyNBcoHpxVnCohD3Y6Gx2LknE7m0 hnFlO0rCZZamk+pSeSlmLkkDM/MNxTx/FQcuZT0omxZtvzrz4cN7a069Gx35C+vr RK6NpiD5NUqTvMCL0zeI2yRpg2GV2PQcwV0CEWjLCsJYMcoeiF8+prSBdwzatgjH 7k1bHUdGwvcRzB74dyxIOPyHBgIDUFzj7bcE+NT0V20WXaz/Jgl73zZaIG9XtW19 aJ+RzW+aBSLEh8+uERc+Al9NpM9dLR94mDWIK/MZWEmlFHo8+W/md27+OxvM5BOr YCRpoQYeYDkepTAyRK2wRlszFXydDze8K6PMAq4DUE7xtUXofEbcodWA0quLxP4N ro2A8E4kqnO6BVD7iN+qch8TxmEiVYpqZnAjNz8eSyQCdn9UORpcMLT8yQ963nml 17yKRjHYDwg/g8EC1UjqJ9KwVFRhqQwdk//IupRyZ/5PPkEChy8t/ZjmmGKfLy0H CfhpRiNi0ozR+bYpUJcOdNM0ckCzgq5++9+M643RGjNWvD4fKDI8idNNn9eLlcom kaABFBC5Gbx2O6/rgpHc =X/Rb -----END PGP SIGNATURE----- From alexander at plaimi.net Fri Aug 19 13:15:40 2016 From: alexander at plaimi.net (Alexander Berntsen) Date: Fri, 19 Aug 2016 15:15:40 +0200 Subject: [Haskell-cafe] Rewrite without parenthesis In-Reply-To: <1e21ff5d-e010-7988-b6f6-6a16f7b769f2@cs.otago.ac.nz> References: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> <1e21ff5d-e010-7988-b6f6-6a16f7b769f2@cs.otago.ac.nz> Message-ID: <6414320c-efd7-1f34-f140-aeb3c57a6a93@plaimi.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 19/08/16 02:46, Richard A. O'Keefe wrote: >>> How do you rewrite head (tail [1,2,3]) without parenthesis. > s/parenthesis/parentheses/ head . tail $ [1, 2, 3] --) - -- Alexander alexander at plaimi.net https://secure.plaimi.net/~alexander -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJXtwZ7AAoJENQqWdRUGk8Bb00P/jhJoUQTh3dCCLqbJHGJm1+x Cvh+DOXMWoQyQcEvOh9u6DruqpnLRGgzcqDVzUOmqM2rwwkt7kznF7vzof5mCcXx UPb9W0X7OI6oMFmvg2Xp9gDxTcQinTfaLDyyKRZzRV5xj+On00xtso8SjriVh2HO ubzQLVs0kxt3irX+7orvz3JmHDiiVnfMVR6bC+TfJE7gnrIjtJH5jxkZP+Os10tC fHOEa0jhRY8E8BR9nbzOhcw2/3HZeQLSek3MIFxvAtgyYT67JprJwKwLbslGHcKV YS7kHL8BEOb+rJbIi3RHyVNwSnYi0hc0WkwrQo4CI7yr2HloAwewMuMPwMHjmNRS CAmWry4lVO+NFAaRnnVCLkXqxUjOKeIs3D5Fin0DTxgfetp245RuHuYiMTiGV/yf 0eSX2QjPf4sNFutOHbUdgwmyLwZJRUFxgdOt2cYQ/keRPSdARjG8vf83rriBqCkB QNbQgC3M1w8zQ4sSeHvQUtYHAPBjyj8JHpQ1yFfy8g3DNyr7950IXalGPHNwvqZJ HGILbKJfMb+bB0n0/9rzsFz8gdXKt/9JvysYEg6VP4TWUaNIhSNoKLGXQsNYLFMB QFYN+byKb4JQVnPT8ojRS7btBcs3m9oAfiu2d+4rK6z9x31TjPMNiQUcNp8Vlmvb Tb9wd51A4uJARO/eja3O =UMCW -----END PGP SIGNATURE----- From i.caught.air at gmail.com Fri Aug 19 14:51:54 2016 From: i.caught.air at gmail.com (Alex Belanger) Date: Fri, 19 Aug 2016 10:51:54 -0400 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> Message-ID: I didn't even know about the composition package. I just wanted it to be readily available to everyone. A quick look, `composition` seems really nice and is probably more aligned with Haskell ecosystem's philosophy of keeping base to what is only stricly needed by GHC. These were some valuable feedback. I think I got my answer and we can let the thread die (: Much appreciated, Alex On Aug 19, 2016 9:08 AM, "Alexander Berntsen" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 18/08/16 23:57, Mike Ledger wrote: > > IMO: I've never seen a compelling use of this; I think it decreases > > clarity, and barely shaves off any characters from equivalent "pointful" > > expressions. > > I think it quite compelling. An example: > > asSeconds :: Hour h -> Minute m -> Second s -> Second t > - -- | asSeconds take some 'TimeUnit's and convert them to 'Second's. > asSeconds h m s = MkSecond $ 3600 * timeVal h + 60 * timeVal m + timeVal s > > hmsToDiffTime :: Hour h -> Minute m -> Second s -> DiffTime > - -- | 'hmsToDiffTime' converts time of day in hours, minutes and seconds > to the > - -- time from midnight as a 'DiffTime'. > hmsToDiffTime = (secondsToDiffTime . timeVal) .:. asSeconds > > > As for putting it in base -- meh. I use the composition package, or > define it myself. So I agree with Oleg; -1. > - -- > Alexander > alexander at plaimi.net > https://secure.plaimi.net/~alexander > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCgAGBQJXtwTXAAoJENQqWdRUGk8BP/UQAIcKzqVRhkVs0qtFDneTpSIi > jLPPXMELbMnQe/ZQH2c5SaVM4+eDJIky33FEzrh9FWMeDftz1QFrsC+pPq+5/Esw > U3h1HJrAJKl+zZ/bC1GQj9ObWKNROj3jEEt9pyNBcoHpxVnCohD3Y6Gx2LknE7m0 > hnFlO0rCZZamk+pSeSlmLkkDM/MNxTx/FQcuZT0omxZtvzrz4cN7a069Gx35C+vr > RK6NpiD5NUqTvMCL0zeI2yRpg2GV2PQcwV0CEWjLCsJYMcoeiF8+prSBdwzatgjH > 7k1bHUdGwvcRzB74dyxIOPyHBgIDUFzj7bcE+NT0V20WXaz/Jgl73zZaIG9XtW19 > aJ+RzW+aBSLEh8+uERc+Al9NpM9dLR94mDWIK/MZWEmlFHo8+W/md27+OxvM5BOr > YCRpoQYeYDkepTAyRK2wRlszFXydDze8K6PMAq4DUE7xtUXofEbcodWA0quLxP4N > ro2A8E4kqnO6BVD7iN+qch8TxmEiVYpqZnAjNz8eSyQCdn9UORpcMLT8yQ963nml > 17yKRjHYDwg/g8EC1UjqJ9KwVFRhqQwdk//IupRyZ/5PPkEChy8t/ZjmmGKfLy0H > CfhpRiNi0ozR+bYpUJcOdNM0ckCzgq5++9+M643RGjNWvD4fKDI8idNNn9eLlcom > kaABFBC5Gbx2O6/rgpHc > =X/Rb > -----END PGP SIGNATURE----- > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paolo.veronelli at gmail.com Fri Aug 19 15:49:30 2016 From: paolo.veronelli at gmail.com (Paolino) Date: Fri, 19 Aug 2016 17:49:30 +0200 Subject: [Haskell-cafe] ordering of structured values Message-ID: Hello Cafè, I'd like to share a piece of code I've found useful to nest ordering on EQ. {-# language GADTs #-} import Data.Monoid (mconcat) import Data.Ord (comparing) data Orderings t where Ascending :: Ord a => (t -> a) -> Orderings t Descending :: Ord a => (t -> a) -> Orderings t comparings :: [Orderings t] -> t -> t -> Ordering comparings c x y = mconcat $ map g c where g (Ascending f) = comparing f x y g (Descending f) = comparing f y x I couldn't find a simpler solution, maybe somebody else has one. I've tried using comparings :: [forall a. Ord a => t -> a] -> t -> t -> Ordering which is not compiling for impredicativity and I'd like to understand better. An example on sorting (Ord a, Ord b, Ord c) => [(a,(b,c)] with 'a' in opposite order, then 'c' and 'b' in ascending order goes like sortBy (comparings [Descending fst, Ascending $ snd . snd, Ascending $ fst . snd]) Thanks for help/comments paolino -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri Aug 19 15:54:52 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 19 Aug 2016 16:54:52 +0100 Subject: [Haskell-cafe] ordering of structured values In-Reply-To: References: Message-ID: <20160819155452.GH21438@weber> On Fri, Aug 19, 2016 at 05:49:30PM +0200, Paolino wrote: > An example on sorting (Ord a, Ord b, Ord c) => [(a,(b,c)] with 'a' in > opposite order, then 'c' and 'b' in ascending order goes like > > sortBy (comparings [Descending fst, Ascending $ snd . snd, Ascending $ fst > . snd]) The answer is: Yes! Haskell can do that: sortBy (flip (comparing fst) <> comparing (snd . snd) <> comparing (fst . snd)) :: (Ord a, Ord b, Ord a1) => [(a, (a1, b))] -> [(a, (a1, b))] From paolo.veronelli at gmail.com Fri Aug 19 16:16:14 2016 From: paolo.veronelli at gmail.com (Paolino) Date: Fri, 19 Aug 2016 18:16:14 +0200 Subject: [Haskell-cafe] ordering of structured values In-Reply-To: <20160819155452.GH21438@weber> References: <20160819155452.GH21438@weber> Message-ID: That was easy, thank you ! paolino 2016-08-19 17:54 GMT+02:00 Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>: > On Fri, Aug 19, 2016 at 05:49:30PM +0200, Paolino wrote: > > An example on sorting (Ord a, Ord b, Ord c) => [(a,(b,c)] with 'a' in > > opposite order, then 'c' and 'b' in ascending order goes like > > > > sortBy (comparings [Descending fst, Ascending $ snd . snd, Ascending $ > fst > > . snd]) > > The answer is: Yes! Haskell can do that: > > sortBy (flip (comparing fst) > <> comparing (snd . snd) > <> comparing (fst . snd)) > > :: (Ord a, Ord b, Ord a1) => [(a, (a1, b))] -> [(a, (a1, b))] > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanuki at gmail.com Fri Aug 19 18:16:59 2016 From: tanuki at gmail.com (Theodore Lief Gannon) Date: Fri, 19 Aug 2016 11:16:59 -0700 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> Message-ID: Well... there's that rather worrisome introductory paragraph of the Data.Composition docs, though: "This module is for convenience and demonstrative purposes more than it is for providing actual value. I do not recommend that you rely on this module for performance-sensitive code. Because this module is not based on Prelude's (.), some chances at optimization might be missed by your compiler." On Fri, Aug 19, 2016 at 7:51 AM, Alex Belanger wrote: > I didn't even know about the composition package. I just wanted it to be > readily available to everyone. > > A quick look, `composition` seems really nice and is probably more aligned > with Haskell ecosystem's philosophy of keeping base to what is only stricly > needed by GHC. > > These were some valuable feedback. I think I got my answer and we can let > the thread die (: > > Much appreciated, > Alex > > On Aug 19, 2016 9:08 AM, "Alexander Berntsen" > wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 18/08/16 23:57, Mike Ledger wrote: >> > IMO: I've never seen a compelling use of this; I think it decreases >> > clarity, and barely shaves off any characters from equivalent "pointful" >> > expressions. >> >> I think it quite compelling. An example: >> >> asSeconds :: Hour h -> Minute m -> Second s -> Second t >> - -- | asSeconds take some 'TimeUnit's and convert them to 'Second's. >> asSeconds h m s = MkSecond $ 3600 * timeVal h + 60 * timeVal m + timeVal s >> >> hmsToDiffTime :: Hour h -> Minute m -> Second s -> DiffTime >> - -- | 'hmsToDiffTime' converts time of day in hours, minutes and seconds >> to the >> - -- time from midnight as a 'DiffTime'. >> hmsToDiffTime = (secondsToDiffTime . timeVal) .:. asSeconds >> >> >> As for putting it in base -- meh. I use the composition package, or >> define it myself. So I agree with Oleg; -1. >> - -- >> Alexander >> alexander at plaimi.net >> https://secure.plaimi.net/~alexander >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBCgAGBQJXtwTXAAoJENQqWdRUGk8BP/UQAIcKzqVRhkVs0qtFDneTpSIi >> jLPPXMELbMnQe/ZQH2c5SaVM4+eDJIky33FEzrh9FWMeDftz1QFrsC+pPq+5/Esw >> U3h1HJrAJKl+zZ/bC1GQj9ObWKNROj3jEEt9pyNBcoHpxVnCohD3Y6Gx2LknE7m0 >> hnFlO0rCZZamk+pSeSlmLkkDM/MNxTx/FQcuZT0omxZtvzrz4cN7a069Gx35C+vr >> RK6NpiD5NUqTvMCL0zeI2yRpg2GV2PQcwV0CEWjLCsJYMcoeiF8+prSBdwzatgjH >> 7k1bHUdGwvcRzB74dyxIOPyHBgIDUFzj7bcE+NT0V20WXaz/Jgl73zZaIG9XtW19 >> aJ+RzW+aBSLEh8+uERc+Al9NpM9dLR94mDWIK/MZWEmlFHo8+W/md27+OxvM5BOr >> YCRpoQYeYDkepTAyRK2wRlszFXydDze8K6PMAq4DUE7xtUXofEbcodWA0quLxP4N >> ro2A8E4kqnO6BVD7iN+qch8TxmEiVYpqZnAjNz8eSyQCdn9UORpcMLT8yQ963nml >> 17yKRjHYDwg/g8EC1UjqJ9KwVFRhqQwdk//IupRyZ/5PPkEChy8t/ZjmmGKfLy0H >> CfhpRiNi0ozR+bYpUJcOdNM0ckCzgq5++9+M643RGjNWvD4fKDI8idNNn9eLlcom >> kaABFBC5Gbx2O6/rgpHc >> =X/Rb >> -----END PGP SIGNATURE----- >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Fri Aug 19 18:50:44 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 19 Aug 2016 14:50:44 -0400 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> Message-ID: <1471632644.3428.14.camel@joachim-breitner.de> Hi, Am Freitag, den 19.08.2016, 11:16 -0700 schrieb Theodore Lief Gannon: > Well... there's that rather worrisome introductory paragraph of the > Data.Composition docs, though: > > "This module is for convenience and demonstrative purposes more than > it is for providing actual value. I do not recommend that you rely on > this module for performance-sensitive code. Because this module is > not based on Prelude's (.), some chances at optimization might be > missed by your compiler." I wonder if that is really something to worry about. Prelude’s (.) is not special in any way: -- | Function composition. {-# INLINE (.) #-} -- Make sure it has TWO args only on the left, so that it inlines -- when applied to two functions, even if there is no final argument (.)    :: (b -> c) -> (a -> b) -> a -> c (.) f g = \x -> f (g x) The INLINE pragma and the definition with the right arity could be used in Data.Composition as well, and it would yield the same results. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From dave at zednenem.com Sat Aug 20 02:38:19 2016 From: dave at zednenem.com (David Menendez) Date: Fri, 19 Aug 2016 22:38:19 -0400 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: <1471632644.3428.14.camel@joachim-breitner.de> References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> <1471632644.3428.14.camel@joachim-breitner.de> Message-ID: On Fri, Aug 19, 2016 at 2:50 PM, Joachim Breitner wrote: > Hi, > > Am Freitag, den 19.08.2016, 11:16 -0700 schrieb Theodore Lief Gannon: > > Well... there's that rather worrisome introductory paragraph of the > > Data.Composition docs, though: > > > > "This module is for convenience and demonstrative purposes more than > > it is for providing actual value. I do not recommend that you rely on > > this module for performance-sensitive code. Because this module is > > not based on Prelude's (.), some chances at optimization might be > > missed by your compiler." > > I wonder if that is really something to worry about. Prelude’s (.) is > not special in any way: > The INLINE pragma and the definition with the right arity could be used > in Data.Composition as well, and it would yield the same results. > Any RULEs involving Prelude’s (.) would need to be copied as well. -- Dave Menendez -------------- next part -------------- An HTML attachment was scrubbed... URL: From ak3ntev at gmail.com Sat Aug 20 16:51:26 2016 From: ak3ntev at gmail.com (Eugene Akentyev) Date: Sat, 20 Aug 2016 19:51:26 +0300 Subject: [Haskell-cafe] GHC-related project for undergraduate thesis Message-ID: Hello, I am an undergraduate student and would like to do something useful for GHC as undergraduate thesis. This list https://ghc.haskell.org/trac/ghc/wiki/ProjectSuggestions is outdated (last modified 6 years ago) and some projects are already done (?). Do you have any ideas/projects? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Sat Aug 20 17:29:37 2016 From: david.feuer at gmail.com (David Feuer) Date: Sat, 20 Aug 2016 13:29:37 -0400 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> <1471632644.3428.14.camel@joachim-breitner.de> Message-ID: On Fri, Aug 19, 2016 at 10:38 PM, David Menendez wrote: > Any RULEs involving Prelude’s (.) would need to be copied as well. There aren't any, and if there are any then they're almost certainly broken. The INLINE pragma on (.) isn't marked with a simplifier phase, so it will be inlined almost immediately when optimization begins, as long as it has at least two arguments. There is no time for rules involving it to take effect. Rewrite rules end up working with the inlined version. For example, Data.Sequence has a rule saying forall f g xs . fmapSeq f (fmapSeq g xs) = fmapSeq (f . g) xs So if you write fmap f . fmap g for sequences, this will specialize to fmapSeq f . fmapSeq g and inline to \xs -> fmapSeq f (fmapSeq g xs) at which point the rewrite rule will fire, changing it to \xs -> fmapSeq (f . g) xs This, in turn, will inline as well, to \xs -> fmapSeq (\x -> f (g x)) xs From harendra.kumar at gmail.com Sat Aug 20 18:27:56 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Sat, 20 Aug 2016 23:57:56 +0530 Subject: [Haskell-cafe] Using stringize and string concatenation in ghc preprocessing Message-ID: Hi, To reduce boilerplate code in an FFI implementation file I am trying to use the stringizing and string concatenation features of the C preprocessor. Since ghc passes '-traditional' to the preprocessor which disables these features I thought I can pass my own flags to the preprocessor like this: {-# OPTIONS_GHC -optP -E -optP -undef #-} But "-optP" seems to only append to the flags that GHC already passes and gcc has no "-no-traditional" option to undo the effect of the "-traditional" that GHC has already passed. I think "-optP" should override the flags passed by ghc rather than appending to them. Is there a reason not to do that? Is there any other better way to achieve this? What is the standard way of doing this if any? -harendra -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmperson1 at gmail.com Sat Aug 20 19:22:46 2016 From: hmperson1 at gmail.com (HMPerson1) Date: Sat, 20 Aug 2016 19:22:46 +0000 Subject: [Haskell-cafe] Build error with llvm-general and lens In-Reply-To: References: Message-ID: If I have a file > module Lib where > import Control.Lens > data Foo = Foo { _x :: Int , _y :: Int } > makeLenses ''Foo and I compile with `stack build`, it works fine. But if I add `llvm-general` to build-depends, and I run `stack build`, I get > [1 of 1] Compiling Lib ( Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Lib.o ) > : can't load .so/.DLL for: /usr/lib/libcurses.so (-lncursesw: cannot open shared object file: No such file or directory) > > -- While building package bug-test-0.1.0.0 using: > /home/user/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.5.0 build lib:bug-test --ghc-options " -ddump-hi -ddump-to-file" > Process exited with code: ExitFailure 1 I've made a tiny test case here: https://git.io/v6MVv If I symlink `/usr/lub/libcurses.so` to `/usr/lub/libncursesw.so` (as suggested at https://git.io/v6MV8 and https://ghc.haskell.org/trac/ghc/ticket/9237), I get > [1 of 1] Compiling Lib ( Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Lib.o ) > > -- While building package bug-test-0.1.0.0 using: > /home/user/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.22.5.0-ghc-7.10.3 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.5.0 build lib:bug-test --ghc-options " -ddump-hi -ddump-to-file" > Process exited with code: ExitFailure (-11) (There's no "can't load..." line and the exit code is different) As a workaround, I can separate the lens instances into a separate library, but I would like to avoid doing so if possible. How can I fix this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sat Aug 20 19:51:37 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 20 Aug 2016 15:51:37 -0400 Subject: [Haskell-cafe] Build error with llvm-general and lens In-Reply-To: References: Message-ID: On Sat, Aug 20, 2016 at 3:22 PM, HMPerson1 wrote: > > Process exited with code: ExitFailure (-11) Uhhh... that looks like you managed to segfault ghc. What version of ghc is this? (And what version of stack? I think newer ones report this slightly better.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hmperson1 at gmail.com Sat Aug 20 20:03:00 2016 From: hmperson1 at gmail.com (HMPerson1) Date: Sat, 20 Aug 2016 20:03:00 +0000 Subject: [Haskell-cafe] Build error with llvm-general and lens In-Reply-To: References: Message-ID: On Sat, Aug 20, 2016 at 3:51 PM Brandon Allbery wrote: > On Sat, Aug 20, 2016 at 3:22 PM, HMPerson1 wrote: > >> > Process exited with code: ExitFailure (-11) > > > Uhhh... that looks like you managed to segfault ghc. What version of ghc > is this? (And what version of stack? I think newer ones report this > slightly better.) > $ stack --version Version 1.1.2 x86_64 hpack-0.14.1 $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 -------------- next part -------------- An HTML attachment was scrubbed... URL: From codygman.consulting at gmail.com Sun Aug 21 19:16:38 2016 From: codygman.consulting at gmail.com (Cody Goodman) Date: Sun, 21 Aug 2016 14:16:38 -0500 Subject: [Haskell-cafe] How can I generalize my innerJoinOnId function to innerJoin with Vinyl? Message-ID: Hello all! I'll get right to it. As a first step I'd like to generalize innerJoinOnId's type signature to something like: innerJoinOnId :: (Id ∈ fields, Id ∈ fields2, Id ∈ fields2) => [Rec Attr fields] -> [Rec Attr fields2] -> [Rec Attr fields3] Or if possible: innerJoinOnId :: (Id ∈ fields) => [Rec Attr fields] -> [Rec Attr fields] -> [Rec Attr fields] As a next step I'd like to create an innerJoin function with type: innerJoinOn :: (a ∈ fields) => [Rec Attr fields] -> [Rec Attr fields] -> [Rec Attr fields] Where a is supplied and that constraint is carried on to the other inputs. Is this possible in Haskell? Here is both a link and the text of my (working, compilable) code thus far. Link: https://github.com/codygman/vinyl-experiments/blob/master/src/Main.hs Source code: {-# LANGUAGE DataKinds, PolyKinds, TypeOperators, TypeFamilies, FlexibleContexts, FlexibleInstances, NoMonomorphismRestriction, GADTs, TypeSynonymInstances, TemplateHaskell, StandaloneDeriving #-} module Main where import Data.Vinyl import Control.Lens hiding (Identity) import Data.Singletons.TH import Data.Maybe import Control.Monad import Data.Vinyl.TypeLevel (RIndex) data Fields = Id | Name | Age | ActivityName deriving Show type Person = ['Id, 'Name, 'Age] type Activity = ['Id, 'ActivityName] type family ElF (f :: Fields) :: * where ElF 'Id = Int ElF 'Name = String ElF 'Age = Int ElF 'ActivityName = String newtype Attr f = Attr { _unAttr :: ElF f } makeLenses ''Attr genSingletons [ ''Fields ] instance Show (Attr 'Id) where show (Attr x) = "id: " ++ show x instance Show (Attr 'Name) where show (Attr x) = "name: " ++ show x instance Show (Attr 'Age) where show (Attr x) = "age: " ++ show x instance Show (Attr 'ActivityName) where show (Attr x) = "activity: " ++ x (=::) :: sing f -> ElF f -> Attr f _ =:: x = Attr x joy :: Rec Attr ['Id, 'Name, 'Age] joy = (SId =:: 1) :& (SName =:: "Joy") :& (SAge =:: 28) :& RNil jon :: Rec Attr ['Id, 'Name, 'Age] jon = (SId =:: 0) :& (SName =:: "Jon") :& (SAge =:: 23) :& RNil karen :: Rec Attr ['Id, 'Name, 'Age] karen = (SId =:: 2) :& (SName =:: "Karen") :& (SAge =:: 15) :& RNil jonFootball :: Rec Attr ['Id, 'ActivityName] jonFootball = (SId =:: 0) :& (SActivityName =:: "football") :& RNil jonDancing :: Rec Attr ['Id, 'ActivityName] jonDancing = (SId =:: 0) :& (SActivityName =:: "dancing") :& RNil joyRacing :: Rec Attr ['Id, 'ActivityName] joyRacing = (SId =:: 1) :& (SActivityName =:: "racing") :& RNil peopleRows :: [Rec Attr ['Id, 'Name, 'Age]] peopleRows = [joy, jon, karen] activitieRows :: [Rec Attr ['Id, 'ActivityName]] activitieRows = [jonFootball, jonDancing, joyRacing] printActvy :: ('ActivityName ∈ fields) => Rec Attr fields -> IO () printActvy r = print (r ^. rlens SActivityName) isInPplIdx :: ('Id ∈ fields) => [Int] -> Rec Attr fields -> Bool isInPplIdx peopleIdx actvyRow = any (== True) . map (== actvyIdInt) $ peopleIdx where actvyIdInt = actvyRow ^. rlens SId . unAttr mkJoinedRow :: (Eq (ElF r1), RElem r1 ['Id, 'Name, 'Age] (RIndex r1 ['Id, 'Name, 'Age]), RElem r1 ['Id, 'ActivityName] (RIndex r1 ['Id, 'ActivityName]), ElF r1 ~ Int) => sing1 r1 -> [Rec Attr ['Id, 'ActivityName]] -> Rec Attr ['Id, 'Name, 'Age] -> [Rec Attr ['Id, 'Name, 'Age, 'ActivityName]] -- mkJoinedRow :: _ -> [Rec Attr ['Id, 'ActivityName]] -> Rec Attr ['Id, 'Name, 'Age] -> [Rec Attr ['Id, 'Name, 'Age, 'ActivityName]] mkJoinedRow field activities person = do let name = person ^. rlens SName . unAttr age = person ^. rlens SAge . unAttr let filteredActivities = filter (\r -> r ^. rlens field . unAttr == person ^. rlens field . unAttr) activities case listToMaybe filteredActivities of Just _ -> do let activityId actvy = actvy ^. rlens field . unAttr activityName actvy = actvy ^. rlens SActivityName . unAttr (\actvy -> (SId =:: activityId actvy) :& (SName =:: name) :& (SAge =:: age) :& (SActivityName =:: activityName actvy) :& RNil) <$> filteredActivities Nothing -> [] innerJoinOnId :: [Rec Attr ['Id, 'Name, 'Age]] -> [Rec Attr ['Id, 'ActivityName]] -> [Rec Attr ['Id, 'Name, 'Age, 'ActivityName]] innerJoinOnId people activities = do let peopleIdx =(\r -> r ^. rlens SId . unAttr) <$> people let filteredActivites = filter (isInPplIdx peopleIdx) activities join $ map (\p -> mkJoinedRow SId filteredActivites p) people main :: IO () main = mapM_ print $ innerJoinOnId peopleRows activitieRows -- example of main running: -- λ> peopleRows -- [{id: 1, name: "Joy", age: 28},{id: 0, name: "Jon", age: 23},{id: 2, name: "Karen", age: 15}] -- λ> activitieRows -- [{id: 0, activity: football},{id: 0, activity: dancing},{id: 1, activity: racing}] -- λ> main -- {id: 1, name: "Joy", age: 28, activity: racing} -- {id: 0, name: "Jon", age: 23, activity: football} -- {id: 0, name: "Jon", age: 23, activity: dancing} -- Code I wish worked: -- λ> mapM_ print $ innerJoinOn SId peopleRows activitieRows -- λ> mapM_ print $ innerJoinOn SName peopleRows activitieRows -- this line would give a compiler error about activitiesRows not containing 'Name -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnusbakken at gmail.com Sun Aug 21 19:38:00 2016 From: magnusbakken at gmail.com (Magnus Grindal Bakken) Date: Sun, 21 Aug 2016 21:38:00 +0200 Subject: [Haskell-cafe] Using MonadRandom with QuickCheck Message-ID: Is there some easy way to use the Gen type from QuickCheck with the MonadRandom class? Links to the packages in question: https://hackage.haskell.org/package/MonadRandom https://hackage.haskell.org/package/QuickCheck Some background in case there's an easier way to solve the problem: I'm toying around with an API for a simple turn-based board game. The main type in my API is called GameState, and I'm trying to define an Arbitrary instance for it so I can set up invariants with QuickCheck. The Arbitrary instance should produce game states that are the result of playing a random number of random moves. At certain points in the gameplay the game itself needs to invoke some randomness. I've designed the public game API to have basically just two functions: playAction :: ActionData -> GameState -> GameState evaluateGameState :: MonadRandom m => GameState -> m GameState The usage is supposed to be that the client first calls playAction with an ActionData value that depends on the current move, and afterwards calls evaluateGameState to evaluate whatever random events need to happen at that point (e.g. reshuffling a deck of cards). That way my main "action" logic doesn't need to concern itself with any form of randomness. I'm using MonadRandom from Control.Monad.Random because it seems like a much nicer way to generate random numbers than using RandomGen directly. However I can't figure out how to make it play nice with QuickCheck. I can easily set up my Arbitrary instance to call playAction an arbitrary number of times, but I can't call evaluateGameState since it lives in the other monad. It would work if Gen were an instance of MonadRandom, but I can't quite work out how to write that instance since most functions on Gen only work if the output type is an instance of Arbitrary, while MonadRandom needs to work with any types that are part of the Random class. This part works: instance MonadRandom Gen where getRandomR = choose But I don't know how to define the other functions on MonadRandom for Gen. I think I might also be able to use the PropertyM monad transformer: https://hackage.haskell.org/package/QuickCheck-2.9.1/docs/Test-QuickCheck-Monadic.html, but monad transformers always confuse me so I haven't been able to figure out how to do that yet either. I've thought about rewriting the API to use the Gen type instead of MonadRandom, but it feels kind of iffy to have the API depend on a testing library. Has anyone tried to use these libraries together before? From codygman.consulting at gmail.com Sun Aug 21 19:56:21 2016 From: codygman.consulting at gmail.com (Cody Goodman) Date: Sun, 21 Aug 2016 14:56:21 -0500 Subject: [Haskell-cafe] How can I generalize my innerJoinOnId function to innerJoin with Vinyl? In-Reply-To: References: Message-ID: I've since generalized a good bit, though I'm not sure what approach to take with mkJoinedRow. Link: https://github.com/codygman/vinyl-experiments/blob/master/src/Main.hs code: {-# LANGUAGE ConstraintKinds, PartialTypeSignatures #-} {-# LANGUAGE DataKinds, PolyKinds, TypeOperators, TypeFamilies, FlexibleContexts, FlexibleInstances#-} {-# LANGUAGE NoMonomorphismRestriction, GADTs, TypeSynonymInstances, TemplateHaskell, StandaloneDeriving #-} {-# LANGUAGE TypeOperators, ScopedTypeVariables, DeriveDataTypeable, KindSignatures #-} module Main where import Data.Vinyl import Control.Lens hiding (Identity) import Data.Singletons.TH import Data.Maybe import Control.Monad import Data.Vinyl.TypeLevel (RIndex) import Data.Typeable import GHC.Exts (Constraint) -- TODO might end up going this route -- type JoinOn a fields = (a ∈ fields) data Fields = Id | Name | Age | ActivityName deriving Show type Person = ['Id, 'Name, 'Age] type Activity = ['Id, 'ActivityName] type family ElF (f :: Fields) :: * where ElF 'Id = Int ElF 'Name = String ElF 'Age = Int ElF 'ActivityName = String newtype Attr f = Attr { _unAttr :: ElF f } makeLenses ''Attr genSingletons [ ''Fields ] instance Show (Attr 'Id) where show (Attr x) = "id: " ++ show x instance Show (Attr 'Name) where show (Attr x) = "name: " ++ show x instance Show (Attr 'Age) where show (Attr x) = "age: " ++ show x instance Show (Attr 'ActivityName) where show (Attr x) = "activity: " ++ x (=::) :: sing f -> ElF f -> Attr f _ =:: x = Attr x joy :: Rec Attr ['Id, 'Name, 'Age] joy = (SId =:: 1) :& (SName =:: "Joy") :& (SAge =:: 28) :& RNil jon :: Rec Attr ['Id, 'Name, 'Age] jon = (SId =:: 0) :& (SName =:: "Jon") :& (SAge =:: 23) :& RNil karen :: Rec Attr ['Id, 'Name, 'Age] karen = (SId =:: 2) :& (SName =:: "Karen") :& (SAge =:: 15) :& RNil jonFootball :: Rec Attr ['Id, 'ActivityName] jonFootball = (SId =:: 0) :& (SActivityName =:: "football") :& RNil jonDancing :: Rec Attr ['Id, 'ActivityName] jonDancing = (SId =:: 0) :& (SActivityName =:: "dancing") :& RNil joyRacing :: Rec Attr ['Id, 'ActivityName] joyRacing = (SId =:: 1) :& (SActivityName =:: "racing") :& RNil peopleRows :: [Rec Attr ['Id, 'Name, 'Age]] peopleRows = [joy, jon, karen] activitieRows :: [Rec Attr ['Id, 'ActivityName]] activitieRows = [jonFootball, jonDancing, joyRacing] printActvy :: ('ActivityName ∈ fields) => Rec Attr fields -> IO () printActvy r = print (r ^. rlens SActivityName) -- TODO leave these as Attr's to compare so compariso works in the general case isInIdx field leftIdx rightRow = any (== True) . map (== unAttrRightRow) $ leftIdx where unAttrRightRow = rightRow ^. rlens field . unAttr -- TODO generalize mkJoinedRow if possible or require a typeclass instance of mkJoinedRow -- TODO maybe we can just append fields or something mkJoinedRow field activities person = do let name = person ^. rlens SName . unAttr age = person ^. rlens SAge . unAttr let filteredActivities = filter (\r -> r ^. rlens field . unAttr == person ^. rlens field . unAttr) activities case listToMaybe filteredActivities of Just _ -> do let activityId actvy = actvy ^. rlens field . unAttr activityName actvy = actvy ^. rlens SActivityName . unAttr (\actvy -> (SId =:: activityId actvy) :& (SName =:: name) :& (SAge =:: age) :& (SActivityName =:: activityName actvy) :& RNil) <$> filteredActivities Nothing -> [] innerJoinOn field people activities = do let peopleIdx =(\r -> r ^. rlens field . unAttr) <$> people let filteredActivites = filter (isInIdx field peopleIdx) activities join $ map (\p -> mkJoinedRow field filteredActivites p) people main :: IO () main = mapM_ print $ innerJoinOn SId peopleRows activitieRows -- example of main running: -- λ> peopleRows -- [{id: 1, name: "Joy", age: 28},{id: 0, name: "Jon", age: 23},{id: 2, name: "Karen", age: 15}] -- λ> activitieRows -- [{id: 0, activity: football},{id: 0, activity: dancing},{id: 1, activity: racing}] -- λ> mapM_ print $ innerJoinOn SId peopleRows activitieRows -- {id: 1, name: "Joy", age: 28, activity: racing} -- {id: 0, name: "Jon", age: 23, activity: football} -- {id: 0, name: "Jon", age: 23, activity: dancing} On Sun, Aug 21, 2016 at 2:16 PM, Cody Goodman wrote: > Hello all! I'll get right to it. > > As a first step I'd like to generalize innerJoinOnId's type signature to > something like: > > innerJoinOnId :: (Id ∈ fields, Id ∈ fields2, Id ∈ fields2) => [Rec Attr > fields] -> [Rec Attr fields2] -> [Rec Attr fields3] > > Or if possible: > > innerJoinOnId :: (Id ∈ fields) => [Rec Attr fields] -> [Rec Attr fields] > -> [Rec Attr fields] > > As a next step I'd like to create an innerJoin function with type: > > innerJoinOn :: (a ∈ fields) => [Rec Attr fields] -> [Rec Attr fields] -> > [Rec Attr fields] > > Where a is supplied and that constraint is carried on to the other inputs. > Is this possible in Haskell? > > Here is both a link and the text of my (working, compilable) code thus far. > > Link: https://github.com/codygman/vinyl-experiments/blob/master/ > src/Main.hs > > Source code: > > {-# LANGUAGE DataKinds, PolyKinds, TypeOperators, TypeFamilies, > FlexibleContexts, FlexibleInstances, NoMonomorphismRestriction, GADTs, > TypeSynonymInstances, TemplateHaskell, StandaloneDeriving #-} > > module Main where > > import Data.Vinyl > import Control.Lens hiding (Identity) > import Data.Singletons.TH > import Data.Maybe > import Control.Monad > import Data.Vinyl.TypeLevel (RIndex) > > data Fields = Id | Name | Age | ActivityName deriving Show > > type Person = ['Id, 'Name, 'Age] > type Activity = ['Id, 'ActivityName] > > type family ElF (f :: Fields) :: * where > ElF 'Id = Int > ElF 'Name = String > ElF 'Age = Int > ElF 'ActivityName = String > > newtype Attr f = Attr { _unAttr :: ElF f } > makeLenses ''Attr > genSingletons [ ''Fields ] > instance Show (Attr 'Id) where show (Attr x) = "id: " ++ show x > instance Show (Attr 'Name) where show (Attr x) = "name: " ++ show x > instance Show (Attr 'Age) where show (Attr x) = "age: " ++ show x > instance Show (Attr 'ActivityName) where show (Attr x) = "activity: " ++ x > > (=::) :: sing f -> ElF f -> Attr f > _ =:: x = Attr x > > joy :: Rec Attr ['Id, 'Name, 'Age] > joy = (SId =:: 1) > :& (SName =:: "Joy") > :& (SAge =:: 28) > :& RNil > jon :: Rec Attr ['Id, 'Name, 'Age] > jon = (SId =:: 0) > :& (SName =:: "Jon") > :& (SAge =:: 23) > :& RNil > > karen :: Rec Attr ['Id, 'Name, 'Age] > karen = (SId =:: 2) > :& (SName =:: "Karen") > :& (SAge =:: 15) > :& RNil > > jonFootball :: Rec Attr ['Id, 'ActivityName] > jonFootball = (SId =:: 0) > :& (SActivityName =:: "football") > :& RNil > > jonDancing :: Rec Attr ['Id, 'ActivityName] > jonDancing = (SId =:: 0) > :& (SActivityName =:: "dancing") > :& RNil > > joyRacing :: Rec Attr ['Id, 'ActivityName] > joyRacing = (SId =:: 1) > :& (SActivityName =:: "racing") > :& RNil > > peopleRows :: [Rec Attr ['Id, 'Name, 'Age]] > peopleRows = [joy, jon, karen] > > activitieRows :: [Rec Attr ['Id, 'ActivityName]] > activitieRows = [jonFootball, jonDancing, joyRacing] > > printActvy :: ('ActivityName ∈ fields) => Rec Attr fields -> IO () > printActvy r = print (r ^. rlens SActivityName) > > isInPplIdx :: ('Id ∈ fields) => [Int] -> Rec Attr fields -> Bool > isInPplIdx peopleIdx actvyRow = any (== True) . map (== actvyIdInt) $ > peopleIdx > where actvyIdInt = actvyRow ^. rlens SId . unAttr > > > mkJoinedRow :: (Eq (ElF r1), > RElem > r1 > ['Id, 'Name, 'Age] > (RIndex r1 ['Id, 'Name, 'Age]), > RElem > r1 > ['Id, 'ActivityName] > (RIndex r1 ['Id, 'ActivityName]), > ElF r1 ~ Int) => sing1 r1 -> [Rec Attr > ['Id, 'ActivityName]] -> Rec Attr ['Id, 'Name, 'Age] -> [Rec Attr ['Id, > 'Name, 'Age, 'ActivityName]] > -- mkJoinedRow :: _ -> [Rec Attr ['Id, 'ActivityName]] -> Rec Attr ['Id, > 'Name, 'Age] -> [Rec Attr ['Id, 'Name, 'Age, 'ActivityName]] > mkJoinedRow field activities person = do > let name = person ^. rlens SName . unAttr > age = person ^. rlens SAge . unAttr > > let filteredActivities = filter (\r -> r ^. rlens field . unAttr == > person ^. rlens field . unAttr) activities > case listToMaybe filteredActivities of > Just _ -> do > let activityId actvy = actvy ^. rlens field . unAttr > activityName actvy = actvy ^. rlens SActivityName . unAttr > (\actvy -> (SId =:: activityId actvy) :& (SName =:: name) :& (SAge > =:: age) :& (SActivityName =:: activityName actvy) :& RNil) <$> > filteredActivities > Nothing -> [] > > innerJoinOnId :: [Rec Attr ['Id, 'Name, 'Age]] -> [Rec Attr ['Id, > 'ActivityName]] -> [Rec Attr ['Id, 'Name, 'Age, 'ActivityName]] > innerJoinOnId people activities = do > let peopleIdx =(\r -> r ^. rlens SId . unAttr) <$> people > let filteredActivites = filter (isInPplIdx peopleIdx) activities > join $ map (\p -> mkJoinedRow SId filteredActivites p) people > > main :: IO () > main = mapM_ print $ innerJoinOnId peopleRows activitieRows > > -- example of main running: > -- λ> peopleRows > -- [{id: 1, name: "Joy", age: 28},{id: 0, name: "Jon", age: 23},{id: 2, > name: "Karen", age: 15}] > -- λ> activitieRows > -- [{id: 0, activity: football},{id: 0, activity: dancing},{id: 1, > activity: racing}] > -- λ> main > -- {id: 1, name: "Joy", age: 28, activity: racing} > -- {id: 0, name: "Jon", age: 23, activity: football} > -- {id: 0, name: "Jon", age: 23, activity: dancing} > > -- Code I wish worked: > > -- λ> mapM_ print $ innerJoinOn SId peopleRows activitieRows > -- λ> mapM_ print $ innerJoinOn SName peopleRows activitieRows -- this > line would give a compiler error about activitiesRows not containing 'Name > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From li-yao.xia at ens.fr Sun Aug 21 20:37:28 2016 From: li-yao.xia at ens.fr (Li-yao Xia) Date: Sun, 21 Aug 2016 22:37:28 +0200 Subject: [Haskell-cafe] Using MonadRandom with QuickCheck In-Reply-To: References: Message-ID: Hi Magnus, Import Test.QuickCheck.Gen to get the internals of Gen, which AFAIK is currently the only way to get to the underlying random generator (QCGen). getRandom = MkGen $ \g _ -> fst (random g) -- repeat with randomRs, randoms. I don't know why Gen is not an instance of MonadRandom either. It seems reasonable to add one, though it might go against some design principle of QuickCheck by ignoring the size parameter. Regards, Li-yao On 08/21/2016 09:38 PM, Magnus Grindal Bakken wrote: > Is there some easy way to use the Gen type from QuickCheck with the > MonadRandom class? > > Links to the packages in question: > https://hackage.haskell.org/package/MonadRandom > https://hackage.haskell.org/package/QuickCheck > > Some background in case there's an easier way to solve the problem: > I'm toying around with an API for a simple turn-based board game. The > main type in my API is called GameState, and I'm trying to define an > Arbitrary instance for it so I can set up invariants with QuickCheck. > The Arbitrary instance should produce game states that are the result > of playing a random number of random moves. > > At certain points in the gameplay the game itself needs to invoke some > randomness. I've designed the public game API to have basically just > two functions: > > playAction :: ActionData -> GameState -> GameState > evaluateGameState :: MonadRandom m => GameState -> m GameState > > The usage is supposed to be that the client first calls playAction > with an ActionData value that depends on the current move, and > afterwards calls evaluateGameState to evaluate whatever random events > need to happen at that point (e.g. reshuffling a deck of cards). That > way my main "action" logic doesn't need to concern itself with any > form of randomness. > > I'm using MonadRandom from Control.Monad.Random because it seems like > a much nicer way to generate random numbers than using RandomGen > directly. However I can't figure out how to make it play nice with > QuickCheck. I can easily set up my Arbitrary instance to call > playAction an arbitrary number of times, but I can't call > evaluateGameState since it lives in the other monad. It would work if > Gen were an instance of MonadRandom, but I can't quite work out how to > write that instance since most functions on Gen only work if the > output type is an instance of Arbitrary, while MonadRandom needs to > work with any types that are part of the Random class. This part > works: > > instance MonadRandom Gen where > getRandomR = choose > > But I don't know how to define the other functions on MonadRandom for Gen. > > I think I might also be able to use the PropertyM monad transformer: > https://hackage.haskell.org/package/QuickCheck-2.9.1/docs/Test-QuickCheck-Monadic.html, > but monad transformers always confuse me so I haven't been able to > figure out how to do that yet either. > > I've thought about rewriting the API to use the Gen type instead of > MonadRandom, but it feels kind of iffy to have the API depend on a > testing library. > > Has anyone tried to use these libraries together before? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > From allbery.b at gmail.com Sun Aug 21 20:52:21 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 21 Aug 2016 16:52:21 -0400 Subject: [Haskell-cafe] Using stringize and string concatenation in ghc preprocessing In-Reply-To: References: Message-ID: On Sun, Aug 21, 2016 at 4:31 PM, Boespflug, Mathieu wrote: > I ran into this very problem recently. Turns out -traditional knows string > concatenation too. I seem to remember learning this by browsing the GHC > source code, but now I can't find any occurrence of this pattern. But > here's an example of how to do string concatenation with CPP in > -traditional mode: https://github.com/tweag/sparkle/blob/ > a4e481aa5180b6ec93c219f827aefe932b66a953/inline-java/src/ > Foreign/JNI.hs#L274 > > . > That's the hacky K&R way I mentioned earlier. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at orlitzky.com Mon Aug 22 03:52:57 2016 From: michael at orlitzky.com (Michael Orlitzky) Date: Sun, 21 Aug 2016 23:52:57 -0400 Subject: [Haskell-cafe] Rewrite without parenthesis In-Reply-To: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> References: <88c9f2d3-739b-455d-9a7b-a2a350c51534@googlegroups.com> Message-ID: <57BA7719.2000800@orlitzky.com> On 08/18/2016 08:03 AM, Carl Petersen wrote: > How do you rewrite head (tail [1,2,3]) without parenthesis. > case [1,2,3] of x1:x2:xs -> Just x2; otherwise -> Nothing From harendra.kumar at gmail.com Mon Aug 22 05:51:49 2016 From: harendra.kumar at gmail.com (Harendra Kumar) Date: Mon, 22 Aug 2016 11:21:49 +0530 Subject: [Haskell-cafe] Using stringize and string concatenation in ghc preprocessing In-Reply-To: References: Message-ID: Thanks Mathieu. This works pretty well for gcc ( https://gcc.gnu.org/onlinedocs/cpp/Traditional-macros.html) but sadly it does not work for clang cpp as Brandon too pointed out earlier that clang does not have a traditional mode. -harendra On 22 August 2016 at 02:01, Boespflug, Mathieu wrote: > Hi Harendra, > > I ran into this very problem recently. Turns out -traditional knows string > concatenation too. I seem to remember learning this by browsing the GHC > source code, but now I can't find any occurrence of this pattern. But > here's an example of how to do string concatenation with CPP in > -traditional mode: https://github.com/tweag/sparkle/blob/ > a4e481aa5180b6ec93c219f827aefe932b66a953/inline-java/src/ > Foreign/JNI.hs#L274. > > HTH, > > -- > Mathieu Boespflug > Founder at http://tweag.io. > > On 20 August 2016 at 20:33, Brandon Allbery wrote: > >> On Sat, Aug 20, 2016 at 2:27 PM, Harendra Kumar > > wrote: >> >>> But "-optP" seems to only append to the flags that GHC already passes >>> and gcc has no "-no-traditional" option to undo the effect of the >>> "-traditional" that GHC has already passed. I think "-optP" should override >>> the flags passed by ghc rather than appending to them. Is there a reason >>> not to do that? >>> >>> Is there any other better way to achieve this? What is the standard way >>> of doing this if any? >>> >> >> Removing -traditional will break much Haskell source. Go look at the >> history of clang with ghc (clang doesn't do -traditional) to see what >> happens. (tl;dr: without -traditional, cpp knows too much about what >> constitutes valid C, and mangles and/or throws errors on valid Haskell that >> doesn't lex the way C does.) >> >> You might want to look at cpphs as an alternative preprocessor. There are >> some ancient K&R-era hacks that could be used if absolutely necessary, but >> cpphs should be a much simpler and cleaner solution. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allbery.b at gmail.com >> ballbery at sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chneukirchen at gmail.com Mon Aug 22 14:41:36 2016 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Mon, 22 Aug 2016 16:41:36 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2016-08-25 @ 19:30 Message-ID: <87wpj8987z.fsf@gmail.com> Dear all, This week, our monthly Munich Haskell Meeting will take place again on Thursday, August 25 at Hirschgarten Biergarten at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-aug-2016/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From winterkoninkje at gmail.com Tue Aug 23 05:23:07 2016 From: winterkoninkje at gmail.com (wren romano) Date: Mon, 22 Aug 2016 22:23:07 -0700 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: <1471632644.3428.14.camel@joachim-breitner.de> References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> <1471632644.3428.14.camel@joachim-breitner.de> Message-ID: On Fri, Aug 19, 2016 at 11:50 AM, Joachim Breitner wrote: > Hi, > > Am Freitag, den 19.08.2016, 11:16 -0700 schrieb Theodore Lief Gannon: >> Well... there's that rather worrisome introductory paragraph of the >> Data.Composition docs, though: >> >> "This module is for convenience and demonstrative purposes more than >> it is for providing actual value. I do not recommend that you rely on >> this module for performance-sensitive code. Because this module is >> not based on Prelude's (.), some chances at optimization might be >> missed by your compiler." > > I wonder if that is really something to worry about. Prelude’s (.) is > not special in any way: Yes and no. Prelude's (.) is not special in that GHC doesn't identify it as something that must be treated differently from what's expected from the definition (as opposed to, say, ($)). However, (.) is inherently a special case because of performance issues about closures. For example, whether we define: (.) f g = \x -> f (g x) vs: (.) f g x = f (g x) has ramifications, though it's fairly easy to guess which one of those two will be most performant. However, it's much less clear which of the following definitions will be the most performant: (.:) = (.) . (.) (.:) f g = (f .) . g (.:) f g = \x y -> f (g x y) For the version implemented in pointless-fun:Data.Function.Pointless, I actually did some benchmarking to determine which was fastest. It is (a) faster by a surprisingly large margin, and (b) not the one I expected to be the fastest. I haven't run those benchmarks on the latest versions of GHC, but that just underscores the point. Because the performance difference is significant and unexpected, having a single blessed (and maintained!) definition would be beneficial to anyone who actually uses this function in production code— whether that blessed definition is in base or some other library everyone has and knows about. -- Live well, ~wren From winterkoninkje at gmail.com Tue Aug 23 05:52:32 2016 From: winterkoninkje at gmail.com (wren romano) Date: Mon, 22 Aug 2016 22:52:32 -0700 Subject: [Haskell-cafe] Data.Set optimisations [was: library for set of heterogeneous values?] In-Reply-To: <1471248920.855526301@f13.my.com> References: <1470890276.638665871@f25.my.com> <1471171977.697413830@f13.my.com> <1471248920.855526301@f13.my.com> Message-ID: On Mon, Aug 15, 2016 at 1:15 AM, Anthony Clayden wrote: > "indirect jumps are particularly expensive on a modern processor > architecture, because they fox the branch prediction hardware, leading to a > stall of 10 or more cycles depending on the length of the pipeline." > [Introduction. The paper goes on to estimate a penalty around 7 to 9 % in > general GHC code.] Indeed, this is the point I was about to bring up (but I've been AWOL the last few weeks). The cost model here makes sense if you think about a recursive function over something like lists. To compile down to a tight C-like loop we'll chose the conditional statement to be "is this nil" and assume it's always false, so that code falls through straightline to do whatever loop body, and then does an unconditional jump back up to the top of the loop. "Almost always" our assumption that the condition fails will be correct, as it's correct in the recursive case and only fails in the basis case. (This notion of "almost always" is assuming we don't have most of our input arguments be the empty list; with felicity degrading as nil inputs begin to dominate.) Regardless of how GHC does things, those basics of branch prediction and primop ordering will remain the same. The question is just about how we get there, how we go from english descriptions like "the recursive case" and "the basis case" (or the "common" and "uncommon" cases) and get to the actual byte code. In practice GHC does the naive thing of ordering branches to be in order of declaration in the data type definition. This is good in as much as it doesn't matter how users textually order their case analyses, since GHC will reorder them. But it's bad in that the assumed ordering is not always very smart— especially when the order of data constructors in a data type's definition is also used for other magic, like deriving Ord. Really, we'd like to make GHC smarter here about how it orders things; but that gets complicated very quickly. > That seems to me worrying for case/constructor branching code in general. Do > we pay that cost for every pattern-match on a list or a Maybe, for example? In principle, yes. In practice, not so much. Because it's not recursive, you gotta figure you're just going to be wrong half the time— but you don't know which half. The only stable solutions here are (a) use dynamic instrumentation to determine which is the hot path and then recompile, or (b) distinguish the (Nothing | Some a) type from the (Just a | Everything) type— which we often want anyways for other things like Ord and Monoid instances, but noone other than me seems to care very much. In addition to these, there are also various unstable solutions: (c) assume the user-provided case-analysis order gives the most likely constructor first (but do we treat Maybe as a special case? do we over-serialize everything?), (d) add a new pragma to specify for each case analysis which constructor should be considered hot (but how much should we actually trust the user to get that right?), etc... -- Live well, ~wren From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Aug 23 07:09:19 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 23 Aug 2016 08:09:19 +0100 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> <1471632644.3428.14.camel@joachim-breitner.de> Message-ID: <20160823070919.GR21438@weber> On Mon, Aug 22, 2016 at 10:23:07PM -0700, wren romano wrote: > (.) f g = \x -> f (g x) > > vs: > > (.) f g x = f (g x) > > has ramifications, though it's fairly easy to guess which one of those > two will be most performant. Are these not synonyms? What is the meaning of fargs var = expr if not fargs = \var -> expr ? From hyarion at iinet.net.au Tue Aug 23 07:19:38 2016 From: hyarion at iinet.net.au (Ben) Date: Tue, 23 Aug 2016 17:19:38 +1000 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: <20160823070919.GR21438@weber> References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> <1471632644.3428.14.camel@joachim-breitner.de> <20160823070919.GR21438@weber> Message-ID: At the semantic level of "does my program compute correct results" they're identical. At the operational level of "how fast does my program run" they're different. On August 23, 2016 5:09:19 PM GMT+10:00, Tom Ellis wrote: >On Mon, Aug 22, 2016 at 10:23:07PM -0700, wren romano wrote: >> (.) f g = \x -> f (g x) >> >> vs: >> >> (.) f g x = f (g x) >> >> has ramifications, though it's fairly easy to guess which one of >those >> two will be most performant. > >Are these not synonyms? What is the meaning of > > fargs var = expr > >if not > > fargs = \var -> expr > >? >_______________________________________________ >Haskell-Cafe mailing list >To (un)subscribe, modify options or view archives go to: >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >Only members subscribed via the mailman list are allowed to post. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Aug 23 07:33:02 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 23 Aug 2016 08:33:02 +0100 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> <1471632644.3428.14.camel@joachim-breitner.de> <20160823070919.GR21438@weber> Message-ID: <20160823073302.GS21438@weber> On the contrary, they're exactly the same (on GHC 7.6.3): module Foo where comp1 f g x = f (g x) comp2 f g = \x -> f (g x) % ghc -O0 -dsuppress-all -fforce-recomp -no-link -ddump-prep test.hs [1 of 1] Compiling Foo ( test.hs, test.o ) ==================== CorePrep ==================== Result size of CorePrep = {terms: 24, types: 36, coercions: 0} comp2 comp2 = \ @ t_aeU @ t1_aeV @ t2_aeW f_sfz g_sfy x_sfx -> let { sat_sfI sat_sfI = g_sfy x_sfx } in f_sfz sat_sfI comp1 comp1 = \ @ t_af5 @ t1_af6 @ t2_af7 f_sfG g_sfF x_sfE -> let { sat_sfJ sat_sfJ = g_sfF x_sfE } in f_sfG sat_sfJ (the same holds for -O2, if you compile them separately) On Tue, Aug 23, 2016 at 05:19:38PM +1000, Ben wrote: > At the semantic level of "does my program compute correct results" they're > identical. At the operational level of "how fast does my program run" > they're different. > > > On August 23, 2016 5:09:19 PM GMT+10:00, Tom Ellis wrote: > >On Mon, Aug 22, 2016 at 10:23:07PM -0700, wren romano wrote: > >> (.) f g = \x -> f (g x) > >> > >> vs: > >> > >> (.) f g x = f (g x) > >> > >> has ramifications, though it's fairly easy to guess which one of > >those > >> two will be most performant. > > > >Are these not synonyms? What is the meaning of > > > > fargs var = expr > > > >if not > > > > fargs = \var -> expr > > > >? From matthewtpickering at gmail.com Tue Aug 23 08:56:25 2016 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Tue, 23 Aug 2016 09:56:25 +0100 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: <20160823073302.GS21438@weber> References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> <1471632644.3428.14.camel@joachim-breitner.de> <20160823070919.GR21438@weber> <20160823073302.GS21438@weber> Message-ID: I think the point which no-one has articulated yet is that the source-level arity of (.) affects whether GHC will decide to inline it. Only fully saturated applications are inlined, thus by having two explicit arguments GHC will inline (.) in the common case where is it used with two arguments which will improve optimisation opportunities for code which composes many functions. On the other hand, it is not very common to write > (.) f g x which is why (.) is defined in such a way. Matt On Tue, Aug 23, 2016 at 8:33 AM, Tom Ellis wrote: > On the contrary, they're exactly the same (on GHC 7.6.3): > > module Foo where > > comp1 f g x = f (g x) > > comp2 f g = \x -> f (g x) > > > % ghc -O0 -dsuppress-all -fforce-recomp -no-link -ddump-prep test.hs > [1 of 1] Compiling Foo ( test.hs, test.o ) > > ==================== CorePrep ==================== > Result size of CorePrep = {terms: 24, types: 36, coercions: 0} > > comp2 > comp2 = > \ @ t_aeU @ t1_aeV @ t2_aeW f_sfz g_sfy x_sfx -> > let { > sat_sfI > sat_sfI = g_sfy x_sfx } in > f_sfz sat_sfI > > comp1 > comp1 = > \ @ t_af5 @ t1_af6 @ t2_af7 f_sfG g_sfF x_sfE -> > let { > sat_sfJ > sat_sfJ = g_sfF x_sfE } in > f_sfG sat_sfJ > > (the same holds for -O2, if you compile them separately) > > On Tue, Aug 23, 2016 at 05:19:38PM +1000, Ben wrote: >> At the semantic level of "does my program compute correct results" they're >> identical. At the operational level of "how fast does my program run" >> they're different. >> >> >> On August 23, 2016 5:09:19 PM GMT+10:00, Tom Ellis wrote: >> >On Mon, Aug 22, 2016 at 10:23:07PM -0700, wren romano wrote: >> >> (.) f g = \x -> f (g x) >> >> >> >> vs: >> >> >> >> (.) f g x = f (g x) >> >> >> >> has ramifications, though it's fairly easy to guess which one of >> >those >> >> two will be most performant. >> > >> >Are these not synonyms? What is the meaning of >> > >> > fargs var = expr >> > >> >if not >> > >> > fargs = \var -> expr >> > >> >? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Tue Aug 23 09:22:13 2016 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Tue, 23 Aug 2016 10:22:13 +0100 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> <1471632644.3428.14.camel@joachim-breitner.de> <20160823070919.GR21438@weber> <20160823073302.GS21438@weber> Message-ID: <20160823092213.GU21438@weber> *Very* interesting. Here is the key section of the GHC users guide: GHC will only inline the function if it is fully applied, where “fully applied” means applied to as many arguments as appear (syntactically) on the LHS of the function definition That this is a good heuristic is *extremely* counterintuitive to me. I would have supposed that being more explicit, for example {-# INLINE (.) f g #-} to inline on all static applications of at least two arguments would have been a much clearer way to communicate this message. What's the rationale behind the current behaviour? Tom On Tue, Aug 23, 2016 at 09:56:25AM +0100, Matthew Pickering wrote: > I think the point which no-one has articulated yet is that the > source-level arity of (.) affects whether GHC will decide to inline it. > > Only fully saturated applications are inlined [...] > > On Tue, Aug 23, 2016 at 8:33 AM, Tom Ellis > wrote: > > On the contrary, they're exactly the same (on GHC 7.6.3): > > > > module Foo where > > > > comp1 f g x = f (g x) > > > > comp2 f g = \x -> f (g x) > > > > > > % ghc -O0 -dsuppress-all -fforce-recomp -no-link -ddump-prep test.hs > > [1 of 1] Compiling Foo ( test.hs, test.o ) > > > > ==================== CorePrep ==================== > > Result size of CorePrep = {terms: 24, types: 36, coercions: 0} > > > > comp2 > > comp2 = > > \ @ t_aeU @ t1_aeV @ t2_aeW f_sfz g_sfy x_sfx -> > > let { > > sat_sfI > > sat_sfI = g_sfy x_sfx } in > > f_sfz sat_sfI > > > > comp1 > > comp1 = > > \ @ t_af5 @ t1_af6 @ t2_af7 f_sfG g_sfF x_sfE -> > > let { > > sat_sfJ > > sat_sfJ = g_sfF x_sfE } in > > f_sfG sat_sfJ > > > > (the same holds for -O2, if you compile them separately) > > > > On Tue, Aug 23, 2016 at 05:19:38PM +1000, Ben wrote: > >> At the semantic level of "does my program compute correct results" they're > >> identical. At the operational level of "how fast does my program run" > >> they're different. > >> > >> > >> On August 23, 2016 5:09:19 PM GMT+10:00, Tom Ellis wrote: > >> >On Mon, Aug 22, 2016 at 10:23:07PM -0700, wren romano wrote: > >> >> (.) f g = \x -> f (g x) > >> >> > >> >> vs: > >> >> > >> >> (.) f g x = f (g x) > >> >> > >> >> has ramifications, though it's fairly easy to guess which one of > >> >those > >> >> two will be most performant. > >> > > >> >Are these not synonyms? What is the meaning of > >> > > >> > fargs var = expr > >> > > >> >if not > >> > > >> > fargs = \var -> expr > >> > > >> >? From alan.zimm at gmail.com Tue Aug 23 09:42:41 2016 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Tue, 23 Aug 2016 11:42:41 +0200 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: <20160823092213.GU21438@weber> References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> <1471632644.3428.14.camel@joachim-breitner.de> <20160823070919.GR21438@weber> <20160823073302.GS21438@weber> <20160823092213.GU21438@weber> Message-ID: Suddenly the eta reduce hlint warning becomes much more important. Alan On 23 Aug 2016 11:22 a.m., "Tom Ellis" < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > *Very* interesting. Here is the key section of the GHC users guide: > > GHC will only inline the function if it is fully applied, where “fully > applied” means applied to as many arguments as appear (syntactically) > on > the LHS of the function definition > > That this is a good heuristic is *extremely* counterintuitive to me. I > would have supposed that being more explicit, for example > > {-# INLINE (.) f g #-} > > to inline on all static applications of at least two arguments would have > been a much clearer way to communicate this message. > > What's the rationale behind the current behaviour? > > Tom > > > On Tue, Aug 23, 2016 at 09:56:25AM +0100, Matthew Pickering wrote: > > I think the point which no-one has articulated yet is that the > > source-level arity of (.) affects whether GHC will decide to inline it. > > > > Only fully saturated applications are inlined > [...] > > > > On Tue, Aug 23, 2016 at 8:33 AM, Tom Ellis > > wrote: > > > On the contrary, they're exactly the same (on GHC 7.6.3): > > > > > > module Foo where > > > > > > comp1 f g x = f (g x) > > > > > > comp2 f g = \x -> f (g x) > > > > > > > > > % ghc -O0 -dsuppress-all -fforce-recomp -no-link -ddump-prep > test.hs > > > [1 of 1] Compiling Foo ( test.hs, test.o ) > > > > > > ==================== CorePrep ==================== > > > Result size of CorePrep = {terms: 24, types: 36, coercions: 0} > > > > > > comp2 > > > comp2 = > > > \ @ t_aeU @ t1_aeV @ t2_aeW f_sfz g_sfy x_sfx -> > > > let { > > > sat_sfI > > > sat_sfI = g_sfy x_sfx } in > > > f_sfz sat_sfI > > > > > > comp1 > > > comp1 = > > > \ @ t_af5 @ t1_af6 @ t2_af7 f_sfG g_sfF x_sfE -> > > > let { > > > sat_sfJ > > > sat_sfJ = g_sfF x_sfE } in > > > f_sfG sat_sfJ > > > > > > (the same holds for -O2, if you compile them separately) > > > > > > On Tue, Aug 23, 2016 at 05:19:38PM +1000, Ben wrote: > > >> At the semantic level of "does my program compute correct results" > they're > > >> identical. At the operational level of "how fast does my program run" > > >> they're different. > > >> > > >> > > >> On August 23, 2016 5:09:19 PM GMT+10:00, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > > >> >On Mon, Aug 22, 2016 at 10:23:07PM -0700, wren romano wrote: > > >> >> (.) f g = \x -> f (g x) > > >> >> > > >> >> vs: > > >> >> > > >> >> (.) f g x = f (g x) > > >> >> > > >> >> has ramifications, though it's fairly easy to guess which one of > > >> >those > > >> >> two will be most performant. > > >> > > > >> >Are these not synonyms? What is the meaning of > > >> > > > >> > fargs var = expr > > >> > > > >> >if not > > >> > > > >> > fargs = \var -> expr > > >> > > > >> >? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Tue Aug 23 13:29:45 2016 From: david.feuer at gmail.com (David Feuer) Date: Tue, 23 Aug 2016 09:29:45 -0400 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: <4789e728-7ea1-c8f3-14d7-6c1417ed5134@plaimi.net> <1471632644.3428.14.camel@joachim-breitner.de> <20160823070919.GR21438@weber> <20160823073302.GS21438@weber> <20160823092213.GU21438@weber> Message-ID: And also sometimes wrong. I don't really understand why, but sometimes eta *expansion* is important when working around RULES. On Aug 23, 2016 5:42 AM, "Alan & Kim Zimmerman" wrote: Suddenly the eta reduce hlint warning becomes much more important. Alan On 23 Aug 2016 11:22 a.m., "Tom Ellis" wrote: > *Very* interesting. Here is the key section of the GHC users guide: > > GHC will only inline the function if it is fully applied, where “fully > applied” means applied to as many arguments as appear (syntactically) > on > the LHS of the function definition > > That this is a good heuristic is *extremely* counterintuitive to me. I > would have supposed that being more explicit, for example > > {-# INLINE (.) f g #-} > > to inline on all static applications of at least two arguments would have > been a much clearer way to communicate this message. > > What's the rationale behind the current behaviour? > > Tom > > > On Tue, Aug 23, 2016 at 09:56:25AM +0100, Matthew Pickering wrote: > > I think the point which no-one has articulated yet is that the > > source-level arity of (.) affects whether GHC will decide to inline it. > > > > Only fully saturated applications are inlined > [...] > > > > On Tue, Aug 23, 2016 at 8:33 AM, Tom Ellis > > wrote: > > > On the contrary, they're exactly the same (on GHC 7.6.3): > > > > > > module Foo where > > > > > > comp1 f g x = f (g x) > > > > > > comp2 f g = \x -> f (g x) > > > > > > > > > % ghc -O0 -dsuppress-all -fforce-recomp -no-link -ddump-prep > test.hs > > > [1 of 1] Compiling Foo ( test.hs, test.o ) > > > > > > ==================== CorePrep ==================== > > > Result size of CorePrep = {terms: 24, types: 36, coercions: 0} > > > > > > comp2 > > > comp2 = > > > \ @ t_aeU @ t1_aeV @ t2_aeW f_sfz g_sfy x_sfx -> > > > let { > > > sat_sfI > > > sat_sfI = g_sfy x_sfx } in > > > f_sfz sat_sfI > > > > > > comp1 > > > comp1 = > > > \ @ t_af5 @ t1_af6 @ t2_af7 f_sfG g_sfF x_sfE -> > > > let { > > > sat_sfJ > > > sat_sfJ = g_sfF x_sfE } in > > > f_sfG sat_sfJ > > > > > > (the same holds for -O2, if you compile them separately) > > > > > > On Tue, Aug 23, 2016 at 05:19:38PM +1000, Ben wrote: > > >> At the semantic level of "does my program compute correct results" > they're > > >> identical. At the operational level of "how fast does my program run" > > >> they're different. > > >> > > >> > > >> On August 23, 2016 5:09:19 PM GMT+10:00, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > > >> >On Mon, Aug 22, 2016 at 10:23:07PM -0700, wren romano wrote: > > >> >> (.) f g = \x -> f (g x) > > >> >> > > >> >> vs: > > >> >> > > >> >> (.) f g x = f (g x) > > >> >> > > >> >> has ramifications, though it's fairly easy to guess which one of > > >> >those > > >> >> two will be most performant. > > >> > > > >> >Are these not synonyms? What is the meaning of > > >> > > > >> > fargs var = expr > > >> > > > >> >if not > > >> > > > >> > fargs = \var -> expr > > >> > > > >> >? > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From conal at conal.net Tue Aug 23 21:58:54 2016 From: conal at conal.net (Conal Elliott) Date: Tue, 23 Aug 2016 14:58:54 -0700 Subject: [Haskell-cafe] Proposal: (.:) operator in base. In-Reply-To: References: Message-ID: Exactly! I'd be disappointed to see (.:) get enshrined in the base when it's such a special case: just one functor ((->) a), just one class (Functor), and just two levels deep. Once people learn the general patterns, they're easy to read & write and *much* more general & flexible. See http://conal.net/blog/posts/semantic-editor-combinators and the lens libraries. -- Conal On Wed, Aug 17, 2016 at 2:14 PM, Tony Morris wrote: > You'd generalise it to: > > fmap . fmap :: (Functor f, Functor g) => (a -> b) -> f (g a) -> f (g b) > > And then, would you do the same for Traversable, Foldable and Applicative? > > On 18/08/16 03:43, Alex Belanger wrote: > > Hi, > > Some of you might be familiar with (.:) = (.) . (.). > > It has type :: (c -> d) -> (a -> b -> c) -> a -> b -> d > > It allows the composition of two functions, the first one, accepting one > operand, and the second, two operands. > > This appears to be a very common pattern, referenced a bit everywhere, > almost always defined on lambdabot and found in multiple codebases in the > wild. > > I'd like the know the general sentiment about this operator, as well as > how its inclusion in base, probably Data.Function, would be perceived > before I actually try to make it happen. > > Cheers, > Alex (nitrix). > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to:http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch.howard at zoho.com Wed Aug 24 05:32:56 2016 From: ch.howard at zoho.com (Christopher Howard) Date: Tue, 23 Aug 2016 21:32:56 -0800 Subject: [Haskell-cafe] How to report builds...? Message-ID: <57BD3188.4060304@zoho.com> Hi list. Hackage cannot build my package, because for some reason it will only use base-4.9.0.0, which does not satisfy the dependencies of some of my dependencies. So, I was trying to figure out how to report my own builds. However, when I use the "cabal report" command, cabal take my username and password, and then (so far as I can tell) does nothing. I tried increasing the verbosity, as well as upgrading to the latest version of cabal, but this did not work. And I can seem to find the documentation for this feature. Please advise. -- https://qlfiles.net My PGP public key ID is 0x340EA95A (pgp.mit.edu). From daniel.trstenjak at gmail.com Wed Aug 24 07:52:51 2016 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Wed, 24 Aug 2016 09:52:51 +0200 Subject: [Haskell-cafe] How to report builds...? In-Reply-To: <57BD3188.4060304@zoho.com> References: <57BD3188.4060304@zoho.com> Message-ID: <20160824075251.GA7580@octa> Hi Christopher, On Tue, Aug 23, 2016 at 09:32:56PM -0800, Christopher Howard wrote: > Hi list. Hackage cannot build my package, because for some reason it > will only use base-4.9.0.0, which does not satisfy the dependencies of > some of my dependencies. There's a dependency between the GHC version and the base library version, each GHC comes with its own base library. In the case of base-4.9.0.0 you are using GHC 8.0.1, which is the latest and quite new compiler version, so most likely some of your dependencies just don't support GHC 8.0.1 yet. For now it might be easier to stick with GHC 7.10, until more libraries are updated. Greetings, Daniel From ch.howard at zoho.com Wed Aug 24 14:53:28 2016 From: ch.howard at zoho.com (Christopher Howard) Date: Wed, 24 Aug 2016 06:53:28 -0800 Subject: [Haskell-cafe] How to report builds...? In-Reply-To: <20160824080105.GB7580@octa> References: <57BD3188.4060304@zoho.com> <20160824080105.GB7580@octa> Message-ID: <57BDB4E8.3090502@zoho.com> On 08/24/2016 12:01 AM, Daniel Trstenjak wrote: > > On Tue, Aug 23, 2016 at 09:32:56PM -0800, Christopher Howard wrote: >> Hi list. Hackage cannot build my package, because for some reason it >> will only use base-4.9.0.0, which does not satisfy the dependencies of >> some of my dependencies. So, I was trying to figure out how to report my >> own builds. However, when I use the "cabal report" command, cabal take >> my username and password, and then (so far as I can tell) does nothing. >> I tried increasing the verbosity, as well as upgrading to the latest >> version of cabal, but this did not work. And I can seem to find the >> documentation for this feature. Please advise. > > But the first thing you could try is to call cabal with the '--allow-newer' > option, which allows newer library versions then specified by the > constraints. This will only work if the newer library versions don't > containt breaking changes, so it's just a way to get going for the > moment but no real solution. > > About the reporting, there's no other way then to contact every single > developer of the breaking libraries. > Well, I know the reason it cannot build with base-4.9.0.0: My library is fully compatible with base (>=4.6 && <4.10), but it depends on the Gloss library (>=1.7 && <1.10). I cannot use Gloss 1.10, because Gloss 1.10 has a breaking API change on one of the Gloss functions I use in my library, which I could only get around if I used a lot of conditional code, which I haven't done yet. However, only Gloss 1.10.* is compatible with base-4.9.0.0. http://hackage.haskell.org/package/mars http://hackage.haskell.org/package/mars-0.2.1.0/reports/ Hackage, it is seems, will only try building with base-4.9.0.0, rather than reverting to an earlier version and compiler. The package builds just fine on my system, using an earlier base and compiler. So, I guess the question is, do I have to further restrict the dependencies of my library (to exclude 4.9.0.0) just because one of my dependencies cannot handle that version? -- https://qlfiles.net My PGP public key ID is 0x340EA95A (pgp.mit.edu). From daniel.trstenjak at gmail.com Wed Aug 24 15:36:30 2016 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Wed, 24 Aug 2016 17:36:30 +0200 Subject: [Haskell-cafe] How to report builds...? In-Reply-To: <57BDB4E8.3090502@zoho.com> References: <57BD3188.4060304@zoho.com> <20160824080105.GB7580@octa> <57BDB4E8.3090502@zoho.com> Message-ID: <20160824153630.GA6276@octa> On Wed, Aug 24, 2016 at 06:53:28AM -0800, Christopher Howard wrote: > The package builds just fine on my system, using an earlier base and compiler. So you're saying that gloss <1.10 builds with base 4.9? Then ask the maintainer of gloss if there would be any issues of supporting base 4.9 with gloss 1.9. Most likely they didn't bother to support newer ghcs with older gloss versions. But If they're nice they might release a new gloss 1.9 version supporting base 4.9. From morten at lysgaard.no Wed Aug 24 15:49:02 2016 From: morten at lysgaard.no (Morten Olsen Lysgaard) Date: Wed, 24 Aug 2016 15:49:02 +0000 Subject: [Haskell-cafe] Rigid type variables and their role in type checking Message-ID: I am making a toy compiler for a polymorphic lambda calculus working of Stephen Diehls excellent Write You a Haskell [1]. I would like to add explicit type annotations to the language, eg. type signatures for functions, but yesterday stumbled over a nut I still haven't been able to crack. The problem is with the semantics of programmer specified type annotations, type variables contained in those signatures and how they interact with the type checker. First off, the WYAH type inference algorithm is a text-book implementation of Hindley-Milner algorithm. It is designed to take a program without any explicit type information, and if type checking succeeds, it outputs the types of every part of the AST. This works fine, the issue surfaced when I added explicit type annotations to the AST. Lets say I have the function: foo1 :: a -> a foo1 x = x The inferred type of `foo1` is `foo1 :: t -> t`, when unified with the annotated type, `a -> a`, the substitution [t = a] is found. Everything works out, as it should. Now consider: foo2 :: Int -> Int foo2 x = x The inferred type of `foo2` is `foo2 :: t -> t` when unified with the annotated type, `Int -> Int`, a substitution [t = Int] is found. Everything works out, as it should. Lastly consider: foo3 :: a -> Int foo3 x = x The inferred type of `foo3` is, again, `foo3 :: t -> t`, when unified with the annotated type, `a -> Int`, we find that `t` must have the same type as `a`, and `t` must be of type `Int`, thus `t = a = Int`. Everything works out!? This is of course not intended behavior, the type annotation on foo3 is horribly wrong, and is blatantly lying about the actual type of the function. When I found this my first instinct was to check how the Haskell compiler would check this function. I found that Haskell complains: Couldn't match expected type `a' with actual type `Int' `a' is a rigid type variable bound by the type signature for foo3 :: a -> Int at foo3.hs:1:9 As far as I understand, Haskell has the notion of a rigid type variable, which my compiler is missing, I am also guessing that these rigid type variables have different rules with respect to unification? Where can I read more about these strange things? I have been trying to form the rules for unification from my intuition about Haskell type checking, but still haven't grasped the whole story, eg. how does one decide if the rigid type variable can be "specialized" or not. In `foo2` it is ok to specialize `a` into `Int`, but in `foo3`, this is not ok. I am struggling to see the underlying rules for this, and would gladly appreciate any pointers to enlightenment! Bonus question! Given the function: foo4 :: a -> a foo4 x = -(x :: Int) The inferred type of `foo4` is `foo4 :: Int -> Int`. When unified with the annotated type, `a -> a`, the substitution [a = Int] is found, everything checks out! >From intuition we know that the type annotation for `foo4` is "to general", that is, `generalness(Int -> Int) < generalness(a -> a)`, but how does one actually express that in code? That is, what is the algorithm that lies behind the function `generalness`? [1] http://dev.stephendiehl.com/fun/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.gigante at gmail.com Wed Aug 24 15:59:17 2016 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Wed, 24 Aug 2016 17:59:17 +0200 Subject: [Haskell-cafe] Stack and Circle CI Message-ID: <8AA3AD6E-1D62-4E7C-BB40-EF334D75E75E@gmail.com> Hi all, has any of you had any success testing haskell projects on CircleCI with a setup that involved Stack? CircleCI seems to directly support haskell by specifying the version of GHC but I wanted my dependencies and tests to be handled by Stack also on the testing machines, since it is my main development tool. I’m also new to Circle CI in particular, although I used Travis in the past. I’ve tried collecting some example files but it seems to have problems with the first ‘stack build’ phase since I see no output in the online console. My circle.yml file: dependencies: cache_directories: - "~/.stack" pre: - wget https://github.com/commercialhaskell/stack/releases/download/v0.1.2.0/stack-0.1.2.0-x86_64-linux.gz -O /tmp/stack.gz - gunzip /tmp/stack.gz && chmod +x /tmp/stack - sudo mv /tmp/stack /usr/bin/stack override: - stack setup - stack build test: override: - stack test Anybody? Thanks. Greetings, Nicola From joel.hermanns at gmail.com Wed Aug 24 16:13:47 2016 From: joel.hermanns at gmail.com (Joel H) Date: Wed, 24 Aug 2016 16:13:47 +0000 Subject: [Haskell-cafe] Stack and Circle CI In-Reply-To: <8AA3AD6E-1D62-4E7C-BB40-EF334D75E75E@gmail.com> References: <8AA3AD6E-1D62-4E7C-BB40-EF334D75E75E@gmail.com> Message-ID: Hi, I've used this one: https://github.com/jhedev/todobackend-haskell/blob/master/circle.yml And it worked great so far. Maybe this helps. Regards, Joel On Wed, 24 Aug 2016 at 17:59, Nicola Gigante wrote: > Hi all, > > has any of you had any success testing haskell projects on > CircleCI with a setup that involved Stack? > > CircleCI seems to directly support haskell by specifying the > version of GHC but I wanted my dependencies and tests to > be handled by Stack also on the testing machines, since it > is my main development tool. > > I’m also new to Circle CI in particular, although I used Travis > in the past. I’ve tried collecting some example files but it seems > to have problems with the first ‘stack build’ phase since I see > no output in the online console. > > My circle.yml file: > > dependencies: > cache_directories: > - "~/.stack" > pre: > - wget > https://github.com/commercialhaskell/stack/releases/download/v0.1.2.0/stack-0.1.2.0-x86_64-linux.gz > -O /tmp/stack.gz > - gunzip /tmp/stack.gz && chmod +x /tmp/stack > - sudo mv /tmp/stack /usr/bin/stack > override: > - stack setup > - stack build > > test: > override: > - stack test > > > Anybody? Thanks. > > Greetings, > Nicola > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed Aug 24 16:29:46 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 24 Aug 2016 12:29:46 -0400 Subject: [Haskell-cafe] Rigid type variables and their role in type checking In-Reply-To: References: Message-ID: On Wed, Aug 24, 2016 at 11:49 AM, Morten Olsen Lysgaard wrote: > Lastly consider: > > foo3 :: a -> Int > foo3 x = x > > The inferred type of `foo3` is, again, `foo3 :: t -> t`, when unified with > the annotated type, `a -> Int`, we find that `t` must have the same type as > `a`, and `t` must be of type `Int`, thus `t = a = Int`. Everything works > out!? I mentioned this when you were asking about this in IRC, but you may have missed it. All type variables are implicitly qualified at top level in standard Haskell (and in ghc if they are not explicitly qualified at some level). Thus the actual type signature is foo3 :: forall a. a -> Int and (forall a. a) does *not* unify with Int. This does not work in both directions, though; in your second example, the *inferred* type (t -> t) is permitted to unify with an explicitly specified type (Int -> Int). It is only explicitly specified types that do this (this is what "rigid" means: explicitly specified, therefore not permitted to unify with a more specific type). The reason for this is that the type signature specifies the contract with callers. (a -> a) which means (forall a. a -> a) promises the caller you will accept any (a) the *caller* chooses. This is why such explicit signatures are rigid: you promised the caller you will accept any (a), so you may not renege on that contract and always produce (Int). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicola.gigante at gmail.com Wed Aug 24 16:36:16 2016 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Wed, 24 Aug 2016 18:36:16 +0200 Subject: [Haskell-cafe] Stack and Circle CI In-Reply-To: References: <8AA3AD6E-1D62-4E7C-BB40-EF334D75E75E@gmail.com> Message-ID: <2145C021-CA91-40CC-B611-7F4CAAB364C7@gmail.com> > Il giorno 24 ago 2016, alle ore 18:13, Joel H ha scritto: > > Hi, > > I've used this one: https://github.com/jhedev/todobackend-haskell/blob/master/circle.yml And it worked great so far. > > Maybe this helps. > Thanks! It fails on the update-alternatives command. 'update-alternatives: error: alternative path /usr/bin/gcc-4.6 doesn't exist’ What should they do? > Regards, > Joel Greetings, Nicola From jkarni at turingjump.com Wed Aug 24 19:39:05 2016 From: jkarni at turingjump.com (Julian Arni) Date: Wed, 24 Aug 2016 16:39:05 -0300 Subject: [Haskell-cafe] ANN: Bookkeeper Message-ID: <20160824193905.GO22420@Tal> I was playing around with GHC 8 yesterday, and ended up writing another extensible records library: https://hackage.haskell.org/package/bookkeeper And a blog post about it: https://turingjump.com/blog/bookkeeper/ I hope someone finds this useful! -- Julian K. Arni Haskell Consultant, Turing Jump https://turingjump.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From olshanskydr at gmail.com Wed Aug 24 21:10:12 2016 From: olshanskydr at gmail.com (Dmitry Olshansky) Date: Thu, 25 Aug 2016 00:10:12 +0300 Subject: [Haskell-cafe] ANN: Bookkeeper In-Reply-To: <20160824193905.GO22420@Tal> References: <20160824193905.GO22420@Tal> Message-ID: This is really interesting. But how many fields in Book could be? I'm afraid there could be a problem for time and memory consumption by compiler. Isn't it? Best regards, Dmitry 2016-08-24 22:39 GMT+03:00 Julian Arni : > I was playing around with GHC 8 yesterday, and ended up writing another > extensible records library: > > https://hackage.haskell.org/package/bookkeeper > > And a blog post about it: > > https://turingjump.com/blog/bookkeeper/ > > > I hope someone finds this useful! > > -- > Julian K. Arni > Haskell Consultant, Turing Jump > https://turingjump.com > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From monkleyon at googlemail.com Wed Aug 24 21:51:45 2016 From: monkleyon at googlemail.com (MarLinn) Date: Wed, 24 Aug 2016 23:51:45 +0200 Subject: [Haskell-cafe] Confused about logBase Message-ID: <03d67261-49c1-c697-1f7b-bc2a88d33863@gmail.com> Hi, I discovered that in base /logBase/, the functions representing arbitrary logarithms, are defined in terms of two applications of /log/. /log/, the functions representing the natural logarithm, just pass responsibility on to some primitives. That is fine, mathematically speaking. But from an implementation standpoint, I wonder why one would do that. The logarithm that should be the fastest and the most precise one to approximate by a cpu should be the one to base two. In fact if one already has a floating point representation, it should be almost ridiculously easy to compute from the exponent. I suppose it's probably a good idea to use primitive functions for the harder cases to get some speed-up. What I don't see is why the choice seems to have been an /xor/ instead of an /and/. I am by absolutely no means an expert on these things, so I am probably missing something here. Is there actually a good reason for this choice? For example will ghc optimize such logarithms anyway? Cheers, MarLinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Wed Aug 24 23:26:48 2016 From: vogt.adam at gmail.com (adam vogt) Date: Wed, 24 Aug 2016 19:26:48 -0400 Subject: [Haskell-cafe] ANN: Bookkeeper In-Reply-To: References: <20160824193905.GO22420@Tal> Message-ID: Book seems to use a quicksort (in package type-level-sets) to avoid duplicates. A couple years ago I did a benchmark http://code.haskell.org/~aavogt/HList-nodup/Run.html that includes a different quicksort. It is a good method, but maybe type-level-sets has a better implementation. Provided my timings generalize, I think dealing with many records of 50 elements will be frustrating. On Wed, Aug 24, 2016 at 5:10 PM, Dmitry Olshansky wrote: > This is really interesting. But how many fields in Book could be? I'm > afraid there could be a problem for time and memory consumption by > compiler. Isn't it? > > Best regards, > Dmitry > > 2016-08-24 22:39 GMT+03:00 Julian Arni : > >> I was playing around with GHC 8 yesterday, and ended up writing another >> extensible records library: >> >> https://hackage.haskell.org/package/bookkeeper >> >> And a blog post about it: >> >> https://turingjump.com/blog/bookkeeper/ >> >> >> I hope someone finds this useful! >> >> -- >> Julian K. Arni >> Haskell Consultant, Turing Jump >> https://turingjump.com >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >> > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cutsea110 at gmail.com Thu Aug 25 01:00:15 2016 From: cutsea110 at gmail.com (cutsea110) Date: Wed, 24 Aug 2016 18:00:15 -0700 (PDT) Subject: [Haskell-cafe] cat as banana In AOP Message-ID: <38cc3000-3ad7-4750-90c0-a70dbcdb4c8a@googlegroups.com> Hi,all I'm studying `Algebra of Programming' written by Prof. Richard Bird. My question is for section 3.5 "Concatenation and currying > Exponentials". In page 74, he said ``` cat = (| curry ([outr, cons] . (id+id x apply) . (id+assocr) . distl) |) ``` where (| ... |) means banana operator. But I guess this left hand side `cat' is typo of `ccat` or `curry cat`? I think this is reasoned below. ----------------------------- cat . (alpha x id) = [outr, cons] . (id + id x cat) . phi <= page 73 start expr (maybe this is from equation (3.6)) = {- Theorem 3.1 precondition -} cat = apply . ( (| curry (h . G apply . phi |) x id) ----- (A) = {- on the other hand, exponential's universal property : g = curry f == apply . (g x id) = f -} cat = apply . ((curry cat) x id) ----- (B) = {- from (A) and (B) -} (curry cat) = (| curry (h . G apply . phi |) ----------------------------- This result is curry cat = (| curry ( [outr, cons] . (id + id x apply) . (id + assocr) . distl) |) not cat = rhs(above). How about this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkarni at turingjump.com Thu Aug 25 02:49:23 2016 From: jkarni at turingjump.com (Julian Arni) Date: Wed, 24 Aug 2016 23:49:23 -0300 Subject: [Haskell-cafe] ANN: Bookkeeper In-Reply-To: References: <20160824193905.GO22420@Tal> Message-ID: <20160825024923.GP22420@Tal> This is a very fair point - indeed compilation is quite slow with larger records. I'll see if it can be made better. The link Adam sent is very helpful! On Wed, Aug 24, 2016 at 07:26:48PM -0400, adam vogt wrote: > Book seems to use a quicksort (in package type-level-sets) to avoid > duplicates. A couple years ago I did a benchmark > http://code.haskell.org/~aavogt/HList-nodup/Run.html that includes a > different quicksort. It is a good method, but maybe type-level-sets has a > better implementation. Provided my timings generalize, I think dealing with > many records of 50 elements will be frustrating. > > On Wed, Aug 24, 2016 at 5:10 PM, Dmitry Olshansky > wrote: > > > This is really interesting. But how many fields in Book could be? I'm > > afraid there could be a problem for time and memory consumption by > > compiler. Isn't it? > > > > Best regards, > > Dmitry > > > > 2016-08-24 22:39 GMT+03:00 Julian Arni : > > > >> I was playing around with GHC 8 yesterday, and ended up writing another > >> extensible records library: > >> > >> https://hackage.haskell.org/package/bookkeeper > >> > >> And a blog post about it: > >> > >> https://turingjump.com/blog/bookkeeper/ > >> > >> > >> I hope someone finds this useful! > >> > >> -- > >> Julian K. Arni > >> Haskell Consultant, Turing Jump > >> https://turingjump.com > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> To (un)subscribe, modify options or view archives go to: > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> Only members subscribed via the mailman list are allowed to post. > >> > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > -- Julian K. Arni Haskell Consultant, Turing Jump https://turingjump.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From joel.hermanns at gmail.com Thu Aug 25 09:17:08 2016 From: joel.hermanns at gmail.com (Joel Hermanns) Date: Thu, 25 Aug 2016 11:17:08 +0200 Subject: [Haskell-cafe] Stack and Circle CI In-Reply-To: <2145C021-CA91-40CC-B611-7F4CAAB364C7@gmail.com> References: <8AA3AD6E-1D62-4E7C-BB40-EF334D75E75E@gmail.com> <2145C021-CA91-40CC-B611-7F4CAAB364C7@gmail.com> Message-ID: I had some weird linker issues (see https://circleci.com/gh/jhedev/todobackend-haskell/48 ) when using an older gcc 4.9. So switching to gcc-4.6 helped. I think you are using the newer ubuntu 14.04 build image which does not include gcc-4.6. Maybe you can try removing the update alternatives commands. For your problem I guess its more important to set `-j 1` for the `stack build` command. To avoid getting no output etc. Regards, Joel > On 24 Aug 2016, at 18:36, Nicola Gigante wrote: > > >> Il giorno 24 ago 2016, alle ore 18:13, Joel H ha scritto: >> >> Hi, >> >> I've used this one: https://github.com/jhedev/todobackend-haskell/blob/master/circle.yml And it worked great so far. >> >> Maybe this helps. >> > > Thanks! > > It fails on the update-alternatives command. > > 'update-alternatives: error: alternative path /usr/bin/gcc-4.6 doesn't exist’ > > What should they do? > >> Regards, >> Joel > > Greetings, > Nicola -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgoggans at gmail.com Thu Aug 25 19:05:43 2016 From: rgoggans at gmail.com (Ryan G) Date: Thu, 25 Aug 2016 15:05:43 -0400 Subject: [Haskell-cafe] Fwd: Executable runs but dynamic linking fails within ghci In-Reply-To: References: Message-ID: I'm working with a GUI library and I can get everything to work when I run my executable. When I try to call my gui function within ghci, it crashes with: user error (unknown GLU entry gluOrtho2D). I'm on Arch running ghc version 7.10.3. The GLURaw maintainer could reproduce this and added some insight I can reproduce this both with LTS Haskell (based on GHC 7.10.3) and > Stackage nightly (based on GHC 8.0.1) on Ubuntu 16.04, too. This is somehow > related to GHCi's dynamic linker, which has changed a few times in the > past, and there are still issues with it. Alas, I don't remember the > details, but perhaps you can get some answers on the haskell-cafe mailing > list. All I can say is that things worked even within GHCi at some point in > the past... [image: :wink:] > > The gory details: Given an API entry name like "gluOrtho2D", the GLURaw > package uses dlopen anddlsym to get the address of the function, see the Haskell > part > and > the C part > . > For some reason, dlsymdoesn't find the GLU entries when running under > GHCi, while the compiled version does. > Any help is appreciated -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.skladnoy at gmail.com Thu Aug 25 19:27:24 2016 From: alexey.skladnoy at gmail.com (Alexey Khudyakov) Date: Thu, 25 Aug 2016 22:27:24 +0300 Subject: [Haskell-cafe] Confused about logBase In-Reply-To: <03d67261-49c1-c697-1f7b-bc2a88d33863@gmail.com> References: <03d67261-49c1-c697-1f7b-bc2a88d33863@gmail.com> Message-ID: On 25 August 2016 at 00:51, MarLinn via Haskell-Cafe wrote: > Hi, > > I discovered that in base logBase, the functions representing arbitrary > logarithms, are defined in terms of two applications of log. log, the > functions representing the natural logarithm, just pass responsibility on to > some primitives. That is fine, mathematically speaking. But from an > implementation standpoint, I wonder why one would do that. > > The logarithm that should be the fastest and the most precise one to > approximate by a cpu should be the one to base two. In fact if one already > has a floating point representation, it should be almost ridiculously easy > to compute from the exponent. > Speaking of precision. log in any base is a transcendental function so best we can do is to ensure that approximation differs from true answer no more that 0.5 ULPs. Also I don't think log in base 2 would be any more performant than natural logarithm. Yes calculations for exponent is easy but you still need to calculate it for mantissa and it's not easier task. And most of the time natural logarithm is used. From monkleyon at googlemail.com Fri Aug 26 01:43:58 2016 From: monkleyon at googlemail.com (MarLinn) Date: Fri, 26 Aug 2016 03:43:58 +0200 Subject: [Haskell-cafe] Confused about logBase In-Reply-To: References: <03d67261-49c1-c697-1f7b-bc2a88d33863@gmail.com> Message-ID: On 2016-08-25 21:27, Alexey Khudyakov wrote: >> I discovered that in base logBase, the functions representing arbitrary >> logarithms, are defined in terms of two applications of log. log, the >> functions representing the natural logarithm, just pass responsibility on to >> some primitives. That is fine, mathematically speaking. But from an >> implementation standpoint, I wonder why one would do that. >> >> The logarithm that should be the fastest and the most precise one to >> approximate by a cpu should be the one to base two. In fact if one already >> has a floating point representation, it should be almost ridiculously easy >> to compute from the exponent. > Also I don't think log in base 2 would be any more performant than > natural logarithm. Yes calculations for exponent is easy but you still > need to calculate it for mantissa and it's not easier task. And most > of the time natural logarithm is used. Calculating the binary logarithm of an integer is a search for the least significant bit. For integers, that's either a build-in or a binary search. For floating point values, you already know where that bit is because the exponent tells you (modulo some edge cases and an offset). And even if I'm wrong, just combine both methods, add two numbers, done. That should still be faster than even the division operation alone that you otherwise need to combine the two values. Divisions are expensive, too. (interesting fact: Java uses a seven-fingered merge sort with bit-shift-trickery to approximate a division by seven because the division is so damn expensive) So sorry, I don't believe that claim of yours. I'm not sure about your second claim either. Maybe natural logarithms are used more often, maybe not. I don't have any numbers either way and I don't read enough papers to have a feeling what the scientific community uses. Maybe if speed is an issue people just resort to external libraries. Still, I had hoped for some more insight into why the choices were made as they were. I guess I'll have to assume the original easier implementation was just never changed because there where bigger, more important targets. Not 100% satisfying but reasonable. MarLinn From allbery.b at gmail.com Fri Aug 26 01:56:01 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 25 Aug 2016 21:56:01 -0400 Subject: [Haskell-cafe] Confused about logBase In-Reply-To: References: <03d67261-49c1-c697-1f7b-bc2a88d33863@gmail.com> Message-ID: On Thu, Aug 25, 2016 at 9:43 PM, MarLinn via Haskell-Cafe < haskell-cafe at haskell.org> wrote: > So sorry, I don't believe that claim of yours. I'm not sure about your > second claim either. Maybe natural logarithms are used more often, maybe > not. I don't have any numbers either way and I don't read enough papers to > have a feeling what the scientific community uses. Natural logs almost exclusively... because their occurrence all through the physical sciences and biology, etc. is what got them the name "natural". Which is why CPUs have natural log as a built-in FP operation. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at fenestra.com Fri Aug 26 02:16:19 2016 From: steve at fenestra.com (Steve Schafer) Date: Thu, 25 Aug 2016 21:16:19 -0500 Subject: [Haskell-cafe] Confused about logBase In-Reply-To: References: <03d67261-49c1-c697-1f7b-bc2a88d33863@gmail.com> Message-ID: On Thu, 25 Aug 2016 21:56:01 -0400, you wrote: >Which is why CPUs have natural log as a built-in FP operation. That's not quite true, as far as I know. The FPU log instructions (FYL2X and FYL2XP1) use base 2, but the FPU also provides FLDLN2 and FLDLG2 constant-loading instructions to allow for easy conversion to natural and base-10 logs, respectively. -Steve Schafer -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From ok at cs.otago.ac.nz Fri Aug 26 05:24:17 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 26 Aug 2016 17:24:17 +1200 Subject: [Haskell-cafe] Confused about logBase In-Reply-To: References: <03d67261-49c1-c697-1f7b-bc2a88d33863@gmail.com> Message-ID: <92f9926f-7faa-73d7-af43-b96adc06715e@cs.otago.ac.nz> On 26/08/16 1:43 PM, MarLinn via Haskell-Cafe wrote: > > Calculating the binary logarithm of an integer is a search for the least > significant bit. For integers, that's either a build-in or a binary > search. The binary log of an integer is close to the location of the MOST significant bit. (Common Lisp, see HAULONG. Smalltalk, see #highBit.) Some machines have hardware for "Count Leading Zeros" that can be used to get this. BUT that's still not the binary logarithm. 4 and 5 have their most significant bit in the same place, but do not have the same base-2 logarithm. log2(4) = 2.0000000000000000 log2(5) = 2.3219280948873622 Realistically, the hard part happens *after* you find the most significant bit. For floating point values, you already know where that bit is > because the exponent tells you (modulo some edge cases and an offset). That's not the hard part. In the open source libm, log() is 104 SLOC of C, while log2() is 119 SLOC of C. In both of them, extracting the exponent from the floating point number is indeed just a couple of lines. It's everything ELSE that's hard. Getting below 0.90 ULP of error is not easy. It's worth noting that these days the standard C library has log1p() and log() -- both base e -- and also log2 and log10. But that's recent; the C library used to include just log(). > That should still be faster than even the division operation alone that > you otherwise need to combine the two values. Divisions are expensive, too. > (interesting fact: Java uses a seven-fingered merge sort with > bit-shift-trickery to approximate a division by seven because the > division is so damn expensive) Java was designed by a company that left integer division entirely out of the hardware of their machine (SPARC V7). While this was fixed in SPARC V8, some experiences leave scars. For what it's worth, gcc and other C compilers have been optimising integer divisions by known constants into shifts and adds/subtracts for a long time. The bit-shift trickery may well be an idea whose time has gone. What this has to do with FLOATING-POINT divisions is not clear. Looking at all the work that log() -- or log2() -- has to do makes me think that a Haskell program that could NOTICE an extra floating-point division would be a very unusual Haskell program indeed. > So sorry, I don't believe that claim of yours. I'm not sure about your > second claim either. Maybe natural logarithms are used more often, maybe > not. I don't have any numbers either way and I don't read enough papers > to have a feeling what the scientific community uses. Natural logarithms have some rather pleasant mathematical properties. log10 is nice for human beings, but that's a user interface issue more than actual calculation. log2 is useful if you are calculating "information", but even then, for most purposes other than user output measuring information in nats is just as good as measuring in bits. From svenpanne at gmail.com Fri Aug 26 07:02:47 2016 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 26 Aug 2016 09:02:47 +0200 Subject: [Haskell-cafe] Confused about logBase In-Reply-To: References: <03d67261-49c1-c697-1f7b-bc2a88d33863@gmail.com> Message-ID: 2016-08-26 3:43 GMT+02:00 MarLinn via Haskell-Cafe : > [...] Divisions are expensive, too. > Yes, considered in isolation they are, but things are totally different if you consider modern CPU architectures and the program as a whole: With highly pipelined architectures, out-of-order execution, register renaming etc. it is not uncommon that the high cost of the division itself is hidden because e.g. its result is not immediately needed. And the other observation is: The cunning bit-fiddling algorithms of the past often have very high hidden costs because they need more registers, have strong value dependencies (leading to pipeline stalls), interact badly with branch prediction etc. As a result, it is not uncommon that the most straightforward code is the fastest. In the end you have to measure... (on various platforms) > (interesting fact: Java uses a seven-fingered merge sort with > bit-shift-trickery to approximate a division by seven because the division > is so damn expensive) [...] > This is a perfect example for a bad algorithm on current CPUs: An integer division by a constant can and should be replaced by an integer multiplication plus some tiny correction by a shift/add, see e.g. section "8.1 Replacing division with multiplication" in AMD's optimization guide ( http://support.amd.com/TechDocs/25112.PDF) or "Computing Magic Numbers" in Hacker's Delight (http://www.hackersdelight.org/). Looking at e.g. the Skylake table in http://www.agner.org/optimize/instruction_tables.pdf (the CPU performance "bible" ;-), you can see how blazingly fast that is. In a nutshell: We don't program on our grandpa's CPUs anymore, :-D at least not on the desktop/server, so a lot of traditional advice from the past is misleading nowadays. -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Fri Aug 26 06:49:47 2016 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Fri, 26 Aug 2016 18:49:47 +1200 Subject: [Haskell-cafe] Data.Set optimisations [was: library for set of heterogeneous values?] Message-ID: <57bfe68b.1db.57bf.28533@clear.net.nz> > > On Mon, Aug 15, 2016 at 1:15 AM, Anthony Clayden wrote: > > "indirect jumps are particularly expensive on a modern > > processor architecture, because they fox the branch > > prediction hardware, leading to a stall of 10 or more > > cycles depending on the length of the pipeline." > [Introduction. The paper goes on to estimate a penalty > > around 7 to 9 % in general GHC code.] > The cost model here makes sense if ... Thanks Wren. Is that 7 to 9 % figure unduly alarmist? (It is consistent with Milan's benchmarking.) For example would strictifying or inlining have much greater benefits than worrying about constructors? And it only affects processor-intensive applications(?) > ... > Regardless of how GHC does things, those basics of branch > prediction and primop ordering will remain the same. ... > In practice GHC does the naive thing of ordering branches > to be in order of declaration in the data type definition. > This is good in as much as it doesn't matter how users > textually order their case analyses, since GHC will > reorder them. ... > ...the order of data constructors in a data type's definition > is also used for other magic, like deriving Ord. ... Hmm, I'd hardly describe derivng Ord as "magic". It's what the language report says [Chapter 11]. > Really, we'd like to make GHC smarter here about > how it orders [case branchng code]; > but that gets complicated very quickly. I can see that. I gave some possible rules of thumb in an earlier message. (In particular, recursive constructors are more likely.) > ... noone other than me seems to care very much. ... I guess not many know. We kinda expect GHC will be much smarter than we could achieve by hand-crafting the object code. Those who could write assembler code must be dying out ;-) Judging by the 2006 paper, part of the difficulty seems to be that the C code GHC generates is none too idiomatic for what a C optimiser is tuned for. AntC From monkleyon at googlemail.com Fri Aug 26 07:07:07 2016 From: monkleyon at googlemail.com (MarLinn) Date: Fri, 26 Aug 2016 09:07:07 +0200 Subject: [Haskell-cafe] Confused about logBase In-Reply-To: <92f9926f-7faa-73d7-af43-b96adc06715e@cs.otago.ac.nz> References: <03d67261-49c1-c697-1f7b-bc2a88d33863@gmail.com> <92f9926f-7faa-73d7-af43-b96adc06715e@cs.otago.ac.nz> Message-ID: <96174a8b-331a-1b94-fe06-14e78fc5d622@gmail.com> And /that's/ why non-experts like me should not be let near the actual implementation. Thank you very much for all the detailed information and for purging some of the falsehoods in my worldview. I knew that I misunderstood a lot of stuff but now I have a better picture of were the errors actually are. So again, thanks! MarLinn -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaumh at gmail.com Fri Aug 26 15:47:59 2016 From: guillaumh at gmail.com (Guillaume Hoffmann) Date: Fri, 26 Aug 2016 12:47:59 -0300 Subject: [Haskell-cafe] problem installing GHC on Ubuntu 16.10 Message-ID: Hi, Anyone knows why I am not able to install GHC 8 nor 7.10 on my Ubuntu 16.10 machine using the packages from GHC's page nor using stack setup? Here are the errors thrown by stack setup: * http://lpaste.net/180513 * http://lpaste.net/180514 Ubuntu 16.10 provides GHC 7.10 as package but I'd like to have GHC 8. thanks Guillaume From olshanskydr at gmail.com Fri Aug 26 16:58:45 2016 From: olshanskydr at gmail.com (Dmitry Olshansky) Date: Fri, 26 Aug 2016 19:58:45 +0300 Subject: [Haskell-cafe] problem installing GHC on Ubuntu 16.10 In-Reply-To: References: Message-ID: Did you look at http://docs.haskellstack.org/en/stable/install_and_upgrade/ as log suggest? Does your stack with last version (1.1.2 I suppose)? 2016-08-26 18:47 GMT+03:00 Guillaume Hoffmann : > Hi, > > Anyone knows why I am not able to install GHC 8 nor 7.10 on my Ubuntu > 16.10 machine using the packages from GHC's page nor using stack > setup? > > Here are the errors thrown by stack setup: > > * http://lpaste.net/180513 > * http://lpaste.net/180514 > > Ubuntu 16.10 provides GHC 7.10 as package but I'd like to have GHC 8. > > thanks > > Guillaume > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guillaumh at gmail.com Fri Aug 26 17:19:11 2016 From: guillaumh at gmail.com (Guillaume Hoffmann) Date: Fri, 26 Aug 2016 14:19:11 -0300 Subject: [Haskell-cafe] problem installing GHC on Ubuntu 16.10 In-Reply-To: References: Message-ID: Yes it is the last version of stack. But anyway the same error occurs during the "make install" step of installing packages from GHC's website. From david.feuer at gmail.com Fri Aug 26 20:43:49 2016 From: david.feuer at gmail.com (David Feuer) Date: Fri, 26 Aug 2016 16:43:49 -0400 Subject: [Haskell-cafe] Confused about logBase In-Reply-To: <96174a8b-331a-1b94-fe06-14e78fc5d622@gmail.com> References: <03d67261-49c1-c697-1f7b-bc2a88d33863@gmail.com> <92f9926f-7faa-73d7-af43-b96adc06715e@cs.otago.ac.nz> <96174a8b-331a-1b94-fe06-14e78fc5d622@gmail.com> Message-ID: If you decide to research specialized algorithms for calculating logs with a variety of bases, it may make sense to start trying to add one to the numeric-functions package [*] before going for base. Aleksey Khudyakov has been doing a lot of work on that package of late, and would likely be able to help you work out potential issues. [*] https://hackage.haskell.org/package/math-functions On Aug 26, 2016 3:10 AM, "MarLinn via Haskell-Cafe" < haskell-cafe at haskell.org> wrote: > And *that's* why non-experts like me should not be let near the actual > implementation. > > Thank you very much for all the detailed information and for purging some > of the falsehoods in my worldview. I knew that I misunderstood a lot of > stuff but now I have a better picture of were the errors actually are. > So again, thanks! > MarLinn > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ch.howard at zoho.com Sat Aug 27 05:13:17 2016 From: ch.howard at zoho.com (Christopher Howard) Date: Fri, 26 Aug 2016 21:13:17 -0800 Subject: [Haskell-cafe] StdGen Reliability Across Versions / Systems Message-ID: <57C1216D.1010002@zoho.com> I know that, ff you feed mkStdGen a particular seed, and pull a list of random numbers from that StdGen, that that the list will always be the same if your run your compiled program over and over again on that same system. But which of the following will cause you to get different output?: 1) Changes in GHC version 2) Changes in "random" library version 3) Compiling / Running on a different host computer (but compiling with the same GHC & random versions. -- https://qlfiles.net My PGP public key ID is 0x340EA95A (pgp.mit.edu). From lemming at henning-thielemann.de Sat Aug 27 10:23:13 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sat, 27 Aug 2016 12:23:13 +0200 (CEST) Subject: [Haskell-cafe] managing embedded structs Message-ID: I want to write a Haskell interface to a C library that provides two data structures A and B, where B is contained in A. That is, if A is freed, then B is automatically freed, too. There are two ways to obtain a Ptr B. Either construct it separately or as part of A, i.e. b0 :: Ptr B b0 <- createB b1 :: Ptr B b1 <- getBofA =<< createA Now I want to let the garbage collector manage the resources for B in a ForeignPtr. The first case is easy: fb0 :: ForeignPtr B fb0 <- newForeignPtr deleteB =<< createB But how to create an fb1? fa1 :: ForeignPtr A fa1 <- newForeignPtr deleteA =<< createA fb1 :: ForeignPtr B fb1 <- newForeignPtr ??? =<< withForeignPtr fa1 getBofA Obviously, there is nothing I can insert for ???. fb1 must not have its own finalizer, because fa1 already has one. But I have to make sure that fa1 lives at least as long as fb1. How to do that? From magnusbakken at gmail.com Sat Aug 27 10:59:39 2016 From: magnusbakken at gmail.com (Magnus Grindal Bakken) Date: Sat, 27 Aug 2016 03:59:39 -0700 (PDT) Subject: [Haskell-cafe] Using MonadRandom with QuickCheck In-Reply-To: References: Message-ID: <2e57eb62-678f-4027-95b5-3a9699efa408@googlegroups.com> Thanks, Li-yao! For anyone else reading this, this is the MonadRandom instance I ended up with: mkGen :: (QCGen -> a) -> Gen a mkGen f = MkGen $ \g _ -> f g instance MonadRandom Gen where getRandom = mkGen (fst . random) getRandoms = mkGen randoms getRandomR range = mkGen (fst . randomR range) getRandomRs range = mkGen (randomRs range) With that said, I found that in many cases to get the game states I needed for my property tests I had to use more specific generators that took input such as a range of number of moves, whether the game was finished or not, the current action, etc., so it didn't end up being as useful for me as I hoped. > On Sunday, August 21, 2016 at 10:37:35 PM UTC+2, Li-yao Xia wrote: > > Hi Magnus, > > Import Test.QuickCheck.Gen to get the internals of Gen, which AFAIK is > currently the only way to get to the underlying random generator (QCGen). > > getRandom = MkGen $ \g _ -> fst (random g) > -- repeat with randomRs, randoms. > > I don't know why Gen is not an instance of MonadRandom either. It seems > reasonable to add one, though it might go against some design principle > of QuickCheck by ignoring the size parameter. > > Regards, > Li-yao > > On 08/21/2016 09:38 PM, Magnus Grindal Bakken wrote: > > Is there some easy way to use the Gen type from QuickCheck with the > > MonadRandom class? > > > > Links to the packages in question: > > https://hackage.haskell.org/package/MonadRandom > > https://hackage.haskell.org/package/QuickCheck > > > > Some background in case there's an easier way to solve the problem: > > I'm toying around with an API for a simple turn-based board game. The > > main type in my API is called GameState, and I'm trying to define an > > Arbitrary instance for it so I can set up invariants with QuickCheck. > > The Arbitrary instance should produce game states that are the result > > of playing a random number of random moves. > > > > At certain points in the gameplay the game itself needs to invoke some > > randomness. I've designed the public game API to have basically just > > two functions: > > > > playAction :: ActionData -> GameState -> GameState > > evaluateGameState :: MonadRandom m => GameState -> m GameState > > > > The usage is supposed to be that the client first calls playAction > > with an ActionData value that depends on the current move, and > > afterwards calls evaluateGameState to evaluate whatever random events > > need to happen at that point (e.g. reshuffling a deck of cards). That > > way my main "action" logic doesn't need to concern itself with any > > form of randomness. > > > > I'm using MonadRandom from Control.Monad.Random because it seems like > > a much nicer way to generate random numbers than using RandomGen > > directly. However I can't figure out how to make it play nice with > > QuickCheck. I can easily set up my Arbitrary instance to call > > playAction an arbitrary number of times, but I can't call > > evaluateGameState since it lives in the other monad. It would work if > > Gen were an instance of MonadRandom, but I can't quite work out how to > > write that instance since most functions on Gen only work if the > > output type is an instance of Arbitrary, while MonadRandom needs to > > work with any types that are part of the Random class. This part > > works: > > > > instance MonadRandom Gen where > > getRandomR = choose > > > > But I don't know how to define the other functions on MonadRandom for > Gen. > > > > I think I might also be able to use the PropertyM monad transformer: > > > https://hackage.haskell.org/package/QuickCheck-2.9.1/docs/Test-QuickCheck-Monadic.html > , > > but monad transformers always confuse me so I haven't been able to > > figure out how to do that yet either. > > > > I've thought about rewriting the API to use the Gen type instead of > > MonadRandom, but it feels kind of iffy to have the API depend on a > > testing library. > > > > Has anyone tried to use these libraries together before? > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zocca.marco at gmail.com Sun Aug 28 10:38:41 2016 From: zocca.marco at gmail.com (Marco Zocca) Date: Sun, 28 Aug 2016 12:38:41 +0200 Subject: [Haskell-cafe] [Haskell-community] haskell.org download page Message-ID: -1 to making HP the first method Stack is easier to get started with and makes tinkering easier. In this sense, it's a more natural choice for beginners. Also, the Minimal option is kind of dead for Mac users since GHCForMacOSX is not maintained anymore. (NB: I speak out of personal experience and have no conflicting interests) From fa-ml at ariis.it Sun Aug 28 13:00:25 2016 From: fa-ml at ariis.it (Francesco Ariis) Date: Sun, 28 Aug 2016 15:00:25 +0200 Subject: [Haskell-cafe] [Haskell] I repeat my Question becaue I not really sure to do it right In-Reply-To: References: Message-ID: <20160828130025.GA24813@casa.casa> haskell at haskell.org is low traffic, for announcements only, I am replying to haskell-cafe at haskell.org , where this question is better suited (and most people willing to help are). On Sun, Aug 28, 2016 at 10:50:50PM +1000, Ivan Lazar Miljenovic wrote: > On 28 August 2016 at 22:40, wrote: > > This is Leksah http://leksah.org/ > > Please excuse my false name for it > > And the Question is why can I install it. > > What error messages do you have when you try? > > From here, this is what you need to do: > https://github.com/leksah/leksah/wiki/download > > > cabal install gtk2hs-buildtools > > > cabal install leksah > > > > > > > excuse me. > > Mungo1981 > > > > Gesendet: Sonntag, 28. August 2016 um 13:49 Uhr > > Von: "Ivan Lazar Miljenovic" > > An: CCUTM at web.de > > Cc: "Haskell List" > > Betreff: Re: [Haskell] I repeat my Question becaue I not really sure to do > > it right > > On 28 August 2016 at 20:43, wrote: > >> Ok Haskell is good. > >> Ok Laska is great. > >> And my Ubuntu Studio ist rubish > >> So I try to install Laska on Ubuntu Studio > >> But when I do this, i will get a long list of dependecies > >> which could not reallise > >> So I not know what should I do > > > > Which question? > > > > What is Laska that you're having trouble installing it? > > > >> > >> Mungo1981 > >> > >> _______________________________________________ > >> Haskell mailing list > >> Haskell at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > >> > > > > > > > > -- > > Ivan Lazar Miljenovic > > Ivan.Miljenovic at gmail.com > > http://IvanMiljenovic.wordpress.com > > > > _______________________________________________ > > Haskell mailing list > > Haskell at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > > > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell From alexey.skladnoy at gmail.com Sun Aug 28 15:39:54 2016 From: alexey.skladnoy at gmail.com (Alexey Khudyakov) Date: Sun, 28 Aug 2016 18:39:54 +0300 Subject: [Haskell-cafe] managing embedded structs In-Reply-To: References: Message-ID: On 27 August 2016 at 13:23, Henning Thielemann wrote: > > I want to write a Haskell interface to a C library that provides two data > structures A and B, where B is contained in A. That is, if A is freed, then > B is automatically freed, too. > I don't quite understand. Do A and B live in the same buffer and problem in keeping buffer alive as long as there're pointers to A or B. If so it's easy problem and vector solves exactly this problem for storable vectors. Check implementation of basicUnsafeSlice. Idea is to share finalizer between ForeignPtr If they live in different buffers and B should not be collected as long as A lives... I don't know how to implement this. From marco-oweber at gmx.de Sun Aug 28 16:49:23 2016 From: marco-oweber at gmx.de (Marc Weber) Date: Sun, 28 Aug 2016 16:49:23 +0000 Subject: [Haskell-cafe] Is anybody interested in taking over maintaining hasktags? Message-ID: <1472402905-sup-6207@nixos> There is not much to be done - patch requests come in once or twice a year. Current task would be uploading a new version to hackage fixing compilation bug. The patch is already on github Marc Weber From jhenahan at me.com Sun Aug 28 16:56:14 2016 From: jhenahan at me.com (Jack Henahan) Date: Sun, 28 Aug 2016 12:56:14 -0400 Subject: [Haskell-cafe] Is anybody interested in taking over maintaining hasktags? In-Reply-To: <1472402905-sup-6207@nixos> References: <1472402905-sup-6207@nixos> Message-ID: I have been looking for an excuse to properly familiarize myself with the Hackage process, and I get enough use out of hasktags that it would be nice to contribute something. I volunteer, but I'll also defer to anyone with more experience and the necessary bandwidth who wants it. Marc Weber writes: > There is not much to be done - patch requests come in once or twice a > year. > > Current task would be uploading a new version to hackage fixing > compilation bug. The patch is already on github > > Marc Weber > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Jack -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 800 bytes Desc: not available URL: From lemming at henning-thielemann.de Sun Aug 28 18:17:27 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Sun, 28 Aug 2016 20:17:27 +0200 (CEST) Subject: [Haskell-cafe] managing embedded structs In-Reply-To: References: Message-ID: On Sun, 28 Aug 2016, Alexey Khudyakov wrote: > On 27 August 2016 at 13:23, Henning Thielemann > wrote: >> >> I want to write a Haskell interface to a C library that provides two data >> structures A and B, where B is contained in A. That is, if A is freed, then >> B is automatically freed, too. >> > I don't quite understand. Do A and B live in the same buffer and problem in > keeping buffer alive as long as there're pointers to A or B. If so > it's easy problem > and vector solves exactly this problem for storable vectors. Check > implementation > of basicUnsafeSlice. Idea is to share finalizer between ForeignPtr Sharing finalizer between ForeignPtr A and ForeignPtr B might indeed be a solution. It would require dependence on the ghc package (and thus GHC), though. > If they live in different buffers and B should not be collected as > long as A lives... This would be true in another situation, where I create a finalizer by the LLVM-JIT and need to finalize the finalizer's code if it is no longer needed. https://ghc.haskell.org/trac/ghc/ticket/12547 From will.t.murphy at gmail.com Sun Aug 28 19:24:59 2016 From: will.t.murphy at gmail.com (Will Tennien Murphy) Date: Sun, 28 Aug 2016 15:24:59 -0400 Subject: [Haskell-cafe] Haskell Tutorials to Spread the Word Message-ID: Hey, I'm looking for people to help spread the word about Haskell by translating or writing tutorials. I'm a contributor to py-app.com . Py is an app that teaches programming concepts "on the go"—that is, with a mobile focus. Do you... 1. Want to help spread the word about Haskell? 2. Like helping other people learn? 3. Speak another natural language and can translate existing content? 4. Know a tutorial you'd like to make more mobile-friendly? If you meet ANY of these conditions—especially if you are proficient another language—drop me a line at wtmurp at gmail.com. I'm very intent on making things as easy as possible for writers so you can write in whatever you find most convenient[1] and I'll figure out how to get it into the app. [1] except PDF -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivan.miljenovic at gmail.com Sun Aug 28 21:36:42 2016 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 29 Aug 2016 07:36:42 +1000 Subject: [Haskell-cafe] [Haskell] I repeat my Question becaue I not really sure to do it right In-Reply-To: References: Message-ID: On 28 August 2016 at 23:15, wrote: > Hello it is possible that this is the solution. > But I don't know how I can istall it. See the Ubuntu section here: http://www.leksah.org/download.html > > Gesendet: Sonntag, 28. August 2016 um 15:07 Uhr > Von: "Ivan Lazar Miljenovic" > An: CCUTM at web.de > Betreff: Re: Re: [Haskell] I repeat my Question becaue I not really sure to > do it right > Do you have the -dev libraries installed for gtk, glib, etc.? > > Or is there a gtk2hs package available for Ubuntu? > > On Sun, 28 Aug 2016, 11:05 PM wrote: >> >> I'm seem rubish, >> but exactly that have I do >> And I have at first install cabal. >> But this is comming: >> >> Resolving dependencies... >> Configuring glib-0.13.4.0... >> Building glib-0.13.4.0... >> Failed to install glib-0.13.4.0 >> Build log ( /home/thomas/.cabal/logs/glib-0.13.4.0.log ): >> [1 of 1] Compiling Main ( >> /tmp/cabal-tmp-4585/glib-0.13.4.0/dist/setup/setup.hs, >> /tmp/cabal-tmp-4585/glib-0.13.4.0/dist/setup/Main.o ) >> Linking /tmp/cabal-tmp-4585/glib-0.13.4.0/dist/setup/setup ... >> Configuring glib-0.13.4.0... >> Building glib-0.13.4.0... >> Preprocessing library glib-0.13.4.0... >> /usr/bin/ld: dist/build/System/Glib/StoreValue_hsc_make.o: Die Umlagerung >> von >> dist/build/System/Glib/StoreValue_hsc_make.o: error adding symbols: >> Ungültiger Wert >> collect2: error: ld returned 1 exit status >> linking dist/build/System/Glib/StoreValue_hsc_make.o failed (exit code 1) >> command was: /usr/bin/gcc dist/build/System/Glib/StoreValue_hsc_make.o >> dist/build/System/Glib/StoreValue_hsc_utils.o -o >> dist/build/System/Glib/StoreValue_hsc_make -fno-PIE -fno-stack-protector >> -lgobject-2.0 -lglib-2.0 >> -L/home/thomas/.cabal/lib/x86_64-linux-ghc-7.10.3/utf8-string-1.0.1.1-L8eKHa7Iv9q7FVKUYW6u4b >> -Wl,-R,/home/thomas/.cabal/lib/x86_64-linux-ghc-7.10.3/utf8-string-1.0.1.1-L8eKHa7Iv9q7FVKUYW6u4b >> -L/home/thomas/.cabal/lib/x86_64-linux-ghc-7.10.3/text-1.2.2.1-HmqVQnZSpjaC156ABqPhne >> -Wl,-R,/home/thomas/.cabal/lib/x86_64-linux-ghc-7.10.3/text-1.2.2.1-HmqVQnZSpjaC156ABqPhne >> -L/usr/lib/ghc/binar_3uXFWMoAGBg0xKP9MHKRwi >> -Wl,-R,/usr/lib/ghc/binar_3uXFWMoAGBg0xKP9MHKRwi >> -L/usr/lib/ghc/conta_2C3ZI8RgPO2LBMidXKTvIU >> -Wl,-R,/usr/lib/ghc/conta_2C3ZI8RgPO2LBMidXKTvIU >> -L/usr/lib/ghc/bytes_6VWy06pWzJq9evDvK2d4w6 >> -Wl,-R,/usr/lib/ghc/bytes_6VWy06pWzJq9evDvK2d4w6 >> -L/usr/lib/ghc/deeps_6vMKxt5sPFR0XsbRWvvq59 >> -Wl,-R,/usr/lib/ghc/deeps_6vMKxt5sPFR0XsbRWvvq59 >> -L/usr/lib/ghc/array_67iodizgJQIIxYVTp4emlA >> -Wl,-R,/usr/lib/ghc/array_67iodizgJQIIxYVTp4emlA >> -L/usr/lib/ghc/base_HQfYBxpPvuw8OunzQu6JGM >> -Wl,-R,/usr/lib/ghc/base_HQfYBxpPvuw8OunzQu6JGM >> -L/usr/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS >> -Wl,-R,/usr/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS -lgmp >> -L/usr/lib/ghc/ghcpr_8TmvWUcS1U1IKHT0levwg3 >> -Wl,-R,/usr/lib/ghc/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/usr/lib/ghc/rts >> -Wl,-R,/usr/lib/ghc/rts -lm -lrt -ldl -lffi >> cabal: Error: some packages failed to install: >> ghcjs-dom-0.2.4.0 depends on glib-0.13.4.0 which failed to install. >> gio-0.13.3.0 depends on glib-0.13.4.0 which failed to install. >> glib-0.13.4.0 failed during the building phase. The exception was: >> ExitFailure 1 >> gtk3-0.14.5 depends on glib-0.13.4.0 which failed to install. >> gtksourceview3-0.13.3.0 depends on glib-0.13.4.0 which failed to install. >> jsaddle-0.3.0.3 depends on glib-0.13.4.0 which failed to install. >> leksah-0.15.2.0 depends on glib-0.13.4.0 which failed to install. >> leksah-server-0.15.2.0 depends on glib-0.13.4.0 which failed to install. >> ltk-0.15.0.5 depends on glib-0.13.4.0 which failed to install. >> pango-0.13.3.0 depends on glib-0.13.4.0 which failed to install. >> vcsgui-0.1.3.0 depends on glib-0.13.4.0 which failed to install. >> webkitgtk3-0.14.2.0 depends on glib-0.13.4.0 which failed to install. >> webkitgtk3-javascriptcore-0.13.2.0 depends on glib-0.13.4.0 which failed >> to >> install. >> >> Please can you help me!!? >> >> >> Gesendet: Sonntag, 28. August 2016 um 14:50 Uhr >> >> Von: "Ivan Lazar Miljenovic" >> An: CCUTM at web.de >> Cc: "Haskell List" >> Betreff: Re: [Haskell] I repeat my Question becaue I not really sure to do >> it right >> On 28 August 2016 at 22:40, wrote: >> > This is Leksah http://leksah.org/ >> > Please excuse my false name for it >> > And the Question is why can I install it. >> >> What error messages do you have when you try? >> >> From here, this is what you need to do: >> https://github.com/leksah/leksah/wiki/download >> >> > cabal install gtk2hs-buildtools >> >> > cabal install leksah >> >> >> >> > >> > excuse me. >> > Mungo1981 >> > >> > Gesendet: Sonntag, 28. August 2016 um 13:49 Uhr >> > Von: "Ivan Lazar Miljenovic" >> > An: CCUTM at web.de >> > Cc: "Haskell List" >> > Betreff: Re: [Haskell] I repeat my Question becaue I not really sure to >> > do >> > it right >> > On 28 August 2016 at 20:43, wrote: >> >> Ok Haskell is good. >> >> Ok Laska is great. >> >> And my Ubuntu Studio ist rubish >> >> So I try to install Laska on Ubuntu Studio >> >> But when I do this, i will get a long list of dependecies >> >> which could not reallise >> >> So I not know what should I do >> > >> > Which question? >> > >> > What is Laska that you're having trouble installing it? >> > >> >> >> >> Mungo1981 >> >> >> >> _______________________________________________ >> >> Haskell mailing list >> >> Haskell at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >> >> >> > >> > >> > >> > -- >> > Ivan Lazar Miljenovic >> > Ivan.Miljenovic at gmail.com >> > http://IvanMiljenovic.wordpress.com >> > >> > _______________________________________________ >> > Haskell mailing list >> > Haskell at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >> > >> >> >> >> -- >> Ivan Lazar Miljenovic >> Ivan.Miljenovic at gmail.com >> http://IvanMiljenovic.wordpress.com -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From jaccokrijnen at gmail.com Mon Aug 29 09:05:35 2016 From: jaccokrijnen at gmail.com (Jacco Krijnen) Date: Mon, 29 Aug 2016 11:05:35 +0200 Subject: [Haskell-cafe] [Haskell] I repeat my Question becaue I not really sure to do it right In-Reply-To: References: Message-ID: ! Please note that Leksah is currently quite unstable. There's quite some known bugs and rough edges so I'd recommend waiting for the next official release. The only reliable way to build it on Linux right now is from source/github with cabal-install >= 1.24 (see https://github.com/leksah/leksah#building-from-source). We're planning to look into .deb installers to make the installation on Linux easier, but there is limited man power and it is not really high-priority. Jacco 2016-08-28 23:36 GMT+02:00 Ivan Lazar Miljenovic : > On 28 August 2016 at 23:15, wrote: > > Hello it is possible that this is the solution. > > But I don't know how I can istall it. > > See the Ubuntu section here: http://www.leksah.org/download.html > > > > > Gesendet: Sonntag, 28. August 2016 um 15:07 Uhr > > Von: "Ivan Lazar Miljenovic" > > An: CCUTM at web.de > > Betreff: Re: Re: [Haskell] I repeat my Question becaue I not really sure > to > > do it right > > Do you have the -dev libraries installed for gtk, glib, etc.? > > > > Or is there a gtk2hs package available for Ubuntu? > > > > On Sun, 28 Aug 2016, 11:05 PM wrote: > >> > >> I'm seem rubish, > >> but exactly that have I do > >> And I have at first install cabal. > >> But this is comming: > >> > >> Resolving dependencies... > >> Configuring glib-0.13.4.0... > >> Building glib-0.13.4.0... > >> Failed to install glib-0.13.4.0 > >> Build log ( /home/thomas/.cabal/logs/glib-0.13.4.0.log ): > >> [1 of 1] Compiling Main ( > >> /tmp/cabal-tmp-4585/glib-0.13.4.0/dist/setup/setup.hs, > >> /tmp/cabal-tmp-4585/glib-0.13.4.0/dist/setup/Main.o ) > >> Linking /tmp/cabal-tmp-4585/glib-0.13.4.0/dist/setup/setup ... > >> Configuring glib-0.13.4.0... > >> Building glib-0.13.4.0... > >> Preprocessing library glib-0.13.4.0... > >> /usr/bin/ld: dist/build/System/Glib/StoreValue_hsc_make.o: Die > Umlagerung > >> von > >> dist/build/System/Glib/StoreValue_hsc_make.o: error adding symbols: > >> Ungültiger Wert > >> collect2: error: ld returned 1 exit status > >> linking dist/build/System/Glib/StoreValue_hsc_make.o failed (exit code > 1) > >> command was: /usr/bin/gcc dist/build/System/Glib/StoreValue_hsc_make.o > >> dist/build/System/Glib/StoreValue_hsc_utils.o -o > >> dist/build/System/Glib/StoreValue_hsc_make -fno-PIE > -fno-stack-protector > >> -lgobject-2.0 -lglib-2.0 > >> -L/home/thomas/.cabal/lib/x86_64-linux-ghc-7.10.3/utf8-string-1.0.1.1- > L8eKHa7Iv9q7FVKUYW6u4b > >> -Wl,-R,/home/thomas/.cabal/lib/x86_64-linux-ghc-7.10.3/ > utf8-string-1.0.1.1-L8eKHa7Iv9q7FVKUYW6u4b > >> -L/home/thomas/.cabal/lib/x86_64-linux-ghc-7.10.3/text-1.2. > 2.1-HmqVQnZSpjaC156ABqPhne > >> -Wl,-R,/home/thomas/.cabal/lib/x86_64-linux-ghc-7.10.3/text-1.2.2.1- > HmqVQnZSpjaC156ABqPhne > >> -L/usr/lib/ghc/binar_3uXFWMoAGBg0xKP9MHKRwi > >> -Wl,-R,/usr/lib/ghc/binar_3uXFWMoAGBg0xKP9MHKRwi > >> -L/usr/lib/ghc/conta_2C3ZI8RgPO2LBMidXKTvIU > >> -Wl,-R,/usr/lib/ghc/conta_2C3ZI8RgPO2LBMidXKTvIU > >> -L/usr/lib/ghc/bytes_6VWy06pWzJq9evDvK2d4w6 > >> -Wl,-R,/usr/lib/ghc/bytes_6VWy06pWzJq9evDvK2d4w6 > >> -L/usr/lib/ghc/deeps_6vMKxt5sPFR0XsbRWvvq59 > >> -Wl,-R,/usr/lib/ghc/deeps_6vMKxt5sPFR0XsbRWvvq59 > >> -L/usr/lib/ghc/array_67iodizgJQIIxYVTp4emlA > >> -Wl,-R,/usr/lib/ghc/array_67iodizgJQIIxYVTp4emlA > >> -L/usr/lib/ghc/base_HQfYBxpPvuw8OunzQu6JGM > >> -Wl,-R,/usr/lib/ghc/base_HQfYBxpPvuw8OunzQu6JGM > >> -L/usr/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS > >> -Wl,-R,/usr/lib/ghc/integ_2aU3IZNMF9a7mQ0OzsZ0dS -lgmp > >> -L/usr/lib/ghc/ghcpr_8TmvWUcS1U1IKHT0levwg3 > >> -Wl,-R,/usr/lib/ghc/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/usr/lib/ghc/rts > >> -Wl,-R,/usr/lib/ghc/rts -lm -lrt -ldl -lffi > >> cabal: Error: some packages failed to install: > >> ghcjs-dom-0.2.4.0 depends on glib-0.13.4.0 which failed to install. > >> gio-0.13.3.0 depends on glib-0.13.4.0 which failed to install. > >> glib-0.13.4.0 failed during the building phase. The exception was: > >> ExitFailure 1 > >> gtk3-0.14.5 depends on glib-0.13.4.0 which failed to install. > >> gtksourceview3-0.13.3.0 depends on glib-0.13.4.0 which failed to > install. > >> jsaddle-0.3.0.3 depends on glib-0.13.4.0 which failed to install. > >> leksah-0.15.2.0 depends on glib-0.13.4.0 which failed to install. > >> leksah-server-0.15.2.0 depends on glib-0.13.4.0 which failed to install. > >> ltk-0.15.0.5 depends on glib-0.13.4.0 which failed to install. > >> pango-0.13.3.0 depends on glib-0.13.4.0 which failed to install. > >> vcsgui-0.1.3.0 depends on glib-0.13.4.0 which failed to install. > >> webkitgtk3-0.14.2.0 depends on glib-0.13.4.0 which failed to install. > >> webkitgtk3-javascriptcore-0.13.2.0 depends on glib-0.13.4.0 which > failed > >> to > >> install. > >> > >> Please can you help me!!? > >> > >> > >> Gesendet: Sonntag, 28. August 2016 um 14:50 Uhr > >> > >> Von: "Ivan Lazar Miljenovic" > >> An: CCUTM at web.de > >> Cc: "Haskell List" > >> Betreff: Re: [Haskell] I repeat my Question becaue I not really sure to > do > >> it right > >> On 28 August 2016 at 22:40, wrote: > >> > This is Leksah http://leksah.org/ > >> > Please excuse my false name for it > >> > And the Question is why can I install it. > >> > >> What error messages do you have when you try? > >> > >> From here, this is what you need to do: > >> https://github.com/leksah/leksah/wiki/download > >> > >> > cabal install gtk2hs-buildtools > >> > >> > cabal install leksah > >> > >> > >> > >> > > >> > excuse me. > >> > Mungo1981 > >> > > >> > Gesendet: Sonntag, 28. August 2016 um 13:49 Uhr > >> > Von: "Ivan Lazar Miljenovic" > >> > An: CCUTM at web.de > >> > Cc: "Haskell List" > >> > Betreff: Re: [Haskell] I repeat my Question becaue I not really sure > to > >> > do > >> > it right > >> > On 28 August 2016 at 20:43, wrote: > >> >> Ok Haskell is good. > >> >> Ok Laska is great. > >> >> And my Ubuntu Studio ist rubish > >> >> So I try to install Laska on Ubuntu Studio > >> >> But when I do this, i will get a long list of dependecies > >> >> which could not reallise > >> >> So I not know what should I do > >> > > >> > Which question? > >> > > >> > What is Laska that you're having trouble installing it? > >> > > >> >> > >> >> Mungo1981 > >> >> > >> >> _______________________________________________ > >> >> Haskell mailing list > >> >> Haskell at haskell.org > >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > >> >> > >> > > >> > > >> > > >> > -- > >> > Ivan Lazar Miljenovic > >> > Ivan.Miljenovic at gmail.com > >> > http://IvanMiljenovic.wordpress.com > >> > > >> > _______________________________________________ > >> > Haskell mailing list > >> > Haskell at haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > >> > > >> > >> > >> > >> -- > >> Ivan Lazar Miljenovic > >> Ivan.Miljenovic at gmail.com > >> http://IvanMiljenovic.wordpress.com > > > > -- > Ivan Lazar Miljenovic > Ivan.Miljenovic at gmail.com > http://IvanMiljenovic.wordpress.com > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Mon Aug 29 18:09:38 2016 From: chrisdone at gmail.com (Christopher Done) Date: Mon, 29 Aug 2016 20:09:38 +0200 Subject: [Haskell-cafe] Which tab width do you prefer for Haskell code? Message-ID: Hi everyone, I'm trying to get a feel for the modern Haskell community's opinion on default tab-width for HIndent. Here is a link to the online poll: http://doodle.com/poll/82xf854t9mmuv22h#table Quote: > For the HIndent tool we'd like to choose the standard tab width. > For now, it is 4, the width set by the Johan Tibell style guide. > A survey of 1000 top-downloaded packages on Hackage reveals about 50-50 either way:https://gist.github.com/chrisdone/e3d1796d8f5df717b91db54aae36c440 > HIndent is meant as a "community standard" tool; it should reflect the community's actual practice. If there's a clear preference for 2, we'll switch to that. Otherwise, we remain with 4. Cheers! From amindfv at gmail.com Mon Aug 29 20:23:34 2016 From: amindfv at gmail.com (Tom Murphy) Date: Mon, 29 Aug 2016 16:23:34 -0400 Subject: [Haskell-cafe] MPTCs and extended defaulting Message-ID: I've got a case in a library I'm working on where having -XExtendedDefaultRules with MPTCs would be very, very helpful. Is it possible? I.e., we can now write: ``` {-# LANGUAGE ExtendedDefaultRules #-} data AB = A | B Double deriving (Show) class Foo x where foo :: x -> AB instance Foo Double where foo = B main = print $ foo 5 ``` And -XExtendedDefaultRules makes sure we don't need to write "5 :: Double" If, though, I want 'Foo' to take another parameter (here, a :: [Symbol]), it falls apart: ``` {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} import GHC.TypeLits data AB = A | B Double deriving (Show) class Foo x (a :: [Symbol]) where foo :: x -> AB instance Foo Double a where foo = B main = print $ foo 5 ``` Is there a reason MPTCs can't support ExtendedDefaultRules? Thanks! Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Tue Aug 30 03:56:56 2016 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Tue, 30 Aug 2016 15:56:56 +1200 Subject: [Haskell-cafe] Which tab width do you prefer for Haskell code? In-Reply-To: References: Message-ID: On 30/08/16 6:09 AM, Christopher Done wrote: > Hi everyone, > > I'm trying to get a feel for the modern Haskell community's opinion on > default tab-width for HIndent. Here is a link to the online poll: > > http://doodle.com/poll/82xf854t9mmuv22h#table > > Quote: > >> For the HIndent tool we'd like to choose the standard tab width. >> For now, it is 4, the width set by the Johan Tibell style guide. >> A survey of 1000 top-downloaded packages on Hackage reveals about 50-50 either way:https://gist.github.com/chrisdone/e3d1796d8f5df717b91db54aae36c440 >> HIndent is meant as a "community standard" tool; it should reflect the community's actual practice. If there's a clear preference for 2, we'll switch to that. Otherwise, we remain with 4. There seems to be some confusion here. The Johan Tibell style guide does NOT "set" "the standard tab width" to 4. Far from it! The guide says plainly "TABS ARE ILLEGAL". What the style guide talks about is INDENTATION steps. Not tab width! When it comes to TAB width, the Haskell 2010 report is explicit and unambiguous, leaving no room for anyone's preferences. Chapter 10 says The "indentation" of a lexeme is the column number of the first character of that lexeme; the indentation of a line is the indentation of its leftmost lexeme. To determine the column number, assume a fixed- width font with the following conventions: * The characters newline, return, linefeed, and formfeed, all start a new line. * The first column is designated column 1, not 0. * TAB STOPS ARE 8 CHARACTERS APART. * A tab character causes the insertion of enough spaces to align the current position with the next tab stop. From cma at bitemyapp.com Tue Aug 30 05:35:32 2016 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 30 Aug 2016 00:35:32 -0500 Subject: [Haskell-cafe] Which tab width do you prefer for Haskell code? In-Reply-To: References: Message-ID: When most Haskellers say tab width, they're colloquially referring to how many literal spaces each "indent" action should be. That is the case here as well. Most Haskellers I know do not use tabs at all to avoid indent issues, unlike Golang which is exclusively tabs. On Mon, Aug 29, 2016 at 10:56 PM, Richard A. O'Keefe wrote: > > > On 30/08/16 6:09 AM, Christopher Done wrote: >> >> Hi everyone, >> >> I'm trying to get a feel for the modern Haskell community's opinion on >> default tab-width for HIndent. Here is a link to the online poll: >> >> http://doodle.com/poll/82xf854t9mmuv22h#table >> >> Quote: >> >>> For the HIndent tool we'd like to choose the standard tab width. >>> For now, it is 4, the width set by the Johan Tibell style guide. >>> A survey of 1000 top-downloaded packages on Hackage reveals about 50-50 >>> either >>> way:https://gist.github.com/chrisdone/e3d1796d8f5df717b91db54aae36c440 >>> HIndent is meant as a "community standard" tool; it should reflect the >>> community's actual practice. If there's a clear preference for 2, we'll >>> switch to that. Otherwise, we remain with 4. > > > There seems to be some confusion here. > The Johan Tibell style guide does NOT "set" > "the standard tab width" to 4. Far from it! > The guide says plainly "TABS ARE ILLEGAL". > > What the style guide talks about is INDENTATION steps. > Not tab width! > > When it comes to TAB width, the Haskell 2010 report > is explicit and unambiguous, leaving no room for > anyone's preferences. Chapter 10 says > > The "indentation" of a lexeme is the column number > of the first character of that lexeme; > the indentation of a line is the indentation of > its leftmost lexeme. > To determine the column number, assume a fixed- > width font with the following conventions: > * The characters newline, return, linefeed, > and formfeed, all start a new line. > * The first column is designated column 1, not 0. > * TAB STOPS ARE 8 CHARACTERS APART. > * A tab character causes the insertion of enough > spaces to align the current position with the > next tab stop. > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -- Chris Allen Currently working on http://haskellbook.com From vandijk.roel at gmail.com Tue Aug 30 07:35:07 2016 From: vandijk.roel at gmail.com (Roel van Dijk) Date: Tue, 30 Aug 2016 09:35:07 +0200 Subject: [Haskell-cafe] Which tab width do you prefer for Haskell code? In-Reply-To: References: Message-ID: Please note that, apparently, anonymous users can delete comments and edit and delete existing entries. I can change my own entry that I created yesterday on a separate system. 2016-08-29 20:09 GMT+02:00 Christopher Done : > Hi everyone, > > I'm trying to get a feel for the modern Haskell community's opinion on > default tab-width for HIndent. Here is a link to the online poll: > > http://doodle.com/poll/82xf854t9mmuv22h#table > > Quote: > > > For the HIndent tool we'd like to choose the standard tab width. > > For now, it is 4, the width set by the Johan Tibell style guide. > > A survey of 1000 top-downloaded packages on Hackage reveals about 50-50 > either way:https://gist.github.com/chrisdone/ > e3d1796d8f5df717b91db54aae36c440 > > HIndent is meant as a "community standard" tool; it should reflect the > community's actual practice. If there's a clear preference for 2, we'll > switch to that. Otherwise, we remain with 4. > > Cheers! > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robstewart57 at gmail.com Tue Aug 30 15:23:16 2016 From: robstewart57 at gmail.com (Rob Stewart) Date: Tue, 30 Aug 2016 16:23:16 +0100 Subject: [Haskell-cafe] Cache miss performance costs for Haskell programs? Message-ID: Hi, Any Haskell profiling and performance tuning blog or tutorial will advise the use of memory space and runtime profiling, using GHC tooling. Far less is said about the impact of increased cache miss rates as program size increases. The paper "Secrets of the Glasgow Haskell Compiler inliner", in the Journal of Functional Programming, July 2002, talks a lot about the benefits of inlining, i.e. it's part of GHCs simplifier as it enables many other optimisations, some that ultimately reduce program size. Not much is said about detrimental effect that bad inlining choices has to runtime. The paper says: "Bloated programs are bad (increased compilation time, lower cache hit rates)" in Section 2.2. I'd really like to see how badly Haskell runtimes are affected as cache hit rates decrease. Is anyone aware of any empirical studies, or papers, or blog posts, that show examples where: For the same Haskell program, increasing inlining causes lower cache hit rates, which slows down runtime due to costly cycles to fetch from main memory more often. Thanks, -- Rob From mail at joachim-breitner.de Tue Aug 30 15:28:11 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 30 Aug 2016 11:28:11 -0400 Subject: [Haskell-cafe] Cache miss performance costs for Haskell programs? In-Reply-To: References: Message-ID: <1472570891.1636.9.camel@joachim-breitner.de> Hi Rob, Am Dienstag, den 30.08.2016, 16:23 +0100 schrieb Rob Stewart: > I'd really like to see how badly Haskell runtimes are affected as > cache hit rates decrease. Is anyone aware of any empirical studies, or > papers, or blog posts, that show examples where: > > For the same Haskell program, increasing inlining causes lower cache > hit rates, which slows down runtime due to costly cycles to fetch from > main memory more often. note quite inlinine, but I have had an experience like this when evaluating the benefit of the Call Arity program analysis. Here is the relevant excerpt from my thesis (§3.5.3, you can find the thesis at http://www.joachim-breitner.de/thesis/): Initially, I attempted to use the actual run time measurements, but it turned out to be a mostly pointless endeavour. For example the knights benchmark would become 9% slower when enabling Call Arity (i.e. when comparing (A) to (B)), a completely unexpected result, given that the changes to the GHC Core code were reasonable. Further investigation using performance data obtained from the CPU indicated that with the changed code, the CPU’s instruction decoder was idling for more cycles, hinting at cache effects and/or bad program layout. Indeed: When I compiled the code with the compiler flag -g, which includes debugging information in the resulting binary, but should oth- erwise not affect the relative performance characteristics much, the un- expected difference vanished. I conclude that non-local changes to the Haskell or Core code will change the layout of the generated program code in unpredictable ways and render such run time measurements mostly meaningless. This conclusion has been drawn before [MDHS09], and recently, tools to mitigate this effect, e.g. by randomising the code layout [CB13], were created. Unfortunately, these currently target specific C compilers, so I could not use them here. In the following measurements, I avoid this problem by not measuring program execution time, but simply by counting the number of instruc- tions performed. This way, the variability in execution time due to code layout does not affect the results. To obtain the instruction counts I em- ploy valgrind [NS07], which runs the benchmarks on a virtual CPU and thus produces more reliable and reproducible measurements. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From robstewart57 at gmail.com Tue Aug 30 15:57:08 2016 From: robstewart57 at gmail.com (Rob Stewart) Date: Tue, 30 Aug 2016 16:57:08 +0100 Subject: [Haskell-cafe] Cache miss performance costs for Haskell programs? In-Reply-To: <1472570891.1636.9.camel@joachim-breitner.de> References: <1472570891.1636.9.camel@joachim-breitner.de> Message-ID: Hi Joachim, Thanks for the reply, and really interesting work! > In the following measurements, I avoid this problem by not measuring program execution time, but simply by counting the number of instructions performed. Are these a count of all instructions performed at runtime? Did you isolate a count of just the memory access instructions that ended up fetching from main memory? Also, did you measure the clock cycle latency averages for memory access instructions for (B) (C) and (D), to get an indication of cache misses? I've just measured this program with perf: fib 0 = 0 fib 1 = 1 fib n = fib (n-1) + fib (n-2) main = print $ fib 39 I.e. perf stat -e task-clock,cycles,instructions,cache-references,cache-misses fib-exe 63245986 Performance counter stats for 'fib-exe': 5989.527848 task-clock (msec) # 1.268 CPUs utilized 18,825,545,684 cycles # 3.143 GHz 42,833,528,405 instructions # 2.28 insns per cycle 70,496,109 cache-references # 11.770 M/sec 161,186 cache-misses # 0.229 % of all cache refs 4.725101260 seconds time elapsed For three runs, the number of cache misses were: 161186 (4.7 seconds), 80802 (4.4 seconds), and 102681 (4.5 seconds). I'm interested in hearing about Haskell developers who've used Valgrind, or perf, to start caring about ensuring minimising executable size, by injecting NOINLINE pragmas or removing INLINE pragmas. -- Rob On 30 August 2016 at 16:28, Joachim Breitner wrote: > Hi Rob, > > Am Dienstag, den 30.08.2016, 16:23 +0100 schrieb Rob Stewart: >> I'd really like to see how badly Haskell runtimes are affected as >> cache hit rates decrease. Is anyone aware of any empirical studies, or >> papers, or blog posts, that show examples where: >> >> For the same Haskell program, increasing inlining causes lower cache >> hit rates, which slows down runtime due to costly cycles to fetch from >> main memory more often. > > note quite inlinine, but I have had an experience like this when > evaluating the benefit of the Call Arity program analysis. Here is the > relevant excerpt from my thesis (§3.5.3, you can find the thesis at > http://www.joachim-breitner.de/thesis/): > > Initially, I attempted to use the actual run time measurements, but it > turned out to be a mostly pointless endeavour. For example the knights > benchmark would become 9% slower when enabling Call Arity (i.e. when > comparing (A) to (B)), a completely unexpected result, given that the > changes to the GHC Core code were reasonable. Further investigation > using performance data obtained from the CPU indicated that with the > changed code, the CPU’s instruction decoder was idling for more cycles, > hinting at cache effects and/or bad program layout. > > Indeed: When I compiled the code with the compiler flag -g, which > includes debugging information in the resulting binary, but should oth- > erwise not affect the relative performance characteristics much, the un- > expected difference vanished. I conclude that non-local changes to the > Haskell or Core code will change the layout of the generated program > code in unpredictable ways and render such run time measurements > mostly meaningless. > > This conclusion has been drawn before [MDHS09], and recently, tools > to mitigate this effect, e.g. by randomising the code layout [CB13], were > created. Unfortunately, these currently target specific C compilers, so I > could not use them here. > > In the following measurements, I avoid this problem by not measuring > program execution time, but simply by counting the number of instruc- > tions performed. This way, the variability in execution time due to code > layout does not affect the results. To obtain the instruction counts I em- > ploy valgrind [NS07], which runs the benchmarks on a virtual CPU and > thus produces more reliable and reproducible measurements. > > Greetings, > Joachim > -- > Joachim “nomeata” Breitner > mail at joachim-breitner.de • https://www.joachim-breitner.de/ > XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F > Debian Developer: nomeata at debian.org > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From branimir.maksimovic at gmail.com Tue Aug 30 16:06:34 2016 From: branimir.maksimovic at gmail.com (Branimir Maksimovic) Date: Tue, 30 Aug 2016 18:06:34 +0200 Subject: [Haskell-cafe] Cache miss performance costs for Haskell programs? In-Reply-To: References: <1472570891.1636.9.camel@joachim-breitner.de> Message-ID: Keep in mind that OS interrupts process about 1000 times per second and completely invalidates cache that many times. Greets. On 08/30/2016 05:57 PM, Rob Stewart wrote: > Hi Joachim, > > Thanks for the reply, and really interesting work! > >> In the following measurements, I avoid this problem by not measuring program execution time, but simply by counting the number of instructions performed. > Are these a count of all instructions performed at runtime? Did you > isolate a count of just the memory access instructions that ended up > fetching from main memory? Also, did you measure the clock cycle > latency averages for memory access instructions for (B) (C) and (D), > to get an indication of cache misses? > > I've just measured this program with perf: > > fib 0 = 0 > fib 1 = 1 > fib n = fib (n-1) + fib (n-2) > > main = print $ fib 39 > > I.e. > > perf stat -e task-clock,cycles,instructions,cache-references,cache-misses > fib-exe > 63245986 > > Performance counter stats for 'fib-exe': > > 5989.527848 task-clock (msec) # 1.268 CPUs > utilized > 18,825,545,684 cycles # 3.143 GHz > 42,833,528,405 instructions # 2.28 insns per > cycle > 70,496,109 cache-references # 11.770 M/sec > 161,186 cache-misses # 0.229 % of all > cache refs > > 4.725101260 seconds time elapsed > > > For three runs, the number of cache misses were: 161186 (4.7 seconds), > 80802 (4.4 seconds), and 102681 (4.5 seconds). > > I'm interested in hearing about Haskell developers who've used > Valgrind, or perf, to start caring about ensuring minimising > executable size, by injecting NOINLINE pragmas or removing INLINE > pragmas. > > -- > Rob > > > > On 30 August 2016 at 16:28, Joachim Breitner wrote: >> Hi Rob, >> >> Am Dienstag, den 30.08.2016, 16:23 +0100 schrieb Rob Stewart: >>> I'd really like to see how badly Haskell runtimes are affected as >>> cache hit rates decrease. Is anyone aware of any empirical studies, or >>> papers, or blog posts, that show examples where: >>> >>> For the same Haskell program, increasing inlining causes lower cache >>> hit rates, which slows down runtime due to costly cycles to fetch from >>> main memory more often. >> note quite inlinine, but I have had an experience like this when >> evaluating the benefit of the Call Arity program analysis. Here is the >> relevant excerpt from my thesis (§3.5.3, you can find the thesis at >> http://www.joachim-breitner.de/thesis/): >> >> Initially, I attempted to use the actual run time measurements, but it >> turned out to be a mostly pointless endeavour. For example the knights >> benchmark would become 9% slower when enabling Call Arity (i.e. when >> comparing (A) to (B)), a completely unexpected result, given that the >> changes to the GHC Core code were reasonable. Further investigation >> using performance data obtained from the CPU indicated that with the >> changed code, the CPU’s instruction decoder was idling for more cycles, >> hinting at cache effects and/or bad program layout. >> >> Indeed: When I compiled the code with the compiler flag -g, which >> includes debugging information in the resulting binary, but should oth- >> erwise not affect the relative performance characteristics much, the un- >> expected difference vanished. I conclude that non-local changes to the >> Haskell or Core code will change the layout of the generated program >> code in unpredictable ways and render such run time measurements >> mostly meaningless. >> >> This conclusion has been drawn before [MDHS09], and recently, tools >> to mitigate this effect, e.g. by randomising the code layout [CB13], were >> created. Unfortunately, these currently target specific C compilers, so I >> could not use them here. >> >> In the following measurements, I avoid this problem by not measuring >> program execution time, but simply by counting the number of instruc- >> tions performed. This way, the variability in execution time due to code >> layout does not affect the results. To obtain the instruction counts I em- >> ploy valgrind [NS07], which runs the benchmarks on a virtual CPU and >> thus produces more reliable and reproducible measurements. >> >> Greetings, >> Joachim >> -- >> Joachim “nomeata” Breitner >> mail at joachim-breitner.de • https://www.joachim-breitner.de/ >> XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F >> Debian Developer: nomeata at debian.org >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. From svenpanne at gmail.com Tue Aug 30 18:01:45 2016 From: svenpanne at gmail.com (Sven Panne) Date: Tue, 30 Aug 2016 20:01:45 +0200 Subject: [Haskell-cafe] Cache miss performance costs for Haskell programs? In-Reply-To: References: <1472570891.1636.9.camel@joachim-breitner.de> Message-ID: 2016-08-30 17:57 GMT+02:00 Rob Stewart : > [...] I'm interested in hearing about Haskell developers who've used > Valgrind, or perf, to start caring about ensuring minimising > executable size, by injecting NOINLINE pragmas or removing INLINE > pragmas. > Note that the size of an executable and memory cache hit rates are only some of the many things heavily influencing performance. You can easily get a slowdown of an order of magnitude if your program e.g. interacts badly with branch prediction or if it has pseudo-dependencies between instructions due to partial register writes. One can work around these issues on a low level: * If the branch predictor has no clue, backward jumps are normally assumed to be taken (loops!) and forward jumps are assumed to be not taken. So your code generator should better layout the common case in a straight line. * Use the right dependency-breaking instructions when needed, see e.g. section 3.5.1.8 "Clearing Registers and Dependency Breaking Idioms" in http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf . * If you ever wondered why e.g. the Intel processors have various seemingly identical instructions, the answer is: Some registers are internally "typed", and you pay a relatively high cost if you access the in an "untyped" manner. If LLVM is used as the backend, this should be handled automatically, at least if we give the right hints to it. In a nutshell: Size matters only sometimes. ;-) If you really care about performance in detail, you have to look at lots of perf values, e.g. pipeline stalls, branch mispredictions, etc. etc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Aug 31 02:52:03 2016 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 30 Aug 2016 22:52:03 -0400 Subject: [Haskell-cafe] Cache miss performance costs for Haskell programs? In-Reply-To: References: <1472570891.1636.9.camel@joachim-breitner.de> Message-ID: <1472611923.23196.5.camel@joachim-breitner.de> Hi Rob, Am Dienstag, den 30.08.2016, 16:57 +0100 schrieb Rob Stewart: > Thanks for the reply, and really interesting work! > > > > > In the following measurements, I avoid this problem by not > > measuring program execution time, but simply by counting the number > > of instructions performed. > > Are these a count of all instructions performed at runtime? Did you > isolate a count of just the memory access instructions that ended up > fetching from main memory? Also, did you measure the clock cycle > latency averages for memory access instructions for (B) (C) and (D), > to get an indication of cache misses? I did not dig deeper. I just ran the test suite under valgrind (nofib has support for that) and took the number of instructions that came out. My working hypothesis was that the effect of high level (i.e. Core) transformation on code layout / branch prediction / pipeline stuff / cache hits and misses are too hard to predict and such measurements would not give me useful information. But you seem to be after a more optimistic and principled approach here, so I’ll be keen to hear what you find out. Greetings, Joachim -- Joachim “nomeata” Breitner   mail at joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata at joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From david.feuer at gmail.com Wed Aug 31 05:51:40 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 31 Aug 2016 01:51:40 -0400 Subject: [Haskell-cafe] Announcing containers 0.5.8.1 Message-ID: There's a lot to see in this one. There are plenty of brand-new functions in Data.Map, Data.Set, and Data.Sequence, including a highly-optimized lens-inspired map alteration function and a brand-new API for merging maps efficiently. Several key map, set, and sequence functions have sped up considerably. The full change log is below. I have tried to give appropriate credit to all the non-maintainers who contributed to this release, some of whom made very major contributions indeed. If I missed anyone, please give a shout. General package changes: Remove all attempts to support nhc98 and any versions of GHC before 7.0. Integrate benchmarks with Cabal. (Thanks, Gabriel Gonzalez!) Make Cabal report required extensions properly, and stop using default extensions. Note that we do not report extensions conditionally enabled based on GHC version, as doing so would lead to a maintenance nightmare with no obvious benefits. Use BangPatterns throughout to reduce noise. This extension is now required to compile containers. Improve QuickCheck properties taking arbitrary functions by using Test.QuickCheck.Function.Fun instead of evil Show instances for functions. Expose several internal modules through Cabal (as requested by Edward Kmett). These remain completely unsupported. New exports and instances: Add alterF, restrictKeys, and withoutKeys to Data.Map and Data.IntMap. Add take, drop, splitAt, takeWhileAntitone, dropWhileAntitone, and spanAntitone for Data.Map and Data.Set. Thanks to Cale Gibbard for suggesting these. Add merge, mergeA, and associated merge tactics for Data.Map. Many thanks to Cale Gibbard, Ryan Trinkle, and Dan Doel for inspiring the merge idea and helping refine the interface. Add fromDescList, fromDescListWith, fromDescListWithKey, and fromDistinctDescList to Data.Map. Add fromDescList and fromDistinctDescList to Data.Set. Add Empty, :<|, and :|> pattern synonyms for Data.Sequence, as originally envisioned in the finger tree paper by Paterson and Hinze. Add adjust', (!?), lookup, chunksOf, cycleTaking, insertAt, deleteAt, intersperse, foldMapWithIndex, and traverseWithIndex for Data.Sequence. Derive Generic and Generic1 for Data.Tree.Tree, Data.Sequence.ViewL, and Data.Sequence.ViewR. Add foldTree for Data.Tree. (Thanks, Daniel Wagner!) Semantic changes: Make Data.Sequence.splitAt strict in its arguments. Previously, it returned a lazy pair. Fix completely erroneous definition of length for Data.Sequence.ViewR. Make Data.Map.Strict.traverseWithKey force result values before installing them in the new map. Make Data.Tree.drawTree handle newlines better. (Thanks, recursion-ninja!) Deprecations: All functions in Data.Map proper that have been documented as deprecated since version 0.5 or before now have DEPRECATED pragmas and will actually be removed after another cycle or two. Tree printing functions in Data.Map intended for library debugging are now deprecated. They will continue to be available for the foreseeable future in an internal module. Performance changes: Substantially speed up splitAt, zipWith, take, drop, fromList, partition, foldl', and foldr' for Data.Sequence. Special thanks to Lennart Spitzner for digging into the performance problems with previous versions of fromList and finding a way to make it really fast. Slightly optimize replicateA. Stop traverse from performing many unnecessary fmap operations. Most operations in Data.Sequence advertised as taking logarithmic time (including >< and adjust) now use their full allotted time to avoid potentially building up chains of thunks in the tree. In general, the only remaining operations that avoid doing more than they really need are the particular bulk creation and transformation functions that really benefit from the extra laziness. There are some situations where this change may slow programs down, but I think having more predictable and usually better performance more than makes up for that. Add rewrite rules to fuse fmap with reverse for Data.Sequence. Switch from hedge algorithms to divide-and-conquer algorithms for union, intersection, difference, and merge in both Data.Map and Data.Set. These algorithms are simpler, are known to be asymptotically optimal, and are faster according to our benchmarks. Speed up adjust for Data.Map. Allow map to inline, and define a custom (<$). This considerably improves mapping with a constant function. Remove non-essential laziness throughout the Data.Map.Lazy implementation. Slightly speed up deletion and alteration functions for Data.IntMap. From heraldhoi at gmail.com Wed Aug 31 07:36:52 2016 From: heraldhoi at gmail.com (Geraldus) Date: Wed, 31 Aug 2016 07:36:52 +0000 Subject: [Haskell-cafe] Announcing containers 0.5.8.1 In-Reply-To: References: Message-ID: Wow, thanks! ср, 31 авг. 2016 г. в 10:52, David Feuer : > There's a lot to see in this one. There are plenty of brand-new > functions in Data.Map, Data.Set, and Data.Sequence, including a > highly-optimized lens-inspired map alteration function and a brand-new > API for merging maps efficiently. Several key map, set, and sequence > functions have sped up considerably. The full change log is below. I > have tried to give appropriate credit to all the non-maintainers who > contributed to this release, some of whom made very major > contributions indeed. If I missed anyone, please give a shout. > > > General package changes: > > Remove all attempts to support nhc98 and any versions of GHC before 7.0. > > Integrate benchmarks with Cabal. (Thanks, Gabriel Gonzalez!) > > Make Cabal report required extensions properly, and stop using default > extensions. Note that we do not report extensions conditionally > enabled based on GHC version, as doing so would lead to a maintenance > nightmare with no obvious benefits. > > Use BangPatterns throughout to reduce noise. This extension is now > required to compile containers. > > Improve QuickCheck properties taking arbitrary functions by using > Test.QuickCheck.Function.Fun instead of evil Show instances for > functions. > > Expose several internal modules through Cabal (as requested by Edward > Kmett). These remain completely unsupported. > > > > New exports and instances: > > Add alterF, restrictKeys, and withoutKeys to Data.Map and Data.IntMap. > > Add take, drop, splitAt, takeWhileAntitone, dropWhileAntitone, and > spanAntitone for Data.Map and Data.Set. Thanks to Cale Gibbard for > suggesting these. > > Add merge, mergeA, and associated merge tactics for Data.Map. Many > thanks to Cale Gibbard, Ryan Trinkle, and Dan Doel for inspiring the > merge idea and helping refine the interface. > > Add fromDescList, fromDescListWith, fromDescListWithKey, and > fromDistinctDescList to Data.Map. > > Add fromDescList and fromDistinctDescList to Data.Set. > > Add Empty, :<|, and :|> pattern synonyms for Data.Sequence, as > originally envisioned in the finger tree paper by Paterson and Hinze. > > Add adjust', (!?), lookup, chunksOf, cycleTaking, insertAt, deleteAt, > intersperse, foldMapWithIndex, and traverseWithIndex for > Data.Sequence. > > Derive Generic and Generic1 for Data.Tree.Tree, Data.Sequence.ViewL, > and Data.Sequence.ViewR. > > Add foldTree for Data.Tree. (Thanks, Daniel Wagner!) > > > > Semantic changes: > > Make Data.Sequence.splitAt strict in its arguments. Previously, it > returned a lazy pair. > > Fix completely erroneous definition of length for Data.Sequence.ViewR. > > Make Data.Map.Strict.traverseWithKey force result values before > installing them in the new map. > > Make Data.Tree.drawTree handle newlines better. (Thanks, recursion-ninja!) > > > > Deprecations: > > All functions in Data.Map proper that have been documented as > deprecated since version 0.5 or before now have DEPRECATED pragmas and > will actually be removed after another cycle or two. > > Tree printing functions in Data.Map intended for library debugging are > now deprecated. They will continue to be available for the foreseeable > future in an internal module. > > > > Performance changes: > > Substantially speed up splitAt, zipWith, take, drop, fromList, > partition, foldl', and foldr' for Data.Sequence. Special thanks to > Lennart Spitzner for digging into the performance problems with > previous versions of fromList and finding a way to make it really > fast. Slightly optimize replicateA. Stop traverse from performing many > unnecessary fmap operations. > > Most operations in Data.Sequence advertised as taking logarithmic time > (including >< and adjust) now use their full allotted time to avoid > potentially building up chains of thunks in the tree. In general, the > only remaining operations that avoid doing more than they really need > are the particular bulk creation and transformation functions that > really benefit from the extra laziness. There are some situations > where this change may slow programs down, but I think having more > predictable and usually better performance more than makes up for > that. > > Add rewrite rules to fuse fmap with reverse for Data.Sequence. > > Switch from hedge algorithms to divide-and-conquer algorithms for > union, intersection, difference, and merge in both Data.Map and > Data.Set. These algorithms are simpler, are known to be asymptotically > optimal, and are faster according to our benchmarks. > > Speed up adjust for Data.Map. Allow map to inline, and define a custom > (<$). This considerably improves mapping with a constant function. > > Remove non-essential laziness throughout the Data.Map.Lazy implementation. > > Slightly speed up deletion and alteration functions for Data.IntMap. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lemming at henning-thielemann.de Wed Aug 31 09:10:22 2016 From: lemming at henning-thielemann.de (Henning Thielemann) Date: Wed, 31 Aug 2016 11:10:22 +0200 (CEST) Subject: [Haskell-cafe] Announcing containers 0.5.8.1 In-Reply-To: References: Message-ID: On Wed, 31 Aug 2016, David Feuer wrote: > Use BangPatterns throughout to reduce noise. This extension is now > required to compile containers. Btw. there is no strong need for BangPatterns. Instead of f !x !y = ... you can write f = strict2 $ \x y -> ... {-# INLINE strict2 #-} strict2 :: (a -> b -> x) -> a -> b -> x strict2 f a b = (f $! a) $! b Sometimes I hope that availability of portable libraries would help non-mainstream compilers to gain ground. From ram at rkrishnan.org Wed Aug 31 09:52:14 2016 From: ram at rkrishnan.org (Ramakrishnan Muthukrishnan) Date: Wed, 31 Aug 2016 15:22:14 +0530 Subject: [Haskell-cafe] Cache miss performance costs for Haskell programs? In-Reply-To: References: Message-ID: <1472637134.4129548.711315297.2D54B33B@webmail.messagingengine.com> On Tue, Aug 30, 2016, at 08:53 PM, Rob Stewart wrote: > > Any Haskell profiling and performance tuning blog or tutorial will > advise the use of memory space and runtime profiling, using GHC > tooling. Far less is said about the impact of increased cache miss > rates as program size increases. > > The paper "Secrets of the Glasgow Haskell Compiler inliner", in the > Journal of Functional Programming, July 2002, talks a lot about the > benefits of inlining, i.e. it's part of GHCs simplifier as it enables > many other optimisations, some that ultimately reduce program size. > > Not much is said about detrimental effect that bad inlining choices > has to runtime. The paper says: "Bloated programs are bad (increased > compilation time, lower cache hit rates)" in Section 2.2. > > I'd really like to see how badly Haskell runtimes are affected as > cache hit rates decrease. Is anyone aware of any empirical studies, or > papers, or blog posts, that show examples where: > > For the same Haskell program, increasing inlining causes lower cache > hit rates, which slows down runtime due to costly cycles to fetch from > main memory more often. Hi Rob, Have you looked at the `perf' tool supported in recent linux kernel versions? It seem to have tools to report cache statistics. I haven't used it on Haskell programs though.. -- Ramakrishnan From merijn at inconsistent.nl Wed Aug 31 10:34:31 2016 From: merijn at inconsistent.nl (Merijn Verstraaten) Date: Wed, 31 Aug 2016 12:34:31 +0200 Subject: [Haskell-cafe] Cache miss performance costs for Haskell programs? In-Reply-To: <1472637134.4129548.711315297.2D54B33B@webmail.messagingengine.com> References: <1472637134.4129548.711315297.2D54B33B@webmail.messagingengine.com> Message-ID: <6C34F8A4-BD67-438C-B61E-8B6D882EDBDC@inconsistent.nl> Accidentally didn't address the mailing list: Additionally, if you want to investigate things like cache misses, etc. Intel VTune Amplifier is an amazing profiling tool and there is a non-commercial open source license available for it. Cheers, Merijn > On 31 Aug 2016, at 11:52, Ramakrishnan Muthukrishnan wrote: > > On Tue, Aug 30, 2016, at 08:53 PM, Rob Stewart wrote: >> >> Any Haskell profiling and performance tuning blog or tutorial will >> advise the use of memory space and runtime profiling, using GHC >> tooling. Far less is said about the impact of increased cache miss >> rates as program size increases. >> >> The paper "Secrets of the Glasgow Haskell Compiler inliner", in the >> Journal of Functional Programming, July 2002, talks a lot about the >> benefits of inlining, i.e. it's part of GHCs simplifier as it enables >> many other optimisations, some that ultimately reduce program size. >> >> Not much is said about detrimental effect that bad inlining choices >> has to runtime. The paper says: "Bloated programs are bad (increased >> compilation time, lower cache hit rates)" in Section 2.2. >> >> I'd really like to see how badly Haskell runtimes are affected as >> cache hit rates decrease. Is anyone aware of any empirical studies, or >> papers, or blog posts, that show examples where: >> >> For the same Haskell program, increasing inlining causes lower cache >> hit rates, which slows down runtime due to costly cycles to fetch from >> main memory more often. > > Hi Rob, > > Have you looked at the `perf' tool supported in recent linux kernel > versions? It seem to have tools to report cache statistics. > > > > I haven't used it on Haskell programs though.. > > -- > Ramakrishnan > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From david.feuer at gmail.com Wed Aug 31 13:04:10 2016 From: david.feuer at gmail.com (David Feuer) Date: Wed, 31 Aug 2016 09:04:10 -0400 Subject: [Haskell-cafe] Announcing containers 0.5.8.1 In-Reply-To: References: Message-ID: Wren and I made the decision to use bang patterns to make it easier for us to read and write the code. We hope that rather modest extension will be in the next Haskell Report. From my perspective, this decision is non-negotiable. It's just too hard for my poor brain to work with all the possible strictification functions we'd need for various numbers of arguments and the awkwardness required to use them. This was previously done with a combination of manual seq and CPP, and I found it nasty. On Aug 31, 2016 5:10 AM, "Henning Thielemann" wrote: > > On Wed, 31 Aug 2016, David Feuer wrote: > > Use BangPatterns throughout to reduce noise. This extension is now >> required to compile containers. >> > > Btw. there is no strong need for BangPatterns. Instead of > > f !x !y = ... > > you can write > > f = strict2 $ \x y -> ... > > {-# INLINE strict2 #-} > strict2 :: (a -> b -> x) -> a -> b -> x > strict2 f a b = (f $! a) $! b > > > Sometimes I hope that availability of portable libraries would help > non-mainstream compilers to gain ground. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.skladnoy at gmail.com Wed Aug 31 13:44:12 2016 From: alexey.skladnoy at gmail.com (Alexey Khudyakov) Date: Wed, 31 Aug 2016 16:44:12 +0300 Subject: [Haskell-cafe] Announcing containers 0.5.8.1 In-Reply-To: References: Message-ID: On 31 August 2016 at 12:10, Henning Thielemann wrote: > On Wed, 31 Aug 2016, David Feuer wrote: > >> Use BangPatterns throughout to reduce noise. This extension is now >> required to compile containers. > > Btw. there is no strong need for BangPatterns. Instead of > > ... > > Sometimes I hope that availability of portable libraries would help > non-mainstream compilers to gain ground. > Compiler that doesn't support bang patterns (and half of GHC extensions) cannot gain ground. From p.giarrusso at gmail.com Wed Aug 31 17:34:43 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Wed, 31 Aug 2016 10:34:43 -0700 (PDT) Subject: [Haskell-cafe] Which tab width do you prefer for Haskell code? In-Reply-To: References: Message-ID: <411f4164-7db0-4ac4-969c-8fa46dd14dad@googlegroups.com> On Tuesday, August 30, 2016 at 9:35:42 AM UTC+2, Roel van Dijk wrote: > > Please note that, apparently, anonymous users can delete comments and edit > and delete existing entries. I can change my own entry that I created > yesterday on a separate system. > FWIW Anonymous users can delete anonymous entries on Doodle—if you vote after logging in, your vote and comments are locked in. > 2016-08-29 20:09 GMT+02:00 Christopher Done >: > >> Hi everyone, >> >> I'm trying to get a feel for the modern Haskell community's opinion on >> default tab-width for HIndent. Here is a link to the online poll: >> >> http://doodle.com/poll/82xf854t9mmuv22h#table >> >> Quote: >> >> > For the HIndent tool we'd like to choose the standard tab width. >> > For now, it is 4, the width set by the Johan Tibell style guide. >> > A survey of 1000 top-downloaded packages on Hackage reveals about 50-50 >> either way: >> https://gist.github.com/chrisdone/e3d1796d8f5df717b91db54aae36c440 >> > HIndent is meant as a "community standard" tool; it should reflect the >> community's actual practice. If there's a clear preference for 2, we'll >> switch to that. Otherwise, we remain with 4. >> >> Cheers! >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.giarrusso at gmail.com Wed Aug 31 20:39:32 2016 From: p.giarrusso at gmail.com (Paolo Giarrusso) Date: Wed, 31 Aug 2016 13:39:32 -0700 (PDT) Subject: [Haskell-cafe] StdGen Reliability Across Versions / Systems In-Reply-To: <57C1216D.1010002@zoho.com> References: <57C1216D.1010002@zoho.com> Message-ID: <01614b31-b843-4cd7-b44b-d435d86f132c@googlegroups.com> On Saturday, August 27, 2016 at 7:13:28 AM UTC+2, Christopher Howard wrote: > > I know that, ff you feed mkStdGen a particular seed, and pull a list of > random numbers from that StdGen, that that the list will always be the > same if your run your compiled program over and over again on that same > system. But which of the following will cause you to get different output?: > > 2) Changes in "random" library version > Here's my semi-informed two cents: In principle yes if they change random-generation algorithm. 1) Changes in GHC version > 3) Compiling / Running on a different host computer (but compiling with > the same GHC & random versions. > IIUC no: the actual random number generator is not only a fully deterministic algorithm, but is written using simple integer arithmetic (not even bitwise operations) which should always have the same semantics (my only doubt is about the size of `Int`). OTOH generating random floating-point numbers does more hackery which would require a closer inspection. Reference: stdNext and stdSplit in http://hackage.haskell.org/package/random-1.1/docs/src/System-Random.html#StdGen For further details and better reassurances, you might have better luck asking the authors (on GitHub). Maybe this could be documented? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.dubuisson at gmail.com Wed Aug 31 20:48:24 2016 From: thomas.dubuisson at gmail.com (Thomas DuBuisson) Date: Wed, 31 Aug 2016 13:48:24 -0700 Subject: [Haskell-cafe] StdGen Reliability Across Versions / Systems In-Reply-To: <57C1216D.1010002@zoho.com> References: <57C1216D.1010002@zoho.com> Message-ID: If you want random numbers that are consistent across package version changes then you could simply leverage a package that aims to implement a standard. Short of bug fixes, code implementing a standard should not behave differently across versions. For example, use a cryptographic algorithm (AES CTR or ChaCha20) or a standardized cryptographic RNG like Hash SP 800-90 as your RNG. -Thomas On Fri, Aug 26, 2016 at 10:13 PM, Christopher Howard wrote: > I know that, ff you feed mkStdGen a particular seed, and pull a list of > random numbers from that StdGen, that that the list will always be the > same if your run your compiled program over and over again on that same > system. But which of the following will cause you to get different output?: > > 1) Changes in GHC version > 2) Changes in "random" library version > 3) Compiling / Running on a different host computer (but compiling with > the same GHC & random versions. > > -- > https://qlfiles.net > My PGP public key ID is 0x340EA95A (pgp.mit.edu). > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.