Hi, (and sorry for the delay)
On Sat, Jan 23, 2016 at 11:31:00PM +0100, Karel Gardas wrote:
> > Well, it's of course more elegant, but it would also mean that
> > everytime a new pledge promise will be introduced or an existing
> > one removed, this type has to be changed. I don't know how stable
> > the set of promises of pledge(2) are, but it feels like a change
> > like this should be deferred until after 5.9.
>
> I tend to agree, but on the other hand. Hmm, I guess you did this as
> you've been motivated to pledge some of haskell-based binaries you
> maintain packages for?
abieber@ talked a little bit about pledging xmonad, so i added the
binding.
I'll try to pledge darcs (which requires me to re-enable the testsuite
first). Maybe also alex, happy, cabal-install and ghc itself (but
not the interactive mode, because it dynamically loads your libraries
which can do *anything*)
> If so, then with your approach if some promise
> is removed and you use it in package binary, then you will not find
> this by building the package but only by running it (EINVAL return
> value from pledge). On the other hand if you do this more
> type-constrained way (like I non-perfectly try), then you will find
> this kind of issues just by compiling the package -- so wil it save
> your time or not? :-)
It depends on wether packages are closely up-to-date and you're
updating packages after updating the base system.
But another reason I won't to use just the string argument for the
promises is that I don't want to have to update ghc whenever the
set of valid promises change. So, *if* the set changes, anyone can
adopt it to any haskell program immediately, without waiting for
the changes to appear in the ghc port (or in ghc packages for people
just using packages).
Again, as said: this is just for now. I'm not against it for after
the 5.9 release.
Ciao,
Kili
