[Haskell-cafe] ANN: yi-0.6.7
Hello Cafe After about a year we've released a new version of Yi, text editor written and extensible in Haskell. Please have a look, hopefully you can find something interesting for you, whether you are emacs, vim or $(your-favorite-editor) fan. Changelog is available at https://github.com/yi-editor/yi/blob/master/CHANGELOG We currently lack active maintainers for Pango and Cocoa frontends, Emacs emulation and some smaller modules. Contributors in these areas are especially welcome. Also we have almost no user-level documentation compared to other editors, so if someone new to yi would set it up to his liking and share the experience on wiki or his blog or somewhere else, that would also be a very nice contribution. Places to dicuss using and developing yi: mailing list: https://groups.google.com/group/yi-devel issue tracker: https://github.com/yi-editor/yi/issues IRC channel: #yi@freenode (it's very slow compared to #haskell, please don't quit after 10 mins) Regards, Dmitry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using a win32 dll (Happy too soon)
Brandon, thank you for your explanation. I got it working with: ghc --make testGlasPng.hs -LD:\glas\dlls -lglasPng. It needs both the -L and the -l argument. The dll is in the PATH. I don't understand why it needs the -L argument. I'll figure this out later. If I use -lglasPng.dll (additional .dll) it doesn't work either. Now everything works fine. I can pass strings from haskell to the dll and vice versa. Kees -- On Wed, May 29, 2013 at 9:40 AM, Kees Bleijenberg k.bleijenb...@lijbrandt.nl wrote: If I compile with ghc --make testGlasPng.hs –lglasPng I get: ….\ld.exe: cannot find –lglasPng. Collect 2: ld returned 1 exit status. Ld can’t find lglasPng (with the l in front, does it trim the l?). Why? Okay I try It's reproducing the thing passed to it, rather than outputting both the dll and implib versions that it actually looks for. Same happens on unixlikes where it's looking for a .so/.dylib/whatever or a .a. ghc --make testGlasPng.hs –Lpath to glasPng.dll I get: Not quite right; -L identifies a *directory* to search, then you must specify the actual filename afterward. testGlasPng.o: fake: (.text + 0x82) :undefined reference to ‘getPngVersion@0’. I think it has found the This just means it can't find the symbol; it does not mean it necessarily found the DLL. I run ghc on a 64 bits computer. The dll is 32 bits. Is that the problem? That can certainly be a problem, yes, and is likely why it wasn't found with the first one. But it's not so much what kind of machine you are on, as what kind of ghc you are using: a 64-bit ghc cannot link 32-bit libraries, and vice versa. But a 32-bit ghc and toolchain will work fine on a 64-bit system, aside from not linking 64-bit DLLs. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Problem with compilation on MAC OS X
New machine, latest version of the Haskell Platform for 64 bit Mac OS X. In trying to build a new version of cabal-install and also of Agda I get variants of the same error dist/build/autogen/Paths_Agda.hs:21:13: Not in scope: `catch' any thoughts on what I am doing wrong? I have XCode command line tools installed. Thanks! Simon T. Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thomp...@kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Problem with compilation on MAC OS X
Thanks - unfortunately it breaks cabal-install too! S. On 30 May 2013, at 13:28, Artyom Kazak artyom.ka...@gmail.com wrote: Apparently, Agda has been broken by the recent decision to remove 'catch', which had already been deprecated for some time, from Prelude. You can fix the source yourself, or wait for a new release. On May 30, 2013 3:04 PM, Simon Thompson s.j.thomp...@kent.ac.uk wrote: Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thomp...@kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using a win32 dll (Happy too soon)
On Thu, May 30, 2013 at 3:15 AM, Kees Bleijenberg k.bleijenb...@lijbrandt.nl wrote: argument. The dll is in the PATH. I don't understand why it needs the -L argument. I'll figure this out later. If I use -lglasPng.dll (additional .dll) it doesn't work either. Unix has standard places to install and search for libraries; Windows doesn't, and almost every library that doesn't come with your build system will need at least one -L option to tell the linker where to find it. As I mentioned in my first message, it looks for multiple file names with -l: first it tries a .dll, then it tries a .lib (static library or import library for older DLLs). It does this mechanically; if you also include the .dll suffix, then it looks for library.dll.dll and library.dll.lib, which is almost certainly wrong. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using a win32 dll (Happy too soon)
Brandon, thanks again for your explanation Are you sure about the non existing search order for dynamic loaded dll’s? I.e. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx#standard_search_order_for_desktop_applications says there is a search order, starting with the current directory (I think). I don’t understand why the linker needs to see the dll anyway. I think you should be able to develop a executable (that later will use a dll), while the dll isn’t there at link time. The dll only has to be there at runtime (kind of lazy loading..). Or maybe not even that. I.e. the executable uses the dll only in special cases and the user can download this dll if he wants it. This is possible in Delphi. Is Haskell dynamic loading more limited? Kees Van: Brandon Allbery [mailto:allber...@gmail.com] Verzonden: donderdag 30 mei 2013 16:13 Aan: Kees Bleijenberg CC: haskell-cafe Onderwerp: Re: [Haskell-cafe] using a win32 dll (Happy too soon) On Thu, May 30, 2013 at 3:15 AM, Kees Bleijenberg k.bleijenb...@lijbrandt.nl wrote: argument. The dll is in the PATH. I don't understand why it needs the -L argument. I'll figure this out later. If I use -lglasPng.dll (additional .dll) it doesn't work either. Unix has standard places to install and search for libraries; Windows doesn't, and almost every library that doesn't come with your build system will need at least one -L option to tell the linker where to find it. As I mentioned in my first message, it looks for multiple file names with -l: first it tries a .dll, then it tries a .lib (static library or import library for older DLLs). It does this mechanically; if you also include the .dll suffix, then it looks for library.dll.dll and library.dll.lib, which is almost certainly wrong. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Two GHC-related GSoC Proposals
What's the plan for what control / synchronization structures you'll use in part 2 of the plan to implement a parallel driver? Is the idea just to use an IO thread for each compile and block them on MVars when they encounter dependencies? Or you can use a pool of worker threads and a work queue, and only add modules to the work queue when all their dependencies are met (limits memory use)... many options for executing a task DAG. Fortunately the granularity is coarse. -Ryan On Sun, Apr 21, 2013 at 10:34 PM, Patrick Palka patr...@parcs.ath.cxwrote: Good points. I did not take into account whether proposal #2 may be worth it in light of -fllvm. I suppose that even if the LLVM codegen is able to perform similar optimizations, it would still be beneficial to implement proposal #2 as a core-to-core pass because the transformations it performs would expose new information to subsequent core-to-core passes. Also, Haskell has different overflow rules than C does (whose rules I assume LLVM's optimizations are modeled from): In Haskell, integer overflow is undefined for all integral types, whereas in C it's only undefined for signed integral types. This limits the number of optimizations a C-based optimizer can perform on unsigned arithmetic. I'm not sure how I would break up the parallel compilation proposal into multiple self-contained units of work. I can only think of two units: making GHC thread safe, and writing the new parallel compilation driver. Other incidental units may come up during development (e.g. parallel compilation might exacerbate #4012http://hackage.haskell.org/trac/ghc/ticket/4012), but I still feel that three months of full time work is ample time to complete the project, especially with existing familiarity with the code base. Thanks for the feedback. On Sun, Apr 21, 2013 at 5:55 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Hey Patrick, both are excellent ideas for work that would be really valuable for the community! (independent of whether or not they can be made into GSOC sided chunks ) --- I'm actually hoping to invest some time this summer investigating improving the numerics optimization story in ghc. This is in large part because I'm writing LOTs of numeric codes in haskell presently (hopefully on track to make some available to the community ). That said, its not entirely obvious (at least to me) what a tractable focused GSOC sized subset of the numerics optimization improvement would be, and that would have to also be a subset that has real performance impact and doesn't benefit from eg using -fllvm rather than -fasm . - For helping pave the way to better parallel builds, what are some self contained units of work on ghc (or related work on cabal) that might be tractable over a summer? If you can put together a clear roadmap of work chunks that are tractable over the course of the summer, I'd favor choosing that work, especially if you can give a clear outline of the plan per chunk and how to evaluate the success of each unit of work. basically: while both are high value projects, helping improve the parallel build tooling (whether in performance or correctness or both!) has a more obvious scope of community impact, and if you can layout a clear plan of work that GHC folks agree with and seems doable, i'd favor that project :) hope this feedback helps you sort out project ideas cheers -Carter On Sun, Apr 21, 2013 at 12:20 PM, Patrick Palka patr...@parcs.ath.cxwrote: Hi, I'm interested in participating in the GSoC by improving GHC with one of these two features: 1) Implement native support for compiling modules in parallel (see #910http://hackage.haskell.org/trac/ghc/ticket/910). This will involve making the compilation pipeline thread-safe, implementing the logic for building modules in parallel (with an emphasis on keeping compiler output deterministic), and lots of testing and benchmarking. Being able to seamlessly build modules in parallel will shorten the time it takes to recompile a project and will therefore improve the life of every GHC user. 2) Improve existing constant folding, strength reduction and peephole optimizations on arithmetic and logical expressions, and optionally implement a core-to-core pass for optimizing nested comparisons (relevant tickets include #2132 http://hackage.haskell.org/trac/ghc/ticket/2132, #5615 http://hackage.haskell.org/trac/ghc/ticket/5615,#4101http://hackage.haskell.org/trac/ghc/ticket/4101). GHC currently performs some of these simplifications (via its BuiltinRule framework), but there is a lot of room for improvement. For instance, the core for this snippet is essentially identical to the Haskell source: foo :: Int - Int - Int - Int foo a b c = 10*((b+7+a+12+b+9)+4) + 5*(a+7+b+12+a+9) + 7 + b + c Yet the RHS is actually equivalent to 20*a + 26*b + c + 467 And: bar :: Int - Int - Int bar a b = a + b - a -
Re: [Haskell-cafe] using a win32 dll (Happy too soon)
On Thu, May 30, 2013 at 11:46 AM, Kees Bleijenberg k.bleijenb...@lijbrandt.nl wrote: Brandon, thanks again for your explanation Are you sure about the non existing search order for dynamic loaded dll’s? I.e. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx#standard_search_order_for_desktop_applicationssays there is a search order, starting with the current directory (I think). There is a search order. What I said is that there are no standard locations to install things. That is, every library package stows stuff in its own directory structure and no compiler can possibly know all the places it needs to look to find every library off in its own directory. I don’t understand why the linker needs to see the dll anyway. Because it's better to catch that symbol doesn't exist at build time instead of throwing an ugly error at runtime, among other things. possible in Delphi. Is Haskell dynamic loading more limited? There are ways to do that kind of dynamic linking; this is not one of them. C and C++ don't automatically dynload the way you're thinking either, because you should test for the DLL you're distributing (you are distributing it, right, not forcing the end user on a wild goose chase to find their own copy of the DLL, hoping it's the right/compatible version, and figure out where to put it so your program will run?) being the right one *when you build the program*, not defer that test until it is run. If you think about it, this is very similar to doing your type checking at compile time instead of runtime. If you want lazy type checking, why are you using Haskell? If you want lazy library checking, why are you using a compiler? -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell.org Google Summer of Code 2013] Approved Projects
Similarly (to some degree), in the ML world John Reppy had a very nice system that employed user customization via combinators rather than inference to generate application/library specific FFIs, see: http://people.cs.uchicago.edu/~jhr/papers/2006/gpce-fig.pdf On 29 May 2013 18:57, Jason Dagit dag...@gmail.com wrote: Are you folks aware of the work on this topic by Tristan Ravitch? https://github.com/travitch/foreign-inference Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN stm-chans 2.1 / 3.0
-- stm-chans 2.1 / 3.0
The stm-chans package offers a collection of channel types, similar to
Control.Concurrent.STM.{TChan,TQueue} but with additional features.
-- Changes (since 2.0.0)
By popular demand, the functions newBroadcastTMChan{,IO} have been
added. However, these rely on newBroadcastTChan{,IO} which are only
available in stm = 2.4 and do not appear to be replicable using the
public API of stm 2.4. Thus, the minimum version of stm is now 2.4,
which obviates all the compatibility modules.
Version 2.1.0 adds the new functions and issues deprecation warnings
about using the compatibility modules. This version is just to help
people transition. If you can use this version without warnings (i.e.,
you don't use the Compat modules directly) then you should be able to
use version 3.0 as well.
Version 3.0 removes the compatibility modules.
-- Long description
In particular stm-chans offers the following data types:
* Control.Concurrent.STM.TBChan: Bounded FIFO channels.
When the channel is full, writers will block/retry. This ensures
that the writers do not get too far ahead of the readers, which helps to
make sure that memory and cpu resources are used responsibly.
* Control.Concurrent.STM.TMChan: Closeable FIFO channels.
* Control.Concurrent.STM.TMQueue: Closeable FIFO queues.
Like TChan (Maybe a) but with a monotonicity guarantee that once
Nothing is returned all future reads will be Nothing as well.
* Control.Concurrent.STM.TBMChan: Bounded Closeable FIFO channels.
* Control.Concurrent.STM.TBMQueue: Bounded Closeable FIFO queues.
Combines the capabilities of TBChan and TMChan.
-- Links
Homepage:
http://code.haskell.org/~wren/
Hackage:
http://hackage.haskell.org/package/stm-chans
Darcs:
http://community.haskell.org/~wren/stm-chans
Haddock (Darcs version):
http://community.haskell.org/~wren/stm-chans/dist/doc/html/stm-chans
--
Live well,
~wren
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell.org Google Summer of Code 2013] Approved Projects
thanks for these references all. As some folks who help with GSOC mentoring have pointed out offline, this summers work is not to be a research project, but a concretely achievable over the summer by a single student project. if we hit hard obstacles i'll help sort out a concrete path that maintains a path to success, but research here isn't the goal. rather lets make something that WORKS WELL. Sometimes the novelty requirements for research are contrary to the best tech choices for building robust usable tools. point being, thanks for sharing the fun reading, if any can help the student along, i'm happy to pass it along, but lets not nerd snipe students into other projects. (i'm bad enough with that for myself as is :) ) On Thu, May 30, 2013 at 2:27 PM, Stephen Tetley stephen.tet...@gmail.comwrote: Similarly (to some degree), in the ML world John Reppy had a very nice system that employed user customization via combinators rather than inference to generate application/library specific FFIs, see: http://people.cs.uchicago.edu/~jhr/papers/2006/gpce-fig.pdf On 29 May 2013 18:57, Jason Dagit dag...@gmail.com wrote: Are you folks aware of the work on this topic by Tristan Ravitch? https://github.com/travitch/foreign-inference Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using a win32 dll (Happy too soon)
On Thu, 30 May 2013 16:13:22 +0200, Brandon Allbery allber...@gmail.com wrote: On Thu, May 30, 2013 at 3:15 AM, Kees Bleijenberg k.bleijenb...@lijbrandt.nl wrote: argument. The dll is in the PATH. I don't understand why it needs the -L argument. I'll figure this out later. If I use -lglasPng.dll (additional .dll) it doesn't work either. Unix has standard places to install and search for libraries; Windows doesn't, and almost every library that doesn't come with your build system will need at least one -L option to tell the linker where to find it. You could also try using the environment variable LIBRARY_PATH, see; http://www.haskell.org/haskellwiki/Windows#Tools_for_compilation Regards, Henk-Jan van Tuyl -- Folding@home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Projects using Shake
Hi, I'm considering to convert one of my projects to Shake; everything I've seen so far seemed really interesting! However, before I start, I'd like to see how other people structure their Shake-based build systems. I tried to find some open source projects which showcase how Shake is used, but unfortunately I didn't find anything yet. Is anybody aware of open source projects which I could look at, or is there maybe a conventional file extension for… what do you call them, Shakefiles? other than .hs which I could google for? -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Projects using Shake
On Thu, May 30, 2013 at 8:17 PM, Frerich Raabe ra...@froglogic.com wrote: Hi, I'm considering to convert one of my projects to Shake; everything I've seen so far seemed really interesting! However, before I start, I'd like to see how other people structure their Shake-based build systems. I tried to find some open source projects which showcase how Shake is used, but unfortunately I didn't find anything yet. Is anybody aware of open source projects which I could look at, or is there maybe a conventional file extension for… what do you call them, Shakefiles? other than .hs which I could google for? Hi Frerich, There are a couple hackages that depend on shake: http://packdeps.haskellers.com/reverse/shake -- Adam ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 268
Welcome to issue 268 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the week of May 12 to 25, 2013. Quotes of the Week * tikhonjelvis: the lesson is that the fix function exists to fix any type problems you may encounter * shachaf: The trouble with peano arithmetic is that it stops at 88. * Peaker: Python's dynamic nature adds slowness and unsafety, but doesn't actually make things more expressive * sj4nz: Programming in weakly-typed languages forever after will feel like working with punch cards. Send in your program to the nodejs interpreter and hope for a result to come back. * xplat: if you want to carry your machete all the time and not make people nervous, you need to constantly blaze trails * otters: heh, F# is just the unboxed version of F * quchen: This was the first time in months that I thought imperatively. Conclusion: 1. it complicated things, 2. it was refreshing * cmccann: I still kind of expect that the next standard will be haskell2017 or something, and all it will do is a minor change to lexical syntax of comments that fixes nothing but nevertheless breaks 20% of hackage. * cmccann: [on reimplementing cryptography in pure Haskell] writing in Haskell lets you use type safety to ensure that all the security holes you create are subtle instead of obvious. Top Reddit Stories * Haskell in Production [slides] Domain: mth.io, Score: 60, Comments: 114 On Reddit: [1] http://goo.gl/ldnv0 Original: [2] http://goo.gl/tMjTd * B-trees with GADTs Domain: matthew.brecknell.net, Score: 56, Comments: 6 On Reddit: [3] http://goo.gl/Sjf9U Original: [4] http://goo.gl/sQnYW * Yearly revisions to the Haskell language: who killed Haskell Prime? Domain: self.haskell, Score: 54, Comments: 19 On Reddit: [5] http://goo.gl/5GWKg Original: [6] http://goo.gl/5GWKg * Elm paper accepted at PLDI: Asynchronous FRP for GUIs! Domain: people.seas.harvard.edu, Score: 51, Comments: 4 On Reddit: [7] http://goo.gl/iYiyh Original: [8] http://goo.gl/98jft * The complete correctness of sorting [Agda] Domain: twanvl.nl, Score: 49, Comments: 5 On Reddit: [9] http://goo.gl/PLH6m Original: [10] http://goo.gl/RQGZn * Anatomy of an MVar operation Domain: blog.ezyang.com, Score: 47, Comments: 7 On Reddit: [11] http://goo.gl/7miao Original: [12] http://goo.gl/3ZHSI * Typing Haskell in Haskell Domain: web.cecs.pdx.edu, Score: 44, Comments: 34 On Reddit: [13] http://goo.gl/q1ghy Original: [14] http://goo.gl/M5csQ * STM in Haskell is better because of types Domain: joeyh.name, Score: 44, Comments: 8 On Reddit: [15] http://goo.gl/wj9Ab Original: [16] http://goo.gl/fmLM1 * Typed Template Haskell ready for testing in GHC Domain: haskell.org, Score: 44, Comments: 13 On Reddit: [17] http://goo.gl/he61y Original: [18] http://goo.gl/YJIZB * A detailed look at GHC's STM implementation from a non-GHC hacker Domain: fryguybob.github.io, Score: 38, Comments: 11 On Reddit: [19] http://goo.gl/pTp2c Original: [20] http://goo.gl/4oe3Y * New Haskell Communities and Activity Report (May 2013) is out Domain: haskell.org, Score: 37, Comments: 2 On Reddit: [21] http://goo.gl/P2kz1 Original: [22] http://goo.gl/YoIE4 * Three examples of problems with Lazy I/O Domain: newartisans.com, Score: 36, Comments: 31 On Reddit: [23] http://goo.gl/reKqZ Original: [24] http://goo.gl/ZagPt * Understanding the Yoneda Lemma Domain: fpcomplete.com, Score: 35, Comments: 48 On Reddit: [25] http://goo.gl/RUZ4h Original: [26] http://goo.gl/xbAJj * Simon Peyton Jones to keynote Haskell eXchange 2013! Domain: skillsmatter.com, Score: 35, Comments: 2 On Reddit: [27] http://goo.gl/DlfRt Original: [28] http://goo.gl/5lpwh * Greg Hale's Functional programming elevator pitch Domain: fpcomplete.com, Score: 34, Comments: 8 On Reddit: [29] http://goo.gl/gbhX3 Original: [30] http://goo.gl/QrrxP * FP Complete is looking for a Technical Sales Engineer and Support Specialist Domain: fpcomplete.com, Score: 32, Comments: 1 On Reddit: [31] http://goo.gl/nYNci Original: [32] http://goo.gl/VGCoa * A Typed Markup Language Based On Haskell Domain: blog.functorial.com, Score: 31, Comments: 9 On Reddit: [33] http://goo.gl/eLLjV Original: [34] http://goo.gl/wFxcv * Announcing: Snap Framework v0.12 Domain: snapframework.com, Score: 28, Comments: 2 On Reddit: [35] http://goo.gl/5wYLk Original: [36] http://goo.gl/KibyP * John Wiegley's Understanding Continuations, on School of Haskell Domain: fpcomplete.com, Score: 27, Comments: 17 On Reddit: [37] http://goo.gl/ZT7d6 Original: [38]
Re: [Haskell-cafe] mapFst and mapSnd
On Tue, May 28, 2013 at 1:54 AM, Dominique Devriese dominique.devri...@cs.kuleuven.be wrote: Hi all, I often find myself needing the following definitions: mapPair :: (a - b) - (c - d) - (a,c) - (b,d) mapPair f g (x,y) = (f x, g y) mapFst :: (a - b) - (a,c) - (b,c) mapFst f = mapPair f id mapSnd :: (b - c) - (a,b) - (a,c) mapSnd = mapPair id But they seem missing from the prelude and Hoogle or Hayoo only turn up versions of them in packages like scion or fgl. Has anyone else felt the need for these functions? Am I missing some generalisation of them perhaps? One generalization of them is to lenses. For example `lens` has both, _1, _2, such that mapPair = over both, mapFst = over _1, etc., but you can also get fst = view _1, set _2 = \y' (x,_) - (x,y'), and so on. (Since both refers to two elements, you end up with view both = \(x,y) - mappend x y.) The types you end up with are simple generalizations of mapFoo, with just an extra Functor or Applicative (think mapMFoo): both :: Applicative f = (a - f b) - (a,a) - f (b,b) both f (x,y) = (,) $ f x * g y _2 :: Functor f = (a - f b) - (e,a) - f (e,b) _2 f (x,y) = (,) x $ f y With an appropriate choice of f you can get many useful functions. Shachaf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mapFst and mapSnd
On Thu, May 30, 2013 at 7:12 PM, Shachaf Ben-Kiki shac...@gmail.com wrote: One generalization of them is to lenses. For example `lens` has both, _1, _2, such that mapPair = over both, mapFst = over _1, etc., but you can also get fst = view _1, set _2 = \y' (x,_) - (x,y'), and so on. (Since both refers to two elements, you end up with view both = \(x,y) - mappend x y.) The types you end up with are simple generalizations of mapFoo, with just an extra Functor or Applicative (think mapMFoo): both :: Applicative f = (a - f b) - (a,a) - f (b,b) both f (x,y) = (,) $ f x * g y _2 :: Functor f = (a - f b) - (e,a) - f (e,b) _2 f (x,y) = (,) x $ f y With an appropriate choice of f you can get many useful functions. I spoke too quickly -- your mapPair is something different. Indeed bimap (or (***), if you prefer base) is the place to find it -- lenses don't really fit here. My both is for mapping one function over both elements. Shachaf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
