The Hugs98 interpreter has been extended with features which lets you instantiate and use .NET objects from within Haskell, and vice versa Hugs98 for .NET takes a hands-off approach, providing 'just' the ability to interoperate well with .NET. That is, it does not try to compile Haskell into .NET's IL and have the .NET run-time execute it. Instead the Hugs98 interpreter operates side-by-side with the .NET run-time
So why is the restriction imposed? The reasoning behind it is fairly subtle, and is fully explained in the Haskell 98 report. Basically, it solves one practical problem (without the restriction, there would be some ambiguous types) and one semantic problem (without the restriction, there would be some repeated evaluation where a programmer might expect the evaluation to be shared). Those who are for the restriction argue that these cases should be dealt with correctly. Those who are against the restriction argue that these cases are so rare that it's not worth sacrificing the type-independence of eta reduction.
A witness is a value that witnesses some sort of constraint on some list of type variables. This library provides support for simple witnesses, that constrain a type variable to a single type, and equality witnesses, that constrain two type variables to be the same type. The library also provides classes for representatives, which are values that represent types.
The Curry-Howard correspondence is a mapping between logic and type systems. On the one hand you have logic systems with propositions and proofs. On the other hand you have type systems with types and programs (or functions). As it turns out these two very different things have very similar rules. This article will explore the Curry-Howard correspondence by constructing a proof system using the Haskell type system (how appropriate since Haskell is named after Haskell Curry, the "Curry" in "Curry-Howard"). We'll set up the rules of logic using Haskell types and programs. Then we'll use these rules as an abstract interface to perform some logic profs.
The result is a unified concurrency model providing both thread abstractions and event abstractions. We implemented the unified concurrency model in Haskell Our implementation demonstrates how to use these techniques by building an application-level thread library with support for multiprocessing and asynchronous I/O mechanisms in Linux. The thread library is type-safe, is relatively simple to implement, and has good performance. Application-level threads are extremely lightweight (scaling to 10,000,000 threads!) and our scheduler, which is implemented as a modular and extensible event-driven system, outperforms NPTL in I/O benchmarks.
One obvious solution is to do two passes -- one to lay everything out, then another to generate now that offsets are known.Here's where it gets clever. Rather than two passes, they instead write the code in such a way that the code-generator function's output is also passed as a parameter to the same function.
In denotational semantics and functional programming, the terms monad morphism, monad layering, monad constructor, and monad transformer have by now accumulated 20 years of twisted history. The exchange between Eric Kidd and sigfpe about the probability monad prompted me to investigate this history
In a previous post, I wondered about the differences between the thought processes that goes into writing good static code, and those that go into good dynamic code. We figured that there wasn't a lot out there to help dynamic programmers get the hang of static style thinking, so what follows is a simple little toy example, solved in what I think is probably a fairly static typey style.