- Haskell-Cafe - Haskell.org

Hard cases for "Note 5" in Haskell layout parsing
by Chris Smith 18 Mar '19

18 Mar '19

Quick question. I'm trying to resolve Haskell layout in order to provide better syntax highlighting, but without committing to building a full Haskell parser. The reason this is hard at face value is because of the "Note 5" in the relevant part of the Haskell Report, which says that a layout context closes whenever (a) the next token without closing the layout context would not be the start of any valid Haskell syntax, but (b) the current statement followed by an implicit '}' could be valid Haskell syntax. This rule is why it's okay to write "let x = 5 in x^2", even though let introduces a new layout syntax: the "in" implicitly closes it because "x = 5 in" isn't the start of any valid syntax, so the layout context is implicitly closed before the "in". Now for my question. Does anyone know other cases besides let/in where this commonly comes up? Everywhere I've seen this before uses let/in as an example, but then concludes that full parsing is needed and gives up on simpler answers. But the specific example with let/in is easily handled with a special-purpose rule that closes layout contexts as needed when an "in" keyword shows up. I cannot seem to construct any other examples, because other layout-introducing keywords have their contents at the end of syntactic element. Is there something I've missed here? I don't even care if it's a situation where something is technically valid but a horrible edge case. I'm interested in realistic counterexamples. Thanks, Chris

3 3

Learn you a Haskell for great good! Group readnig
by Jaysinh shukla 17 Mar '19

17 Mar '19

Respected Member, I am trying to learn Haskell from the book Learn you a Haskell for great good! [1]. I livestream my reading sessions at this [2] Twitch channel. Group reading is helping me to learn better. It is way more productive than reading alone. If you are learning Haskell, please join us. If you already know Haskell, please join to teach. Teaching will give you a good revision. Don't worry about the commitment to attend each and every session. It is fine to attend sessions on the day you are available and skip the rest. The fun part is, all the sessions will be on weekends. You can watch videos of past sessions here [3]. I am trying to maintain an event calendar for upcoming sessions here [4]. Please share these resources with whoever learning the Haskell. Don't hesitate to ask your questions here or in a personal mail. Thanks! 1: http://learnyouahaskell.com 2: https://www.twitch.tv/jaysinhp 3: https://www.twitch.tv/jaysinhp/videos 4: https://www.twitch.tv/jaysinhp/events

1 0

Preferred location for symlink-bindir?
by David Banas 15 Mar '19

15 Mar '19

Hi all, In moving to the cabal 'new-install' command, is there a preferred definition for the ‘symlink-bindir’ cabal configuration variable on Mac OS X? Thanks, -db

1 0

initialization of AlexUserState
by Kees Bleijenberg 15 Mar '19

15 Mar '19

Hi All, I have a Alex lexer with wrapper "monadUserState-bytestring". The AlexUserState = AlexUserState {sheetNames:: {String], currSheet:: Int}. The lexer should check whether a found sheetname is in sheetNames. The sheetNames from AlexUserState come from outside. I want to invoke the lexer many times with different AlexUserStates. Therefore the alexInitUserState function is not what I want. I'de like to initialize the AlexUserState while starting the lexer, i.e. as a parameter to runAlex. Can that be done? Kees --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. https://www.avast.com/antivirus

2 1

[TFP'19] second call for papers: Trends in Functional Programming 2019, 12-14 June 2019, Vancouver, BC, CA
by Peter Achten 15 Mar '19

15 Mar '19

-------------------------------- 2 N D C A L L F O R P A P E R S -------------------------------- ====== TFP 2019 ====== 20th Symposium on Trends in Functional Programming 12-14 June, 2019 Vancouver, BC, CA https://www.tfp2019.org/index.html == Important Dates == Submission Deadline for pre-symposium formal review Thursday, March 28, 2019 Sumbission Deadline for Draft Papers Thursday, May 9, 2019 Notification for pre-symposium submissions Thursday, May 2, 2019 Notification for Draft Papers Tuesday, May 14, 1029 TFPIE Tuesday, June 11, 2019 Symposium Wednesday, June 12, 2019 – Friday, June 14, 2019 Notification of Student Paper Feedback Friday June 21, 2019 Submission Deadline for revised Draft Papers (post-symposium formal review) Thursday, August 1, 2019 Notification for post-symposium submissions Thursday, October 24, 2019 Camera Ready Deadline (both pre- and post-symposium) Friday, November 29, 2019 The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below at scope). Please be aware that TFP uses two distinct rounds of submissions (see below at submission details). TFP 2019 will be the main event of a pair of functional programming events. TFP 2019 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 11. == Scope == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: Leading-edge, previously unpublished research work Position Articles: On what new trends should or should not be Project Articles: Descriptions of recently started new projects Evaluation Articles: What lessons can be drawn from a finished project Overview Articles: Summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include, but are not limited to: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2019 program chairs, William J. Bowman and Ron Garcia. == Best Paper Awards == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == Instructions to Author == Papers must be submitted at: https://easychair.org/conferences/?conf=tfp2019 Authors of papers have the choice of having their contributions formally reviewed either before or after the Symposium. == Pre-symposium formal review == Papers to be formally reviewed before the symposium should be submitted before an early deadline and receive their reviews and notification of acceptance for both presentation and publication before the symposium. A paper that has been rejected in this process may still be accepted for presentation at the symposium, but will not be considered for the post-symposium formal review. == Post-symposium formal review == Papers submitted for post-symposium review (draft papers) will receive minimal reviews and notification of acceptance for presentation at the symposium. Authors of draft papers will be invited to submit revised papers based on the feedback received at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. == Paper categories == There are two types of submission, each of which can be submitted either for pre-symposium or post-symposium review: Extended abstracts. Extended abstracts are 4 to 10 pages in length. Full papers. Full papers are up to 20 pages in length. Each submission also belongs to a category: research position project evaluation overview paper Each submission should clearly indicate to which category it belongs. Additionally, a draft paper submission—of either type (extended abstract or full paper) and any category—can be considered a student paper. A student paper is one for which primary authors are research students and the majority of the work described was carried out by the students. The submission should indicate that it is a student paper. Student papers will receive additional feedback from the PC shortly after the symposium has taken place and before the post-symposium submission deadline. Feedback is only provided for accepted student papers, i.e., papers submitted for presentation and post-symposium formal review that are accepted for presentation. If a student paper is rejected for presentation, then it receives no further feedback and cannot be submitted for post-symposium review. == Format == Papers must be written in English, and written using the LNCS style. For more information about formatting please consult the Springer LNCS web site (http://www.springer.com/lncs) == Program Committee == Program Co-chairs William J. Bowman University of British Columbia Ronald Garcia University of British Columbia Matteo Cimini University of Massachusetts Lowell Ryan Culpepper Czech Technical Institute Joshua Dunfield Queen's University Sam Lindley University of Edinburgh Assia Mahboubi INRIA Nantes Christine Rizkallah University of New South Wales Satnam Singh Google AI Marco T. Morazán Seton Hall University John Hughes Chalmers University and Quviq Nicolas Wu University of Bristol Tom Schrijvers KU Leuven Scott Smith Johns Hopkins University Stephanie Balzer Carnegie Mellon University Viktória Zsók Eötvös Loránd University

1 0

Annoying problem when pattern matching negative integer literals and wildcards
by Vanessa McHale 15 Mar '19

15 Mar '19

I have the following program: module Bug ( encryptionResult ) where data EncryptionResult = HasEncryption | EncryptionUnknown encryptionResult :: Int -> EncryptionResult encryptionResult 1 = HasEncryption encryptionResult -1 = EncryptionUnknown encryptionResult _ = error "Internal error." When I try to compile it with GHC I get [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:1: error: Multiple declarations of ‘encryptionResult’ Declared at: Bug.hs:7:1 Bug.hs:9:1 | 9 | encryptionResult _ = error "Internal error." | ^^^^^^^^^^^^^^^^ I can replicate this in Hugs, viz. ERROR "Bug.hs":7 - "encryptionResult" multiply defined However, everything compiles fine when I write module Bug ( encryptionResult ) where data EncryptionResult = HasEncryption | EncryptionUnknown encryptionResult :: Int -> EncryptionResult encryptionResult 1 = HasEncryption encryptionResult -1 = EncryptionUnknown or module Bug ( encryptionResult ) where data EncryptionResult = HasEncryption | EncryptionUnknown encryptionResult :: Int -> EncryptionResult encryptionResult 1 = HasEncryption encryptionResult 0 = EncryptionUnknown encryptionResult _ = error "Internal error." Am I doing something obviously screwy? This seems like a pretty annoying feature on the language (to the point where I assumed it was a GHC bug until I got the same behavior with Hugs) and I can't figure out why it exists. Cheers, Vanessa McHale

3 3

How to use alex with param -g in cabal
by Kees Bleijenberg 14 Mar '19

14 Mar '19

Hi all, Alex is in the build-tools part of the cabal file. The docs of Alex says that invoking Alex with -g makes the resulting lexer significantly faster and smaller. How can I pass the -g parameter in the cabal file? Kees --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. https://www.avast.com/antivirus

2 1

ANN: Radicle
by Julian Arni 13 Mar '19

13 Mar '19

Today we're releasing the alpha version of Radicle. Radicle is a p2p code collaboration platform (think Github replacement). Issues, patches (like PRs) and optionally code are distributed via IPFS, without a centralized server, and with tooling that's meant to work directly from your terminal. There's a lot more info on the webpage [0]. Radicle is written in Haskell (minus the parts that are written in the Radicle language itself, though the language is implemented in Haskell), and open-source, which is why I thought to post here. [0] www.radicle.xyz

2 1

Apply Haskell at scale in a music start-up
by Jeroen Bransen 12 Mar '19

12 Mar '19

* Dear Haskellers, Chordify is hiring! Chordify is a young and fast growing music e-learning platform that helps musicians to play their favorite music. We automatically analyse the chords of a piece of music and display them in an intuitive player. Try it yourself at: https://chordify.net/or download one of our apps https://chordify.net/app The cool thing is: our backend serving our apps and website has been written mostly in Haskell. With over 8 million users per month we apply functional programming at scale. We hope to broaden our team with a functional programmer. We are looking for people who are pro-active, independent, and creative to improve Chordify. You’d have the opportunity to be productive with advanced type-system features and powerful GHC extensions. Our back-end is powered by libraries like Servant, Persistent and Esqueleto and we distribute computation using Cloud Haskell. If you are interested in working at Chordify, please have a look at: https://jobs.chordify.net/ All the best, Jeroen Bransen *

2 2

[OT] thoughts about OO vs. functional "philosophy"
by Dennis Raddle 12 Mar '19

12 Mar '19

I have a thought about OO vs. functional programming . I'm moderately experienced with functional languages such as Haskell and Purescript and have used OO for many years at work (Python, C++). I'm giving tutoring lessons in Python to a professional who wants to use programming as part of his work. (He's an entrepreneur.) He is eager to understand functional and OO styles within Python--he keeps asking about the real benefit of each, not content with a superficial approach. I've explained about "encapsulation": gathering related functions together and minimizing coupling to the rest of the program. He asks "why do we encapsulate?" I've explained that one reason is to help we, the programmers, be confident that our code is correct. For example, in a class we try to isolate the implementation details from the rest of the program, and the compiler helps enforce that.So when we're writing our code and confirming to ourselves it's correct, we can make simplifying assumptions. We know the rest of the program won't modify our private variables and won't access us in any way other than the interface we've presented to the world. I explained that a large program is like a corporation, and pieces of the program are like individual employees. When we write a class or function, in a sense we "become" that employee and "forget about" a lot of the details of other employees. (i.e., encapsulation). Then has asked why functional programming is helpful. I explained about referential transparency. Say we're a function: then other "employees" (other functions) can trust us with simplifying assumptions, like no side-effects. Then this thought occurred to me, which is nifty but maybe not the whole story. """ Say we're a class. Then the simplifying assumptions of OO allow *us* to trust the *rest of the program* won't mess with us. Say we're a function. Then the simplifying assumptions of functional style help the *rest of the program* trust that *we* won't mess with it. """ D

10 14