- Haskell-Cafe - Haskell.org

Call for Papers: Workshop in OCL and Textual Modeling (OCL 2018)
by Achim D. Brucker 10 May '18

10 May '18

(Apologies for duplicates) CALL FOR PAPERS 18th International Workshop on OCL and Textual Modeling Co-located with MODELS 2018: ACM/IEEE 21th International Conference on Model Driven Engineering Languages and System, October 14 (tbc), 2018, Copenhagen, Denmark http://oclworkshop.github.io Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but they have weaknesses: for example, detailed visual representations bear the risk of becoming overcrowded faster than textual models and some of the visual features lack the level of precision required to create complete and unambiguous specifications. These weaknesses of graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual modeling languages have their roots in formal language paradigms like logic, programming and databases. The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. ## Topics of interest Topics of interest include (but are not limited to): - Mappings between textual modeling languages and other languages/formalisms - Mathematical models and/or formal semantics for textual modeling languages - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for: - validation, verification, and testing, - model transformation and code generation, - meta-modeling and DSLs, and - query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Model-driven security using textual modeling languages - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports: - usage of textual modeling languages and tools in complex domains, - usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks We particularly encourage submissions describing applications and case studies of textual modeling as well as test suites and benchmark collections for evaluating textual modeling tools. ## Venue This workshop will be organized as a part of MODELS 2018 Conference in Copenhagen, Denmark. Similar to its predecessors, the workshop addresses both people from academia and industry. The aim is to provide a forum for addressing integration of OCL and other textual modeling languages, as well as tools for textual modeling, and for disseminating good practice and discussing the new requirements for textual modeling. ## Workshop Format The workshop will include short (about 15 min) presentations, parallel sessions of working groups, and sum-up discussions. ## Submissions Two types of papers will be considered: * Short contributions (between 5 and 7 pages) describing new ideas, innovative tools or position papers. * Full papers (between 10 and 14 pages). in LNCS format. Submissions should be uploaded to [EasyChair](https://easychair.org/conferences/?conf=ocl2018). The program committee will review the submissions (minimum 2 reviews per paper, usually 3 reviews) and select papers according to their relevance and interest for discussions that will take place at the workshop. Accepted papers will be published online, as part of the MODELS workshop proceedings, in [CEUR](http://www.ceur-ws.org). ## Important Dates - Submission of papers: July 17, 2018 - Notification: August 17, 2018 - Workshop date: October 14, 2018 (tbc) -- Dr. Achim D. Brucker | Software Assurance & Security | University of Sheffield https://www.brucker.ch | https://logicalhacking.com/blog @adbrucker | @logicalhacking

1 0

Taking over `data-default-*`
by Marco Zocca 10 May '18

10 May '18

Dear all, I've been increasingly relying on data-default-class, but sadly it doesn't look like it's currently maintained; there are some tickets on the github issue tracker that would need some attention. I have tried contacting the authro/current maintainer Lukas Mai (CC'd) by email but have not received an answer so far (I hope he's doing well, btw). This is my first public request for taking over the `data-default` family of packages: data-default-class data-default-instances-base data-default-instances-containers data-default-instances-dlist data-default-instances-old-locale data-default Kind regards, Marco Zocca (http://hackage.haskell.org/user/ocramz)

11 17

Re: [Haskell-cafe] How to expose if a constraint is satisfiable
by Anthony Clayden 09 May '18

09 May '18

Thanks David, Oliver, I'll leave it so Clinton whether that helps his use case. I see the write-ups for both the Constraint Unions package and ifCxt mentioned on the reddit thread talk about needing large amounts of boilerplate. That is, an instance for each class and type that effectively tells the class has an instance for that type. So that's the same as the AdvancedOverlap I linked to -- from Oleg + SPJ. IIUC, what Clinton's asking is: since there are already instances for `Show Int`, `Ord Float`, etc (declared in the Prelude), why can't ghc 'just know' that and expose it to type-level logic that can say: if there's `Show a` do this, otherwise do that? AntC > On *Tue May 8 22:29:20 UTC 2018*, David Feuer wrote: > Maybe look at https://www.reddit.com/r/haskell/comments/6k86je/constraint_unions_bringing… > (relating to the repository Oliver links to) and note also Edward Kmett's response. Eurrm. Could somebody explain that response using familiar language. I think the `:-` operator might be referring to Edward's & David's 'constraints' package on github, for which I've asked if there's human-facing documentation. Also asked if it'll be superseded by the 'Qualified Constraints' new development. >> On Tue, May 8, 2018 at 9:52 AM, Oliver Charles <ollie at ocharles.org.uk <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>> wrote: >>* I've only skimmed the thread, so sorry if this is a red herring, but could *>>* this be helpful?*

1 0

Scoped Type Variables discussion forum [was: open up the issues tracker on ghc-proposals]
by Anthony Clayden 09 May '18

09 May '18

This thread is a discussion about discussions, not the discussion itself ;-) I'm cc'ing to the cafe; but I'd prefer replies to come to glasgow-haskell-users. >> I can volunteer to at least scrape together all the objections to ScopedTypeVariables as currently. It's not yet a proposal, so not on github. Start a wiki page? A cafe thread? (It'll get lost.) A ghc-users thread? (It'll get ignored.) > ... don’t care what forums or list or whatever. As long as it’s collated and such > It could even be on the prime issue tracker for prime proposals. Just that it’s written down :) Thanks Carter, but I understand Haskell Prime to be to assess mature/stable proposals (preferably already delivered as extensions). This discussion is at first going to be more exploratory: * likes and dislikes about ScopedTypeVariables as currently. * confusions experienced by users (especially newbies) -- although absolute newbies wouldn't be using it(?), so intermediates? * feedback from those teaching Haskell. * wild ideas for possible alternative designs. * possible improvements to the current design. * I think we're all agreed that ScopedTypeVariables should have been in Haskell from the beginning; but it wasn't, so now we have to worry about backwards compatibility for programs that worked around the omission. Or do we? What code would break? How much pain would that cause? * anything else? > We have lots of forums, but your point is that certain sorts of discussions never get going with the right audience – you especially point to “confused beginners”. > ... It’s quite a challenge because beginners tend not to be vocal, and yet they are a crucial set of Haskell users. Every Haskell user started as a beginner. On this particular topic, there's plenty of confused people asking questions on StackOverflow. (Heads up: they're especially asking why they need explicit `forall` whereas in reguar Haskell that 'intermediates' see, the forall is implicit.) Can other people point me to questions/likes/dislikes on other forums? Reddit for example. If you've read this far, you now understand what we're trying to cover. It's going to be random/varied thoughts at first, then perhaps coalescing to an approach or two. At that point a formal proposal on github proper; and the random stuff might be interesting background but will essentially get archived/thrown away. I do agree with David's suggestion that github Issue tracker looks like a suitable solution. We can write formatted code and text. We can add links and references. What do others think? Joachim has opened up Issues tracker, as a try-out. If using it doesn't work out, that's fine and in keeping with my "thrown away" above. Also where else should I post links to this message to 'advertise' the thread? I don't reddit much, so if that's suitable, please someone post there. Thank you AntC

2 1

How to expose if a constraint is satisfiable
by Clinton Mead 08 May '18

08 May '18

It's occurred to me that one could write a class C t which is satisfied whenever (A t) or (B t) is satisfied like so: --- data Satisfied type family IsSatisfiable :: Constraint -> Type class A t class B t class C' t ta tb instance A t => C' t Satisfied tb where ... instance B t => C' t ta Satisfied where ... instance (A t, B t) => C' t Satisfied Satisfied where ... class C' t ( IsSatisfiable (A t)) ( IsSatisfiable (B t)) => C t --- We may need overlapping instances (with all the caveats that come with it) but it should be fine otherwise. "IsSatisfiable" here is defined as follows: IsSatisfiable c = Satisfied -- (if c is satisfiable) IsSatisfiable c = IsSatisfiable c -- (if c is not satisfiable) That's all that's needed. And it seems to be a reasonable type function. I note classes are open, so perhaps it could be dangerous to state that a constraint is not satisfiable (because it might be in another part of a program) but simply not reducing if we can't satisfy the constraint locally should be fine I think. At worst we'll get a compile error, but we shouldn't get inconsistent types. Is there anyway to implement this type function, or alternatively an approach which allows this type of "inherit from two classes" idea?

5 9

Re: [Haskell-cafe] How to expose if a constraint is satisfiable
by Anthony Clayden 08 May '18

08 May '18

> It's occurred to me that one could write a class C t which is satisfied > whenever (A t) or (B t) is satisfied like so: Hi Clinton, this sounds like you might want "Choosing a type-class instance based on the context" https://wiki.haskell.org/GHC/AdvancedOverlap > --- > > data Satisfied > > type family IsSatisfiable :: Constraint -> Type That type family is doing the same job as auxiliary class `ShowPred` on that wiki page. Rather than all the machinery you give for the disjunction, you could use another type family: type family EitherSatisfied :: Type -> Type -> Type instance EitherSatisfied Satisfied tb = Satisfied instance EitherSatisfied ta Satisfied = Satisfied Those two instances do overlap (as you expected); and they exhibit confluence, aka coincident overlap (they produce the same result); so that's fine. But you haven't given any instances for `IsSatisfiable`. How do you expect to get from the Constraint to the `Satisfied` type? You say > IsSatisfiable c = Satisfied -- (if c is satisfiable) What are you going to put for `c`? If you follow that wiki page, you'll need to in effect repeat every instance decl for classes `A, B`: instance A Int where ... type instance IsSatisfiable (A Int) = Satisfied (The wiki page was written before there were type families, so type class `ShowPred` has a Functional Dependency giving a type-level Boolean result.) Your `C t` class becomes class EitherSatisfied ( IsSatisfiable (A t)) ( IsSatisfiable (B t)) ~ Satisfied => C t where ... ---- Nowadays there's a better way: make Associated Types for the two classes, give them a default instance: class A t where type APred t type instance APred t = Satisfied ... class B t where type BPred t type instance BPred t = Satisfied ... Now every instance defined for `A, B` in effect automatically gives you `APred, BPred` instances. Then class EitherSatisifed (APred t) (BPred t) ~ Satisfied => C t where ... AntC

4 6

help with emacs intero
by Dennis Raddle 06 May '18

06 May '18

I started having trouble with Emacs intero mode a week ago. I've tried to get help on the Intero issues list as well as Stack Overflow to no avail. I'm wondering if anyone here knows enough about Intero or Emacs to at least point me to the next debugging step. At this point I don't enough to know what to try or look for. Basically flycheck stopped working, and every time I type a few characters I'm getting "Error while checking syntax automatically: (wrong-type-argument number-or-marker-p "Abort trap: 6") Any clue what this is referring to, or why it would suddenly start last week, when all was fine prior?

1 1

Announce: Haskell Platform 8.4.2
by Gershom B 05 May '18

05 May '18

On behalf of the Haskell Platform team, I'm happy to announce the release of Haskell Platform 8.4.2 Now available at https://www.haskell.org/platform/ This includes GHC 8.4.2, cabal-install 2.2.0.0, and stack 1.7.1, all with substantial improvements since the last platform release. A full list of contents is available at https://www.haskell.org/platform/contents.html Thanks to all the contributors to this release, thanks to all the package and tool maintainers and authors, and a big thanks to the GHC team for all their hard work. There are (still) currently no 32 bit Windows builds available. We're looking into the issues preventing us from building an installer for that platform. The components all appear to work individually in such a case, and can be installed separately by users who so desire. A list of new GHC changes is available at: https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.1-released and https://ghc.haskell.org/trac/ghc/blog/ghc-8.4.2-released A list of cabal changes is available at: https://hackage.haskell.org/package/cabal-install-2.2.0.0/changelog The cabal documentation page is at: https://www.haskell.org/cabal/users-guide/ A list of stack changes is at: https://docs.haskellstack.org/en/stable/ChangeLog/#v171 The stack documentation page is at: https://docs.haskellstack.org/en/stable/README/ Happy Haskell Hacking all, Gershom

1 1

Picking up the CI buildnumber during build
by Magnus Therning 04 May '18

04 May '18

I'm looking for a way to pick up the CI buildnumber from the environment (e.g. $TRAVIS_BUILD_NUMBER) and use it as part of of the output of `my-tool --version`. I don't really know where to start looking, so I'm hoping someone on the list has already done something similar and can point me to a working example :) /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus I am always doing that which I cannot do, in order that I may learn how to do it. — Pablo Picasso

4 5

Strange error with GADT DataKinds -- needs TypeInType!?
by Tom Ellis 04 May '18

04 May '18

Can anyone explain why the type instance for K is fine but the one for I needs TypeInType? (It does indeed work when I turn on TypeInType.) {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} data T a b where K :: b -> T a b I :: T a a type family F (a :: T ka kb) -- Data constructor ‘I’ cannot be used here -- (Perhaps you intended to use TypeInType) -- type instance F 'I = () type instance F ('K b) = ()

2 3