- Haskell-Cafe - Haskell.org

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 21 Oct '20

21 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 20 Oct '20

20 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

Need help to get started
by tech＠jimtyrerrobotics.ca 18 Oct '20

18 Oct '20

hello, I'm an industrial robot tech and the code I write seems to be composed of 99% side-effects ;-) That's the big dumb ones bolted to the floor that make cars and stuff. Decades of imperative sequence coding seem to have fossilized something in my brain. Trying to teach myself Haskell and going nowhere very slowly. Spent the last 8 weeks slowly plodding through "Real World Haskell" and "Learn you a Haskell" with the intention of re-writing a bash script in Haskell. I've normally learned programming by writing something I need instead of tutorials with which I seem to have an attention deficit problem. I use Linux for work and have written a bash script that uses bc and heredocs to write an .adoc file and then calls asciidoctor-pdf to generate an invoice. It's about 90 lines so I am not a scripting pro either. So typing './invoice Wk38' rolls a file called Wk38-of-2020-Invoice.pdf to send to clients. It was while writing this script that I stumbled upon pandoc and then Haskell. And that's where the trouble started. Tha abstraction and macro-approach of Haskell could provide a whole bag of tools for maintaining code (text files) on lines of multiple robots. About the existing script: I write plain text files on my phone that look like this: 14 Sep 0745 1600 Foo y 15 Sep 0815 1500 Foo y 16 Sep 0745 1400 Foo y 17 Sep 0745 1430 Foo y 18 Sep 0745 1400 Foo y and this one is called Wk38 and the fields are: |Date|Time In|Time Out|Proj|Lunch. Then I email it to myself and run the script. So I would be very grateful if someone could write some code for me and put my bootstraps in my fumbling hands: Get the name of the Wkxx file from the command line when running a Haskell standalone executable. fileName <- getArgs Load the lines of the file into a list of list of String[[]]. (or a better way?) lines <- fmap Text.lines (Text.readFile fileName) Recurse through each line of the list(s) and: *: Construct a date::String from the first two fields. (just a string, does not need a real "Date") *: Calc dailyElapsedTime::Double from difference between fields 4 and 3. *: Subtract 0.5hr lunch from dailyElapsedTime if field 6 == "y" *: Add dailyElapsedTime to accumlatedWeekTime::Double. *: Charge = If accumlatedWeekTime < 40hrs then multiply by rate1 *: elseif accumlatedWeekTime > 40hrs then multiply by rate2 *: Append |Date|Time In|Time Out|Charge|Project| to adoc file. If I could load it into ghci and step through it the lights may come on. Thanks very much Noodles

4 3

Re: [Haskell-cafe] ANN: stack-2.5.1
by waldmann 17 Oct '20

17 Oct '20

> Doesn't compile for me GHC 8.10.2 when building using cabal [...] for stack-2.5.0.1, this worked: cabal install --constraint 'base16-bytestring==0.1.1.7' --constraint 'optparse-applicative==0.15.1.0' https://github.com/commercialhaskell/stack/issues/5298#issuecomment-7023387… NB : seems to me there's a whole recent-social-history-of-haskell essay waiting to be written around that question (build 'stack' with 'cabal'). - J.W.

1 0

ANN: stack-2.5.1
by Emanuel Borsboom 16 Oct '20

16 Oct '20

See https://haskellstack.org/ for installation and upgrade instructions. **Changes since v2.3.3** Major changes: * Add the `snapshot-location-base` yaml configuration option, which allows to override the default location of snapshot configuration files. This option affects how snapshot synonyms (LTS/Nightly) are expanded to URLs by the `pantry` library. * `docker-network` configuration key added to override docker `--net` arg Behavior changes: * File watching now takes into account specified targets, old behavior could be restored using the new flag `--watch-all` [#5310](https://github.com/commercialhaskell/stack/issues/5310) Other enhancements: * `stack ls dependencies json` now includes fields `sha256` and `size` for dependencies of `type` `archive` in `location`. [#5280](https://github.com/commercialhaskell/stack/issues/5280) * Build failures now show a hint to scroll up to the corresponding section [#5279](https://github.com/commercialhaskell/stack/issues/5279) * Customisable output styles (see `stack --help` and the `--stack-colors` option, and `stack ls stack-colors --help`) now include `info`, `debug`, `other-level`, `secondary` and `highlight`, used with verbose output. Bug fixes: * Fix `stack test --coverage` when using Cabal 3 * `stack new` now generates PascalCase'd module name correctly. [#5376](https://github.com/commercialhaskell/stack/issues/5376) * Connection issues to Casa server no longer cause builds to failure. Casa acts only as an optimizing cache layer, not a critical piece of infrastructure. * Fix modified time busting caches by always calculating sha256 digest during the build process. [#5125](https://github.com/commercialhaskell/stack/issues/5125) **Thanks to all our contributors for this release:** * Andrea Condoluci * Andreas Herrmann * Andres Schmois * Ariel D. Moya Sequeira * Brandon Chinn * Cheah Jer Fei * DerpyCrabs * Emanuel Borsboom * Felix Yan * Jannik Theiß * Jens Petersen * Junji Hashimoto * Kirill Zaborsky * Michael Snoyman * Mihai Maruseac * Mike Pilgrem * Niklas Hambüchen * Ondřej Slámečka * Piper McCorkle * Thomas Lopatic * tomjaguarpaw

2 1

Re: [Haskell-cafe] Overlapping instances: are functions and typeclass methods treated differently?
by Daniel Díaz 13 Oct '20

13 Oct '20

On Thu, Oct 8, 2020 at 2:12 PM Henning Thielemann < lemming(a)henning-thielemann.de> wrote: > > On Thu, 8 Oct 2020, Daniel Díaz wrote: > > > But now consider this instance: > > > > > newtype Wrapper a = Wrapper (Maybe a) > > > instance Show a => Show (Wrapper a) where > > > show (Wrapper x) = show x > > > > This compiles just fine, despite—to my mind—suffering from the exact > same problem that the "foo" function had. > > Why does it work? > > There is an instance Show (Maybe a) in Prelude, but no instance Show > (Wrapper a), so no overlapping. Sorry, I wasn't very clear there. The problem is not with the "Show (Wrapper a)" instance itself, but with its implementation of "show". It depends (just as the function "foo" did) on "Show (Maybe a)", for which there are overlapping instances. And yet "foo" compiles without problem, while the typeclass method doesn't.

3 2