September 2019 - Haskell-Cafe

FMBC 2019 Call for Participation - Porto (Portugal), October 11
by Bruno Bernardo 23 Sep '19

23 Sep '19

[Please accept our apologies for duplicates.] ===================================================== Call for Participation 1st Workshop on Formal Methods for Blockchains (FMBC) 2019 https://sites.google.com/view/fmbc/home Porto, Portugal, October 11 Part of the 3rd World Congress on Formal Methods http://formalmethods2019.inesctec.pt/ ===================================================== About FMBC ---------------- Blockchains are decentralized transactional ledgers that rely on cryptographic hash functions for guaranteeing the integrity of the stored data. Participants on the network reach agreement on what valid transactions are through consensus algorithms. Blockchains may also provide support for Smart Contracts. Smart Contracts are scripts of an ad-hoc programming language that are stored in the blockchain and that run on the network. They can interact with the ledger’s data and update its state. These scripts can express the logic of possibly complex contracts between users of the blockchain. Thus, Smart Contracts can facilitate the economic activity of blockchain participants. With the emergence and increasing popularity of cryptocurrencies such as Bitcoin and Ethereum, it is now of utmost importance to have strong guarantees of the behavior of blockchain so ware. These guarantees can be brought by using Formal Methods. Indeed, Blockchain software encompasses many topics of computer science where using Formal Methods techniques and tools are relevant: consensus algorithms to ensure the liveness and the security of the data on the chain, programming languages specifically designed to write smart contracts, cryptographic protocols, such as zero-knowledge proofs, used to ensure privacy, etc. This workshop is a forum to identify theoretical and practical approaches of formal methods for blockchain technology. Topics include, but are not limited to: * Design and implementation of Smar Contract languages * Formal models of blockchain applications or concepts * Formal methods for consensus protocols * Formal methods for blockchain-specific cryptographic primitives or protocols * Formal languages for Smart Contracts * Verification of Smart Contracts Invited Speaker -------------------- Ilya Sergey (Yale-NUS College / NUS School of Computing) Contributed papers -------------------------- See the workshop program at: https://sites.google.com/view/fmbc/program Registration ---------------- Registration is shared for all FM events: http://formalmethods2019.inesctec.pt/?page_id=2363 Attending ------------- See the FM webpage at: http://formalmethods2019.inesctec.pt/?page_id=140 Contact ---------- mailto:fmbc19@easychair.org

1 0

Re: [Haskell-cafe] How are we helping? Climate Strike / Earth Strike fri 20, fri 27
by Olaf Klinke 22 Sep '19

22 Sep '19

Haskeller working in the renewable energy sector here. Richard O'Keefe has good points, it is hard for the average programmer to have a real impact on climate change. Power consumption of computing equipment, though, is indeed a huge part of our electricity usage, so any progress will be very welcome in this sector. Ask your cloud computing vendor where the data center sources its power. <shameless advertising> It ought to look like this. [*] </shameless advertising> My suggestion is to help make renewables the cheapest power source in the market. It already is in some countries, and both China and India are investing massively in wind and solar power, not beause of morale, but beause it is cheap. So go ahead and develop good SCADA software, help the grid operators balance their volatile loads, use deep learning and so-called AI to make maintenance cheaper and life cycles longer. And, but this has nothing to do with programming, keep pestering your first-world governments. Even if your country's share in the global emissions is minute, showing that even industrialized countries can reduce their emissions hopefully leads to others following. But this is only going to work if saving the environment is also cheaper compared to going on as usual. Olaf [*] http://windcores.de/en/homepage/#!/who

1 0

How are we helping ? Climate Strike / Earth Strike fri 20, fri 27
by Simon Michael 22 Sep '19

22 Sep '19

Hi all, There's world-wide "strike" event, to raise awareness and stimulate climate action, happening tomorrow and also on friday 27th. Some folks will observe one, the other, both, or the whole period between. We probably don't all share the same awareness or even concern about climate change.. but this is changing rapidly. I wanted to start a discussion and figure out something we could do to support these events.. earlier. But I'm working, preparing for a trip, etc. etc. and "ran out of time". I'll send this now at least. If the site goes green or something, this is the reason. Re the sep 20 and sep 27 events: Thanks to Open Collective, for their leadership and blog post: https://blog.opencollective.com/digital-climate-strike hledger's opencollective, though we're not really using it yet, is opted in for tomorrow: https://opencollective.com/hledger Origin and recent history of this event: https://en.wikipedia.org/wiki/School_strike_for_climate#'Intergenerational'_Global_Climate_Strikes_in_September_2019 There are probably a bunch of "home" sites for this, here are two: https://www.fridaysforfuture.org https://www.earth-strike.com Going forward: I think "How are we helping?" is a standard question every individual, project, institution should be answering. For the hledger project, I've had a few ideas for a long time but haven't managed to manifest them yet. Looking into the near future, some days it feels like working on hledger is a waste of time. Probably many of you can relate. If you are working on anything in this direction I'd love to hear more. Best! -Simon PS I ran out of time even more for crafting a mail to haskell-cafe; cc'ing this anyway.

2 1

Changing a function definition causes an error at link-time
by Vanessa McHale 21 Sep '19

21 Sep '19

Hi all, I have a function ft :: CMode -> FileType ft i = toEnum (fromIntegral i) which is used to marshal a function defined with c2hs, viz. {# fun archive_entry_filetype as ^ { `ArchiveEntryPtr' } -> `FileType' ft #} This all works fine under GHC 8.8.1-GHC-8.2.2. When I try to compile the test suite with GHC 8.0.2 I get Linking /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.0.2/libarchive-2.0.0.0/t/libarchive-test/build/libarchive-test/libarchive-test ... /usr/bin/ld: /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.0.2/libarchive-2.0.0.0/build/libHSlibarchive-2.0.0.0-inplace.a(ArchiveEntry.o): in function `rg6i_info': (.text+0x9cd6): undefined reference to `archive_entry_acl_next_w' /usr/bin/ld: /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.0.2/libarchive-2.0.0.0/build/libHSlibarchive-2.0.0.0-inplace.a(ArchiveEntry.o): in function `cjVN_info': (.text+0x128c6): undefined reference to `archive_entry_acl_next_w' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) When I define the marshaling function with ft :: CMode -> FileType ft 0 = error "here" ft i = toEnum (fromIntegral i) I can no longer compile the test suite; it fails with a linker error, even with GHC 8.8.1-GHC-8.2.2. I get Linking /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.8.1/libarchive-2.0.0.0/t/libarchive-test/build/libarchive-test/libarchive-test ... /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.8.1/libarchive-2.0.0.0/build/libHSlibarchive-2.0.0.0-inplace.a(ArchiveEntry.o)(.text+0x9d86): error: undefined reference to 'archive_entry_acl_next_w' /home/vanessa/programming/haskell/done/libarchive/dist-newstyle/build/x86_64-linux/ghc-8.8.1/libarchive-2.0.0.0/build/libHSlibarchive-2.0.0.0-inplace.a(ArchiveEntry.o):function libarchivezm2zi0zi0zi0zminplace_CodecziArchiveziForeignziArchiveEntry_zdwarchiveEntryAclNextW_info: error: undefined reference to 'archive_entry_acl_next_w' collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) You can have a look at some of some of the code in this branch here: https://github.com/vmchale/libarchive/blob/ghc-potential-bug/src/Codec/Arch… and here: https://github.com/vmchale/libarchive/blob/ghc-potential-bug/src/Codec/Arch… Cheers, Vanessa McHale

1 0

Re: [Haskell-cafe] [Haskell] ANNOUNCE: mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations
by Henning Thielemann 21 Sep '19

21 Sep '19

On Sat, 21 Sep 2019, olexandr543--- via Haskell wrote: > My library that can help to optimize using 'case ... of ...' construction if there are multiple (more than at > least 5) variants. > mm2: The library that can be used for optimization of multiple (Ord a) => a -> b transformations Isn't this a problem you would solve using Data.Map?

2 2

Re: [Haskell-cafe] Explicitly calling syntactic equality on datatypes
by Olaf Klinke 18 Sep '19

18 Sep '19

IMHO Tom's suggestion is the way to go, because: (1) The normalized values form a sub-set of the general ones. If you have just one data type for both, then you'll have no static guarantee of normalization, and this will lead to mistakes once you fail to track the normalize calls. (2) Since the normalized values are a sub-set, coercing a normalized value back into the super-type is cheap. (3) Two distinct types guarantee that you won't do the same work twice. Your proposal of (==) `on` normalize will re-calculate the normalization every time you call (==), if no memoization happens. (4) The existing machinery of the compiler suffices to do what you want. If you consider the two forms semantically equal then maybe the non-normalized form should be represented as a thunk. Isn't that what the ShowS type is about? Just my 2 cents. Olaf

2 1

Explicitly calling syntactic equality on datatypes
by Juan Casanova 18 Sep '19

18 Sep '19

Hello, Pretty simple question here really. I think I've searched for it several times in the past and ended up surprised I did not find an answer. Simple example: sum expressions. One way to define this, one that is comfortable to construct new sums, would be: data Sum = Value Int | Sum Sum Sum Another one, one that is comfortable to check equality with (and other similar things that rely on some notion of normal form), would be (essentially non-empty lists of ints): data Sum = Value Int | Sum Int Sum Now, in many cases you really want to go with the first one for several reasons. You just do not care about normalization in most cases, or maybe you do something more abstract and complicated on top of it that delays the possibility or the sensibility of normalization until something else happens later. So say, that I have the first definition. But then, I want to define equality semantically. An obvious way to go is to produce a function that normalizes Sums (from the first definition) to guarantee that the first sub-sum is always going to be a value, and then check that these two are "equal". And this is where my question comes in, because, of course, the following is infinite recursion: instance Eq Sum where a == b = (normalize a) == (normalize b) What I'd like is to be able to override the default implementation of Eq, but be able to *explicitly* call syntactic equality in calculating it, so that I can do: instance Eq Sum where a == b = (syntacticEq (normalize a) (normalize b)) So, I can see how this is not as straightforward as a function. You cannot correctly produce a polymorphic function syntacticEq :: a -> a -> Bool that works on the SYNTAX of a because it is hidden inside the polymorphic function. What (deriving Eq) does (as I understand it) is to produce an instance at compilation time by looking at how the specific type is presented. But that same compilation time producing could be done to produce it as a function instead of as an implementation of Eq, so that syntacticEq would not be an actual function, but some sort of "macro" that, on compile time, creates the default implementation of equality, but instead of defining it as (==) it defines it as a new function that is only used there. Of course, I can just implement syntactic equality myself explicitly, but when I have to do this for 3, 4, 7 types, some of which have many cases, and a lot of these are polymorphic, so that I have to put all the (Eq arg1, Eq arg2, Eq arg3, ...) => constraints before all of them, it gets old quick. So, is there something like this? Am I saying something really dumb? Of course, I am thinking about equality here, but the same could be said for any standard derivation of classes, like Functor, Show, etc. ALL of them sound like I've wanted to do them at some point in the past. Thanks, Juan. -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

4 8

Practical Aspects of Declarative Languages PADL2020: 2nd CFP
by Ekaterina Komendantskaya 18 Sep '19

18 Sep '19

22nd International Symposium on Practical Aspects of Declarative Languages (PADL 2020) <https://popl20.sigplan.org/home/PADL-2020#22nd-international-symposium-on-p…> <https://popl20.sigplan.org/home/PADL-2020#httpspopl20sigplanorghomepadl-2020> https://popl20.sigplan.org/home/PADL-2020,20-21 January 2020, New Orleans, Louisiana, United States <https://popl20.sigplan.org/home/PADL-2020#20-21-january-2020-new-orleans-lo…>Co-located with ACM POPL 2020 ( <https://popl20.sigplan.org/home/PADL-2020#co-located-with-acm-popl-2020-htt…> https://popl20.sigplan.org/) ------------------------------ *Declarative languages* is an umbrella term that include functional, logic, and constraint programming languages. These languages have been successfully applied to many different real-world situations, ranging from database management to active networks to software engineering to decision support systems. New developments in theory and implementation have opened up new application areas. At the same time, applications of declarative languages to challenging problems raise intriguing research questions, such as scalable design and implementation, language extensions for application deployment, and programming environments. PADL is a well-established forum for researchers and practitioners to present original work emphasizing novel applications and implementation techniques for all forms of declarative programming, including functional and logic programming, database and constraint programming, and theorem proving. Topics of interest include, but are not limited to: - Innovative applications of declarative languages - Declarative domain-specific languages and applications - Practical applications of theoretical results - New language developments and their impact on applications - Declarative languages for software engineering - Evaluation of implementation techniques on practical applications - Practical experiences and industrial applications - Novel uses of declarative languages in the classroom - Practical languages and extensions such as probabilistic and reactive languages *PADL 2020* especially welcomes new ideas and approaches pertaining to applications, design and implementation of declarative languages going beyond the scope of the past PADL symposia, for example, advanced database languages and contract languages, as well as verification and theorem proving methods that rely on declarative languages. Important Dates and Submission Guidelines: <https://popl20.sigplan.org/home/PADL-2020#important-dates-and-submission-gu…> - Abstracts due: 11 October 2019 - Papers due: 18 October 2019 - Notification to authors: 18 November 2019 - Camera-ready: 29 November 2020 - Symposium dates: 20 - 21 January 2020 Submission instructions can be found at: https://popl20.sigplan.org/home/PADL-2020#Call-for-Papers Looking forward to receiving your submission, PADL19 PC members: https://popl20.sigplan.org/home/PADL-2020#About

1 0

Re: [Haskell-cafe] Attach a finalizer to a FunPtr
by Roman Cheplyaka 17 Sep '19

17 Sep '19

On 17/09/2019 10.50, Shao Cheng wrote: > Hi Roman, > > mkWeak# 's "key" and "value" arguments must both be lifted types, see https://gitlab.haskell.org/ghc/ghc/blob/master/rts/PrimOps.cmm#L699. Your code directly passes the raw Addr# which is not a managed pointer, thus the segfault. Ah, that makes sense — thanks Cheng (and Matthew). I modeled my code after mkWeakIORef, and I assumed that MutVar# and Addr# were in the same category. > I recommend using ForeignPtr in this case. You can add finalizers to ForeignPtr properly, and coerce from ForeignPtr to FunPtr when using it, since they're both containing the Addr# under the hood. I considered doing that, but that'd require quite a bit of code to be constantly converting between ForeignPtr and FunPtr and also converting IO () finalizers to FunPtr (...) finalizers. System.Mem.Weak looks like a better fit because it uses IO () finalizers. I think I'll try attaching a finalizer to ForeignPtr itself and be careful to retain a pointer to ForeignPtr (perhaps with the help of a StablePtr) while it's in use. Or, if that doesn't work, I might implement a reference counter instead. Roman

3 2

[ANN] Call for Contributions: BOB 2020 [Feb 28, Deadline Nov 8]
by Stefan Wehr 17 Sep '19

17 Sep '19

BOB Conference 2020 "What happens when we use what's best for a change?" http://bobkonf.de/2020/cfc.html Berlin, February 28 Call for Contributions Deadline: November 8, 2019 You are actively engaged in advanced software engineering methods, implement ambitious architectures and are open to cutting-edge innovation? Attend this conference, meet people that share your goals, and get to know the best software tools and technologies available today. We strive to offer a day full of new experiences and impressions that you can use to immediately improve your daily life as a software developer. If you share our vision and want to contribute, submit a proposal for a talk or tutorial! NOTE: The conference fee will be waived for presenters. Travel expenses will not be covered (for exceptions see "Speaker Grants"). Speaker Grants BOB has Speaker Grants available to support speakers from groups under-represented in technology. We specifically seek women speakers and speakers who are not be able to attend the conference for financial reasons. Shepherding ----------- The program committee offers shepherding to all speakers. Shepherding provides speakers assistance with preparing their sessions, as well as a review of the talk slides. Topics ------ We are looking for talks about best-of-breed software technology, e.g.: - functional programming - persistent data structures and database - event-based modelling and architectures - types - formal methods for correctness and robustness - abstractions for concurrency and parallelism - metaprogramming - probabilistic programming - math and programming - controlled side effects - beyond REST and SOAP - effective abstractions for data analytics - ... everything really that isn’t mainstream, but you think should be. Presenters should provide the audience with information that is practically useful for software developers. We're especially interested in experience reports. Other topics are also relevant, e.g.: - introductory talks on technical background - overviews of a given field - demos and how-tos Requirements ------------- We accept proposals for presentations of 45 minutes (40 minutes talk + 5 minutes questions), as well as 90 minute tutorials for beginners. The language of presentation should be either English or German. Your proposal should include (in your presentation language of choice): - An abstract of max. 1500 characters. - A short bio/cv - Contact information (including at least email address) - A list of 3-5 concrete ideas of how your work can be applied in a developer's daily life - additional material (websites, blogs, slides, videos of past presentations, …) Submit here: https://bobcfc.active-group.de/en/bob2020/cfp Organisation ------------ - Direct questions to contact at bobkonf dot de - Proposal deadline: November 8, 2019 - Notification: November 22, 2019 - Program: December 6, 2019 Program Committee ----------------- (more information here: https://bobkonf.de/2020/programmkomitee.html) - Matthias Fischmann, Wire - Matthias Neubauer, SICK AG - Nicole Rauch, Softwareentwicklung und Entwicklungscoaching - Michael Sperber, Active Group - Stefan Wehr, factis research Scientific Advisory Board - Annette Bieniusa, TU Kaiserslautern - Torsten Grust, Uni Tübingen - Peter Thiemann, Uni Freiburg

1 0