- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Transforming from on State-transformer to another
by Olaf Klinke 22 Nov '19

22 Nov '19

> Am 21.11.2019 um 22:56 schrieb Jacques Carette <carette(a)mcmaster.ca>: > > On 2019-Nov.-21 15:57 , Olaf Klinke wrote: >>> Is there a way to have a function of type (a -> b) -> State a c -> State >>> b c ? >> djinn says no. The reason ist that the a occurs both positively and negatively in State a c, that is, on the left and the right hand side of the -> in State. >> >>> In the particular case of interest, I am interested in is actually b -> >>> State a c -> (State (a,b) c), which is of course a special case of the >>> above. >> djinn says yes. The suggested term is >> >> \f -> \(a,b) -> let (a,c) = f a in ((a,b),c) > > > Thanks. I tried to play with the online djinn to ask about exactly this - and failed! How should I be asking? I downloaded the djinn package and built it with cabal. > > Also, something is weird about that term, since it doesn't match "b -> State a c -> (State (a,b) c)" at all. It does match "(b -> State a c) -> (State (a,b) c)" which is a completely different type (and not interesting...) Sorry, I tried to simplify djinn's output and failed. The term should be \f -> \(a,b) -> let (c,a') = f a in (c,(a',b)) :: (a -> (c, a3)) -> (a, b) -> (c, (a3, b)) where you can let a3 = a to get State a c -> State (a,b) c That is, it maps a transformer of state a into a transformer of state (a,b) that leaves the b component unchanged. Olaf

1 0

Re: [Haskell-cafe] filepath
by Johannes Waldmann 21 Nov '19

21 Nov '19

Dear Cafe, is there a library that provides an "abstract representation of file and directory pathnames"? This had been discussed before - e.g., https://mail.haskell.org/pipermail/libraries/2007-December/008769.html (it's one message of a longer thread) That message references an obsolete (?) Java library, they now have https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/nio/file/… It seems that https://hackage.haskell.org/package/filepattern-0.1.1/docs/System-FilePatte… does cover typical usage. It is based on FilePath = String, and its implementation has some "++"-ing. That indicates that an abstraction layer is missing - or, that such a layer is indeed not required? - J.W.

2 1

Transforming from on State-transformer to another
by Jacques Carette 20 Nov '19

20 Nov '19

Is there a way to have a function of type (a -> b) -> State a c -> State b c ? In the particular case of interest, I am interested in is actually b -> State a c -> (State (a,b) c), which is of course a special case of the above. This matches 'first' on Data.Bifunctor, but State is not a Bifunctor. Nor a Profunctor, AFAIK. Use case: a Stateful computation where a local sub-computation needs more (local) state that will be, in-time, de-allocated. I guess the usual solution is probably to use 2 stacked State, but I'm curious if there's another way. Jacques

4 4

Summer internship with a Haskell-related project (DAAD Rise Germany)
by Niels Bunkenburg 19 Nov '19

19 Nov '19

My department (PL and compiler construction) at the University of Kiel, Germany, offers a summer internship in 2020 sponsored by DAAD Rise Germany [1]. The topic of the project is verification of effectful Haskell programs in Coq. For a brief overview of the internship and the topic, please have a look at the project page [2]. We'd be very happy to host a motivated student who likes working with our haskell-to-coq compiler. Depending on personal interests, the focus of the internship can be the compiler itself or its output and the Coq framework for reasoning about the generated code. Previous knowledge of Coq is not required! If you have any questions beforehand, feel free to reply directly or email us at the addresses listed on the project page. The program funding is based on the number of applications, so please spread the news to your colleagues, students or classmates! Best regards, Niels [1] https://www.daad.de/rise/en/rise-germany/find-an-internship/ [2] https://bunkenburg.net/projects/2019-11-01-daad-rise.html

1 0

[Job] PureScript and Haskell, Tokyo or remote
by Ramin Honary 19 Nov '19

19 Nov '19

*[Job] PureScript and Haskell, Tokyo or remote* Cross Compass <https://www.cross-compass.com/en> in Tokyo is hiring programmers to build a data science IDE on top of JupyterLab <https://jupyterlab.readthedocs.io/en/stable/> , with a Haskell backend and a PureScript/React frontend. The JupyterLab stack is new and we're building new technology. This is a small team and we want to add generalists to work full-time. We are looking for candidates with these areas of interest and experience. - Browser-based GUI applications, especially React and PureScript - Functional programming, especially Haskell - Devops, especially Docker and Nix - Python and the Jupyter ecosystem - Machine learning and data science *About Cross Compass* Cross Compass is a Japanese AI consultancy founded in 2015 in Tokyo <https://goo.gl/maps/79wQbmfbGYgLZgYd9>. It is a leader in AI for manufacturing and industrial robotics with 80~100 projects per year. There are 66 employees (43 engineers), and the office conversation is about half Japanese, half English, with 15 nationalities represented among our staff. The number of self-described Haskellers at Cross Compass currently stands at 4 in Tokyo and 2 remote. github.com/xc-jp - Ramin Honary https://github.com/RaminHAL9001 <https://github.com/RaminHAL9001> - Dennis Gosnell https://github.com/cdepillabout <https://github.com/cdepillabout> - Jonas Carpay https://github.com/jonascarpay <https://github.com/jonascarpay> - Viktor Kronvall https://github.com/considerate <https://github.com/considerate> - Robert Prije https://github.com/rprije <https://github.com/rprije> - James Brock https://github.com/jamesdbrock <https://github.com/jamesdbrock> *Application* We would like to see examples of how you work, so if you have any work published on the internet, please tell us where to look for it, and explain what is interesting about it. Please apply by email to recruit(a)cross-compass.com <recruit(a)cross-compass.com?subject=Programmer+Data+Science+IDE+RECR-371> and include the following: - Highlights of work history - Highlights of education history - Open source software links - Papers, articles, social media, anything which reflects well on you - Request to work in Tokyo office or remote If you want to talk about this position or anything else, please email me at james.brock(a)cross-compass.com. Salary will be based on experience and shall be determined by market pay rates for programming positions in Tokyo. The application process will include a one month trial period. Remote work is possible but we prefer candidates who live, or want to live, in Tokyo, for a larger interaction with our teams. We provide visa sponsorship.

1 0

Reverse of -ddump-splices
by Markus Läll 19 Nov '19

19 Nov '19

Hi list! Is it so that there is no reverse for -ddump-splices? In ghci I can set it with :set -ddump-splices and it turns on, but adding "no" to the flag appears not to work. Found this https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html so probably there is no reverse? -- Markus Läll

4 6

monoid fold concurrently
by PICCA Frederic-Emmanuel 16 Nov '19

16 Nov '19

Hello, I would like to create a fucntion whcih does mkCube :: [IO a] -> IO a mkCube = ... I want to fold all this concurrently in order to obtain the final a I have a function like this merge :: a -> a -> IO a in order to sort of merge two a into another one. I did not found something like this on hoogle. so I would like your advices in order to write mkCube Thanks Frederic

2 7

FLOPS 2020: DEADLINE EXTENSION (abstract 22 Nov, full paper 29 Nov)
by Shin-Cheng Mu 16 Nov '19

16 Nov '19

FINAL Call For Papers (*** DEADLINE EXTENSION ***) FLOPS 2020: 15th International Symposium on Functional and Logic Programming In-Cooperation with ACM SIGPLAN =============================== 23-25 April, 2020, Akita, Japan https://www.ipl.riec.tohoku.ac.jp/FLOPS2020/ Writing down detailed computational steps is not the only way of programming. An alternative, being used increasingly in practice, is to start by writing down the desired properties of the result. The computational steps are then (semi-)automatically derived from these higher-level specifications. Examples of this declarative style of programming include functional and logic programming, program transformation and rewriting, and extracting programs from proofs of their correctness. FLOPS aims to bring together practitioners, researchers and implementors of the declarative programming paradigm, to discuss mutually interesting results and common problems: theoretical advances, their implementations in language systems and tools, and applications of these systems in practice. The scope includes all aspects of the design, semantics, theory, applications, implementations, and teaching of declarative programming. FLOPS specifically aims to promote cross-fertilization between theory and practice and among different styles of declarative programming. *** Scope *** FLOPS solicits original papers in all areas of the declarative programming: * functional, logic, functional-logic programming, rewriting systems, formal methods and model checking, program transformations and program refinements, developing programs with the help of theorem provers or SAT/SMT solvers, verifying properties of programs using declarative programming techniques; * foundations, language design, implementation issues (compilation techniques, memory management, run-time systems, etc.), applications and case studies. FLOPS promotes cross-fertilization among different styles of declarative programming. Therefore, research papers must be written to be understandable by the wide audience of declarative programmers and researchers. In particular, each submission should explain its contributions in both general and technical terms, clearly identifying what has been accomplished, explaining why it is significant for its area, and comparing it with previous work. Submission of system descriptions and declarative pearls are especially encouraged. *** Submission *** Submissions should fall into one of the following categories: * Regular research papers: they should describe new results and will be judged on originality, correctness, and significance. * System descriptions: they should describe a working system and will be judged on originality, usefulness, and design. * Declarative pearls: new and excellent declarative programs or theories with illustrative applications. System descriptions and declarative pearls must be explicitly marked as such in the title. Submissions must be unpublished and not submitted for publication elsewhere. Work that already appeared in unpublished or informally published workshops proceedings may be submitted. See also ACM SIGPLAN Republication Policy, as explained on the web at http://www.sigplan.org/Resources/Policies/Republication. Submissions must be written in English and can be up to 15 pages excluding references, though system descriptions and pearls are typically shorter. The formatting has to conform to Springer's guidelines. Regular research papers should be supported by proofs and/or experimental results. In case of lack of space, this supporting information should be made accessible otherwise (e.g., a link to an anonymized Web page or an appendix, which does not count towards the page limit). However, it is the responsibility of the authors to guarantee that their paper can be understood and appreciated without referring to this supporting information; reviewers may simply choose not to look at it when writing their review. FLOPS 2020 will employ a double-blind reviewing process. To facilitate this, submitted papers must adhere to two rules: 1. author names and institutions must be omitted, and 2. references to authors' own related work should be in the third person (e.g., not "We build on our previous work..." but rather "We build on the work of..."). The purpose of this process is to help the reviewers come to a judgement about the paper without bias, not to make it impossible for them to discover the authors if they were to try. Nothing should be done in the name of anonymity that weakens the submission or makes the job of reviewing the paper more difficult (e.g., important background references should not be omitted or anonymized). In addition, authors should feel free to disseminate their ideas or draft versions of their paper as they normally would. For instance, authors may post drafts of their papers on the web or give talks on their research ideas. Papers should be submitted electronically at https://easychair.org/conferences/?conf=flops2020 Springer Guidelines https://www.springer.com/gp/computer-science/lncs/conference-proceedings-gu… *** Proceedings *** The proceedings will be published by Springer International Publishing in the Lecture Notes in Computer Science (LNCS) series (www.springer.com/lncs) *** Important Dates *** [EXTENDED] 22 November 2019 (AoE): Abstract submission [EXTENDED] 29 November 2019 (AoE): Submission deadline [EXTENDED] 31 January 2020: Author notification [EXTENDED] 20 February 2020: Camera ready due 23-25 April 2020: FLOPS Symposium *** Programming Comittee *** Elvira Albert Universidad Complutense de Madrid María Alpuente Universitat Politècnica de València Edwin Brady University of St Andrews Michael Hanus CAU Kiel Nao Hirokawa JAIST Zhenjiang Hu Peking University John Hughes Chalmers University of Technology Kazuhiro Inaba Google Shin-Ya Katsumata National Institute of Informatics Ekaterina Komendantskaya Heriot-Watt University Leonidas Lampropoulos University of Pennsylvania Akimasa Morihata The University of Tokyo Shin-Cheng Mu Academia Sinica Keisuke Nakano Tohoku University (co-chair) Koji Nakazawa Nagoya University Enrico Pontelli New Mexico State University Didier Remy INRIA Ricardo Rocha University of Porto Konstantinos Sagonas Uppsala University (co-chair) Ilya Sergey Yale-NUS College Kohei Suenaga Kyoto University Tachio Terauchi Waseda University Kazushige Terui Kyoto University Simon Thompson University of Kent Philip Wadler, University of Edinburgh *** Organizers *** Keisuke Nakano Tohoku University, Japan (PC Co-Chair, General Chair) Kostis Sagonas Uppsala University, Sweden (PC Co-Chair) Kazuyuki Asada Tohoku University, Japan (Local Co-Chair) Ryoma Sin'ya Akita University, Japan (Local Co-Chair) Katsuhiro Ueno Tohoku University, Japan (Local Co-Chair) *** Contact Address *** flops2020 _AT_ easychair.org

1 0

GHC API: parsing as much as I can
by Artem Pelenitsyn 15 Nov '19

15 Nov '19

Hello Cafe, I need an advice on how to use GHC API to parse big collections of Haskell source files. Say, I want to collect ASTs of everything that is on Hackage. I downloaded the whole Hackage (latest versions only) and have it locally now. I tried simple advice found in the Parse module documentation: https://hackage.haskell.org/package/ghc-8.6.5/docs/Parser.html runParser :: DynFlags -> String -> P a -> ParseResult a runParser flags str parser = unP parser parseState where filename = "<interactive>" location = mkRealSrcLoc (mkFastString filename) 1 1 buffer = stringToStringBuffer str parseState = mkPState flags buffer location It mostly works: 75% of .hs files on Hackage seem to parse fine. I looked into the rest 25% and noticed that this snippet can't handle files using GHC extensions such as RankNTypes, TemplateHaskell, BangPatterns, etc.when given the default DynFlags. This leads me to the question of how should I initialize DynFlags? Currently, I use this for getting DynFlags: initDflags :: IO DynFlags initDflags = do let ldir = Just libdir mySettings <- initSysTools ldir myLlvmConfig <- initLlvmConfig ldir initDynFlags (defaultDynFlags mySettings myLlvmConfig) I understand that simple parsing of individual files can't take into account extensions activated inside .cabal files. But I'd expect that it should be possible to, at least, consider the extensions mentioned in the LANGUAGE pragmas. Currently, this isn't happening. Any suggestions on how to achieve this are welcomed. I probably won't get to parsing 100% of Hackage, but I'd hope for better than the current 75%. -- Best wishes, Artem

2 2

ANN: semialign-extras-0.1.0.0, and a request for help
by Jack Kelly 15 Nov '19

15 Nov '19

I have just pushed an initial release of semialign-extras[1] to Hackage. semialign-extras aims to collect interesting abstractions/operations that: 1. Build on top of (at least) the Semialign typeclass, or related classes from the semialign universe; and 2. Do not belong inside other packages in the semialign universe. PRs that serve these goals are most welcome, as are GitHub issues[2]. Currently, there are two modules: * Data.Semialign.Diff has diffing/patching for Semialigns; and * Data.Semialign.Merge has a collection of merge operations for Semialigns which are also Filterable/Traversable/Witherable Request for help: The functions in Data.Semialign.Diff work across a lot of types, but are are often not the most efficient way to diff. There is a high-performance merge API for Data.Map.Map in Data.Map.Merge.Lazy[3], and it would be great to have some rewrite rules that took advantage of this. I have been able to write rules that GHC accepts, but not make them actually fire[4]. I'd be grateful for any assistance people can provide. Best, -- Jack [1]: http://hackage.haskell.org/package/semialign-extras-0.1.0.0 [2]: https://github.com/qfpl/semialign-extras [3]: https://hackage.haskell.org/package/containers-0.6.0.1/docs/Data-Map-Merge-… [4]: https://github.com/qfpl/semialign-extras/issues/3

1 0