- Haskell-Cafe - Haskell.org

Advert for: 12 fully-funded 3-year PhD scholarships at Kent
by Simon Thompson 22 Feb '19

22 Feb '19

The Programming Languages and Systems (PLAS) group at the University of Kent's School of Computing invites applications for 12 fully-funded 3-year PhD scholarships (for UK/EU students). Applications are due by the 26th April 2019. The PLAS group is one of the largest programming languages research groups in Europe. It is currently ranked 17th worldwide by the independent CSrankings website: http://csrankings.org/#/index?plan&world. We provide a supportive environment for research and we have a vibrant postgraduate population. We encourage our students to engage with the wider research community through attending conferences and taking internships with leading industrial companies. We are located in Canterbury, a lively and cosmopolitan historic town with convenient travel links to London and Europe. You can apply to study for a PhD in any topic that falls within our range of expertise. We have studentships up to a value of £19,945 per annum that are available by competition. Application process: Select a potential supervisor (see below) and send them an informal project proposal as well as a brief CV (preferably by the first week of April 2019). Staff contact details can be found on their web pages. Submit your formal applications through the university admission system by the 26th April 2019. Your application should include a completed online admission form; the name and contact details of two referees; an original document providing confirmation of your degree (or a transcript if the degree is not yet awarded). For non-native English speakers, a certificate of competence in English is required at IELTS 6.5 or higher, with no element less than 6.0 (or equivalent). Programming Languages and Systems Group: https://www.cs.kent.ac.uk/research/groups/plas/index.html Topics suggested by our group https://www.cs.kent.ac.uk/research/groups/plas/pgprojects.html Applications process: https://www.cs.kent.ac.uk/research/studyingforaphd/howtoapply.html For general inquiries about the process, please e-mail: cs-phd-plas(a)kent.ac.uk. PLAS is a large research group with potential supervisors who work across the breadth of programming languages and systems research. *Dr Mark Batty* (Additional scholarship: https://www.cs.kent.ac.uk/people/staff/mjb211/studentship/studentship.htm) Concurrency; software verification; systems; relaxed memory; programming language semantics; GPU concurrency. *Dr Laura Bocchi* Foundations and engineering of API with complex behaviour, verification of distributed concurrent systems; behavioural types; real-time systems; transactions and transaction protocols. *Dr Olaf Chitil* Tracing, semantics, algorithmic debugging, type error debugging, compilation and functional programming. *Dr Radu Grigore* Program analysis; runtime verification; probabilistic models of computation. *Dr Rogerio de Lemos* Software engineering for self-adaptive systems: assurances and resilience evaluation; architecting resilient systems. *Prof. Richard Jones* Language implementation; memory management; garbage collection; object demographics; program analysis for improved memory management; program visualisation, rigorous performance evaluation. *Dr Stefan Kahrs* Expressiveness of programming languages, type systems, term rewriting, infinitary rewriting. *Dr Stephen Kell* Language implementation, tools, interoperability, runtimes and operating systems. *Prof. Andy King* Abstract interpretation, logic programming, decompilation and reverse engineering *Dr Julien Lange* Process calculi, automata theory, behavioural types, model checking and their application to the implementation and verification of concurrent and distributed systems. *Dr Stefan Marr* Language implementation techniques, concurrency, parallel programming, optimizations, tooling, debugging, virtual machines, interpreters, compilation. *Dr Matteo Migliavacca* On-line data processing, distributed publish-subscribe, and high-performance event processing in large scale and cloud scenarios. *Dr Dominic Orchard* Mathematical structure of programs; logical foundations of programming; categorical semantics; behavioural type theories; programming language design; program verification for computational science. *Dr Scott Owens* Semantics of shared memory concurrency; design of programming languages; formal verification for software and interactive theorem proving, especially for CakeML (https://cakeml.org) *Dr Tomas Petricek* Programming languages and tools, especially for data science, studying interactions of programming, bridging the gap between data and types; foundations of programming in a broad sense, including design and human experience; philosophy and history of computing and programming. *Prof. Simon Thompson* Functional programming in Haskell, Erlang and OCaml; refactoring functional programs: tool building. theory and practice: dependently-typed functional programming; DLT: languages for smart contracts on blockchains, including Marlowe on Cardano. Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk <mailto:s.j.thompson@kent.ac.uk> | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt <http://www.cs.kent.ac.uk/~sjt>

1 0

ANNOUNCE: waargonaut-0.6.0.0 (better mousetrap)
by Sean Chalmers 22 Feb '19

22 Feb '19

## Waargonaut 0.6.0.0 This release of Waargonaut sees several issues fixed and a generous helping of cleanups and refactoring. This is a breaking change as the API has been drastically altered for some parts. Other changes include more granular modules and generalisation. ### Bug fixes - Unicode was not being handled correctly, sometimes. The encoding/decoding to a `Text` or `String` value wasn't correct due to my own lack of understanding. - Upper-case hexadecimal input was being silently zeroed out during some conversion steps. Those issues should all be resolved now. In the process of fixing those issues, it tugged on a couple of threads for things I've been wanting to do. So I did them, see below: ### Changes: #### Decoding! Using `parseWith` and the requirement to DIY almost an entire parsing function is a thing of the past. Replaced with the following structure: Functions: - `decodeWith` - `decodeFromText` - `decodeFromString` - `decodeFromByteString` - `decodeWithInput` - as well as their pure variants These functions only require you provide a function from the respective input type and has an implementation of the `CharParsing` interface. The greatly simplifies the process of providing your own parsing function. #### Default Parsing Functions! Waargonaut now provides some default parsing functions using the `attoparsec` package. These are in the `Waargonaut.Attoparsec` module and should make it easier for people to be up and running with the package when requirements of a custom parser aren't important. #### New Optics! The `Waargonaut.Lens` module provides some Prisms for use with the `Json` type. Working in a similar way to the `lens-aeson` package. These optics are law abiding and they have tests to prove it. #### Better Builder To complement the more streamlined parsing functions, the encoder has had its builder internals reworked to support either `Text` or `ByteString`. In the style of "scrap your typeclasses" to keep things simple. Added tests to check their output matches. #### More modules! - Factored out components into more focused submodules: - UnescapedJChar - EscapedJChar - HexDigit4 - Elem - Elems - JAssoc - Decode.Runners - Builders for all `Json` types now live under `Waargonaut.Encode.Builder` #### Deprecate Traversal decoder The decoder in `Waargonaut.Decode.Traversal` has been marked as deprecated and will be removed in a future release. It is bit rotting somewhat compared to the succinct powered decoder and doesn't operate at anywhere near the same level of speed or memory efficiency. If people care they can open an issue to let me know. #### Test re-structure Tests have been reordered into more granular modules. Some tests have been removed or reworked to be more accurate. More tests have been added to try to protect from regressions. More tests have been added to confirm that various instances or functions are law abiding. As a consequence there have been a few instances and functions that have been removed.

1 0

ghci segmentation fault
by Damien Mattei 21 Feb '19

21 Feb '19

when executing this code i have a segmentation fault: printNameAndData :: (String,Float,Float) -> IO () printNameAndData (name,bdSidonie,bdWDS) = do putStrLn $ name ++ " " ++ show bdSidonie ++ " " ++ show bdWDS return () main :: IO () main = do rm <- mapM printNameAndData fltrdNamesBDsApprox *Main> :load UpdateSidonie.hs [1 of 1] Compiling Main ( UpdateSidonie.hs, interpreted ) Ok, one module loaded. *Main> main Segmentation fault (core dumped) if i hat a print statement: putStrLn $ show rm it works: [output cut] ... STT 448 28.4162 28.4162 STT 453 6.493 6.493 STT 487 79.761 79.761 STT 518 7.952 7.952 STT 524 19.3533 19.3533 STT 531 37.878 37.878 STT 534 21.3296 21.3296 VDK 1 26.1293 26.1293 VDK 2 7.4946 7.4946 VOU 42 -16.461 -16.461 WOR 7 71.851 71.851 WOR 12 27.4445 27.4445 WOR 17 -9.956 -9.956 WOR 20 16.2316 16.2316 WOR 24 31.25 31.25 [(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),(),()] strange? the version is: GHCi, version 8.2.2 Damien

3 4

(no subject)
by Damien Mattei 20 Feb '19

20 Feb '19

in my previous message instead of 'hat' we must read 'add' ... gasp...

1 0

Deadline extension: DBPL 19
by Alvin Cheung 20 Feb '19

20 Feb '19

Due to multiple requests, we are extending the deadline for *both* paper tracks to *Monday Feb 25* (anytime on Earth). Please feel free to submit via our hotcrp website. Questions can be directed to dbpl19-pcchairs(a)cs.washington.edu . ---------------------------------------------------------------------- The 17th International Symposium on Database Programming Languages https://pldi19.sigplan.org/track/dbpl-2019-papers Phoenix, Arizona, USA June 23, 2019 hosted as part of PLDI 2019 Call for Papers For over 25 years, DBPL has established itself as the principal venue for publishing and discussing new ideas at the intersection of databases and programming languages. Many key contributions in query languages for object-oriented data, persistent databases, nested relational data, and semistructured data, as well as fundamental ideas in types for query languages, were first announced at DBPL. Today, this creative research area is broadening into a subfield of data-centric computation, currently scattered among a range of venues. DBPL is an established destination for such new ideas and solicits submissions from researchers in databases, programming languages or any other community interested in the design, implementation or foundations of data-centric computation. Scope ----- DBPL solicits practical and theoretical papers in all topics at the intersection of databases and programming languages. Papers emphasizing new topics or emerging areas are especially welcome. Suggested, but not exclusive, topics of interest for submissions include: - Compiling Query Languages to Modern Hardware - Data-Centric Programming Abstractions, Comprehensions, Monads - Data Integration, Exchange, and Interoperability - Data Synchronization and Bidirectional Transformations - Declarative Data Centers (e.g., distributed query processing, serverless computing platforms, social computing platforms, etc) - Emerging and Nontraditional Data Models - Language-Based Security in Data Management - Language-Integrated Query Mechanisms - Managing Uncertain and Imprecise Information - Metaprogramming and Heterogeneous Staged Computation - Programming Language Support for Data-Centric Programming (e.g., databases, web programming, machine learning, etc) - Query Compilation and In-memory Databases - Query Language Design and Implementation - Query Transformation and Optimization - Schema Mapping and Metadata Management - Semantics and Verification of Database Systems - Stream Data Processing and Query Languages - Type and Effect Systems for Data-Centric Programming Author Guidelines ----------------- Prospective authors are invited to submit full papers in English presenting original research. Submitted papers must be unpublished and not submitted for publication elsewhere. Submissions should be no more than 10 pages long, excluding references, in the two-column ACM proceedings format, following PLDI's formatting requirements (https://pldi19.sigplan.org/track/pldi-2019-papers#Call-for-Papers) Each submission should begin with a succinct statement of the problem and a summary of the main results. Authors may provide more details to substantiate the main claims of the paper by including a clearly marked appendix at the end of the submission, which is not included in the page limit and is read at the discretion of the committee. At least one author of each accepted paper must attend the symposium to present their work. Short papers of at most 4 pages (same format as long papers) describing work in progress, demos, research challenges or visions are also welcome. Accepted short papers may be included or excluded from the formal proceedings, whichever the author(s) prefer. Full and short papers are both due on the deadline, February 25, 2019. Instructions on how to submit will be posted on the symposium website noted above. Review is single-blind, so authors do not need to anonymize their submissions. PC submissions are allowed, except for the co-chairs. Important Dates --------------- - Paper Submission: February 25, 2019 - Notification: March 29, 2019 - Final versions due: April 16, 2019 - Symposium: June 23, 2019 Proceedings ----------- Accepted papers will appear as part of the PLDI Proceedings for DBPL 2019. Program Committee ----------------- *Program Co-Chairs* Alvin Cheung, University of Washington Kim Nguyen, Universite Paris-Sud *Program Committee* William Cook, University of Texas at Austin Vasiliki Kalavri, ETH Harshad Kasture, Oracle Oleg Kiselyov, University of Tsukuba Sam Lindley, University of Edinburgh Tiark Rompf, Purdue University Stefanie Scherzinger, OTH Regensberg Amir Shaikhha, EPFL / University of Oxford Avi Shinnar, IBM Guido Wachsmuth, Oracle Melanie Wu, Pomona College History ------- The 17th Symposium on Data Base Programming Languages (DBPL 2019) continues the tradition of excellence initiated by its predecessors in Roscoff, Finistere (1987), Salishan, Oregon (1989), Nafplion, Argolida (1991), Manhattan, New York (1993), Gubbio, Umbria (1995), Estes Park, Colorado (1997), Kinloch Rannoch, Scotland (1999), Marino, Rome (2001), Potsdam, Germany (2003), Trondheim, Norway (2005), Vienna, Austria (2007), Lyon, France (2009), Seattle, Washington (2011), Riva del Garda, Italy (2013), Pittsburgh, Pennsylvania (2015), Munich, Germany (2017). DBPL was affiliated with VLDB from 1999-2013 and in 2017. In 2015, it is affiliated with SPLASH for the first time and in 2019, it is affiliated with PLDI for the first time.

1 0

ANNOUNCE: eccrypto 0.1.0, timing attack safe cryptography in Haskell
by Marcel Fourné 19 Feb '19

19 Feb '19

Dear Haskell Community! I'd like to introduce some new cryptographic code, containing a verified[*] timing-attack safe pure Haskell[**] implementation of Ed25519 and as of yet unverified implementations of textbook ECDH and ECDSA on the NIST prime curves. Install it by $ cabal install eccrypto or download it from Hackage[0]. Also contained are test vectors, usable by the trusty $ cabal test as well as benchmarking code which you can invoke by $ cabal bench if you want to try my code before using it. Please note that this is a one person project, so there is still much room for optimization. The intended focus groups are implementors of cryptographic protocols as well as other cryptographers and interested third parties. My code uses no[**] embedded C code or assembly to achieve timing attack resistance, only careful Haskell constructions in the internal modules, the obligatory hackers footgun included only in those. ;-) Security sketch: The timing attack safety is built on the constant time criterion, namely, that no branches or memory access indices may be based on the content of the secret key bits. The name of this criterion is from the strict evaluation world of cryptography, but does not prohibit non-strict evaluation semantics per se. The API is only slightly different from contemporary libraries like "ed25519"[1], but the content of the signatures is just the same. The number of dependencies are also in the same ballpark, if you'd like to use the code for infrastructure - but in that case, please talk to me to not use unverified/insecure operations! Best of wishes to a thriving community, Marcel Fourné [*]: paper upcoming but as of now it only exists in my notes; analysis was done "by hand" on assembly generated by GHC 8.4.4, mechanization based on established proofs is planned [**]: using integer-gmp, might change in the future to low-level Haskell [0]: https://hackage.haskell.org/package/eccrypto-0.1.0 [1]: https://hackage.haskell.org/package/ed25519

1 0

Looking for JavaScript(V8)-compilant parser
by Javran Cheng 19 Feb '19

19 Feb '19

Hi Cafe, tl;dr: I'm wondering if there are existing parsers for parsing any dateString that can be accepted by `Date.parse` of JavaScript(V8). The input looks like "Fri, 08 February 2019 12:34:56 +0900". At first I checked [MDN]( https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Ob…) and turns out it's very close to [IETF-compliant RFC 2822 timestamps]( https://tools.ietf.org/html/rfc2822#page-14) but not quite: as I then found [hsemail]( http://hackage.haskell.org/package/hsemail-2/docs/Text-Parsec-Rfc2822.html) to be promising, but it rejected "Fri, 08 February 2019 12:34:56 +0900" but accepted "Fri, 08 Feb 2019 12:34:56 +0900" (notice that RFC2822 does not accept full month name). Refering to language spec doesn't help ( http://www.ecma-international.org/ecma-262/5.1/#sec-15.9.4.2) as it doesn't mention RFC2822 at all. So it seems `Data.parse` accepts a superset of RFC2822 and a version of ISO8601 (as described in MDN above) but I'm not sure what exactly is the accepting set of inputs. Before I start working on a quick and dirty solution (it should work patching hsemail to accept full month name) I want to know if there are existing parsers for this purpose? Thanks! -- Javran (Fang) Cheng

1 0

Amazonka: is it possible to work around deserialisation bug?
by Magnus Therning 19 Feb '19

19 Feb '19

I just created issue #517 on Amazonka [^1] which got me thinking. Is my only option to wait for the bug to be fixed or can I hack my way around it? I looked around in the documentation for Amazonka a bit but failed to find some obvious way to hack together a "send this request but give me the response in JSON". Which is why I'm trying my luck here. I suspect I'm not the first Amazonka user to find myself in this situation, so hopefully someone's got a solution already. /M [^1]: https://github.com/brendanhay/amazonka/issues/517 -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus(a)therning.org twitter: magthe http://magnus.therning.org/ Computers are useless. They can only give you answers. — Pablo Picasso

3 3

Re: [Haskell-cafe] Need help understanding a GADT related error
by David Banas 18 Feb '19

18 Feb '19

Hilco, Your first error arrises, because you’re offering to the caller of `h` that she may demand any type of `a`, but are “hard-wiring” `a :: T E` in the definition of that function. Reflecting that fact in the function type signature eliminates the error: -- h :: H (T a) h :: H (T E) h [] = (E' (E "E"), []) h (head:rest) = (E' (E ("E")), rest) Your second error is explained (I hope) in the comments I’ve added to your original code: tt' :: [Char] -> [T a] tt' = tt h [a, b] -- tt :: H t -> [P Char t] -> TT t -- :: ([Char] -> (t, [Char])) -> [P Char t] -> [Char] -> [t] -- -- h :: [Char] -> (t, [Char]) ~ H (T E) -- h :: [Char] -> (t, [Char]) ~ [Char] -> (T E, [Char]) -- ==> t ~ T E -- -- [a, b] :: [P Char t] -- a :: P Char (T E) /~ P Char (T A) -- b :: P Char (T E) /~ P Char (T B) -db

1 0

Need help understanding a GADT related error
by Hilco Wijbenga 18 Feb '19

18 Feb '19

Hi all, I created some GADT code (see https://pastebin.com/vkJ3RzNA and below). When compiling this I get these errors: $ stack build parser-0.1.0.0: build (exe) Preprocessing executable 'parser' for parser-0.1.0.0.. Building executable 'parser' for parser-0.1.0.0.. [2 of 2] Compiling Main ( src/Main.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1/build/parser/parser-tmp/Main.o ) /home/hilco/workspaces/haskell/parser/src/Main.hs:30:18: error: • Couldn't match type ‘a’ with ‘E’ ‘a’ is a rigid type variable bound by the type signature for: h :: forall a. H (T a) at src/Main.hs:29:1-12 Expected type: T a Actual type: T E • In the expression: E' (E "E") In the expression: (E' (E "E"), []) In an equation for ‘h’: h [] = (E' (E "E"), []) • Relevant bindings include h :: H (T a) (bound at src/Main.hs:30:1) | 30 | h [] = (E' (E "E"), []) | ^^^^^^^^^^ /home/hilco/workspaces/haskell/parser/src/Main.hs:34:16: error: • Couldn't match type ‘B’ with ‘A’ Expected type: P Char (T A) Actual type: P Char (T B) • In the expression: b In the second argument of ‘tt’, namely ‘[a, b]’ In the expression: tt h [a, b] | 34 | tt' = tt h [a, b] | ^ -- While building custom Setup.hs for package parser-0.1.0.0 using: /home/hilco/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.3 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1 build exe:parser --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Why is "T a" not a more generic version of "T E"? Why doesn't "T E + T A + TB" yield "T a" as a generic type? Cheers, Hilco 1 {-# LANGUAGE GADTs #-} 2 3 module Main where 4 5 data PR t a = PR (Maybe ([t], a)) 6 data P t a = P ([t] -> PR t a) 7 8 a :: P Char (T A) 9 a = undefined 10 11 b :: P Char (T B) 12 b = undefined 13 14 data A = A 15 data B = B 16 data E = E String 17 18 data T a where 19 A' :: T A 20 B' :: T B 21 E' :: E -> T E 22 23 type H t = [Char] -> (t, [Char]) 24 type TT t = [Char] -> [t] 25 26 tt :: H t -> [P Char t] -> TT t 27 tt = undefined 28 29 h :: H (T a) 30 h [] = (E' (E "E"), []) 31 h (head:rest) = (E' (E ("E")), rest) 32 33 tt' :: [Char] -> [T a] 34 tt' = tt h [a, b] 35 36 main :: IO () 37 main = putStrLn "Hello"

3 2