Re: behaviour change in getDirectoryContents in GHC 7.2?
On Thu, Nov 03, 2011 at 09:41:32AM +, Max Bolingbroke wrote: On 2 November 2011 21:46, Ganesh Sittampalam gan...@earth.li wrote: The workaround you propose seems a little complex and it might be a bit problematic that 100% roundtripping can't be guaranteed even once your fix is applied. I can understand this perspective, although the roundtripping as implemented will only fail in certain very obscure cases. Depending on the software one is writing, any failure, no matter how obscure, would not be acceptable. Think of a file browser, or backup software. So, yes, a non-destructive way of reading directories is important. At least one Linux distribution (I think Gentoo) actually has invalid pathnames in the filesystem in order to make sure that software that is part of the system will be able to handle them. For 'harchive' (which I am still gradually working on), I had to write my own version of readDirStream out of Posix that returns both the path and the inode number (FileID). Most filesystems on Linux are vastly faster if you 'stat' the entires of a directory in inode order rather than the order they were returned by readdir. In this sense, I'm not all that concerned if the regular getDirectoryContents isn't round trippable. David ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
I really like Simon PJ's proposal for records in Haskell. Some reasons for this are: - Anonymous record types. For example, an anonymous record type can easily hold ad-hoc keyword arguments. (Oh, just noticed that said in the document.) - To quote the document, We can express polymorphic update (a standard awkward case) quite nicely. (If I'm not mistaken (please tell me if so), OverloadedRecordFields proposal fails here.) - Nice syntax (in my opinion). Possible record member set syntax: let x.k = value in x Pros: - No new syntax - Least Surprise Cons: - Verbosity (especially such: (\ x - let x.k = value in x)) On 20/10/2011, Simon Peyton-Jones simo...@microsoft.com wrote: | Subject: Re: Records in Haskell | | I have added my proposal to the wiki.The only downsides to it that I can see are: Thanks to Barney for articulating a proposal for records in Haskell. Over various plane rides and ICFP chats I've worked out some more details. It's not as simple as I'd hoped. I'm underwater with stuff at the moment but I did find the time to capture a summary here http://hackage.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields Please do correct errors, suggest solutions, or explore variants. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Matthew Farkas-Dyck ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
problems with impredicativity
Hello,
this code is accepted by GHC 7.0.4:
{-# LANGUAGE ImpredicativeTypes #-}
polyId :: (forall a. a) - a
polyId x = x
polyIdMap :: [forall a. a] - [forall a. a]
polyIdMap xs = fmap polyId xs
However, this one isn’t:
{-# LANGUAGE ImpredicativeTypes #-}
polyId :: (forall a. Maybe a) - Maybe a
polyId x = x
polyIdMap :: [forall a. Maybe a] - [forall a. Maybe a]
polyIdMap xs = fmap polyId xs
Is there a way to make it accepted?
Best wishes,
Wolfgang
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problems with impredicativity
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 :: (forall a. Maybe a) - Maybe a
polyId x = x
polyIdMap :: [forall a. Maybe a] - [forall a. Maybe a]
polyIdMap xs = fmap polyId xs
Is there a way to make it accepted?
Yep, fix the type signature. There is no type you can substitute for
a in Maybe a that results in forall a. Maybe a. But GHC accepts
the same code with the following type signature, which should make
clear what I mean:
polyIdMap :: [forall a. Maybe a] - [Maybe (forall a. a)]
~d
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Records in Haskell
On 04/11/2011, Simon Peyton-Jones simo...@microsoft.com wrote: | I really like Simon PJ's proposal for records in Haskell. Some | reasons for this are: Which one? You'll need to give your readers an explicit link S Sorry. http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html -- Matthew Farkas-Dyck ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: problems with impredicativity
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 :: (forall a. Maybe a) - Maybe a
polyId x = x
polyIdMap :: [forall a. Maybe a] - [forall a. Maybe a]
polyIdMap xs = fmap polyId xs
Is there a way to make it accepted?
Yep, fix the type signature. There is no type you can substitute for
a in Maybe a that results in forall a. Maybe a. But GHC
accepts the same code with the following type signature, which
should make clear what I mean:
polyIdMap :: [forall a. Maybe a] - [Maybe (forall a. a)]
It occurred to me that you may have been attempting to do something
else, so perhaps I fired off my first reply too quickly. Another
interpretation is that the type of polyIdMap is correct, but the type
of polyId isn't.
The first thing to observe is that, ideally, the following two types
would mean slightly different things:
polyId :: forall b. (forall a. Maybe a) - Maybe b
polyId :: (forall a. Maybe a) - (forall b. Maybe b)
The first means: first, choose a monomorphic type, then specialize the
first argument to that monomorphic type. The second means: take a
polymorphic value, then return it, delaying the choice of a
monomorphic type until later. (And, again ideally, any unbound
variables would implicitly put their forall at the top level, as in
the first signature above.) If this distinction existed, then your
polyIdMap would be fully compatible with a polyId having the second
type signature.
Unfortunately, in GHC, these two types do not mean different things:
foralls on the result side of an arrow are silently floated to the
top level, even if you explicitly choose to put them later in your
type annotation. The only way I know of to prevent this is to make a
newtype barrier. For example, the following works:
newtype PolyMaybe = PolyMaybe (forall a. Maybe a)
polyId :: PolyMaybe - PolyMaybe
polyId x = x
polyIdMap :: [PolyMaybe] - [PolyMaybe]
polyIdMap xs = fmap polyId xs
Then, later, you can unwrap the PolyMaybe -- but only when you're
ready to turn it into a monomorphic Maybe! (Note that none of these
things is using ImpredicativeTypes, which is what made me jump to my
first, probably mistaken impression of what you were trying to do.
Rank2Types is enough for the above to compile.)
~d
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
