- Haskell-Cafe - Haskell.org

More death to partial functions: Should -fwarn-incomplete-uni-patterns be enabled with -Wall?
by Niklas Hambüchen 08 Nov '15

08 Nov '15

Hello everyone, to my dismay, a -Wall compiled program I deployed today crashed with Exception: Non-exhaustive patterns in lambda and I learned from http://dev.stephendiehl.com/hask/ that A more subtle case is when implicitly pattern matching with a single "uni-pattern" in a lambda expression. The following will fail when given a Nothing. boom = \(Just a) -> something GHC can warn about these cases with the -fwarn-incomplete-uni-patterns flag. And in fact: ghci -Wall > map (\Nothing -> "ok") [Just 'a'] ["*** Exception: <interactive>:2:6-21: Non-exhaustive patterns in lambda > :set -fwarn-incomplete-uni-patterns > map (\Nothing -> "ok") [Just 'a'] <interactive>:4:6: Warning: Pattern match(es) are non-exhaustive It really surprised me that -fwarn-incomplete-uni-patterns is not included in -Wall; I've felt really safe with my -Wall so far, especially about totality and similar things that will almost certainly lead to crashes. In an older mail from 2010 (https://mail.haskell.org/pipermail/glasgow-haskell-users/2010-September/019…) I saw Simon mention that it wasn't planned to warn about inexhaustive patterns like this. I feel like there has been a strong push towards more totality in the last years, and I would like to ask if enabling -fwarn-incomplete-uni-patterns in -Wall may be reconsidered for a coming next GHC version, or if there are still opponents to that. Niklas

9 10

Pattern matching with OverloadedLists
by Vlatko Basic 07 Nov '15

07 Nov '15

Hello Cafe, wiki for OverloadedLists says that g [x,y,z] = ... is treated as g (toList-> [x,y,z]) = Shouldn't this work? Both 'f's should be treated the same. f :: Text -> Int f (toList -> ('9':_)) = 1 -- OK f ('1':_) = 2 -- Couldn't match expected type ‘Text’ with actual type ‘[Char]’ (OverloadedStrings is also on) Am I missing something? br, vlatko

2 2

User guide for DeriveAnyClass
by Kostiantyn Rybnikov 06 Nov '15

06 Nov '15

Is there a topic for DeriveAnyClass extension in user guide? It is mentioned several times in different places, also I see link to it in from cabal haddocs [0] into its page inside "other type extensions" [1], but it leads nowhere. Thank you. [0]: https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Language-H… [1]: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/other-type-…

2 2

How to install newest ghcjs-base
by Arie Peterson 06 Nov '15

06 Nov '15

5 days ago a change [1] was made to the ghcjs-base library. How can one obtain a ghcjs that incorporates such a recent version of ghcjs-base? I installed ghcjs from git master yesterday, and installed the boot libraries using "ghcjs-boot --dev". However, I still get "Module ‘JavaScript.Web.MessageEvent’ does not export ‘getData’", so apparently my ghcjs-base lags behind somehow. What determines the version of ghcjs-base that is installed? Regards, Arie [1] <https://github.com/ghcjs/ghcjs-base/commit/e827ded07053a3281c50ee52b3e3ebd3…>

2 1

Yampa: upcoming changes; maintaining the projects we care about
by Ivan Perez 05 Nov '15

05 Nov '15

Dear all I am the current maintainer of the FRP implementation Yampa. (For context: I'm a PhD student at Nottingham, working with Henrik Nilsson.) Yampa contains legacy code that used to be useful to get things running quickly. In the interest of having minimal overhead and using existing robust solutions whenever possible, we'd like to remove some of that old auxiliary code. These changes will not affect the core of Yampa (SF definitions, arrow combinators, switches, etc.), but only auxiliary/miscelaneous stuff (vector spaces, deep strict evaluation type class, tupling/monad aux functions, etc.). We've been introducing these changes progressively over the last year, by first re-structuring the code base and marking some functions as deprecated. The time is coming for backwards incompatible changes, but I'd like to make sure that the projects you care about keep working as before. This may include (but is not limited to): * Code (which may not be on hackage, so it may be difficult for me to even know it exists). * Examples included in papers, slides, blog posts, etc. So, if you may be affected by these changes, please: - Watch the github project [1] and subscribe to yampa-users(a)cs.yale.edu, which is where details will be announced. It's a low traffic mailing list. - If you can deal with it yourself by upgrading your code, please do so. Otherwise, feel free to drop a line. - If your use case does not support easy upgrading (papers? talk videos?) please let me know. For starters, we may be able to concentrate all the potential compilation errors that your users might get in one place in the documentation. - If you are affected in a way that I'm not seeing, please let me know. All the best Ivan [1] http://github.com/ivanperez-keera/Yampa

1 0

Looking for a new maintainer: Bindings-DSL, c2hsc
by John Wiegley 05 Nov '15

05 Nov '15

Hello, The Bindings-DSL libraries, and the c2hsc tool that parses C headers into .hsc files, both on Hackage, are looking for new maintainers. People are using these libraries to get real work done, and I no longer wish to be a stumbling block due to lack of time. If you're interested, please drop me a line. Anyone with experience at C parsing would be great, but those with a desire to learn it are good too. I'd be available to help with questions indefinitely, I just lack the time to stay on top of every bug. Thank you, John Wiegley

3 2

Warnings suppression and examples
by Эдгар Жаворонков 05 Nov '15

05 Nov '15

Hello everyone! This may be a strange question, but nevertheless. I am interested in examples of warnings, thrown by GHC, that you, Haskell programmers, want to suppress. To be more precise, i am interested, what kind of warnings you would like to suppress in: 1. Functions 2. Imports 3. Typeclasses 4. Instances Thank you! P.S. I want to implement possibility of warning suppression with single pragma, that's why i am asking my question here --- С уважением, Жаворонков Эдгар Best regards, Edgar A. Zhavoronkov --- С уважением, Жаворонков Эдгар Best regards, Edgar A. Zhavoronkov

2 1

Re: [Haskell-cafe] [Haskell] ANNOUNCE: polymap 0.1.0.1
by Roman Cheplyaka 05 Nov '15

05 Nov '15

(moving from haskell@ to haskell-cafe@) Hi David, As someone who is not familiar with the concept of polygonal maps, I find this package severely underdocumented. What is a polymap? Why would I want to use one? What is storage and how should I choose it? The example clears it up a bit, but it could also use more prose. And perhaps there could be a more motivated example (showing how polymap solves an actual problem). On 09/24/2015 09:53 PM, David Farrell wrote: > I'm excited to announce the first release of a package I've been working > on over the last week called polymap, a library providing type-safe > polygonal maps whose sides are defined by a kindlist of types zipped > with a storage type for each side. I've tried to match the interface > exposed by the containers package as closely as possible. For example: > > import Data.Set (Set) > import Data.PolyMap.Nat (first, second, third) > import qualified Data.PolyMap as PM > > mEmpty :: PM.PolyMap '[ '(String, Set), '(Int, Set) ] > mEmpty = PM.empty > > mOne :: PM.SimplePolyMap '[String, Int] Set > mOne = PM.singleton ("one", length "one") > > main = do > print mEmpty -- empty PolyMap > print mOne -- PolyMap with one Relation > print mTwo -- PolyMapwith two Relations > print (PM.member first "one" mTwo) -- True > print (PM.notMember first "asdf" mTwo) -- True > --print (PM.notMember second "asdf" mTwo) -- will not typecheck > --print (PM.notMember third "asdf" mTwo) -- will not typecheck > print (PM.lookup first "two" mTwo) -- second Relation of PolyMap > where mTwo = PM.insert ("two", length "two") mOne > > This is a short usage example of most of the functions currently written > for polymap. There's still a long way to go both in terms of exposed > functions and in terms of efficiency and such, but I felt it prudent to > make a public release of my work so far as I feel it's reached a stage > where it could be beneficial to others. Note that GHC 7.10 (base >=4.8, > GHC extensions) is required. > > Git Repository: > https://github.com/shockkolate/hs-polymap > > Issue Tracker: > https://github.com/shockkolate/hs-polymap > > Hackage: > https://hackage.haskell.org/package/polymap > > The code is licensed under the Unlicense license--that is to say, the > code is released into the public domain for the benefit of others. > > I'd love to hear any feedback/suggestions/improvements/anything you want > to say about polymap over the mailing list (which may be more suited to > the haskell-cafe mailing list; I don't know) or in #haskell on Freenode > (I'm usually in there as Shockk). > > N.B. Version 0.1.0.0 of the package will not build due to the use of a > function in containers that has been submitted as a pull request but > does not exist yet/at all. > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >

4 4

record field names vs. -fwarn-unused-binds
by Evan Laforge 05 Nov '15

05 Nov '15

[ ccing haskell-cafe since while it's a ghc flag, I'll bet most compilers have an equivalent ] I really like -fwarn-unused-binds because it frequently finds bugs where I forgot to call something or use some value. If I put an export list on, it can find dead functions I forgot to delete. However, there's one case where it frequently gives false positives, and that's unused record field names. The problem is that I sometimes use record field names as documentation, but the record itself is internal and small, so I'm comfortable using positional pattern matching to open it (and in fact that can be safer, since then warn-unused-binds will make sure I used all the fields). But GHC sees these as unused functions, so it warns about them. I can work around by putting underscores on field names I haven't used yet, but it's a hassle to go edit them when I want to use them. The warning can be useful if it indicates an unused field, but since fields can also be extracted via the positional syntax it's not reliable. The other use of the warning for dead code or functions you forgot to use doesn't apply to record accessors because they're trivial and compiler generated. So, would it be reasonable to exclude record field accessors from -fwarn-unused-binds? Or is there another way to work around it? I guess GHC doesn't have a "suppress warning" pragma like Java does, but even if we did it wouldn't be much better than changing the name, and more likely to get stale.

4 4

Haskell positions in Moscow, Positive Technologies
by Kosyrev Serge 04 Nov '15

04 Nov '15

Good day! The Moscow office of Positive Technologies (http://ptsecurity.com) seeks Haskell developers with strong C background, as part of an effort to develop a next-generation (of course!) democratic security platform. Think widely available, easy-to-use, dramatically enhanced security. If this kind of thing feels motivating, please send your resume to career(a)ptsecurity.com and CC skosyrev(a)ptsecurity.com. Position: Senior Software Engineer Vague description: - bare-metal, kernel, userland development Required experience: - C programming - experience of applying GHC in FFI-heavy context - experience with kernel development (some of Linux, Windows, Darwin) - experience writing resource-efficient Haskell code - experience with parallelism - taming laziness - taming the GC (desirable) - experience with the Intel system platform (desirable) - some knowledge of GHC runtime internals (desirable) -- respectfully, Kosyrev Serge http://www.ptsecurity.com/ Habr: http://habr.ru/company/pt Twitter: @ptsecurity https://twitter.com/ptsecurity

1 0