#7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1?
-+--
Reporter: spl | Owner: dreixel
Type: feature request | Status: new
Priority: normal
#1409: Allow recursively dependent modules transparently (without .hs-boot or
anything)
-+--
Reporter: Isaac Dupree | Owner:
Type: feature request | Status: new
#7493: STM and TVar report incorrect results
+---
Reporter: parcs| Owner:
Type: bug | Status: new
Priority: normal
#7487: Deriving Generic1 for a type containing Either
-+--
Reporter: spl | Owner: dreixel
Type: bug | Status: new
Priority: normal|
#7487: Deriving Generic1 for a type containing Either
-+--
Reporter: spl | Owner: dreixel
Type: bug | Status: merge
Priority: normal|
#7493: STM and TVar report incorrect results
+---
Reporter: parcs| Owner:
Type: bug | Status: new
Priority: normal
#7468: incorect waiting for packets on UDP connections.
--+-
Reporter: ET | Owner:
Type: bug | Status: new
#7468: incorect waiting for packets on UDP connections.
--+-
Reporter: ET | Owner:
Type: bug | Status: closed
#7417: replace Control.Concurrent.QSem
---+
Reporter: tibbe | Owner:
Type: bug | Status: closed
Priority: normal| Milestone:
#7494: Allow compatible type synonyms to be the return type of a GADT data
constructor.
-+--
Reporter: topi | Owner:
Type: feature request | Status: new
#7493: STM and TVar report incorrect results
-+--
Reporter: parcs | Owner:
Type: bug | Status: merge
Priority: highest
#7492: Generic1 deriving: Can we replace Rec1 f with f :.: Par1?
-+--
Reporter: spl | Owner: dreixel
Type: feature request | Status: new
Priority: normal
#7495: Rebindable list syntax?
-+--
Reporter: nwf | Owner:
Type: feature request | Status: new
Priority: normal| Component: Compiler
On 09/12/12 21:39, Ian Lynagh wrote:
We are pleased to announce the first release candidate for GHC 7.6.2:
http://www.haskell.org/ghc/dist/7.6.2-rc1/
This includes the source tarball, installers for Windows, and
bindists for Windows, Linux, OS X and FreeBSD, on x86 and x86_64.
We plan
On 08/12/12 23:12, Yuras Shumovich wrote:
Hi,
I'm working on that issue as an exercise/playground while studding the
GHC internals: http://hackage.haskell.org/trac/ghc/ticket/693
It's not at all clear that we want to do this. Perhaps you'll be able
to put the question to rest and close the
On Mon, 2012-12-10 at 10:58 +, Simon Marlow wrote:
On 08/12/12 23:12, Yuras Shumovich wrote:
I tried to hack stg_putMVarzh directly:
if (enabled_capabilities == 1) {
info = GET_INFO(mvar);
} else {
(ptr info) = ccall lockClosure(mvar ptr);
}
On Sun, Dec 9, 2012 at 10:39 PM, Ian Lynagh wrote:
Please test as much as possible; bugs are much cheaper if we find them
before the release!
I tried to build the source tarball on Mac OS X 10.5.8. I used GHC 7.6.1,
which I also built myself (without any problem) and installed in
I don't know my way around the GHC source tree. How can I get the list of
optimizations implemented with Hoopl? Is there overlap with LLVM's
optimization passes? If so, has anyone compared the implementations at
all? Should one group be stealing ideas from the other? Or apples and
oranges?
Hello Greg,
Hoopl passes live in compiler/cmm; searching for DataflowLattice will
turn up lattice definitions which are the core of the analyses and rewrites.
Unfortunately, the number of true Hoopl optimizations was somewhat reduced
when Simon Marlow did aggressive performance optimizations to
On Mon, Dec 10, 2012 at 2:24 PM, Greg Fitzgerald gari...@gmail.com wrote:
Should one group be stealing ideas from the other? Or apples and oranges?
In my opinion we should only implement optimizations in Hoopl that
LLVM cannot do due to lack high-level information that we might have
gotten rid
Right now there isn't really an overlap with LLVM passes. In general
the feeling of many of the GHC developers is that we don't want to
spend time duplicating what LLVM already does. That said, GHC is an
open source project so someone may be inclined to do so and there
isn't a lot of reason not to
I suspect I've found a situation where, to a first approximation, I'd like
SpecConstr to run more than once.
I'm specializing on GADT constructors that contain coercions, so the
constructor-specialized functions have RHSs with refined types. In my
situation, those refined types enable
-
CALL FOR PAPERS
TERMGRAPH 2013
7th International Workshop on
Computing with Terms and Graphs
Rome, Italy, March
(Apologies if you receive multiple copies of this announcement)
Science of Computer Programming
Special Issue on Invariant Generation
-- SECOND CALL FOR PAPERS --
This
On Mon, Nov 26, 2012 at 06:21:33PM -0500, Albert Y. C. Lai wrote:
cabal configure is used by a lot of programmers. Today. Why?
Because they use it on their own projects. They use cabal-install as
a builder, not exactly an installer.
Don't most devs nowadays use sandboxing, a.k.a. cabal-dev?
On 12/08/2012 10:32 AM, Heinrich Apfelmus wrote:
Nathan Hüsken wrote:
Heinrich Apfelmus wrote:
In that light, the separation seems straightforward to me. Given the
time-varying values that represent game objects,
bSpaceShipPosition :: Behavior Position
bAsteroidPositions :: Behavior
Nathan Hüsken nathan.hues...@posteo.de wrote:
I put a pseudo C++ example below the mail. I use the terms model and
view for the game logic and rendering respectively.
The example is a little different. Asteroids explode when they
collide. The moment asteroids explode, they are removed from
I guess you have a point here:
1. The definition of the MonadWriter operations does not need the Monoid
operations.
Hence, the class constraint Monoid w should be removed.
2. The formulation of the MonadWriter laws (which are sadly missing from
the documentation) would need the Monoid
Dear Haskellers,
I'd like to announce a small library tie-knot:
Ties the knot on a given set of structures that reference each other by
keys - replaces the keys with their respective values. Takes Map k (v k)
and converts into Map k v' where v' is the fixed point of v.
Motivation: I
Hi Petr,
On Sun, Dec 9, 2012 at 7:59 AM, Petr P petr@gmail.com wrote:
The class is defined as
class (Monoid w, Monad m) = MonadWriter w m | m - w where
...
What is the reason for the Monoid constrait? It seems superfluous to me. I
recompiled the whole package without it, with no
On Sat, Dec 8, 2012 at 10:27 AM, Takayuki Muranushi muranu...@gmail.com wrote:
Continued discussion from
https://groups.google.com/d/topic/haskell-cafe/-e-xaCEbd-w/discussion
https://groups.google.com/d/topic/haskell-cafe/kM_-NvXAcx8/discussion
Thank you for all the answeres and thinkings;
Repeated thanks to you, Adam! Your code is brilliantly simple.
Sadly, I cannot reproduce the behaviors in your comments on my ghci
(7.6.1) .
Can we guess why? The version of packages we are using?
Mines are here.
https://github.com/nushio3/practice/tree/master/variable-arity/adam
:t
32 matches
Mail list logo
