- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Global Package Install
by Johannes Waldmann 21 Mar '21

21 Mar '21

Hi. Interesting discussion. Thanks for data points on using cabal-install for the classroom. > the work-around described in the second linked cabal issue (#6515), > namely setting `store-dir` and `remote-repo-cache` > to a global read-only location, works very well in practice. Good to know. I will look into it. This "setting" has to be done by each student (once)? Well, they have to create/change other configurations as well (e.g., put proper PATH in .bashrc) so it's probably OK. And, students can then not cabal-install extra private packages? (With global package installs, they could. But perhaps it's better that they cannot, for all the reasons mentioned.) > .. helping students when we were clearly using the same codebase this is solved by `stack --resolver=<...>` but that eats space and requires another extra tool (stack) besides ghc(i). > I saw no reason to try an alternative version [to the global install] Well I did, and that reason was "cabal hell", where "global hell" is the worst, as it regularly requires a fresh ghc install. So for my own work of course I do use per-user install, and other forms of isolation. Best regards, Johannes.

1 0

Re: [Haskell-cafe] Global Package Install
by Johannes Waldmann 21 Mar '21

21 Mar '21

> .. a few people mention that they prefer the > "global package database" style. I'd like to improve my understanding > of why people prefer that style. Teaching. Reduce storage, and save students the extra work and distraction. https://github.com/haskell/cabal/issues/7172 same question, with discussion of possible work-around with "shared local" database: https://github.com/haskell/cabal/issues/6515 I will need this in two week's time .. - J.W.

3 2

WST 2021 - Call for Papers
by Samir Genaim 21 Mar '21

21 Mar '21

====================================================================== WST 2021 - Call for Papers 17th International Workshop on Termination http://costa.fdi.ucm.es/wst2021 July 16, 2021, Pittsburgh, PA, United States Co-located with CADE-28 *** The Workshop will be Virtual *** ====================================================================== The Workshop on Termination (WST) traditionally brings together, in an informal setting, researchers interested in all aspects of termination, whether this interest be practical or theoretical, primary or derived. The workshop also provides a ground for cross-fertilization of ideas from the different communities interested in termination (e.g., working on computational mechanisms, programming languages, software engineering, constraint solving, etc.). The friendly atmosphere enables fruitful exchanges leading to joint research and subsequent publications. IMPORTANT DATES: * submission deadline: April 25, 2021 * notification: May 30, 2021 * final version due: June 13, 2021 * workshop: July 16, 2021 INVITED SPEAKERS: TBA TOPICS: The 17th International Workshop on Termination welcomes contributions on all aspects of termination. In particular, papers investigating applications of termination (for example in complexity analysis, program analysis and transformation, theorem proving, program correctness, modeling computational systems, etc.) are very welcome. Topics of interest include (but are not limited to): * abstraction methods in termination analysis * certification of termination and complexity proofs * challenging termination problems * comparison and classification of termination methods * complexity analysis in any domain * implementation of termination methods * non-termination analysis and loop detection * normalization and infinitary normalization * operational termination of logic-based systems * ordinal notation and subrecursive hierarchies * SAT, SMT, and constraint solving for (non-)termination analysis * scalability and modularity of termination methods * termination analysis in any domain (lambda calculus, declarative programming, rewriting, transition systems, etc.) * well-founded relations and well-quasi-orders SUBMISSION GUIDELINES: Submissions are short papers/extended abstracts which should not exceed 5 pages. There will be no formal reviewing. In particular, we welcome short versions of recently published articles and papers submitted elsewhere. The program committee checks relevance and provides additional feedback for each submission. The accepted papers will be made available electronically before the workshop. Papers should be submitted electronically via the submission page: https://easychair.org/conferences/?conf=wst2021 Please, use LaTeX and the LIPIcs style file http://drops.dagstuhl.de/styles/lipics/lipics-authors.tgz to prepare your submission. PROGRAM COMMITTEE: * Martin Avanzini - INRIA Sophia, Antipolis * Carsten Fuhs - Birkbeck, U. of London * Samir Genaim (chair) - U. Complutense de Madrid * Jürgen Giesl - RWTH Aachen * Matthias Heizmann - U. of Freiburg * Cynthia Kop - Radboud U. Nijmegen * Salvador Lucas - U. Politècnica de València * Étienne Payet - U. de La Réunion * Albert Rubio - U. Complutense de Madrid * René Thiemann - U. of Innsbruck

1 0

strange cabal error
by Ben Franksen 18 Mar '21

18 Mar '21

Any idea what I am running into here? ben@home[5]:.../softIOC/home>cabal build Resolving dependencies... TODO: add support for multiple packages in a directory CallStack (from HasCallStack): error, called at ./Distribution/Client/ProjectOrchestration.hs:548:9 in main:Distribution.Client.ProjectOrchestration This appears immediately after I issued a (successful) ben@home[5]:.../softIOC/home>cabal init --minimal --package-name test Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

1 1

Some Alex beginner questions regarding parsing Java
by Javran Cheng 18 Mar '21

18 Mar '21

Hi Cafe! Firstly, sorry for spamming if you already see this on Stack Overflow, I do feel this is too much for a single SO question. I'm recently playing with Alex + Happy to try parsing Java (for now I'm only working on the lexer / Alex, so whenever you see "parse" below, that means tokenize). My reference is Java SE 15 Spec, the chapter of interest is Chapter 3. Lexical Structure <https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.html> (side note: my timing is a bit interesting as I just realized as of writing this, Java SE 16 spec is out just few days ago, so I might switch to that) and now that I've get my hand dirty a bit, I have few questions and hope if someone can shed some light on them: 1. For now I'm using "monad-bytestring" wrapper for performance, but now I think maybe String-based wrapper is more appropriate, for it allows me to follow 1. and 2. in "3.2. Lexical Translations" properly before passing the input to Alex - namely I can pre-process input stream to (1) do Unicode escaping to turn the raw byte flow into a flow of Chars (2) I can normalize line terminators into just \n. But: 1. Are those two passes (Unicode escape and line terminator normalization) possible within Alex framework? 2. Is there any way that I can stick with a memory-compact string representation? (not sure why Alex doesn't provide any Text-based wrapper, as it did mention in its doc that it internally works on UTF-8 encoded byte sequence) I could probably consider to not use any wrapper, as GHC and Agda did, but that's sort of an undocumented territory so I'm hesitated to do so. 2. The other trouble I have regarding "3.2. Lexical Translations" is the special rules applied to ">"s: "... There is one exception: if lexical translation occurs in a type context (§4.11) ..." - but how in the world am I going to do this? I mean the lexical analysis is not even done how am I going to tell whether it's a type context (and §4.11 is quite long that I won't even try to read it, unless forced)? Maybe I can just tokenize every ">" as an individual operatior, as if ">>", ">>=", ">>>", and ">>>=" don't exist and worry about that later, but that doesn't sound right to me. 3. I realize there's a need for "irrecoverable failure": I have a test case with octal literal "012389", which is supposed to fail, but Alex happily tokenized that into [octal "0123", decimal "89"] - for now my workaround is for every number literal to check whether previous char is a digit and fail if it is indeed so, but I feel this is like ducktaping on a flawed approach and at some point it will fail on some edge cases. an ideal fix IMO would be to have some notion of irrecoverable failure - failing to parse a literal at full should be irrecoverable rather than trying to parse most of it and move on. In addition, as Java spec requires that if a numeric literal doesn't fit in the intended type, it's a compilation error - which can also be encoded as an irrecoverable failure as well. I'm not sure how to do that in Alex though, I can see few ways: 1. encode irrecoverable failure by setting to a special startcode, which does not provide anyway to go back to startcode 0 - so an irrecoverable failure sets that special startcode, and at the start of every action, it checks whether startcode is the special "failure" startcode and fail accordingly 2. this is similar to startcode, but use a wrapper that supports userstate. 3. maybe this is another case that not using a wrapper would give me more control, but I don't have a concrete idea regarding this alternative. Any thoughts on this is appreciated. Thanks! Javran (Fang) Cheng

2 2

Re: [Haskell-cafe] shorter error messages
by Richard Eisenberg 17 Mar '21

17 Mar '21

In the short-term: I'll take option 3. We've already changed some of the datatypes around there, and the new output reflects the new structure. I did poke around a bit (https://gitlab.haskell.org/ghc/ghc/-/issues/19278) asking if anyone relied on the existing structure, and we were told just to update as we saw fit. In the longer-term: Option 1. The JSON feature is, essentially, undesigned. It just happened. There is no real specification or supported story for what tools are likely to consume the data. After this overhaul, it will be easy to imagine arbitrarily structured and informative JSON output, and so I imagine we'll start a conversation with consumers (i.e. IDEs and similar tools) to design an advertised interface. This interface will need to be somewhat unstable in perpetuity, as GHC improves errors, adds new ones, etc. But my hope is that the stated design encompasses this need for change and specifies what will and will not change over time. Maybe even there will be a way to query GHC for its JSON schema? Not sure. An important detail is that the flag for JSON output is -ddump-json, starting with a `d`; this means it's in the "debugging GHC" section of the manual. I hope that changes someday (where "hope" implies that I will actively support efforts at doing so). Richard > On Mar 16, 2021, at 6:01 PM, Sebastiaan Joosten <sjcjoosten(a)gmail.com> wrote: > > Hi Richard, > > this raises a question about the upcoming overhaul: is the JSON dump format following -ddump-json most likely to: > 1. change a lot (complete overhaul is likely and/or feature might disappear - say because all datatypes will be changed and the JSON is just some 'deriving Generic' ToJSON dump with default parameters) > 2. stay the same mostly (if/wherever it changes, it is either a bug or deliberate feature) > 3. change in minor ways (stability is not considered important in the overhaul but there are no reasons to believe this part of the code will be affected much) > ? > > What would your guess be? > > Sebastiaan > > PS: feel free to reply to cafe if that seems fitting – my mails there get rejected (issue on my end) > >> On 16 Mar 2021, at 14:07, Richard Eisenberg <rae(a)richarde.dev> wrote: >> >> There is no "official" way to accommodate this reasonable request. The ideas up-thread are good ones. >> >> I want to pipe in that we're currently going through an internal overhaul of error-message handling that will make such a request much easier to contemplate in the future. This is active work going on right now. So there is hope, possibly for 9.4. Of course, once the internal overhaul is done, we'll need to design any features that actually change the output -- the overhaul just makes it easy to implement such features (which would be very difficult at the moment). >> >> Richard >> >>> On Mar 16, 2021, at 12:56 PM, Jaro Reinders <jaro.reinders(a)gmail.com> wrote: >>> >>> On 16-03-2021 17:40, Tom Smeding wrote: >>>> In any case, the haskell language server just uses GHC internally, so it just shortens the GHC message. But then I believe the same result could be accomplished by some simple text manipulation on GHC's normal output. >>> >>> In fact, you can use -ddump-json to get JSON error messages. I should be easy to convert that to any form you like. >>> >>> But there is no clear specification of that output: >>> https://gitlab.haskell.org/ghc/ghc/-/issues/19278 >>> >>> And I also want to point out that there is a big open issue for better error messages: >>> https://gitlab.haskell.org/ghc/ghc/-/issues/8809 >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> To (un)subscribe, modify options or view archives go to: >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> Only members subscribed via the mailman list are allowed to post. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. >

1 0

shorter error messages
by Ben Franksen 17 Mar '21

17 Mar '21

Is there a way to tell ghc to print errors, especially type errors in a more concise way? Ideally one or two lines of text? I hate it when I have to scroll several pages of text just to see the next/previous error location. Cheers Ben -- Niemand hat das Recht zu gehorchen. -- Hannah Arendt

7 9

International Conference on Applied Data Science and Intelligence - (ADSI 2021) Prague
by matteo＠confscience.com 17 Mar '21

17 Mar '21

Call for papers ************************************************* International Conference on Applied Data Science and Intelligence - (ADSI 2021) Prague- Czech Republic, October 14-15, 2021 https://confscience.com/adsi/ Submission deadline: April 1, 2021 All papers accepted in ADSI 2021 will be published in Springer CCIS (Communications in Computer and Information Science). CCIS is abstracted/indexed in Scopus, SCImago, EI-Compendex, Mathematical Reviews, DBLP, Google Scholar, and Thomson Reuters Conference Proceedings Citation (Former ISI Proceedings) *************************************************************************** IMPORTANT DATES: - Paper Submission: April 1, 2021 - Acceptance Notification: July 1, 2021 - Final Manuscript Due: September 1, 2021 *************************************************************************** The ADSI 2021 conference will be held in Conjunction with: International Conference on Recent Theories and Applications in Transportation and Mobility (RTATM 2021) International Conference on Informatics Revolution for Smarter Healthcare (IRSH 2021) *************************************************************************** TOPICS: Authors are invited to submit their original papers to address the topics of the conference, including but not limited to: FUNDAMENTALS AND THEORIES - Theoretical Models - Spatial and temporal multi-models - Multi-dimensional data - Data acquisition and pre-processing - Data inference - Data Classification and Taxonomy - Data Metrics - New approaches for collaboration and competition - Self-organization, self-healing, fault-tolerance approaches - Spatial reasoning - Context awareness - Intelligent mobility - New approaches to supervised and unsupervised learning - New approaches for security, privacy, trust, and ethics in data science - Real-time data analytics - Multi-Agent Systems for data science - Distributed data analytics - Data authenticity - New theories and approaches for Deep learning - New approaches for Business Intelligence - Fuzzy logic - Decision trees - Support vector machines - Evolutionary computation - Statistical methods - Collaborative filtering - Data engineering - Content mining - Indexing schemes - Information retrieval - Metadata use and management INTELLIGENT DATA PROCESSING AND ANALYTICS - Multi-level data processing - Data analytics optimization - Smart data mining - Machine Learning - Deep Learning - Bio-Inspired Computing - Secure data analytics - Privacy in data analytics - Trust in Big Data - Business intelligence - Visualization Analytics - Intelligence as a Service (IaaS) - Data Science as a Service (DSaaS) - Natural Language Processing - Signal Processing - Simulation and Modeling - Data-Intensive Computing SYSTEMS AND INFRASTRUCTURES - Data storage infrastructure - Data warehouses - Data Query and Indexing Technologies - Software Defined Infrastructures - Software Defined Networks (SDN) - Distributed data systems - Smart grid computing - Intelligent data management - Big Data computing - Smart data networking - Internet of Things - Cyber Physical Systems - Blockchain - Fog and Edge intelligence - Parallel Computing systems - Open Source systems for data science - Embedded intelligence - Embedded data science - In-Memory computing - Intelligent drones - Internet of Drones - Real-time data acquisition systems APPLICATIONS - Intelligent Hazard management - Intelligent data science in healthcare - Intelligent data science in farming - Intelligent data science in Oil and Gas - Smart logistics - Intelligent data science in transportation - Intelligent data science in surveillance - Xtech (Fintech, Agritech, etc.) - Intelligent drones - Digital transformation - Bioinformatics - Marketing - Social Science - E-learning and E-services *************************************************************************** OUTSTANDING PAPERS: Based on the peer review scores as well as the presentations at the conference, the authors of outstanding papers will be invited to extend their works for a potential publication in journals special issues with high impact factors. *************************************************************************** PAPER SUBMISSION: Papers must be submitted electronically as PDF files via easychair (https://easychair.org/conferences/?conf=adsi2021) All papers will be peer reviewed. Length of Full papers: 12-15 pages long (written in the LNCS/CCIS one-column page format, 400 words per page) Length of Short papers: less than 12 pages For more information, please refer to the conference website: https://confscience.com/adsi/ *************************************************************************** CONTACT For more information, please send an email to info-adsi(a)confscience.com

1 0

21st Midlands Graduate School in the Foundations of Computing Science: Final Call for Participation
by Andrei Popescu 17 Mar '21

17 Mar '21

FINAL CALL FOR PARTICIPATION 21st Midlands Graduate School in the Foundations of Computing Science MGS 21 12-16 April 2021, virtually https://staffwww.dcs.shef.ac.uk/people/G.Struth/mgs21.html OVERVIEW The annual Midlands Graduate School in the Foundations of Computing Science (MGS) offers an intensive programme of lectures on the mathematical foundations of computing. It addresses first of all PhD students in their first or second year, but is open to anyone interested in its topics, from academia to industry and around the world. The MGS has been run since 1999 and is hosted alternately by the Universities of Birmingham, Leicester, Nottingham and Sheffield. MGS 21 is its 21st incarnation. Information about previous events can be found at the MGS web site http://www.cs.nott.ac.uk/MGS PROGRAMME MGS 21 consists of eight courses, each with four or five hours of lectures and a similar number of exercise sessions. Three courses are introductory; one is given by an invited lecturer. These should be attended by all participants. The remaining more advanced courses should be selected based on interest. MGS 21 aims at a mix of livestreamed and prerecorded lectures and livestreamed exercise sessions, with additional social online events. Invited lectures: Monads and Interactions Tarmo Uustalu, Reykjavik Introductory courses: Category Theory Jacopo Emmenegger, Birmingham Type Theory Thorsten Altenkirch, Nottingham Proof Theory Anupam Das, Birmingham Advanced courses: Homotopy Type Theory Nicolai Kraus, Nottingham Inductive and Coinductive Reasoning with Isabelle/HOL Andrei Popescu, Sheffield Effects and Call-by-Push-Value Paul Levy, Birmingham Formal Modelling and Analysis of Concurrent Systems Mohammad Mousavi, Leicester In addition we are organising a session where participants can briefly present and discuss their own research. A call will be made in March. REGISTRATION Participation at MGS 21 is free of charge, but selective. Requests must be submitted online via https://staffwww.dcs.shef.ac.uk/people/G.Struth/mgs21.html Registration deadline is April 1. ORGANISATION Please direct all queries about MGS 21 to Georg Struth. The Sheffield organisers are Harsh Beohar (H.Beohar(a)sheffield.ac.uk) Andrei Popescu (A.Popescu(a)sheffield.ac.uk) Georg Struth (G.Struth(a)sheffield.ac.uk)

1 0

Can eta-reduction of (\xs -> augment (flip (flip . foldr) xs)) typecheck?
by Viktor Dukhovni 17 Mar '21

17 Mar '21

With both `augment` and `foldr` from GHC.Base: augment :: (forall b. (a -> b -> b) -> b -> b) -> [a] -> [a] augment g = g (:) foldr :: (a -> b -> b) -> b -> [a] -> b ... The function: \xs -> augment (g xs) where g xs c z = foldr c z xs -- pointfree: g == flip (flip . foldr) typechecks (it is in fact just (++)) λ> let g xs c z = foldr c z xs λ> :t \xs -> augment (g xs) \xs -> augment (g xs) :: [a] -> [a] -> [a] Is it possible to explicitly type annotate some `g'` so that the function: (\xs -> (augment . g') xs) :: [a] -> [a] -> [a] is also just (++). That is, basically `g'` is the same as g, but with an explicit type signature that makes the type checker accept the eta-reduced composition? A completely naive attempt, with no type annotations yields: λ> let g xs c z = foldr c z xs λ> :t g g :: [a] -> (a -> b -> b) -> b -> b λ> :t (augment . g) <interactive>:1:2: error: • Couldn't match type: forall b. (a1 -> b -> b) -> b -> b with: (a -> b0 -> b0) -> b0 -> b0 Expected: ((a -> b0 -> b0) -> b0 -> b0) -> [a1] -> [a1] Actual: (forall b. (a1 -> b -> b) -> b -> b) -> [a1] -> [a1] • In the first argument of ‘(.)’, namely ‘augment’ In the expression: augment . g I haven't found any variant type signatures for "g" that make this go. I think this may require impredicative polymorphism, and so can't be done until perhaps QuickLook lands (don't know whether that'll be enough). -- Viktor.

1 0