- Haskell-Cafe - Haskell.org

ICFP 2016 Call for Workshop and Co-located Event Proposals
by Lindsey Kuper 23 Oct '15

23 Oct '15

         CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS                             ICFP 2016  21st ACM SIGPLAN International Conference on Functional Programming                      September 18-24, 2016                           Nara, Japan                http://icfpconference.org/icfp2016/ The 21st ACM SIGPLAN International Conference on Functional Programming will be held in Nara, Japan on September 18-24, 2016. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as tutorials) to be affiliated with ICFP 2016 and sponsored by SIGPLAN. These events should be less formal and more focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on September 18 (the day before ICFP) and September 22-24 (the three days after ICFP). ---------------------------------------------------------------------- Submission details  Deadline for submission:     November 21, 2015  Notification of acceptance:  December 20, 2015 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2016 workshop co-chairs (Andres Loeh and Nicolas Wu), via email to     icfp2016-workshops(a)googlegroups.com by November 21, 2015. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 20, 2015, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2016-files/icfp16-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://www.sigplan.org/Resources/Proposals/Sponsored/ ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2016 organizing committee, together with the members of the SIGPLAN executive committee.  Workshop Co-Chair: Andres Loeh                        (Well-Typed LLP)  Workshop Co-Chair: Nicolas Wu                  (University of Bristol)  General Co-Chair : Jacques Garrigue                (Nagoya University)  General Co-Chair : Gabriele Keller     (University of New South Wales)  Program Chair:     Eijiro Sumii                    (Tohoku University) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (Andres Loeh and Nicolas Wu), via email to icfp2016-workshops(a)googlegroups.com

1 0

[ANN] haskell-ide project
by Alan & Kim Zimmerman 23 Oct '15

23 Oct '15

The ongoing effort to save us as a community from separately implementing the same functionality over and over around IDEs[1] has found a home in the haskell-ide project on github [2]. This mail serves as a call to collaborate for all parties interested in this space. It is still at a very early stage, but the intent is to pool resources so that we can have really good support for IDEs that can extend through the entire tool chain from changes to GHC to better support tooling through the build environment and community information management. This should mean that people who are familiar with a particular part of the chain can focus their efforts there, knowing that the other parts will be covered too. This is a deliberately broad and vague scope, the reality is likely to be much more limited initially, but the sooner we can get started the sooner we will have something concrete to criticise and improve. For those wishing to get involved the following resources currently exist * the haskell-ide mailing list [3] * the github project page [1] * The #haskell-ide channel on IRC Freenode. This is not aimed at some small inner circle of people, anyone who wants to will be added to the project on github, adress your request to me or @hvr. Regards Alan [1] IDE is a loose term for anything that enables a user to interact with the code. [2] https://github.com/haskell/haskell-ide [3] https://groups.google.com/forum/#!forum/haskell-ide

2 1

New STM Data Structures Collection
by Алексей Семин 23 Oct '15

23 Oct '15

Hi everyone! I want to present a couple of STM data structures which were implemented by me and Ryan Yates this summer (during GSOC 2015). I decided to create only a candidate package [1]. I would be glad if anyone can take a look and/or comment on topic. Since Hackage does not provide the easy way to `cabal install` candidate packages I have written a script [2] which should do all the work for you. It create a directory in /tmp and initialized sandbox along with cloning the library from github [3]. After that it will download Haskell program with an example of data structure usage. Thank you for your attention. [1] https://hackage.haskell.org/package/stm-data-collection-0.1.0.0/candidate [2] https://gist.github.com/Alllex/445f3d74e872fe032596 [3] https://github.com/Alllex/stm-data-collection -- Regards, Alex Semin

7 6

how to create a pipes producer from websockets?
by Dimitri DeFigueiredo 22 Oct '15

22 Oct '15

Hello All, I am trying to use both the websockets library and the pipes library. They seem like a natural fit. However, I wanted to use the websockets library to build a pipes 'Producer' and that does not seem possible without some heavy lifting. The websockets library does not give me a connection I can read from and write to. Instead, I need to supply an IO action (called a clientApp). And execute it using something like: --runClient :: String -- ^ Host -- -> Int -- ^ Port -- -> String -- ^ Path -- -> ClientApp a -- ^ Client application -- type ClientApp a = Connection -> IO a -- -> IO a main :: IO () main = withSocketsDo $ runClient "echo.websocket.org" 80 "/" app The problem happens when you couple this restriction with the requirement that ClientApps have type 'Connection -> IO a'. Pipes producers are Monad transformer stacks. For example, I would like to build something like: messageProducer :: Producer' WebsocketMessage IO () But this does not run in the IO monad and at the same time I cannot get a 'Connection' object unless I use runClient. So, it seems I have a catch22 situation. Or have I overlooked something? I'd rather not have to do "un-lifting" on the monad transformer stack. Has anyone done this before? Any suggestions on how to go about it? Thanks, Dimitri

3 2

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Simon Thompson 21 Oct '15

21 Oct '15

Hello all. I write this to be a little provocative, but … It’s really interesting to have this discussion, which pulls in all sorts of well-made points about orthogonality, teaching, the evolution of the language and so on, but it simply goes to show that the process of evolving Haskell is profoundly broken. Other languages do evolve, but in a managed and reflective way. Simply throwing in changes that would have a profound impact on systems that are commercially and potentially safety critical in an à la carte, offhand, way seems like a breakdown of the collective responsibility of the Haskell community to its users and, indirectly, to its future. If we make claims - I believe rightly - that Haskell is hitting the mainstream, then we need to think about all changes in terms of the costs and benefits of each of them in the widest possible sense. There’s an old fashioned maxim that sums this up in a pithy way: “if it ain’t broke, don’t fix it”. Simon Thompson > On 5 Oct 2015, at 10:47, Michał J Gajda <mjgajda(a)gmail.com> wrote: > > Hi, > > As a person who used Haskell in all three capacities (for scientific research, for commercial purpose, and to introduce others to benefits of pure and strongly typed programming), I must voice an supportive voice for this change: > 1. Orthogonal type classes are easier to explain. > 2. Gradual improvements helps us to generalize further, and this in turn makes education easier. > 3. Gradual change that break only a little help to prevent either stagnation (FORTRAN) and big breakage (py3k). That keeps us excited. > > That would also call to split TCs into their orthogonal elements: return, ap, bind having the basic TC on their own. > > So: > +1, but only if it is possible to have compatibilty mode. I believe that rebindable syntax should allow us to otherwise make our own prelude, if we want such a split. Then we could test it well before it is used by the base library. > > That said, I would appreciate Haskell2010 option just like Haskell98 wad, so that we can compile old programs without changes. Even by using some Compat version of standard library. Would that satisfy need for stability? > > PS And since all experts were beginners some time ago, I beg that we do not call them "peripheral". > -- > Best regards > Michał > > On Monday, 5 October 2015, Malcolm Wallace <malcolm.wallace(a)me.com <mailto:malcolm.wallace@me.com>> wrote: > On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be > (...) > > > -- > Pozdrawiam > Michał > _______________________________________________ > Haskell-prime mailing list > Haskell-prime(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt

53 97

[ANN] codex 0.4
by Alois Cochard 21 Oct '15

21 Oct '15

Hello Café, I have released a new version of `codex`[1] (a ctags file generator for cabal/stack projects and their dependencies). This release include some fixes but more important it *include support for `stack`* projects. As `stack` is multi-platform and so is `codex`, it should work seamlessly on any OS but I have only done testing on unix. Cheers [1] https://github.com/ <https://github.com/aloiscochard/codex>aloiscochard/ codex <https://github.com/aloiscochard/codex> -- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

1 0

Hac Phi: Haskell Exchange in Philadelphia, Nov 6-8
by Richard Eisenberg 21 Oct '15

21 Oct '15

Hi café, Hac Phi, a yearly weekend of Haskell in Philadelphia, will take place Nov. 6-8, hosted 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. Though the event has the same structure as in previous years, it has been renamed from a Haskell Hackathon to a Haskell Exchange (not to be confused with The Haskell eXchange, a different event.) The organizers felt that the title "hackathon" has been given to events too unlike Hac Phi, events where participants code under pressure or over long times in competition. Those are fun affairs, indeed... but they're not like Hac Phi. So, we now say that Hac Phi is a yearly Haskell Exchange, where academics, professionals, and hobbyists can all meet, mingle, hack on each others' projects, and generally have a good time. All the details are on the wiki page: https://wiki.haskell.org/Hac_Phi I hope to see you there! Richard

1 1

Callstack Implicit Param for Unsafe Prelude Functions
by aditya siram 20 Oct '15

20 Oct '15

Since the latest base now has a way of getting generating stack traces via the `CallStack` implicit param, is there any reason not to add that param to the error messages of unsafe functions in the Prelude ( and even commonly used modules like Data.Maybe/Data.List)? The type signature will change but for most users it should be a drop-in replacement and a great aid to debugging. Thanks! -deech

3 2

Job opportunities at Kaspersky Lab (Moscow)
by Dmitry Kulagin 20 Oct '15

20 Oct '15

Here at Kaspersky Lab, we are developing a secure platform&framework. We have two job opportunities right now. Both opportunities assume good command of Haskell, since we use Haskell extensively. These are full time positions, available at our Moscow (Russia) office. If you are interested, please apply on the corporate site or send your CV to me directly at dmitry.kulagin(a)kaspersky.com Descriptions: Software Engineer: Responsibilities: * Development of core of the security system * Tools development (such as compilers/DSL) Skills/experience: * Strong experience developing with Haskell * C/C++ development experience * Good knowledge of basic algorithms and data structures * Compilers/DSLs development experience (desirable) * System programming experience (desirable) * Understanding of OS internals (desirable) * Experience in development of embedded and/or real-time applications (desirable) URL: * http://www.kaspersky.ru/job?vac=283264 Researcher (formal methods/computer security): Responsibilities: * Development of approaches to express and verify security and safety properties of systems Skills/experience: * Masters degree in CS or equivalent. PhD in CS (or related field) is desirable * Strong interest in computer security * Experience in formal verification * Good writing and presentation skills * Haskell programming experience is highly desirable * C-programming experience (desirable) * Prolog programming experience (desirable) URL: * http://www.kaspersky.ru/job?vac=283263

2 1

Displaying specializations in :info or separately?
by David Kraeutmann 20 Oct '15

20 Oct '15

Hi, I'm working on a GHC feature [1] that allows users to view specializations of functions like in (name subject to change) ---- > :binfo find find :: Foldable t => (a -> Bool) -> t a -> Maybe a Specialisations: t ~ [] => find :: (a -> Bool) -> [a] -> Maybe a > :binfo first first :: Arrow a => a b c -> a (b, d) (c, d) Specialisations: a ~ (->) => first :: (b -> c) -> (b, d) -> (c, d) ---- Now there are two things left to decide on: * What command should the specializations be visible under? We can either put it under :info or make a special command :sinfo or :binfo that displays only the expression's type and specialisations like in the example above? * What specializations do we want to display? goldfire suggested using the default list, which has the added benefit of being customizable by e.g. instructors, so adding a default Maybe (in conjunction with [2]) gives the desired behavior and not too many specializations. Thanks for your time! David ---- Links: [1] : https://ghc.haskell.org/trac/ghc/ticket/10972 [2] : https://ghc.haskell.org/trac/ghc/ticket/10971

5 5