- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Monad of no `return` Proposal (MRP): Moving `return` out of `Monad`
by Simon Thompson 22 Oct '15

22 Oct '15

Hello all. I write this to be a little provocative, but … It’s really interesting to have this discussion, which pulls in all sorts of well-made points about orthogonality, teaching, the evolution of the language and so on, but it simply goes to show that the process of evolving Haskell is profoundly broken. Other languages do evolve, but in a managed and reflective way. Simply throwing in changes that would have a profound impact on systems that are commercially and potentially safety critical in an à la carte, offhand, way seems like a breakdown of the collective responsibility of the Haskell community to its users and, indirectly, to its future. If we make claims - I believe rightly - that Haskell is hitting the mainstream, then we need to think about all changes in terms of the costs and benefits of each of them in the widest possible sense. There’s an old fashioned maxim that sums this up in a pithy way: “if it ain’t broke, don’t fix it”. Simon Thompson > On 5 Oct 2015, at 10:47, Michał J Gajda <mjgajda(a)gmail.com> wrote: > > Hi, > > As a person who used Haskell in all three capacities (for scientific research, for commercial purpose, and to introduce others to benefits of pure and strongly typed programming), I must voice an supportive voice for this change: > 1. Orthogonal type classes are easier to explain. > 2. Gradual improvements helps us to generalize further, and this in turn makes education easier. > 3. Gradual change that break only a little help to prevent either stagnation (FORTRAN) and big breakage (py3k). That keeps us excited. > > That would also call to split TCs into their orthogonal elements: return, ap, bind having the basic TC on their own. > > So: > +1, but only if it is possible to have compatibilty mode. I believe that rebindable syntax should allow us to otherwise make our own prelude, if we want such a split. Then we could test it well before it is used by the base library. > > That said, I would appreciate Haskell2010 option just like Haskell98 wad, so that we can compile old programs without changes. Even by using some Compat version of standard library. Would that satisfy need for stability? > > PS And since all experts were beginners some time ago, I beg that we do not call them "peripheral". > -- > Best regards > Michał > > On Monday, 5 October 2015, Malcolm Wallace <malcolm.wallace(a)me.com <mailto:malcolm.wallace@me.com>> wrote: > On other social media forums, I am seeing educators who use Haskell as a vehicle for their main work, but would not consider themselves Haskell researchers, and certainly do not have the time to follow Haskell mailing lists, who are beginning to say that these kinds of annoying breakages to the language, affecting their research and teaching materials, are beginning to disincline them to continue using Haskell. They are feeling like they would be > (...) > > > -- > Pozdrawiam > Michał > _______________________________________________ > Haskell-prime mailing list > Haskell-prime(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson(a)kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt

53 97

[ANN] codex 0.4
by Alois Cochard 22 Oct '15

22 Oct '15

Hello Café, I have released a new version of `codex`[1] (a ctags file generator for cabal/stack projects and their dependencies). This release include some fixes but more important it *include support for `stack`* projects. As `stack` is multi-platform and so is `codex`, it should work seamlessly on any OS but I have only done testing on unix. Cheers [1] https://github.com/ <https://github.com/aloiscochard/codex>aloiscochard/ codex <https://github.com/aloiscochard/codex> -- *Λ\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard

1 0

Hac Phi: Haskell Exchange in Philadelphia, Nov 6-8
by Richard Eisenberg 22 Oct '15

22 Oct '15

Hi café, Hac Phi, a yearly weekend of Haskell in Philadelphia, will take place Nov. 6-8, hosted at the University of Pennsylvania. Hac Phi is a gathering of hackers and Haskell enthusiasts. Come bring a project you're working on or offer to help someone else on a project of theirs. Come give a talk if you've got something to share. Come to learn something new. Though the event has the same structure as in previous years, it has been renamed from a Haskell Hackathon to a Haskell Exchange (not to be confused with The Haskell eXchange, a different event.) The organizers felt that the title "hackathon" has been given to events too unlike Hac Phi, events where participants code under pressure or over long times in competition. Those are fun affairs, indeed... but they're not like Hac Phi. So, we now say that Hac Phi is a yearly Haskell Exchange, where academics, professionals, and hobbyists can all meet, mingle, hack on each others' projects, and generally have a good time. All the details are on the wiki page: https://wiki.haskell.org/Hac_Phi I hope to see you there! Richard

1 1

Callstack Implicit Param for Unsafe Prelude Functions
by aditya siram 21 Oct '15

21 Oct '15

Since the latest base now has a way of getting generating stack traces via the `CallStack` implicit param, is there any reason not to add that param to the error messages of unsafe functions in the Prelude ( and even commonly used modules like Data.Maybe/Data.List)? The type signature will change but for most users it should be a drop-in replacement and a great aid to debugging. Thanks! -deech

3 2

Job opportunities at Kaspersky Lab (Moscow)
by Dmitry Kulagin 20 Oct '15

20 Oct '15

Here at Kaspersky Lab, we are developing a secure platform&framework. We have two job opportunities right now. Both opportunities assume good command of Haskell, since we use Haskell extensively. These are full time positions, available at our Moscow (Russia) office. If you are interested, please apply on the corporate site or send your CV to me directly at dmitry.kulagin(a)kaspersky.com Descriptions: Software Engineer: Responsibilities: * Development of core of the security system * Tools development (such as compilers/DSL) Skills/experience: * Strong experience developing with Haskell * C/C++ development experience * Good knowledge of basic algorithms and data structures * Compilers/DSLs development experience (desirable) * System programming experience (desirable) * Understanding of OS internals (desirable) * Experience in development of embedded and/or real-time applications (desirable) URL: * http://www.kaspersky.ru/job?vac=283264 Researcher (formal methods/computer security): Responsibilities: * Development of approaches to express and verify security and safety properties of systems Skills/experience: * Masters degree in CS or equivalent. PhD in CS (or related field) is desirable * Strong interest in computer security * Experience in formal verification * Good writing and presentation skills * Haskell programming experience is highly desirable * C-programming experience (desirable) * Prolog programming experience (desirable) URL: * http://www.kaspersky.ru/job?vac=283263

2 1

Displaying specializations in :info or separately?
by David Kraeutmann 20 Oct '15

20 Oct '15

Hi, I'm working on a GHC feature [1] that allows users to view specializations of functions like in (name subject to change) ---- > :binfo find find :: Foldable t => (a -> Bool) -> t a -> Maybe a Specialisations: t ~ [] => find :: (a -> Bool) -> [a] -> Maybe a > :binfo first first :: Arrow a => a b c -> a (b, d) (c, d) Specialisations: a ~ (->) => first :: (b -> c) -> (b, d) -> (c, d) ---- Now there are two things left to decide on: * What command should the specializations be visible under? We can either put it under :info or make a special command :sinfo or :binfo that displays only the expression's type and specialisations like in the example above? * What specializations do we want to display? goldfire suggested using the default list, which has the added benefit of being customizable by e.g. instructors, so adding a default Maybe (in conjunction with [2]) gives the desired behavior and not too many specializations. Thanks for your time! David ---- Links: [1] : https://ghc.haskell.org/trac/ghc/ticket/10972 [2] : https://ghc.haskell.org/trac/ghc/ticket/10971

5 5

Problems with Stack on Gentoo Linux
by Nicola Gigante 20 Oct '15

20 Oct '15

Hi all I’m sorry if this is not the right list to ask, I was unsure. I’m having problems compiling a project with stack on a Gentoo machine. I only have shell access to the machine, so I don’t have too much info about it, but the admin assured me that everything is up to date. I’ve upgraded to the latest stack, but the problem was also present with 0.1.4. While doing stack build on my project with resolver lts 3.10 I get the following strange error: ---------------------------------------------------------------------------------------------- -- While building package transformers-base-0.4.4 using: /home/gigabytes/.stack/setup-exe-cache/setup-Simple-Cabal-1.22.4.0-x86_64-linux-ghc-7.10.2 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/ build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/gigabytes/gigabytes.it/.stack-work/logs/transformers-base-0.4.4.log Configuring transformers-base-0.4.4... Building transformers-base-0.4.4... Preprocessing library transformers-base-0.4.4... [1 of 1] Compiling Control.Monad.Base ( src/Control/Monad/Base.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Control/Monad/Base.o ) src/Control/Monad/Base.hs:22:1: Warning: The import of `Data.Monoid' is redundant except perhaps to import instances from `Data.Monoid' To import instances alone, use: import Data.Monoid() src/Control/Monad/Base.hs:24:1: Warning: The import of `Control.Applicative' is redundant except perhaps to import instances from `Control.Applicative' To import instances alone, use: import Control.Applicative() .stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/src/Control/Monad/Base.dump-hi: commitBuffer: invalid argument (invalid character) ---------------------------------------------------------------------------------------------- Note that the warnings are not stopping the compile process themselves, but they somehow trigger the last error which kills the compiler. Stack is using the system-installed GHC here, which is version 7.10.2 (of course, otherwise stack wouldn’t have selected it). Maybe the system-wide compiler wasn’t installed properly (I doubt it, since the admin told me he uses a Gentoo package manager which is written in haskell and everything works well). So I’ve tried installing a stack-local GHC version, but I get a sanity check error: ---------------------------------------------------------------------------------------------- The GHC located at /home/gigabytes/.stack/programs/x86_64-linux/ghc-7.10.2/bin/ghc failed to compile a sanity check. Please see: https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upg… for more information. Exception was: Running /home/gigabytes/.stack/programs/x86_64-linux/ghc-7.10.2/bin/ghc /tmp/stack-sanity-check22752/Main.hs -no-user-package-db exited with ExitFailure 1 [1 of 1] Compiling Main ( /tmp/stack-sanity-check22752/Main.hs, /tmp/stack-sanity-check22752/Main.o ) Linking /tmp/stack-sanity-check22752/Main ... /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.3/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/stack-sanity-check22752/Main.o: relocation R_X86_64_32S against `stg_bh_upd_frame_info' can not be used when making a shared object; recompile with -fPIC /tmp/stack-sanity-check22752/Main.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status ---------------------------------------------------------------------------------------------- So to recap: - The system-wide ghc crashes compiling transformers-base-0.4.4 - The stack-local ghc does not pass a sanity check On an OS X machine, the project compiles and work very well with the same stack and ghc versions and the same LTS, so I suppose this has to do with Gentoo. Any ideas? Thank you, Nicola

3 3

A GC'd heap using weak pointers
by Thomas Koster 20 Oct '15

20 Oct '15

Good afternoon list, I am implementing a simple, interpreted language that needs a garbage- collected heap for storage. Like most discussions on memory management, I use the term "heap" by analogy - the actual data structure is not necessarily a true heap. My Heap type is basically a map of "addresses" (Int) to values. Values may themselves contain addresses, perhaps recursively to each other (like letrec). The extra field in Heap stores the next unused address, used to allocate fresh slots, as you can see in "heapAlloc". > type Address = Int > data Value = ...things with Addresses... > data Heap = Heap !Address (Map Address Value) > > heapAlloc :: Heap -> (Address, Heap) > heapAlloc (Heap nextFreeAddr binds) = > (nextFreeAddr, Heap (succ nextFreeAddr) binds) There is also a stack of roots and an expression under evaluation. > type Stack = [...things with Addresses...] > data Expr = ...things with Addresses... The function I need to write is: > heapGC :: [Address] -> Heap -> Heap > heapGC roots heap = ...collect unreachable values from heap... Rather than re-invent this particularly complex wheel, I am wondering if I could use GHC weak pointers and have the GHC runtime collect values in my heap for me. Something like this: > type Address = Int > data Reference = Reference Address > data Value = ...things with References... > data Heap = Heap !Address (Map Address (Weak Value)) > > heapAlloc :: Heap -> (Reference, Heap) > heapAlloc (Heap nextFreeAddr binds) = > (Reference nextFreeAddr, Heap (succ nextFreeAddr) binds) > > heapStore :: Reference -> Value -> Heap -> IO Heap > heapStore ref@(Reference addr) val (Heap nextFreeAddr binds) = do > weakVal <- mkWeak ref val Nothing > return $ Heap nextFreeAddr (Map.insert addr weakVal binds) Note the new type, Reference. This replaces Address everywhere except in the heap's internal structure, which continues to use Address. Reference values are opaque, unique and obtained from the heap using heapAlloc. The idea is that only two things should cause Values to stay alive: 1. reachable holders of Reference (by GHC's definition of "reachable"), 2. ordinary Haskell closures arising from stepping the interpreter. "Being in the Heap" should not be enough to keep a Value alive. Then, my heapGC function should only have to prune dead addresses from the map. I am having trouble getting a proof-of-concept working (I am unable to observe any finalizers running, ever), but before I get into that, is this idea sound? Has somebody else implemented this in a library already? Thanks, Thomas Koster

2 3

Global fixity (our status quo) vs. local fixity
by Jeffrey Brown 20 Oct '15

20 Oct '15

In Haskell, fixity is global. There are ten levels. You can't stick something between two levels, and you can't subvert the order of the levels. If you want something that binds before >>= but after the logical operators && and ||, you're out of luck -- unless you're willing to define synonyms for && and || that bind faster. (Tidal, a music DSL written in Haskell (it's on Hackage), exemplifies that problem with its |+| operator.) Conceptually, by contrast, fixity is local. The arithmetic operators (* + - / and **), for instance, have a certain fixity defined relative to each other, and that order does not, I believe, in the mind of most users extend beyond arithmetic. Does anybody else think it would be nice if a library's author had only to decide its operators' precedence relative to each other, and could let users decide for themselves how fast its operators should bind relative to operators from another library? -- Jeffrey Benjamin Brown

3 4

hoogte db for the ghc api?
by Erik Rantapaa 20 Oct '15

20 Oct '15

Hi all, Is there a hoogle database for modules which come with GHC? - i.e. the modules on this page: http://downloads.haskell.org/~ghc/7.10.2/docs/html/libraries/ghc-7.10.2/ind… The text files would be preferable to a .hoo file, but I'll take either. Thanks! ER

3 2