Am Freitag, den 04.11.2011, 20:16 -0400 schrieb wagne...@seas.upenn.edu:
Quoting wagne...@seas.upenn.edu:
Quoting Wolfgang Jeltsch g9ks1...@acme.softbase.org:
this code is accepted by GHC 7.0.4:
snip
However, this one isn?t:
{-# LANGUAGE ImpredicativeTypes #-}
polyId ::
On Sat, Nov 5, 2011 at 4:41 PM, Christian Brolin cbro...@gmail.com wrote:
Hello
I try to set-up a gnu makefile for compiling Haskell programs with GHC. I
want to generate dependencies automatically and I want to put my object (.o)
files in a binary specifc directories to be able to compile
Hi GHC users,
When implementing certain concurrent systems-level software in Haskell
it is good to be aware of all potentially blocking operations.
Presently, blocking on an MVar is explicit (it only happens when you
do a takeMVar), but blocking on a BLACKHOLE is implicit and can
potentially
Am Montag, den 07.11.2011, 14:49 +0200 schrieb Wolfgang Jeltsch:
Am Freitag, den 04.11.2011, 20:16 -0400 schrieb wagne...@seas.upenn.edu:
The first thing to observe is that, ideally, the following two types
would mean slightly different things:
polyId :: forall b. (forall a. Maybe a) -
Jan voted for the explicit lockAndBlackhole version as safer.
I realize that for the Bytestring example all you would want to gently
consume what is already available is WHNF detection alone. In that
scenario you don't want to evaluate anything, just consume what is already
evaluated.
I would
I think we should apply the minimal change to make all packages trusted
by default in 7.2.2. Any objections?
Cheers,
Simon
On 06/11/2011 16:36, Chris Dornan wrote:
It's looking good but base is still untrusted out of the box. Is this right?
Chris
-Original Message-
From:
On 06/11/2011 16:56, John Millikin wrote:
2011/11/6 Max Bolingbrokebatterseapo...@hotmail.com:
On 6 November 2011 04:14, John Millikinjmilli...@gmail.com wrote:
For what it's worth, on my Ubuntu system, Nautilus ignores the locale
and just treats all paths as either UTF8 or invalid.
To me,
I am unsure which of this list of proposals you are referring to. The
URL you quote is this
http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels
That sounds familiar, I think I wrote that when I was younger;-)
but it doesn't seem to actually contain a design, merely some
On Mon, Nov 7, 2011 at 09:02, Simon Marlow marlo...@gmail.com wrote:
I think you might be misunderstanding how the new API works. Basically,
imagine a reversible transformation:
encode :: String - [Word8]
decode :: [Word8] - String
this transformation is applied in the appropriate
Y'all have probably seen this, but I have opened #5607 saying a bit more.
http://hackage.haskell.org/trac/ghc/ticket/5607
Chris
-Original Message-
From: Simon Marlow [mailto:marlo...@gmail.com]
Sent: 07 November 2011 16:45
To: Chris Dornan
Cc: 'Ian Lynagh';
On Mon, Nov 07, 2011 at 05:02:32PM +, Simon Marlow wrote:
Basically, imagine a reversible transformation:
encode :: String - [Word8]
decode :: [Word8] - String
this transformation is applied in the appropriate direction by the
IO library to translate filesystem paths into
On 7 November 2011 08:44, Simon Marlow marlo...@gmail.com wrote:
I think we should apply the minimal change to make all packages trusted by
default in 7.2.2. Any objections?
Agreed.
___
Glasgow-haskell-users mailing list
Am Montag, den 07.11.2011, 17:53 + schrieb Barney Hilken:
Here is my understanding of the current state of the argument:
Instead of Labels, there will be a new kind String, which is not a
subkind of *, so its elements are not types. The elements of String
are strings at the type level,
Am Montag, den 07.11.2011, 18:16 +0100 schrieb Claus Reinke:
I am unsure which of this list of proposals you are referring to. The
URL you quote is this
http://hackage.haskell.org/trac/haskell-prime/wiki/FirstClassLabels
That sounds familiar, I think I wrote that when I was younger;-)
On Mon, Nov 7, 2011 at 1:33 PM, Wolfgang Jeltsch g9ks1...@acme.softbase.org
wrote:
Am Montag, den 07.11.2011, 18:16 +0100 schrieb Claus Reinke:
I am unsure which of this list of proposals you are referring to. The
URL you quote is this
The problem with this approach is that different labels do not have
different representations at the value level.
I think this is an advantage, because it means you don't have to carry this
stuff about at runtime.
This allows me to pattern match records, since I can construct record
On Mon, Nov 07, 2011 at 08:31:04PM +0200, Wolfgang Jeltsch wrote:
The problem with this approach is that different labels do not have
different representations at the value level. In my record system, I use
label definitions like the following ones:
data MyName1 = MyName1
data
Ian said
class Has (r :: *) (ft :: *) (f :: ft) (t :: *) where
(where ft stands for field type)?
class Has (r :: *) (f :: ft) (t :: *) where
would be my understanding of how it would be phrased under the current
polymorphic kind system.
This could also solve the representation-hiding
Wolfgang
Is there a wiki page giving a specific, concrete design for the proposal you
advocate? Something at the level of detail of
http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields?
I am unsure whether you regard it as an alternative to the above, or something
that
Simon Marlow wrote:
It would probably be better to have an abstract FilePath type and to keep
the original bytes, decoding on demand. But that is a big change to the API
and would break much more code. One day we'll do this properly; for now we
have this, which I think is a pretty reasonble
On Mon, Nov 7, 2011 at 15:39, Yitzchak Gale g...@sefer.org wrote:
The problem is that Haskell 98 specifies type FilePath = String.
In retrospect, we now know that this is too simplistic.
But that's what we have right now.
This is *a* problem, but not a particularly major one; the definition
of
On Mon, Nov 07, 2011 at 01:25:11AM +0400, Kyra wrote:
On 11/6/2011 5:18 PM, Ian Lynagh wrote:
7.2.2 will be a minimal bugfix release, fixing only bugs that cannot be
worked around. Please let us know if you find any showstoppers.
#5531 is still there and no workarounds are known. Also, it's
We are pleased to announce the first release candidate for GHC 7.2.2:
http://www.haskell.org/ghc/dist/7.2.2-rc1/
Thanks, I did a test build for Fedora 17 Development.
If you wish to test it on Fedora you can get
the srpm or binary packages from:
23 matches
Mail list logo
