I must say though that I'd rather prefer Adres solution because his
init
init :: (forall a. Inotify a - IO b) - IO b
ensures that Inotify does not leak, and so can be disposed of at the
end. So his init enforces the region discipline and could, after a
It's probably not easy to do
* o...@okmij.org o...@okmij.org [2013-05-11 05:26:55-]
I must say though that I'd rather prefer Adres solution because his
init
init :: (forall a. Inotify a - IO b) - IO b
ensures that Inotify does not leak, and so can be disposed of at the
end. So his init enforces the region
I've been working on a new Haskell interface to the linux kernel's inotify
system, which allows applications to subscribe to and be notified of
filesystem events. An application first issues a system call that returns
a file descriptor that notification events can be read from, and then
issues
Hi.
So the natural question here is if we can employ the type system to enforce
this correspondence. Phantom types immediately come to mind, as this
problem is almost the same as ensuring that STRefs are only ever used in a
single ST computation. The twist is that the inotify interface
Maybe I understand the problem incorrectly, but it seems to me that you're
overcomplicating things.
With that kind of interface you don't actually need existential types. Or
phantom types. You can just keep Inotify inside the Watch, like this:
import Prelude hiding (init, map)
import
On Fri, May 10, 2013 at 9:00 AM, Andres Löh and...@well-typed.com wrote:
This twist is very simple to deal with if you have real existential
types,
with the relevant part of the interface looking approximately like
init :: exists a. IO (Inotify a)
addWatch :: Inotify a - FilePath - IO
On Fri, May 10, 2013 at 9:04 AM, MigMit miguelim...@yandex.ru wrote:
With that kind of interface you don't actually need existential types. Or
phantom types. You can just keep Inotify inside the Watch, like this:
Right, that is an alternative solution, but phantom types are a relatively
I'm not sure if it would work for your case, but have you considered using
DataKinds instead of phantom types? At least, it seems like it would be
cheap to try out.
http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/kind-polymorphism-and-promotion.html
On Fri, May 10, 2013 at 12:52 PM,
On Fri, May 10, 2013 at 5:49 PM, Alexander Solla alex.so...@gmail.comwrote:
I'm not sure if it would work for your case, but have you considered using
DataKinds instead of phantom types? At least, it seems like it would be
cheap to try out.
On Fri, May 10, 2013 at 3:31 PM, Leon Smith leon.p.sm...@gmail.com wrote:
On Fri, May 10, 2013 at 5:49 PM, Alexander Solla alex.so...@gmail.comwrote:
I'm not sure if it would work for your case, but have you considered
using DataKinds instead of phantom types? At least, it seems like it
A value has an indefinite extent if it's lifetime is independent of any
block of code or related program structure, think malloc/free or new/gc.
A value has a dynamic extent if is lifetime is statically determined
relative to the dynamic execution of the program (e.g. a stack variable):
in this
But Haskell (and GHC) have existential types, and your prototype code
works with GHC after a couple of trivial changes:
main = do
W nd0 - init
wd0 - addWatch nd0 foo
wd1 - addWatch nd0 bar
W nd1 - init
wd3 - addWatch nd1 baz
printInotifyDesc nd0
printInotifyDesc nd1
12 matches
Mail list logo
