- Haskell-Cafe - Haskell.org

Eq source code?
by Galaxy Being 02 Apr '21

02 Apr '21

While learning about type classes, I tried to find the actual source code for Eq. In my beginner books this much is typically given class Eq a where (==), (/=) :: a -> a -> Bool -- Minimal completion definition: x /= y = not (x == y) x == y = not (x /= y) I then found this <https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Eq.html> at hackage.haskell.org, but the "source" links are dead. On this page is a section of what I can't tell is either source code or just commentary on all the different mathematical ideas about equality, i.e., Reflexivity x == x = True Symmetry x == y = y == x Transitivity if x == y && y == z = True, then x == z = True Substitutivity if x == y = True and f is a "public" function whose return type is an instance of Eq, then f x == f y = True Negation x /= y = not (x == y) I would like to know if this is indeed in the source code or if it's just a sort of commentary. It looks important. Where can I find the actual source for all these basic type classes? LB

3 3

Hackage dependencies
by Aaron Gray 02 Apr '21

02 Apr '21

Hi, Is there a tool or web access to give a list off all Hackage packages dependent upon a Hackage package, please ? Regards, Aaron -- Aaron Gray Independent Open Source Software Engineer, Computer Language Researcher, Information Theorist, and Computer Scientist.

3 3

Bx 2021 - CALL FOR PAPERS
by Meng Wang 31 Mar '21

31 Mar '21

To Haskellers, Bidirectional Transformations (Bx) are also known as lenses! Please consider submitting your Haskell-related papers which are very welcome. Best regards, Meng Meng Wang, PhD (Oxon) University of Bristol Senior Lecturer of Programming Languages Head of PL research group International Director of SCEEM (CS, EEE, EMath) School ********************************************************************************** 9th International Workshop on Bidirectional Transformations (Bx 2021) as part of the STAF conference (June 21, 2021) running virtually, Western Norway University of Applied Sciences, Bergen, Norway http://bx-community.wikidot.com/bx2021:home ********************************************************************************** * Important dates: * Abstract submission: April 27, 2021 * Paper Submission: May 4, 2021 ********************************************************************************** OVERVIEW ========================================= Bidirectional transformations (bx) are a mechanism for maintaining the consistency between two or more related (and heterogeneous) sources of information (i.e., relational databases, software models and code, or any other artefacts following standard or domain-specific formats). The strongest argument in favour of bx is its ability to provide a synchronization mechanism that is guaranteed to be correct by construction. Bx has been attracting a wide range of research areas and communities, with prominent presence at top conferences in several different fields (namely databases, programming languages, software engineering, and graph transformation). Nowadays, the fast-growing complexity of software- or data- intensive systems has forced the industry and the academy to use and investigate different development techniques to manage the many different aspects of the systems. Researchers are actively investigating the use of bidirectional approaches to tackle a diverse set of challenges with various applications including model-driven software development, visualization with direct manipulation, big data, databases, domain-specific languages, serializers, and data transformation, integration and exchange. Bx 2021 is a dedicated venue for bx in all relevant fields and is part of a workshop series that was created in order to promote cross-disciplinary research and awareness in the area. As such, since its beginning in 2012, the workshop has rotated between venues in different fields. TOPICS ========================================= The aim of the workshop is to bring together researchers and practitioners, established and new, interested in bx from different perspectives, including but not limited to: * bidirectional programming languages and frameworks * software development with bx * data and model synchronization * view updating * inter-model consistency analysis and repair * data/schema (or model/metamodel) co-evolution * coupled software/model transformations * inversion of transformations and data exchange mappings * domain-specific languages for bx * analysis and classification of requirements for bx * bridging the gap between formal concepts and application scenarios * analysis of efficiency of transformation algorithms and benchmarks * model-driven and model-based approaches * survey and comparison of bx technologies * case studies and tool support CATEGORIES OF SUBMISSIONS ========================================= Five categories of submissions are considered: * Full Research Papers (13-15 pages) - in-depth presentations of novel concepts and results - applications of bx to new domains - survey papers providing novel comparisons between existing bx technologies and approaches, case studies * Tool Papers (7-8 pages) - guideline papers presenting best practices for employing a specific bx approach (with a specific tool) - presentation of new tools or substantial improvements to existing ones - qualitative and/or quantitative comparisons of applying different bx approaches and tools * Experience Report (7-8 pages) - sharing experiences and lessons learned with bx tools/frameworks/languages - how bx is used in (research/industrial/educational) projects * Short Papers (5 pages) - work in progress - small focused contributions - position papers and research perspectives - critical questions and challenges for bx * Talk Proposals (2 pages) - proposed lectures about topics of interest for bx - existing work representing relevant contributions for bx - promising contributions that are not mature enough to be proposed as papers of the other categories If your submission is not a Full Research Paper, please include the intended submission category in the Title field of EasyChair’s submission form. Tool papers, experience reports and short papers will be mapped to the short paper category in CEUR (5-9 standard pages, 1 standard page = 2500 characters), whereas full research papers will be mapped to the regular paper category in CEUR (min. 10 standard pages). The bibliography is excluded from the page limits. All papers are expected to be self-contained and well-written. Tool papers are not expected to present novel scientific results, but to document artifacts of interest and share bx experience/best practices with the community. Experience papers are expected to report on lessons learnt from applying bx approaches, languages, tools, and theories to practical application case studies. Extended abstracts should primarily provoke interesting discussion at the workshop and will not be held to the same standard of maturity as regular papers; short papers contain focused results, positions or perspectives that can be presented in full in just a few pages, and that correspondingly contain fewer results and that therefore might not be competitive in the full paper category. Talk proposals are expected to present work that is of particular interest to the community and worth a talk slot at the workshop. We strongly encourage authors to ensure that any (variants of) examples are present in the bx example repository at the time of submission, and, for tool papers, to allow for reproducibility with minimal effort, either via a virtual machine (e.g., via Share) or a dedicated website with relevant artifacts and tool access. All submissions will be peer-reviewed by at least three members of the program committee. If a submission is accepted, at least one author is expected to participate in the workshop to present it. Authors of accepted tool paper submissions are also expected to be available to demonstrate their tool at the event. PROCEEDINGS ========================================= The workshop proceedings (in a STAF 2021 joint volume for workshops), including all accepted papers (except talk proposals), shall be submitted after the conference to CEUR-WS.org for online publication. Pre-prints of all papers will be available via the workshop website at the beginning of the conference. Papers must follow the CEUR one column style available at: http://ceur-ws.org/Vol-XXX/CEURART.zip or https://www.overleaf.com/latex/templates/template-for-submissions-to-ceur-w… and must be submitted via EasyChair: https://easychair.org/conferences/?conf=bx2021 Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submissions not complying with the above guidelines may be excluded from the reviewing process without further notice. IMPORTANT DATES ========================================= Abstract submission: April 27, 2021 Paper submission: May 4, 2021 Author notification: May 25, 2021 Early registration: May 27, 2021 Workshop: June 21, 2021 PROGRAM CO-CHAIRS ========================================= The workshop is co-organized by Meng Wang (University of Bristol, UK) and Leen Lambers (Hasso Plattner Institute at the University of Potsdam, Germany). In case of questions, please contact the PC chairs at bx2021(a)easychair.org . Please find further information w.r.t. the Bx 2021 workshop at: http://bx-community.wikidot.com/bx2021:home and STAF 2021 conference at: https://staf2021.hvl.no/ PROGRAM COMMITTEE ========================================= Ravi Chugh, University of Chicago, USA Anthony Cleve, University of Namur, Belgium Alcino Cunha, University of Minho, Portugal Romina Eramo, University of L'Aquila, Italy Michael Johnson, Macquarie University, Australia Hsiang Shang Ko, Academia Sinica, Taiwan Ralf Lämmel, University of Koblenz-Landau, Germany Kazutaka Matsuda, Tohoku University, Japan Fernando Orejas, Universitat Politècnica de Catalunya, Spain Roly Perera, Alan Turing Institute, UK Perdita Stevens, The University of Edinburgh, UK Tarmo Uustalu, Reykjavik University, Iceland Jens Weber, University of Victoria, Canada Bernhard Westfechtel, University of Bayreuth, Germany =========================================

1 0

Injective type classes?
by Tom Smeding 30 Mar '21

30 Mar '21

Hi Cafe, With this class definition with this instance: class C a where instance C b => C (a, b) GHC can of course infer, given 'C b', that 'C (a, b)'. This is nothing more than the meaning of the instance declaration above. However, GHC cannot infer the inverse: {-# LANGUAGE FlexibleContexts #-} foo :: C a => a -> Int foo = undefined bar1 :: C (a, b) => a -> b -> Int bar1 _ = foo This gives an error on the right-hand side of 'bar1': "Could not deduce (C b) arising from a use of ‘foo’; from the context: C (a, b)". The same happens in similar cases: {-# LANGUAGE GADTs #-} bar2 :: (C p, p ~ (a, b)) => a -> b -> Int bar2 _ = foo data Thing a where Tup :: a -> b -> Thing (a, b) bar3 :: C a => Thing a -> Int bar3 (Tup x y) = foo y Both these usages of 'foo' yield the same error. My use-case is 'bar3', where I would like GHC to determine that the call to 'foo' is valid. (I don't actually care directly about bar1 and bar2.) Is there a way to make 'bar3' compile? Note that: - In my actual use case, 'C' is of course not empty. - In my actual use case, my type class instances _are_ in fact injective, even though I do enable FlexibleInstances to be able to write e.g. 'instance C (T a Int)'. - Above, the dictionary for 'C (a, b)' includes a dictionary for 'C b', doesn't it? So if inference can resolve 'C b', then the compilation to Core can find the right dictionary, I think? (Not sure about this part.) Thanks a lot for your help. Cheers, Tom

4 5

Maybe won't let me count
by Galaxy Being 30 Mar '21

30 Mar '21

I've got this import Data.Maybe data MyList a = Empty | Cons a (MyList a) deriving (Eq,Ord,Show) data BaconOrIndex = Bacon | Indx Int deriving (Eq,Ord,Show) whereIsBM Empty = Nothing whereIsBM (Cons idx lx) = if (idx == Bacon) then Just 1 else (whereIsBM lx) which I would like to tell me where the Bacon is (index), not just if there's Bacon, which is what it does now. That is, I need this to happen > whereIsBM (Cons (Indx 5) (Cons Bacon (Cons (Indx 2) (Cons (Indx 8) Empty)))) Just 2 So I need to traverse a BaconOrIndex list and count how deep I went to find the Bacon variable. I get the above code to evaluate error-free, but obviously I'm only returning a Just 1 when it sees Bacon. What I need is to have the last part be . . . else (1 + whereIsBM lx) work; but it keeps giving the error Non type-variable argument in the constraint: Num (Maybe a) (Use FlexibleContexts to permit this) • When checking the inferred type whereIsBM :: forall a. (Num a, Num (Maybe a)) => MyList BaconOrIndex -> Maybe a I haven't a clue what this means. Eventually, I'll wrap this in something that handles the Nothing and does fromJust on the alternative. This whole effort is because if I didn't use the Maybe strategy, and said whereIsBM Empty = 0 ... it would never give back 0 if it didn't find Bacon, rather, it would simply return the whole countdown to Empty. What can I do to make Maybe work here? LB

7 12

Why Haskell?
by Clinton Mead 29 Mar '21

29 Mar '21

I’m looking for recommendations of videos/articles to show to a software development manager about why one should use Haskell, focused more from a benefits to business perspective. Naturally this may involve some code, this manager isn’t completely clueless when it comes to programming languages, but basically something that explains why I’m raving about this “Haskell” thing all the time and why it’s a good idea. Thanks, Clinton

12 16

Arrays in base... (was: ... indexing lists)
by Viktor Dukhovni 29 Mar '21

29 Mar '21

On Mon, Mar 29, 2021 at 10:58:49AM +0200, Henning Thielemann wrote: > On Mon, 29 Mar 2021, Viktor Dukhovni wrote: > > > Thus I applaud Michael Snoyman's quest to address the absense of a basic > > array type in the `base` library. Perhaps more users would stop abusing > > lists (memoisable iterators) as an indexed store. > > Data.Array actually _was_ part of base-3. > > However, I think we should split 'base' in more smaller parts rather than > making it bigger. FWIW, I don't think that splitting base into multiple libraries would achieves much, it would likely raise the cost of coordinating versioning. I do however agree that perhaps separating base from GHC could be a good idea, if GHC could ship a smaller foundational library with primops, ... and `base` evolved somewhat independently. However that too has potential drawbacks, because packages would be more likely to have non-overlapping version bounds on a separately evolving base... Probably manageable, but something to keep in mind. -- Viktor.

3 2

Munich Virtual Haskell Meeting, 2021-03-31 @ 19:30
by Leah Neukirchen 29 Mar '21

29 Mar '21

Dear all, This week, our monthly Munich Haskell Meeting will take place again on Wednesday, March 31 on Google Meet at 19:30 CEST. **Due to meetup limitations in Bavaria, this meeting will take place online!** For details see here: https://muenchen.haskell.bayern/dates.html A Google Meet link to join the room is provided on the page. Everybody is welcome, especially the Haskellers from Bavaria that do not usually come to our Munich meetings due to travel distance! cu, -- Leah Neukirchen <leah(a)vuxu.org> https://leahneukirchen.org/

1 0

Why does my module take so long to compile?
by Troels Henriksen 28 Mar '21

28 Mar '21

I have a program with about 220 modules. One of these modules takes _much_ longer to compile than the others (several minutes longer). I don't understand why. It compiled much faster with GHC 8.8.3, but got orders of magnitude slower when I changed to GHC 8.10.2. I don't understand why, since I don't think there is nothing special about the module - e.g. no type-level programming. Is there any good way to "profile" the stack or cabal compilation process to at least get an intuition for what takes so long? Note that the module is in the middle of the dependency tree of my program, so it is not viable to separate it out and compile it manually with GHC. It's slow even when I pass '--fast' to stack which should disable the optimiser, so I guess the type checker may be spending a lot of time on handling the admittedly large amount of typeclass constraints I have on some of my definitions. I'm mostly looking for techniques and tools I can also use next time this problem occurs, not the specific problem here, but if anyone's curious, the module in question is this one: https://github.com/diku-dk/futhark/blob/master/src/Futhark/Pass/ExtractKern… -- \ Troels /\ Henriksen

6 13

Some questions about Fudgets library
by Antonio 28 Mar '21

28 Mar '21

I wonder why there is no Fudgets package in Hackage. I found this, but the fudgets link is broken: http://hackage.haskell.org/user/ThomasHallgren Nevertheless, there is a cabalized package in the Fudgets homepage, so it's strange it's not in Hackage. Also, is there an arrowized version of Fudgets? If not, why? Is there some fundamental reason that makes it impossible to port it to the arrows framework or simply nobody cared to port it? (Also, the license seems to not allow modifications.) I'm trying to write a bittorrent client in Haskell. I decided to use arrows for it and took a look at Fudgets and Yampa. I haven't decided yet which one to use. Fudgets seems more suitable and I like it more, but the fact that it doesn't use the arrow notation and classes is a bit annoying. I read that Fruit is more or less a mix of Fudgets and Yampa that uses arrows. Sadly, it's unmaintained, the web doesn't exist and it's not in Hackage. Is there any other Fudgets-like option? Greetings.

4 5