- Haskell-Cafe - Haskell.org

Does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus?
by Olaf Klinke 27 Oct '20

27 Oct '20

I used to think that an Alternative is just an Applicative which is also a Monoid but apparently there is no consensus about this [1,2]. Actually it kind of makes sense to make the 'empty' parser fail: Consider the parser combinator choice = Data.Foldable.asum = foldr (<|>) empty which folds over a list of Alternatives. Its semantics can be regarded analogous to 'any' for a list of Booleans, and in the latter the empty list evaluates to False. Put differently: The parser (p <|> q) matches at least as many inputs than either p or q. Hence the neutral element for <|> ought to be the parser that matches the least amount of inputs, but a parser that succeeds on the empty string _does_ match some input. It would be the neutral element for the monoid operation that concatenates parsers. Olaf [1] https://en.wikibooks.org/wiki/Haskell/Alternative_and_MonadPlus [2] https://wiki.haskell.org/MonadPlus

4 10

[Job] Cross Compass is hiring Haskell developers
by Ramin Honary 27 Oct '20

27 Oct '20

Cross Compass ( https://www.cross-compass.com/ ) is a data science and machine learning consultancy located in Tokyo, Japan. We are hiring Haskellers to work on a machine learning platform. We are mainly looking for people skilled in either web programming, machine learning, or embedded development. Technical skills used on our team ================================= Our machine learning platform has quite a few moving parts: - two web frontends (one written in PureScript, and one written in TypeScript) - two backends (one written in Haskell, and one written in Ruby) - a deep learning engine (written in Haskell, calling out to Caffe2) - a library for running models on embedded devices (written in C, C++ and CUDA calling out to oneDNN and cuDNN) Given these various parts, we end up touching a lot of different technologies: - Haskell, including the following libraries: - conduit - JuicyPixels - lens - servant - PureScript, including the following libraries: - affjax - argonaut - protobuf - react-basic - Nix (and a little Docker) - Ruby - TypeScript - C (and a little C++ and CUDA) - machine learning (we are currently mostly focused on deep learning) We have long-term plans to move away from Ruby and TypeScript (and towards Haskell and PureScript), but no concrete time-frame for when this will happen. What sort of developers are we looking for? =========================================== In the short term, we are planning on hiring two developers. We want to hire developers who know some combination of the above technologies, or would be interested in learning. We imagine hiring one developer who is familiar with Ruby, TypeScript, and Haskell. Machine learning experience wouldn't be necessary, but helpful. They would start out with web development in Ruby and Typescript, along with some Haskell work. Over time they would probably move more towards doing web development in Haskell and PureScript. We imagine hiring one other developer who is familiar with machine learning, Haskell, and possibly embedded development. They would help with the Haskell deep learning engine, as well as the C-based embedded library. They would probably also have the chance to help with the Haskel web backend and PureScript web frontend. We are also interested in any other candidates that have unique combinations of the above skills, or interesting backgrounds. Please don't hesitate to apply based on your background or skills. Previous working experience with Haskell or any of the other technologies listed above is not a requirement. Non-technical requirements ========================== We would prefer to hire developers that can work locally from Tokyo. We sponsor visas for developers who want to move to Japan. If we don't find anyone who is willing to relocate to Japan, we will considering hiring remote-only candidates. Most of our meetings take place in the afternoon in JST (UTC+9), which is around 5 AM UTC. Although we are flexible on this point. https://www.timeanddate.com/worldclock/converter.html?iso=20201104T050000&p… We prefer to hire developers who want to work full time (40 hours per week). Pay ==================== The salary range for this position is 6 to 8 million yen (about USD $57,000 to $75,000). Application and hiring process ============================== If this sounds interesting, please feel free to email us at recruit(a)cross-compass.com . We are not too big on standard resumes, but you are welcome to send us any information that you think would catch our attention, including things like: - relevant work history (e.g. work somewhere before using Haskell? Or maybe doing frontend development with TypeScript?) - relevant education history (e.g. took a class on machine learning?) - open-source software links (e.g. author any interesting libraries? have a cool machine learning project?) - papers, articles, blog posts, social media, or anything else which reflects well on you We'd also like to know your situation regarding on-premise work vs. remote, including whether or not you would be interested in moving to Japan. There will be one interview to learn more about you and for you to ask us questions. We will invite promising candidates to a part-time, one-month paid trial period. During this trial period we see what it is like working with you, and you get to see how we work as a team. Ideally, you'd be able to work at least a couple hours a week (so we both have an idea what is it like to work with each other when the month is over), but we are flexible with the details here. We would make you an offer after the trial-period. Haskellers at Cross Compass =========================== There are already a few Haskellers at Cross Compass. You may have interacted with us online or at various meetups and conferences. - Viktor Kronvall ( https://github.com/considerate ) - Jonas Carpay ( https://github.com/jonascarpay ) - Ramin Honary ( https://github.com/RaminHAL9001 ) - James Brock ( https://github.com/jamesdbrock ) - Dennis Gosnell ( https://functor.tokyo/ ) Other Considerations ==================== - We would consider hiring someone part-time with a lot of experience, although we would probably only do this if we don't find someone willing to work full time. - Being able to speak Japanese is not a requirement. - HR will often help employees new to Japan with things like finding an apartment, opening a bank account, getting a cell phone, etc. - We don't particularly have any requirements regarding years of experience. Coronavirus =========== - It is currently possible for people to get a work visa and come to Japan. (At one point foreigners weren't able to enter Japan, but this restriction has been relaxed and now people can enter with a work visa.) - Over the last few months, there are on average a couple hundred cases per day in Tokyo. - Most people in Cross Compass have been working remotely since Coronavirus became a problem in Tokyo. Some people go in to the office once or twice a week. I imagine this will continue until cases of Coronavirus start to drop. I don't know what the plans for what the remote working situation will be like when Coronavirus is no longer a problem. If you're concerned about this, please make sure to ask about this in your application email.

1 0

error when running stack
by Dennis Raddle 26 Oct '20

26 Oct '20

I get this error when running stack: Downloading lts- xxxx building plan aesonException "Error in $['system-info']: key \"os\" not present" running "stack update" didn't help. I'm very confused because I don't remember what I did that provoked this error. Anyone know what's going on? Dennis

3 4

Does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus?
by Compl Yue 25 Oct '20

25 Oct '20

Dear Cafe, Regarding the Alternative instance of ParsecT from Megaparsec here: https://github.com/mrkkrp/megaparsec/blob/ccf314b0b940bdbfec3820b18f42d241e… (https://link.getmailspring.com/link/34AABC73-FAC8-4126-8356-62E7FE0DA273@ge…) -- | 'empty' is a parser that __fails__ without consuming input. instance (Ord e, Stream s) => Alternative (ParsecT e s m) where empty = mzero (<|>) = mplus I come to this question, does it violate the laws of Alternative/Monoid to implement empty/mempty with mzero from MonadPlus? First of all, can I somehow regard Alternative as a repurposed Monoid? So this question applies similarly to Monoid as well? Then I think the lack of failure semantic in Alternative/Monoid might have two different interpretations: 1) It must NOT fail 2) Whether it can fail or not is not cared Which one is correct? I feel 1) is in spirit of purism, that pure code should not fail, but it's a monad, then 2) may in monad's spirit to be effectful and composable with other effects including failing. I'd think it violates the law when interpretation 1) is taken. Background about my confusion: https://github.com/mrkkrp/megaparsec/issues/429#issuecomment-716170935 (https://link.getmailspring.com/link/34AABC73-FAC8-4126-8356-62E7FE0DA273@ge…) The parsing of whitespaces is so handled in Megaparsec's idiom that every lexeme should consume (discard) all whitespaces following it. But after tinkered around with some related issues, I by now would think a silent, joinable empty / mempty might be more sense making for each whitespace block to be parsed individually, i.e. without association with any lexeme while neither will fail the overall parsing. The demand comes in that I'd like the doc comment parser to evaulate to empty and contribute nothing to an enclosing many , in case all following it is whtespaces till eof; while in case it's followed by some artifact definition, the doc comment parser should evaluate to a syntactic doc node assoicated with that artifact. empty seems an ideal device for that purpose, but in the fact it is implemented with mzero, the overall parsing will fail, which makes it infeasible. Best regards, Compl

1 0

How to encode *NoMatch* after consumed some input in a parser
by YueCompl 25 Oct '20

25 Oct '20

Dear Cafe, This is a followup question to my previous one. Also asked as a Megaparsec question issue at https://github.com/mrkkrp/megaparsec/issues/429 <https://github.com/mrkkrp/megaparsec/issues/429> As I observed (have no idea where a canonical definition could live for this) that for the contract of parser combinators: fail with no input consumed will have next alternative to be tried with possible success fail with some input consumed will err out immediately regardless rest alternatives Am I right about these rules? Where is the official specification of such rules? Then I guess that empty result of a parser could mean NoMatch even after consumed some input, and want to leverage this semantic, but encountered error with current implementation https://github.com/complyue/dcp/blob/5be688396b7e2bda00ea80fd99d2a7b3ec5c78… <https://github.com/complyue/dcp/blob/5be688396b7e2bda00ea80fd99d2a7b3ec5c78…> artifactDecl :: Parser ArtDecl artifactDecl = do artCmt <- immediateDocComments (eof >> empty) <|> do artBody <- takeWhileP (Just "artifact body") (not . flip elem (";{" :: [Char])) if T.null $ T.strip artBody then empty -- this is not possible in real cases else return (artCmt, artBody) $ cabal run dcp < samples/full.txt Up to date dcp: 73:1: | 73 | <empty line> | ^ expecting "{#", "{##", or artifact body CallStack (from HasCallStack): error, called at src/Parser.hs:151:14 in main:Parser So how can I achieve that? Background is I'm trying to prototype an implementation of doc comment parsing as described at #428 <https://github.com/mrkkrp/megaparsec/issues/428> Best regards, Compl

1 0

Reason about a Megaparsec error
by YueCompl 25 Oct '20

25 Oct '20

Dear Cafe, I find myself unable to reason about an error that `optional` in a parser err out instead of return Nothing, I asked the question at StackOverflow, and would like to seek your help here as well. https://stackoverflow.com/questions/64522568/why-optional-in-a-parser-can-e… <https://stackoverflow.com/questions/64522568/why-optional-in-a-parser-can-e…> https://github.com/complyue/dcp <https://github.com/complyue/dcp> is a minimum working example to reprod this error $ cabal run dcp:dcp < samples/basic.txt Up to date dcp: 10:1: | 10 | method doXXX() pass | ^ unexpected 'm' expecting ';' CallStack (from HasCallStack): error, called at src/Parser.hs:149:14 in main:Parser $ I believe it's optionalSemicolon causing the failure: https://github.com/complyue/dcp/blob/1df7ad590d78d4fa9a017eb53f9f265e291bdf… <https://github.com/complyue/dcp/blob/1df7ad590d78d4fa9a017eb53f9f265e291bdf…> findIt = do -- ignore leading whitespaces and an optional semicolon in between nbsc >> optionalSemicolon >> nbsc -- try get a doc comment block getIt >>= \case And it's defined like this: https://github.com/complyue/dcp/blob/1df7ad590d78d4fa9a017eb53f9f265e291bdf… <https://github.com/complyue/dcp/blob/1df7ad590d78d4fa9a017eb53f9f265e291bdf…> optionalSemicolon :: Parser Bool optionalSemicolon = fromMaybe False <$> optional (True <$ symbol ";") I can't reason about why it can fail like this. Best regards, Compl

2 10

CFP: TCAD Special Issue on Compiler Frameworks and Co-design Methodologies for Heterogeneous Systems-on-Chip
by Tobias Grosser 21 Oct '20

21 Oct '20

We are pleased to inform you about a Special Issue titled "Compiler Frameworks and Co-design Methodologies for Heterogeneous Systems-on-Chip" that will appear in the IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems (TCAD). We encourage you and your collaborators to submit new significant research-based technical contributions within the scope of this journal. SCOPE AND TOPICS ---------------------------------------------------------------------------- Nowadays, heterogeneous architectures are employed to limit the cost per function and boost energy efficiency in several computing domains, from high-performance computing (HPC) to embedded systems. Advanced heterogeneous systems-on-chip combine diverse processing elements, such as general-purpose processors (GPP), graphics processor units (GPU), digital signal processors (DSP), field-programmable gate arrays (FPGA), and many application-specific hardware accelerators. To fully exploit the power of these platforms and overcome the limits of conventional architectures, system and application designers need new tools and methodologies to address the increasing hardware/software complexity and achieve high productivity. This special issue aims to provide the targeted readers with the new advances and challenges in the area of compiler frameworks, hardware/software methodologies, and related tools to aid the design of complex heterogeneous systems. Relevant topics include, but are not limited to, the following: * Compiler frameworks and co-design workflows for heterogeneous hardware * End-to-end frameworks targeting heterogeneous specialized units * Application-specific co-design methodologies for heterogeneous platforms * Synergistic HW/SW techniques to promote parallelism in heterogeneous computing * Novel programming paradigms to promote heterogeneous design * Source-to-source translation and (semi-)automatic code generation for heterogeneous architectures * Methodologies to improve software portability across heterogeneous targets MANUSCRIPT PREPARATION AND SUBMISSION --------------------------------------------------------------------------- Submissions to this Special Issue must represent original material that has been neither submitted to, nor published in, any other journal. All submitted manuscripts must follow the TCAD guidelines: https://ieee-ceda.org/publication/tcad-publication/tcad-paper-submission Please submit your manuscript in electronic form through Manuscript Central website: https://mc.manuscriptcentral.com/tcad On the first page of the submission form, select this special issue in the "Type" field choosing this option: "SI on Compiler Frameworks and Co-design Methodologies" GUEST EDITORS --------------------------------------------------------------------------- * Luca Benini, Full Professor, Università di Bologna / ETH Zürich (lbenini(a)iis.ee.ethz.ch<mailto:lbenini@iis.ee.ethz.ch>) * Luca Carloni, Full Professor, Columbia University (luca(a)cs.columbia.edu<mailto:luca@cs.columbia.edu>) * Giuseppe Tagliavini, Assistant Professor, University of Bologna (giuseppe.tagliavini(a)unibo.it<mailto:giuseppe.tagliavini@unibo.it>) * Tobias Grosser, Associate Professor, University of Edinburgh (tobias.grosser(a)ed.ac.uk<mailto:tobias.grosser@ed.ac.uk>) TIMELINE --------------------------------------------------------------------------- * Submission Deadline: November 15, 2020 * Reviews Completed: January 15, 2021 * Major Revisions Due: February 15, 2021 * Reviews of Revisions Completed: March 15, 2021 * Notification of Final Acceptance: March 31, 2021 * Publication Materials for Final Manuscripts Due: April 10, 2021 * Publication: May 2021 -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Release a book about math and programming in Haskell
by Xinyu LIU 21 Oct '20

21 Oct '20

Hi, I recently released a book about mathematics and programming in github: https://github.com/liuxinyu95/unplugged I mainly provide examples, and code snippets in Haskell. The PDF can be downloaded under GNU FDL license. There are 7 chapters together with 108 problems as exercise. I also included all the answers in the appendix. Here are the table of content: Preface - A story about isomorphism. Chapter 1, Natural numbers. Peano Axiom, list and folding; Chapter 2, Recursion. Euclidean algorithm, Lambda calculus, and Y-combinator; Chapter 3, Symmetry. Group, Ring, and Field. Galois Theory; Chapter 4, Category theory and type system; Chapter 5, Deforest. Build-fold fusion law, optimization, and algorithm deduction; Chapter 6, Infinity. Set theory, Infinity and stream; Chapter 7, Logic paradox, Gödel's incompleteness theorems, and Turing halting problem. Answers to the exercise. Xinyu LIU https://github.com/liuxinyu95/unplugged *e*^(*π*i)+1 = 0

2 1

Clarification on uniWhite lexical definition
by Immanuel Litzroth 20 Oct '20

20 Oct '20

The haskell report says: uniWhite → any Unicode character defined as whitespace it's not clear to me whether this means that the unicode character should have "Zs" as it's general category ;; Zs Space_Separator a space character (of various non-zero widths) or whether it should be defined as whitespace as in https://www.unicode.org/Public/UCD/latest/ucd/PropList.txt Any clarification appreciated, Immanuel -- -- Researching the dual problem of finding the function that has a given point as fixpoint.

3 2

F-IDE 2021 - Call for Papers
by Andrei Paskevich 19 Oct '20

19 Oct '20

****************************************************************** F-IDE 2021: 6th Workshop on Formal Integrated Development Environment Affiliated with NASA Formal Methods 2021 May 24-28, 2021 -- held online https://cister-labs.pt/f-ide2021 ****************************************************************** Important Dates * Abstract submission: Mon, Feb 22, 2021 * Full paper submission: Mon, Mar 1, 2021 * Notification: Mon, Apr 19, 2021 * Camera-ready: Mon, May 3, 2021 * Workshop: May 24-28, 2021 Overview High levels of safety, security, and privacy standards require the use of formal methods to specify and develop compliant software (sub)systems. Any standard comes with an assessment process, which requires a complete documentation of the application to ease the justification of design choices and the review of code and proofs. Ideally, an F-IDE dedicated to such developments should comply with several requirements. The first one is to associate a logical theory with a programming language, in a way that facilitates the tightly coupled handling of specification properties and program constructs. The second is to offer a language and/or an environment simple enough to be usable by most developers, even if they are not fully acquainted with higher-order logics or set theory, in particular by making development of proofs as easy as possible. The third is to offer automated management of application documentation. It may also be expected that developments done with such an F-IDE are reusable and modular. Tools for testing and static analysis may be embedded within F-IDEs to support the assessment process. Topics The workshop is open to contributions on all aspects of a system development process, including specification, design, implementation, analysis, and documentation. It welcomes the presentation of tools, methods, techniques, and experiments. Topics of interest include, but are not limited to, the following: * F-IDE building: design and integration of languages, development of user-friendly front-ends * How to make high-level logical and programming concepts palatable to industrial developers * Integration of object-oriented and modularity features * Integration of static analyzers * Integration of automated proof tools, theorem provers, and testing tools * Documentation tools * Impact of tools on certification * Experience reports on developing F-IDEs * Experience reports on using F-IDEs * Experience reports on formal methods-based assessments in industrial applications Submission Guidelines We accept both long (15 pages) and short (6 pages) paper submissions. The page limit does not include the bibliography. Submitted papers must present original contributions whose main results and conclusions have not been published or submitted elsewhere. Each submission will be reviewed by at least three members of the Program Committee. We expect that one author of every accepted paper will present their work at the workshop. Submitted papers must be written in English and follow the EPTCS LaTeX format (http://style.eptcs.org) Authors are invited to submit the following types of contributions: * Research papers providing new concepts and results * Experience reports * Position papers and research perspectives * Tool presentations Papers should be submitted via EasyChair at F-IDE 2021's workshop page: https://easychair.org/conferences/?conf=f-ide2021. Preliminary proceedings will be made available in electronic form at the workshop. Post-proceedings will be published in the Electronic Proceedings in Theoretical Computer Science (EPTCS). Program Committee * Andrew Reynolds, University of Iowa, USA * Bernhard Rumpe, RWTH Aachen University, Germany * Carlo A. Furia, Chalmers University of Technology, Sweden * César Muñoz, NASA Langley, USA * Cinzia Bernardeschi, University of Pisa, Italy * Claudio Sacerdoti Coen, University of Bologna, Italy * Enrico Tassi, Inria, France * François Pessaux, ENSTA ParisTech, France * José Creissac Campos, University of Minho, Portugal * Kenneth Lausdahl, Aarhus University, Denmark * Laurent Voisin, Systerel, France * Lucas Wagner, Collins Aerospace, USA * Makarius Wenzel, sketis.net * Markus A. Kuppe, Microsoft Research, USA * Mattias Ulbrich, Karlsruhe Institute of Technology, Germany * Pierre-Yves Strub, LIX, École Polytechnique, France * Rosemary Monahan, Maynooth University, Ireland * Silvia Lizeth Tapia Tarifa, University of Oslo, Norway * Simão Melo de Sousa, Universidade Beira Interior, Portugal * Stefan Mitsch, Carnegie Mellon University, USA * Stephan Merz, Inria, France * Virgile Prevosto, Institut List, CEA Tech, Université Paris-Saclay, France * Yannick Moy, AdaCore, France * Yi Zhang, Massachusetts General Hospital, USA PC Chairs * Andrei Paskevich, Université Paris-Saclay, France * José Proença, CISTER/ISEP, Portugal Steering Committee * Catherine Dubois, Samovar, ENSIIE, France * Paolo Masci, US National Institute of Aerospace (NIA), USA * Dominique Méry, LORIA, Université de Lorraine, France

1 0