Re: [Haskell] ANNOUNCE: GHC version 7.2.2
The GHC Team is pleased to announce a new bugfix release of GHC, 7.2.2. Thanks! I have done a test build for Fedora 17 development: http://koji.fedoraproject.org/koji/taskinfo?taskID=3512016 http://kojipkgs.fedoraproject.org/scratch/petersen/task_3512016/ The testsuite results look pretty good: only two unexpected failures on i686 (none on x86_64). :) Unexpected failures: ../../libraries/process/tests 3231 [bad exit code] (threaded1) numeric/should_run numrun012 [bad stdout] (normal) I expect to move Fedora 17 development soon to ghc-7.2. Jens ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Why not allow empty record updates?
Hello GHC HQ,
I have been toying with phantom types in combination with polymorphic
record-updates (which is a great feature imho), but stumbled over a
limitation: GHC doesn't allow empty record updates (see toy example
below), and I couldn't find a GHC language extension to relax this
constraint. In the toy-example below it was easy to workaround by
performing a dummy record update, but for more advanced uses workarounds
becomes a bit more annoying.
Is there a particular reason why empty record updates are disallowed by
the Haskell Report? Would it be sensible, to allow empty record updates
as a GHC language extension?
hvr.
---
-- empty types for tagging
data Clean
data Dirty
data Foo a = Foo { fa :: Int, fb :: String }
data Bar a = Bar { ba :: Int, bb :: Foo a }
markDirtyFoo :: Foo Clean - Foo Dirty
markDirtyFoo foo = foo { } -- rejected with Empty record update error
markDirtyFoo foo = foo { fa = fa foo } -- workaround: dummy update
markDirtyBar :: Bar Clean - Bar Dirty
markDirtyBar bar = bar { bb = markDirtyFoo (bb bar) } -- works
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: encoding and paths, again
On 13/11/2011 19:41, Ganesh Sittampalam wrote: Hi, I'm not entirely clear on what the overall situation will be once Simon M's patch to add .ByteString versions to unix is added in GHC 7.4.1. In particular the original problem darcs ran into was with getDirectoryContents in the directory package. That in turn uses the unix package on Posix systems and another code path based on Win32 on Windows (http://hackage.haskell.org/packages/archive/directory/1.1.0.1/doc/html/src/System-Directory.html#getDirectoryContents) So a couple of questions: (1) Does Win32 need similar additions? I can't spot any substantial changes to it for Max's PEP383, but I'm not sure if any lower-level library changes might have affected it. No - Win32 file paths cannot by definition contain invalid Unicode. The existing Win32 library is fine. (2) What's the recommended way of doing the equivalent of getDirectoryContents for RawFilePath? Do we also need to add raw versins to the directory package? getDirectoryContents :: RawFilePath - IO [RawFilePath] getDirectoryContents path = do bracket (Posix.openDirStream path) Posix.closeDirStream loop where loop dirp = do e - Posix.readDirStream dirp if B.null e then return [] else do es - loop dirp return (e:es) Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Why not allow empty record updates?
Trouble is, what type does this have?
f x = x {}
In your example the type annotations give the clue, but Haskell is mainly
designed for type annotations to be optional. We require at least one field so
we can figure out, from the field name, which type is being updated.
Yes, something could doubtless be done by following the type annotations, much
like higher-rank types, but it would be somewhat tricky to specify -- and the
whole feature of type-changing update is (as you know) a bit obscure and not
widely used, so it'd be adding complexity to an already-dark corner.
See also the (inconclusive) discussion here, which would involve abolishing the
entire type-changing update mechanism entirely!
http://hackage.haskell.org/trac/ghc/wiki/Records
Simon
| -Original Message-
| From: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-
| boun...@haskell.org] On Behalf Of Herbert Valerio Riedel
| Sent: 14 November 2011 14:31
| To: glasgow-haskell-users@haskell.org
| Subject: Why not allow empty record updates?
|
| Hello GHC HQ,
|
| I have been toying with phantom types in combination with polymorphic
| record-updates (which is a great feature imho), but stumbled over a
| limitation: GHC doesn't allow empty record updates (see toy example
| below), and I couldn't find a GHC language extension to relax this
| constraint. In the toy-example below it was easy to workaround by
| performing a dummy record update, but for more advanced uses workarounds
| becomes a bit more annoying.
|
| Is there a particular reason why empty record updates are disallowed by
| the Haskell Report? Would it be sensible, to allow empty record updates
| as a GHC language extension?
|
|
| hvr.
|
| ---
| -- empty types for tagging
| data Clean
| data Dirty
|
| data Foo a = Foo { fa :: Int, fb :: String }
| data Bar a = Bar { ba :: Int, bb :: Foo a }
|
| markDirtyFoo :: Foo Clean - Foo Dirty
| markDirtyFoo foo = foo { } -- rejected with Empty record update error
| markDirtyFoo foo = foo { fa = fa foo } -- workaround: dummy update
|
| markDirtyBar :: Bar Clean - Bar Dirty
| markDirtyBar bar = bar { bb = markDirtyFoo (bb bar) } -- works
|
|
|
|
|
|
| ___
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
