News aggregator

About that Idris data declaration, could someone please clarify?

Haskell on Reddit - Wed, 05/20/2015 - 8:39pm

At the idris tutorial The code in question

data Vect : Nat -> Type -> Type where Nil : Vect Z a (::) : a -> Vect k a -> Vect (S k) a

some explanation follows, and then this bit:

... We explicitly state the type of the type constructor Vect — it takes a Nat and a type as an argument, where Type stands for the type of types.

Milk snort, WUT! The type of types? What about the type of the type of types? What about the ... infinite string (type of the)* type of types. Why not use a type variable for the type of types?

Where do I learn more about the type of types? Because, I don't feel comfortable moving ahead with the tutorial until this sits better. I haven't taken a course on type theory, that probably explains it.

submitted by herbadah
[link] [22 comments]
Categories: Incoming News

Can GHCi inspect the state of running threads?

glasgow-user - Wed, 05/20/2015 - 4:51pm
Hello, I have a multi-threaded and interactive application that sometimes stops responding, and it would be helpful being able to inspect the state when it doesn't. I thought the GHCi debugger could be useful here, however I see no way to signal a thread and have GHCi show me its state. Here is an example GHCi session: $ cat t.hs import Control.Concurrent import Control.Exception import Control.Monad import System.IO spawnThread :: String -> IO ThreadId spawnThread label = forkIO $ flip finally (putStrLn $ "bye " ++ label) $ forM_ [0..] $ \i -> threadDelay 1000000 $ ghci-7.10.1 t.hs -fbreak-on-exception -v0 *Main> hSetBuffering stdout LineBuffering *Main> t0 <- spawnThread "t0" *Main> throwTo t0 (ErrorCall "end") *Main> It looks like I'm not getting the "bye t0" message when stopping the thread while using -fbreak-on-exception. Is the debugger supposed to be used like this? Otherwise, is there any way in which I could inspect the state of a running thread? Thanks, Facundo
Categories: Offsite Discussion

[ANN] codex 0.3

haskell-cafe - Wed, 05/20/2015 - 3:08pm
Hello Café, I have released a new version of `codex`[1] (a ctags file generator for cabal project and their dependencies). It should be noted that *this version now fully support the windows operating system*, thanks to a great contribution from Ben James. This new version include: - Tagging of the current project can be turned-off - Fix/Enhance the `emacs` and `sublime` default format - Tags file name is now configurable - Replace `curl` with `wrep` - Misc fixes and portability enhancement Thanks to the contributors (Ben James, Tal Walter, Eyal Lotem). [1] https://github.com/aloiscochard/codex
Categories: Offsite Discussion

Erlang Workshop 2015: deadline extension

General haskell list - Wed, 05/20/2015 - 12:22pm
Hi everyone, The PC has decided to extend the paper submission deadline for the 14th ACM SIGPLAN Erlang Workshop. New final dates are as follows, there will not be any further extensions Submissions due: Friday, 29 May, 2015 [extended] Author notification: Friday, 26 June, 2015 [unchanged] Final copy due: Sunday, 19 July, 2015 [unchanged] Workshop date: September 4, 2015 [unchanged] Apologies for any duplicates you may receive. CALL FOR PAPERS =============== Fourteenth ACM SIGPLAN Erlang Workshop ----------------------------------------------------------- Vancouver, Canada, September 4, 2015 Satellite event of the 20th ACM SIGPLAN International Conference on Functional Programming (ICFP 2015) August 30 - September 5, 2015 http://www.erlang.org/workshop/2015/ErlangWorkshop2015.html Erlang is a concurrent, distributed functional programming language aimed at systems with requirements of massive concurrency, soft real time response, fault tolerance, and high availability. It has been available as ope
Categories: Incoming News

NoOO languages

haskell-cafe - Wed, 05/20/2015 - 9:18am
Could we mimic the marketing success of NoSQL databases by branding functional languages as NoOO (or even NoIO)?
Categories: Offsite Discussion

What's an open source Haskell project to which I could contribute?

Haskell on Reddit - Wed, 05/20/2015 - 7:26am

I want to develop further as a haskeller but I don't know what projects are out there that I could help. I've written some pet projects in haskell and put them on github but I don't really know where to go from here.

I'd say I'm most interested in mathematics/statistics applications but really I'm just looking to hone my skills while solving a real problem.

submitted by Frosticus
[link] [15 comments]
Categories: Incoming News

what javascript UI library works best with yesod?

Haskell on Reddit - Wed, 05/20/2015 - 7:12am

being both a javascript noob and yesod noob, I realize this may be nonsensical and maybe it's a bad idea to be learning both at the same time.

I was wondering what people using yesod are using for their javascript UIs (and if there are good code examples for how to transmit information from a widget (like a slider) back to yesod. Being a beginner, it seems there's a dizzying array of equally-hyped-up javascript libraries/frameworks for this - jquery, angular, react.

submitted by klaxion
[link] [7 comments]
Categories: Incoming News

glfw demos ?

haskell-cafe - Wed, 05/20/2015 - 5:04am
Hi, Looks like the demos, including the one on the wiki page, and the glfw-b-demo package, are suffering from bit-rot. I was hoping somebody could point me to a small get-started demo. Meanwhile I am working on trying to get the wiki demo running. Thanks, Brian
Categories: Offsite Discussion

Functional Jobs: Clojure/Erlang backend engineer/architect at Zoomo (Full-time)

Planet Haskell - Wed, 05/20/2015 - 4:40am

You will:

  1. Write backend services that power our listings , internal dashboards and platform. Our services are built on erlang,python and clojure.
  2. Write a clean, fast and maintainable code using functional paradigms.
  3. Research on latest trends in software and adapt them for business needs.
  4. Contribute to open source libraries and write educational blogs.
  5. Take care of health of production setup and ensure all systems are up and running at all times.

What are we looking for ?

  1. Strong fundamentals of computer programming.
  2. Familiarity with any functional programming language.
  3. Have contributed to open source projects.
  4. Have shown a real interest in learning programming.
  5. Ability to learn new languages and frameworks.
  6. In-depth knowledge of libraries and programming languages used on a day to day basis.
  7. In-depth knowledge of rest services, http protocol and messaging services.
  8. Comfortable with event driven programming and multi-threaded programming.

Good to have

  1. Familiarity with angularjs/react.
  2. Familiarity with clojure/lisp/haskell/erlang/sml/racket/scala.

Perks :

  1. Freedom to experiment and evangelize latest technologies.
  2. Best in industry salary and siginificant equity.
  3. Leadership position and fast track career growth.

What are we doing?

We are a peer-to-peer marketplace for used cars. We accelerate p2p car transactions. We want to offer the average Indian, a credible, easy alternative to buying an expensive new car. As you read this, we are coding to make used car buying as systematic as ordering a phone off flipkart.

Where can I see what you have built thus far?

Download zoomo for android. On apple/ desktop check us out at www.gozoomo.com.

Why used cars?

Used cars is a $10B market, and will grow ten folds to $100B in the 7-10 year timeframe

Buying a used car make immense economic sense for a value-for-money economy like ours. A car is a depreciating asset, often losing ~30% of its value in the first year itself Why buy a mid segment hatcback for 6L when you can get an almost new premium hatchback/ Sedan at 4L?

What is it that we are fixing?

Buying a used car is horribly difficult today. Used cars buying is one experience still untouched by advances in interfaces, devices, networks and technology in general. As per our studies more than 70% of users who start searching for a used car drop off to buy an expensive, new car.

We are changing all that. We are making people happy by saving them big bucks. By finding them cars they fall in love with.

So how are you solving this/ are different/ are confident that this is going to be big?

Meet us in person and we will spill the beans :) You will get great coffee and 2-way conveyance

Get information on how to apply for this position.

Categories: Offsite Blogs

FP Complete: Call C functions from Haskell without bindings

Planet Haskell - Wed, 05/20/2015 - 4:00am

Because Haskell is a language of choice for many problem domains, and for scales ranging from one-off scripts to full scale web services, we are fortunate to by now have over 8,000 open source packages (and a few commercial ones besides) available to build from. But in practice, Haskell programming in the real world involves interacting with myriad legacy systems and libraries. Partially because the industry is far older than the comparatively recent strength of our community. But further still, because quality new high-performance libraries are created every day in languages other than Haskell, be it intensive numerical codes or frameworks for shuffling bits across machines. Today we are releasing inline-c, a package for writing mixed C/Haskell source code that seamlessly invokes native and foreign functions in the same module. No FFI required.

The joys of programming with foreign code

Imagine that you just found a C library that you wish to use for your project. The standard workflow is to,

  1. check Hackage if a package with a set of bindings for that library exists,
  2. if one does, program against that, or
  3. if it doesn't, write your own bindings package, using Haskell's FFI.

Writing and maintaining bindings for large C libraries is hard work. The libraries are constantly updated upstream, so that the bindings you find are invariably out-of-date, providing only partial coverage of library's API, sometimes don't compile cleanly against the latest upstream version of the C library or need convoluted and error-prone conditional compilation directives to support multiple versions of the API in the package. Which is a shame, because typically you only need to perform a very specific task using some C library, using only a minute proportion of its API. It can be frustrating for a bindings package to fail to install, only because the binding for some function that you'll never use doesn't match up with the header files of the library version you happen to have installed on your system.

This is especially true for large libraries that expose sets of related but orthogonal and indepedently useful functions, such as GTK+, OpenCV or numerical libraries such as the GNU Scientific Library (GSL), NAG and IMSL. inline-c lets you call functions from these libraries using the full power of C's syntax, directly from client code, without the need for monolithic bindings packages. High-level bindings (or "wrappers") may still be useful to wrap low-level details into an idiomatic Haskell interface, but inline-c enables rapid prototyping and iterative development of code that uses directly some of the C library today, keeping for later the task of abstracting calls into a high-level, type safe wrapper as needed. In short, inline-c let's you "pay as you go" when programming foreign code.

We first developed inline-c for use with numerical libraries, in particular the popular and very high quality commercial NAG library, for tasks including ODE solving, function optimization, and interpolation. If getting seamless access to the gold standard of fast and reliable numerical routines is what you need, then you will be interested in our companion package to work specifically with NAG, inline-c-nag.

A taste of inline-c

What follows is just a teaser of what can be done with inline-c. Please refer to the Haddock documentation and the README for more details on how to use the showcased features.

Let's say we want to use C's variadic printf function and its convenient string formats. inline-c let's you write this function call inline, without any need for a binding to the foreign function:

{-# LANGUAGE QuasiQuotes #-} {-# LANGUAGE TemplateHaskell #-} import qualified Language.C.Inline as C C.include "<stdio.h>" C.include "<math.h>" main :: IO () main = do x <- [C.exp| int{ printf("Some number: %.2f\n", cos(0.5)) } |] putStrLn $ show x ++ " characters printed."

Importing Language.C.Inline brings into scope the Template Haskell function include to include C headers (<stdio.h> and <math.h>), and the exp quasiquoter for embedding expressions in C syntax in Haskell code. Notice how inline-c has no trouble even with C functions that have advanced calling conventions, such as variadic functions. This is a crucial point: we have the full power of C available at our fingertips, not just whatever can be shoe-horned through the FFI.

We can capture Haskell variables to be used in the C expression, such as when computing x below:

mycos :: CDouble -> IO CDouble mycos x = [C.exp| double{ cos($(double x)) } |]

The anti-quotation $(double x) indicates that we want to capture the variable x from the Haskell environment, and that we want it to have type double in C (inline-c will check at compile time that this is a sensible type ascription).

We can also splice in a block of C statements, and explicitly return the result:

C.include "<stdio.h>" -- | @readAndSum n@ reads @n@ numbers from standard input and returns -- their sum. readAndSum :: CInt -> IO CInt readAndSum n = do x <- [C.block| int { int i, sum = 0, tmp; for (i = 0; i < $(int n); i++) { scanf("%d ", &tmp); sum += tmp; } return sum; } |] print x

Finally, the library provides facilities to easily use Haskell data in C. For example, we can easily use Haskell ByteStrings in C:

{-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE QuasiQuotes #-} import qualified Data.ByteString as BS import Data.Monoid ((<>)) import Foreign.C.Types import qualified Language.C.Inline as C import Text.RawString.QQ (r) C.context (C.baseCtx <> C.bsCtx) -- | Count the number of set bits in a 'BS.ByteString'. countSetBits :: BS.ByteString -> IO CInt countSetBits bs = [C.block| int { int i, bits = 0; for (i = 0; i < $bs-len:bs; i++) { unsigned char ch = $bs-ptr:bs[i]; bits += (ch * 01001001001ULL & 042104210421ULL) % 017; } return bits; } |]

In this example, we use the bs-len and bs-ptr anti-quoters to get the length and pointer for a Haskell ByteString. inline-c has a modular design: these anti-quoters are completely optional and can be included on-demand. The C.context invocation adds the extra ByteStrings anti-quoters to the base set. Similar facilities are present to easily use Haskell Vectors as well as for invoking Haskell closures from C code.

Larger examples

We have included various examples in the inline-c and inline-c-nag repositories. Currently they're geared toward scientific and numerical computing, but we would welcome contributions using inline-c in other fields.

For instance, gsl-ode.hs is a great example of combining the strengths of C and the strengths of Haskell to good effect: we use a function from C's GNU Scientific Library for solving ordinary differential equations (ODE) to solve a Lorenz system, and then take advantage of the very nice Chart-diagrams Haskell library to display its x and z coordinates:

In this example, the vec-ptr anti-quoter is used to get a pointer out of a mutable vector:

$vec-ptr:(double *fMut)

Where fMut is a variable of type Data.Storable.Vector.Mutable.Vector CDouble. Moreover, the fun anti-quoter is used to get a function pointer from a Haskell function:

$fun:(int (* funIO) (double t, const double y[], double dydt[], void * params))

Where, funIO is a Haskell function of type

CDouble -> Ptr CDouble -> Ptr CDouble -> Ptr () -> IO CInt

Note that all these anti-quoters (apart from the ones where only one type is allowed, like vec-len or bs-ptr) force the user to specify the target C type. The alternative would have been to write the Haskell type. Either way some type ascription is unfortunately required, due to a limitation of Template Haskell. We choose C type annotations because in this way, the user can understand precisely and state explicitly the target type of any marshalling.

Note that at this stage, type annotations are needed, because it is not possible to get the type of locally defined variables in Template Haskell.

How it works under the hood

inline-c generates a piece of C code for most of the Template Haskell functions and quasi-quoters function that it exports. So when you write

[C.exp| double{ cos($(double x)) } |]

a C function gets generated:

double some_name(double x) { return cos(x); }

This function is then bound to in Haskell through an automatically generated FFI import declaration and invoked passing the right argument -- the x variable from the Haskell environment. The types specified in C are automatically translated to the corresponding Haskell types, to generate the correct type signatures.

Custom anti quoters, such as vec-ptr and vec-len, handle the C and Haskell types independently. For example, when writing

[C.block| double { int i; double res; for (i = 0; i < $vec-len:xs; i++) { res += $vec-ptr:(double *xs)[i]; } return res; } |]

we'll get a function of type

double some_name(int xs_len, double *xs_ptr)

and on the Haskell side the variable xs will be used in conjuction with some code getting its length and the underlying pointer, both to be passed as arguments.

Building programs that use inline-c

The C code that inline-c generates is stored in a file named like the Haskell source file, but with a .c extension.

When using cabal, it is enough to specify generated C source, and eventual options for the C code:

executable foo main-is: Main.hs, Foo.hs, Bar.hs hs-source-dirs: src -- Here the corresponding C sources must be listed for every module -- that uses C code. In this example, Main.hs and Bar.hs do, but -- Foo.hs does not. c-sources: src/Main.c, src/Bar.c -- These flags will be passed to the C compiler cc-options: -Wall -O2 -- Libraries to link the code with. extra-libraries: -lm ...

Note that currently cabal repl is not supported, because the C code is not compiled and linked appropriately. However, cabal repl will fail at the end, when trying to load the compiled C code, which means that we can still use it to type check our package when developing.

If we were to compile the above manually we could do

$ ghc -c Main.hs $ cc -c Main.c -o Main_c.o $ ghc Foo.hs $ ghc Bar.hs $ cc -c Bar.c -o Bar_c.o $ ghc Main.o Foo.o Bar.o Main_c.o Bar_c.o -lm -o MainExtending inline-c

As mentioned previously, inline-c can be extended by defining custom anti-quoters. Moreover, we can also tell inline-c about more C types beyond the primitive ones.

Both operations are done via the Context data type. Specifically, the Context contains a TypesTable, mapping C type specifiers to Haskell types; and a Map of AntiQuoters. A baseCtx is provided specifying mappings from all the base C types to Haskell types (int to CInt, double to CDouble, and so on). Contexts can be composed using their Monoid instance.

For example, the vecCtx contains two anti-quoters, vec-len and vec-ptr. When using inline-c with external libraries we often define a context dedicated to said library, defining a TypesTable converting common types find in the library to their Haskell counterparts. For example inline-c-nag defines a context containing information regarding the types commonly using in the NAG scientific library.

See the Language.C.Inline.Context module documentation for more.

C++ support

Our original use case for inline-c was always C oriented. However, thanks to extensible contexts, it should be possible to build C++ support on top of inline-c, as we dabbled with in inline-c-cpp. In this way, one can mix C++ code into Haskell source files, while reusing the infrastructure that inline-c provides for invoking foreign functions. Since inline-c generates C wrapper functions for all inline expressions, one gets a function with bona fide C linkage to wrap a C++ call, for free. Dealing with C++ templates, passing C++ objects in and out and conveniently manipulating them from Haskell are the next challenges. If C++ support is what you need, feel free to contribute to this ongoing effort!

Wrapping up

We meant inline-c as a simple, modular alternative to monolithic binding libraries, borrowing the core concept of FFI-less programming of foreign code from the H project and language-c-inline. But this is just the first cut! We are releasing the library to the community early in hopes that it will accelerate the Haskell community's embrace of quality foreign libraries where they exist, as an alternative to expending considerable resources reinventing such libraries for little benefit. Numerical programming, machine learning, computer vision, GUI programming and data analysis come to mind as obvious areas where we want to leverage existing quality code. In fact, FP Complete is using inline-c today to enable quick access to all of NAG, a roughly 1.6K function strong library, for a large compute-intensive codebase. We hope to see many more use cases in the future.

Categories: Offsite Blogs

making 7.10.1

glasgow-user - Tue, 05/19/2015 - 7:59pm
People, I am trying to `make' ghc-7.10.1 from source by ghc-7.8.3 on Debian Linux. I command > ./configure --prefix=/home/mechvel/haskell/ghc/7.10.1/inst0 > make >& make.log The former command seems successful: ... #define HAVE_EVENTFD 1 #define CC_SUPPORTS_TLS 1 configure: exit 0 The latter command reports --------------------------------------- ... ... checking whether to build static libraries... yes checking how to run the C++ preprocessor... /lib/cpp configure: error: in `/home/mechvel/haskell/ghc/7.10.1/libffi/build/x86_64-unkn\ own-linux-gnu': configure: error: C++ preprocessor "/lib/cpp" fails sanity check See `config.log' for more details --------------------------------------- And I do not find in config.log anything suspicious about cpp. config.log does have several `error' messages, like, say conftest.c:9:28: error: ac_nonexistent.h: No such file or directory But, probably, they are harmless. Please, how to fix? ------ Sergei
Categories: Offsite Discussion

I'm reading #OutOfTheTarPit does ghc have a relational model built in for state?

haskell-cafe - Tue, 05/19/2015 - 7:35pm
I'm reading #OutOfTheTarPit does ghc have a relational model built in for state? "Out of the Tar Pit" talks about FRP - Functional Relational Programming -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe< at >haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Categories: Offsite Discussion

Naming convention for version branches (Packageversioning)

haskell-cafe - Tue, 05/19/2015 - 6:02pm
Hi all, I am currently writing a tool to automate the release and version bump of cabal projects. Currently you can call the tool by giving as argument the rank of the branch you want to bump, for example given 0.0.0.0: - `cabal-release 0` bump to `1` - `cabal-release 1` bump to `0.1` - `cabal-release 2` bump to `0.0.1` - `cabal-release 3` bump to `0.0.0.1` As we are not all robots (yet), I thought that in addition to this it would be great if the user could give a human friendly name for the rank. For now, here is what I have for the different rank: 0 == --major 1 == --major-fix 2 == --minor 3 == --minor-fix I'm curious to know what you think of those names? any suggestions or known established convention about that? Thanks
Categories: Offsite Discussion

text-icu (and FFI in general) on Windows 64 bits

haskell-cafe - Tue, 05/19/2015 - 5:51pm
I was finally successful in getting text-icu to work on Windows 64 bits. This is probably an indication of what to expect in general for packages requiring FFI on Windows 64 bits. In the past, on 32 bits, the standard Windows binary distribution from the ICU site could be used together with msys/mingw, even though it was officially only for MSVC. This no longer seems to be the case for 64 bits. When I build text-icu in that way with a 64 bit GHC and the Windows 64-bit binary ICU distribution for MSVC, the resulting EXEs segfault as soon as any function from text-icu is called. There is no official ICU download for mingw-w64 binaries. But happily, the MSYS2 project does provide a pre-built ICU binary distribution for mingw-w64. It tends to be quite up-to-date; the current version is ICU 55.1. Note, however, that I was *not* able to use the partial MSYS2 that comes with MinGHC, because pacman seems to be missing. So the solution is: 1. Download and install 64-bit MSYS2, following the instructions on the s
Categories: Offsite Discussion

Cartesian Closed Comic: Security

Planet Haskell - Tue, 05/19/2015 - 5:00pm

Categories: Offsite Blogs

Obverse and Reverse

Haskell on Reddit - Tue, 05/19/2015 - 3:15pm
Categories: Incoming News