from:"Ganesh Sittampalam"

Hi,

As mentioned in the committee's annual report
(http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our
attempt to join SFC has stalled because they don't have the capacity to
accept new projects at the moment.

We therefore applied to join SPI (http://www.spi-inc.org/), and they
have now offered us associated project status
(http://www.spi-inc.org/projects/associated-project-howto/).

We intend to accept this offer, but are taking this final opportunity to
seek feedback from the community before doing so.

SPI is very like SFC in what it does and how it operates, so we don't
expect this to make any substantial differences to the FAQ quoted below.

Regards,

Ganesh
on behalf of the haskell.org committee

On 10/05/2011 23:44, Don Stewart wrote:
 Hello everyone.
 
 The haskell.org committee[1], in the interest of the long-term stability
 of the open source Haskell community infrastructure, has decided to
 incorporate haskell.org as a legal entity. This email outlines our
 recommendation, and seeks input from the community on this decision.
 
 The committee's proposal is that haskell.org incorporate as an entity
 under the Software Freedom Conservancy umbrella organization (the same group
 that Darcs joined recently):
 
 http://sfconservancy.org/
 
 If we proceed with this move, haskell.org will be a legal entity, and
 registered as a non-profit, allowing us to more directly accept
 (US tax-deductible) donations, and to invest in assets that benefit the
 Haskell open source community.
 
 We welcome your feedback on the proposal attached below.
 
 -- Don Stewart (on behalf of the Haskell.org committee)
 
 
 
 
 
 = A proposal for the incorporation of Haskell.org =
 
 In recent years, haskell.org has started to receive assets, e.g. money from
 Google Summer Of Code, donations for Hackathons, and a Sparc machine for use 
 in
 GHC development. We have also started spending this money: in particular, on
 hosting haskell.org itself. There is also interest in running fundraising
 drives for specific things such as Hackathon sponsorship and hosting fees.
 
 However, haskell.org doesn't currently exist as a legal entity, meaning that
 these assets have had to be held on our behalf by other entities, such as
 Galois and various universities. This leads to tricky situations, with no-one
 being sure who should decide how the haskell.org assets can be used.
 
 To solve these problems, we propose that haskell.org applies to become a 
 member
 project of the Software Freedom Conservancy (SFC)
 http://conservancy.softwarefreedom.org/. The SFC is a non-profit 
 organization
 that provides free financial and administrative services to open source
 projects. Additionally, it has 501(c)(3) status, meaning donations from the US
 are tax-deductible. The SFC would hold haskell.org's money and other assets,
 and would be able to accept donations on behalf of haskell.org.
 
 The haskell.org committee, as described here [2], will make decisions on
 spending assets and other decisions related to governing the non-profit.
 
 
 Before proceeding, we are inviting input from the community in the form
 of specific objections or queries regarding the plan.
 
 We've tried to answer some of the most likely questions:
 
 Q: Does this mean that my Haskell project must now be covered by a
  copyleft licence such as GPL?
 A: No, but Haskell projects using haskell.org resource should use an
 Open Source licence
  http://www.opensource.org/licenses/alphabetical.
 
 Q: Will it still be possible to use community.h.o to host
  non-open-source material, such as academic papers?
 A: An overall minority of such content, as is the current situation, is
 not a problem.
 
 Q: Will it still be possible to have job ads on the haskell.org mailing
 lists and website?
 A: Yes.
 
 Q: Will this affect our ability to host the Haskell Symposium
 http://www.haskell.org/haskell-symposium/  and Industrial Haskell
 Grouphttp://industry.haskell.org/  webpages within haskell.org?
 A: No.
 
 Q: What will be the relationship between haskell.org and other
 organizations such as the Haskell Symposium and Industrial Haskell
 Group?
 A: Those organisations will continue to exist as separate entities.
 
 Q: If an umbrella non-profit organisation The Haskell Foundation was
 created, would haskell.org be able to join it?
 A: Yes. It's likely that in such a scenario, the Haskell Foundation
 would become the owner of the haskell.org domain name, with the cost
 divided between the members. The entity that is part of the SFC would
 be renamed community.haskell.org in order to avoid confusion.
 
 [1]: http://www.haskell.org/haskellwiki/Haskell.org_committee
 [2]: http://www.haskell.org/haskellwiki/Haskell.org_committee#Operation
 
 ___
 Haskell mailing list
 hask...@haskell.org

Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org

BTW as with the Don's original message about incorporating, I
distributed this widely to increase awareness, but please restrict any
feedback to haskell-cafe@ and committee@.

Sorry for the noise!

Ganesh

On 16/12/2011 09:08, Ganesh Sittampalam wrote:
 Hi,
 
 As mentioned in the committee's annual report
 (http://haskellorg.wordpress.com/2011/10/26/first-year-report/), our
 attempt to join SFC has stalled because they don't have the capacity to
 accept new projects at the moment.
 
 We therefore applied to join SPI (http://www.spi-inc.org/), and they
 have now offered us associated project status
 (http://www.spi-inc.org/projects/associated-project-howto/).
 
 We intend to accept this offer, but are taking this final opportunity to
 seek feedback from the community before doing so.
 
 SPI is very like SFC in what it does and how it operates, so we don't
 expect this to make any substantial differences to the FAQ quoted below.
 
 Regards,
 
 Ganesh
 on behalf of the haskell.org committee
 
 On 10/05/2011 23:44, Don Stewart wrote:
 Hello everyone.

 The haskell.org committee[1], in the interest of the long-term stability
 of the open source Haskell community infrastructure, has decided to
 incorporate haskell.org as a legal entity. This email outlines our
 recommendation, and seeks input from the community on this decision.

 The committee's proposal is that haskell.org incorporate as an entity
 under the Software Freedom Conservancy umbrella organization (the same group
 that Darcs joined recently):

 http://sfconservancy.org/

 If we proceed with this move, haskell.org will be a legal entity, and
 registered as a non-profit, allowing us to more directly accept
 (US tax-deductible) donations, and to invest in assets that benefit the
 Haskell open source community.

 We welcome your feedback on the proposal attached below.

 -- Don Stewart (on behalf of the Haskell.org committee)



 

 = A proposal for the incorporation of Haskell.org =

 In recent years, haskell.org has started to receive assets, e.g. money from
 Google Summer Of Code, donations for Hackathons, and a Sparc machine for use 
 in
 GHC development. We have also started spending this money: in particular, on
 hosting haskell.org itself. There is also interest in running fundraising
 drives for specific things such as Hackathon sponsorship and hosting fees.

 However, haskell.org doesn't currently exist as a legal entity, meaning that
 these assets have had to be held on our behalf by other entities, such as
 Galois and various universities. This leads to tricky situations, with no-one
 being sure who should decide how the haskell.org assets can be used.

 To solve these problems, we propose that haskell.org applies to become a 
 member
 project of the Software Freedom Conservancy (SFC)
 http://conservancy.softwarefreedom.org/. The SFC is a non-profit 
 organization
 that provides free financial and administrative services to open source
 projects. Additionally, it has 501(c)(3) status, meaning donations from the 
 US
 are tax-deductible. The SFC would hold haskell.org's money and other assets,
 and would be able to accept donations on behalf of haskell.org.

 The haskell.org committee, as described here [2], will make decisions on
 spending assets and other decisions related to governing the non-profit.


 Before proceeding, we are inviting input from the community in the form
 of specific objections or queries regarding the plan.

 We've tried to answer some of the most likely questions:

 Q: Does this mean that my Haskell project must now be covered by a
  copyleft licence such as GPL?
 A: No, but Haskell projects using haskell.org resource should use an
 Open Source licence
  http://www.opensource.org/licenses/alphabetical.

 Q: Will it still be possible to use community.h.o to host
  non-open-source material, such as academic papers?
 A: An overall minority of such content, as is the current situation, is
 not a problem.

 Q: Will it still be possible to have job ads on the haskell.org mailing
 lists and website?
 A: Yes.

 Q: Will this affect our ability to host the Haskell Symposium
 http://www.haskell.org/haskell-symposium/  and Industrial Haskell
 Grouphttp://industry.haskell.org/  webpages within haskell.org?
 A: No.

 Q: What will be the relationship between haskell.org and other
 organizations such as the Haskell Symposium and Industrial Haskell
 Group?
 A: Those organisations will continue to exist as separate entities.

 Q: If an umbrella non-profit organisation The Haskell Foundation was
 created, would haskell.org be able to join it?
 A: Yes. It's likely that in such a scenario, the Haskell Foundation
 would become the owner of the haskell.org domain name, with the cost
 divided between the members. The entity that is part of the SFC would
 be renamed community.haskell.org in order to avoid

Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org

On 16/12/2011 10:59, Giovanni Tirloni wrote:
 On Fri, Dec 16, 2011 at 7:08 AM, Ganesh Sittampalam gan...@earth.li
 mailto:gan...@earth.li wrote:
 
  Q: If an umbrella non-profit organisation The Haskell Foundation was
  created, would haskell.org http://haskell.org be able to
 join it?
  A: Yes. It's likely that in such a scenario, the Haskell Foundation
  would become the owner of the haskell.org http://haskell.org
 domain name, with the cost
  divided between the members. The entity that is part of the
 SFC would
  be renamed community.haskell.org
 http://community.haskell.org in order to avoid confusion.
 
 
 Would it be a too ambitious goal to create the Haskell Foundation at
 this moment?

It would be a lot of administrative effort - managing accounts, tax
filings, etc. While it would give us more control, I don't think the
benefits would be very significant.

So in my view for now it's best not to go it alone.

Cheers,

Ganesh

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] [Haskell] Proposal to incorporate Haskell.org

On 16/12/2011 13:21, Thomas Schilling wrote:
On 16 December 2011 11:10, Ganesh Sittampalam gan...@earth.li wrote:
On 16/12/2011 10:59, Giovanni Tirloni wrote:

Would it be a too ambitious goal to create the Haskell Foundation at
this moment?

It would be a lot of administrative effort - managing accounts, tax
filings, etc. While it would give us more control, I don't think the
benefits would be very significant.

So in my view for now it's best not to go it alone.

I agree. If at some point we feel that having a Haskell Foundation
would be desirable (despite the additional overheads) there shouldn't
be anything stopping us from doing so. Are there any drawbacks in
joining such an organisation? How do they finance their overheads?
Would a donation to haskell.org include a fee to SPI? I couldn't find
any information on their website.

Yes - 5% goes to SPI to cover their overheads. It's detailed in
http://www.spi-inc.org/projects/associated-project-howto/ but not on
their donations page at http://www.spi-inc.org/donations/.

5% seems reasonable to me and in line with what similar donation
aggregators charge, for example the Charities Aid Foundation in the UK
charges 4%:
https://www.cafonline.org/my-personal-giving/plan-your-giving/individual-charity-account.aspx

In effect we've been getting the admin for free from Galois up till now,
but it's been getting too troublesome for them.

Cheers,

Ganesh

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Exception for NaN

2011-05-12 Thread Ganesh Sittampalam

On 12/05/2011 19:41, Nick Bowler wrote:
 On 2011-05-12 21:14 +0400, Grigory Sarnitskiy wrote:

 I don't want NaN to propagate, it is merely stupid, it should be terminated.
 
 NaN propagation is not stupid.  Frequently, components of a computation
 that end up being NaN turn out to be irrelevant at a later point, in
 which case the NaNs can be discarded.

Unfortunately, if a NaN reaches a comparison operation, it can lead to
an end result that doesn't contain NaNs, but was still influenced by one.

Ganesh

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal to incorporate Haskell.org

2011-05-11 Thread Ganesh Sittampalam

On 11/05/2011 06:08, Antoine Latter wrote:

 Which assets would move over to the SFC? The domain name? Any sort of
 hosting could then be leased by the SFC to whomever is doing this now.
 I'm a bit fuzzy here.

Everything but the domain name, so that the Haskell community as a whole
can retain the ability to do other things with it in future that aren't
subject to licensing constraints. Current cash and hardware would move over.

Ganesh
(haskell.org committee member)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Proposal to incorporate Haskell.org

2011-05-11 Thread Ganesh Sittampalam

On 11/05/2011 10:33, Yitzchak Gale wrote:
 Don Stewart wrote:
 The haskell.org committee... has decided to
 incorporate haskell.org as a legal entity. This email outlines our
 recommendation, and seeks input from the community on this decision.
 
 Thanks, good news! And thanks for posting to multiple
 lists for maximum public notification to the community.
 
 Can the committee now designate a single list for further discussion
 please?

Sorry about the noise. I think haskell-cafe is the best choice for
further discussion.

Please, everyone send further followups to any message in this thread to
just haskell-cafe@haskell.org and commit...@haskell.org, or just to
commit...@haskell.org if you want to respond privately.

Ganesh
(haskell.org committee member)

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] A small Darcs anomoly

2011-04-27 Thread Ganesh Sittampalam

On 26/04/2011 12:17, Malcolm Wallace wrote:
 
 On 25 Apr 2011, at 11:13, Andrew Coppin wrote:
 
 On 24/04/2011 06:33 PM, Jason Dagit wrote:

 This is because of a deliberate choice that was made by David Roundy.
 In darcs, you never have multiple branches within a single darcs
 repository directory tree.

 Yes, this seems clear. I'm just wondering whether or not it's the best 
 design choice.
 
 It seems to me to be a considerable insight.  Branches and repositories are 
 the same thing.  There is no need for two separate concepts.  The main reason 
 other VCSes have two concepts is because one of them is often more 
 efficiently implemented (internally) than the other.  But that's silly - how 
 much better to abstract over the mental clutter, and let the implementation 
 decide how its internals look!
 
 So in darcs, two repositories on the same machine share the same files (like 
 a branch), but if they are on different machines, they have separate copies 
 of the files.  The difference is a detail that you really don't need to know 
 or care about.
 
 It does mean that you duplicate information. You have [nearly] the same set 
 of patches stored twice,
 
 No, if on the same machine, the patches only appear once, it is just the 
 index that duplicates some information (I think).  In fact just as if it were 
 a branch in another VCS.

Unfortunately, I don't think this is quite true, because being able to
switch between multiple branches in the same working directory means you
can reuse build products when switching branches. Depending on how
radical the branch shift is, this can be a substantial win, and it's the
main reason that darcs might in future implement in-repo branching of
some form.

Ganesh

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Type families again

2010-12-03 Thread Ganesh Sittampalam


On Thu, 2 Dec 2010, Robert Greayer wrote:


On Thu, Dec 2, 2010 at 4:39 PM, Antoine Latter aslat...@gmail.com wrote:

On Thu, Dec 2, 2010 at 3:29 PM, Andrew Coppin
andrewcop...@btinternet.com wrote:


What we /can't/ do is define a polymorphic map function. One might try to do
something like

 class Functor f where
   type Element f :: *
   fmap :: (Element f2 ~ y) = (x - y) - f - f2

 instance Functor [x] where
   type Element [x] = x
   fmap = map

However, this fails. Put simply, the type for fmap fails to specify that f
and f2 must be /the same type of thing/, just with different element types.

The trouble is, after spending quite a bit of brainpower, I literally cannot
think of a way of writing such a constraint. Does anybody have any
suggestions?


Does this do what you need?

http://hackage.haskell.org/packages/archive/rmonad/0.6/doc/html/Control-RMonad.html#t:RFunctor

Antoine



I think this doesn't handle the ByteString case (wrong kind).  Here's
another mostly unsatisfactory (injectivity issues) solution that may
possibly not even work though it does compile:


I spent a while looking at this a couple of months ago after a similar 
question. What I came up with is below; I haven't got as far as 
deciding whether or how to incorporate this into rmonad. Also, the Const 
type actually already exists in Control.Applicative.


Cheers,

Ganesh

{-# LANGUAGE GADTs, TypeFamilies, MultiParamTypeClasses, FlexibleInstances, 
ScopedTypeVariables, RankNTypes #-}

module Control.RMonad.Wibble where

import Control.RMonad
import Data.ByteString (ByteString)
import qualified Data.ByteString as BS
import qualified Data.ByteString.Char8 as BSC
import Data.Suitable
import GHC.Word (Word8)

-- Part I

-- a little warmup: ByteStrings

-- We have two choices for BSWrapper. Either make
-- it a GADT, which means we can leave out the match on the
-- argument constraints below, or make it a H98 phantom.
-- The second option seems cleaner and more symmetric.
-- It also means we can us newtype to avoid runtime overhead.

-- data BSWrapper a where
--   BSWrapper :: ByteString - BSWrapper Word8

newtype BSWrapper a = BSWrapper ByteString

data instance Constraints BSWrapper a = (a ~ Word8) = BSConstraints

instance Suitable BSWrapper Word8 where
  constraints = BSConstraints

instance RFunctor BSWrapper where
  -- We could also use withResConstraints by rearranging the arguments to mymap 
so Constraints is last
  fmap = mymap constraints constraints
where mymap :: forall x y . Constraints BSWrapper x - Constraints BSWrapper y - (x 
- y) - BSWrapper x - BSWrapper y
  mymap BSConstraints BSConstraints f (BSWrapper x) = BSWrapper (BS.map 
f x)

-- Part II

-- OK, now let's generalise:

-- Having a class here rather than a plain type family isn't really necessary,
-- but it feels natural
class SingletonContainer c where
   type ContainedType c :: *

-- data SingletonWrapper c a where
--   SingletonWrapper :: SingletonContainer c = c - SingletonWrapper c 
(ContainedType c)

-- This is just a generic Const type. Is there a standard one somewhere else?
newtype SingletonWrapper c a = SingletonWrapper c

data instance Constraints (SingletonWrapper c) a = (a ~ ContainedType c) = 
SingletonConstraints

-- important to use the type equality constraint here instead of inlining it
-- on the RHS, as otherwise instance resolution would get stuck
instance (a ~ ContainedType c) = Suitable (SingletonWrapper c) a where
  constraints = SingletonConstraints

class SingletonContainer c = Mappable c where
   lmap :: (ContainedType c - ContainedType c) - c - c

instance Mappable c = RFunctor (SingletonWrapper c) where
  fmap = mymap constraints constraints
where mymap :: forall x y
 . Constraints (SingletonWrapper c) x
- Constraints (SingletonWrapper c) y
- (x - y)
- SingletonWrapper c x
- SingletonWrapper c y
  mymap SingletonConstraints SingletonConstraints f (SingletonWrapper 
x) = SingletonWrapper (lmap f x)


-- so, why is Word8 the blessed instance? Why not Char (from 
Data.ByteString.Char8)?
instance SingletonContainer ByteString where
   type ContainedType ByteString = Word8


-- Part III

-- and finally, let's try to generalise the Singleton concept:

-- using the Const concept again...
newtype Const a b = Const a

instance Show a = Show (Const a b) where
  show (Const x) = show x

data instance Constraints (Const ByteString) a =
   (a ~ Word8) = BSConstraintsWord8
 | (a ~ Char) = BSConstraintsChar

instance Suitable (Const ByteString) Word8 where
   constraints = BSConstraintsWord8

instance Suitable (Const ByteString) Char where
   constraints = BSConstraintsChar

instance RFunctor (Const ByteString) where
  fmap = mymap constraints constraints
where mymap :: forall x y
 . Constraints (Const ByteString) x
- Constraints (Const ByteString) y
- (x - y) - Const ByteString x - Const

[Haskell-cafe] HTTP 4000.1.0 release

2010-11-09 Thread Ganesh Sittampalam


Hi,

I've just released HTTP 4000.1.0 to hackage:

 - Fixed a bug that caused infinite loops for some URLs on some platforms 
(whether the URL was a trigger is probably related to the size of the 
returned data, and the affected platforms. Based on a patch by Daniel 
Wagner.


   - This is technically a breaking change (and hence there is an API 
version bump) as the fix introduces a new member to the HStream class 
which can be used to define a new payload type instead of 
String/ByteString, but I scanned hackage and noone actually seems to be 
doing that.


 - Applied a patch by Antoine Latter to fix a bug in the handling of 
301 and 307 response codes. Here's his description of the change:


***
The Network.Browser module is a convenience layer over the
Network.Http modules offering many of the niceties one would expect in
a web-browser - cookies, user authentication, and transparent handling
of redirects.

When using Network.Browser, previously (since version 4000.0.8) a
redirect response code of 301 or 307 from the server would force the
redirected request to be sent as a GET, even if the original request
was of some other HTTP method. This behavior is only appropriate for a
response code of 302 or 303 and has been fixed.
***

The upstream repo is now on github: https://github.com/haskell/HTTP, 
though I may well switch back to darcs if I remain maintainer for long.


I'd like to emphasise that I have no particular desire to maintain HTTP 
and if anyone else would like to take over they would be very welcome!


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Bug in HTTP (bad internal error handling)

2010-11-03 Thread Ganesh Sittampalam


On Wed, 3 Nov 2010, Simon Marlow wrote:


On 29/10/2010 23:24, Ganesh Sittampalam wrote:


4000.0.10 should fix the reported issue with fail and Either, and bumps
the base dep to build with GHC 7.0


That's great.  Any chance you could also look at this one, which appears to 
be a pretty serious bug for some people, and has a patch?


http://hackage.haskell.org/trac/ghc/ticket/4251


Sure, I'll do it this weekend. Given that the HTTP test suite is pretty 
minimal, we'll just have to hope for no unintended side-effects 
though (which also applies to the previous change, of course).


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Bug in HTTP (bad internal error handling)

2010-10-29 Thread Ganesh Sittampalam


On Fri, 22 Oct 2010, Sigbjorn Finne wrote:


On Fri, Oct 22, 2010 at 9:35 AM, Sittampalam, Ganesh 
ganesh.sittampa...@credit-suisse.com wrote:


libraries@, what's the right way to proceed? Can I make a Debian-style
non-maintainer upload with minimal changes to fix urgent issues like
these?



I'd be much obliged if you could, and I do apologise for leaving all of this
just hanging.


I've just done this. Thanks for the blessing.

4000.0.10 should fix the reported issue with fail and Either, and bumps 
the base dep to build with GHC 7.0



No time available for Haskell projects these days unfortunately, Opera
engine development taking up most of my waking hours. Getting someone to
take over HTTP would be best, or maybe rewrite it altogether..it is not the
prettiest thing around :)


I'm not particularly keen on taking over maintainership, but I guess if 
noone else wants it I could take it over and do at least minimal updates 
like this.


Any other volunteers?

Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Bug in HTTP (bad internal error handling)

2010-10-24 Thread Ganesh Sittampalam


On Sun, 24 Oct 2010, Bit Connor wrote:


On Sat, Oct 23, 2010 at 8:49 PM, Ganesh Sittampalam gan...@earth.li wrote:


I'm just looking at fixing this so I can make an upload as discussed with
Sigbjorn. I guess the best thing to do is to make all the calls to fail into
something more explicit.


Yep. Ideally, simpleHTTP and its friends should never throw an IO
exception (and should certainly never call prelude's error, as
happens now). Network errors and other errors should be reported by
returning an appropriate ConnError Result:


I'm not going to try to audit for that exhaustively right now, but I've 
changed all the calls to fail that were broken by the Either change, so 
hopefully we should be back where we started.


I've put a repo up with the changes and a base dependency bump at 
http://urchin.earth.li/git/HTTP - could you (and anyone else interested) 
give it a try? I haven't done anything but the most minimal testing and in 
particular I haven't made any effort to reproduce your specific problem.


I plan to upload this as HTTP-4000.0.10 in the next few days.

Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Bug in HTTP (bad internal error handling)

2010-10-23 Thread Ganesh Sittampalam


Hi Bit,

On Thu, 21 Oct 2010, Bit Connor wrote:


On Sat, Oct 16, 2010 at 10:29 AM, Claus Reinke claus.rei...@talk21.com wrote:

After it catches this error, the function returns (line 376):

return (fail (show e))

The fail is running in the Either monad (The Result type = Either).
This calls the default Monad implementation of fail, which is just a
call to plain old error. This basically causes the entire program to
crash.



Actually, it appears that simpleHTTP isn't actually supposed to throw
an IOException, and it is instead supposed to return a ConnError
result. So the real fix is to fix the code to make this happen. But


Sounds like a victim of
  http://hackage.haskell.org/trac/ghc/ticket/4159

For mtl clients, 'fail' for 'Either' used to call 'Left'. That was
changed, though the ticket does not indicate the library
versions affected.


This looks like the problem. Any idea how to get the HTTP package
fixed? I could try making a patch myself, but I would prefer hearing
from the HTTP maintainer first, who doesn't seem to be around.


I'm just looking at fixing this so I can make an upload as discussed with 
Sigbjorn. I guess the best thing to do is to make all the calls to fail 
into something more explicit.


BTW, can you confirm that you were using GHC 7.0 (or 6.13) when this went 
wrong?


Cheers,

Ganesh___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: explicit big lambdas

2010-03-19 Thread Ganesh Sittampalam


On Fri, 19 Mar 2010, o...@okmij.org wrote:



Paul Brauner wrote:

is there a way in some haskell extension to explicit (system F's) big
lambdas and (term Type) applications in order to help type inference?


Actually, yes: newtype constructor introductions may act as a big
lambda, with constructor elimination acting as type applications:
http://okmij.org/ftp/Haskell/types.html#some-impredicativity


Newtypes are also handy for turning type functions (defined by type
families) into real lambdas. For example, given the following code


Isn't this the equivalent of explicitly naming a function rather than
making an anonymous one with lambda?

Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: ANN: hakyll-0.1

2009-12-08 Thread Ganesh Sittampalam


On Tue, 8 Dec 2009, Tom Tobin wrote:


On Tue, Dec 8, 2009 at 3:30 PM, Ben Franksen ben.frank...@online.de wrote:

Ketil Malde wrote:

Your contributions could still be licensed under a different license
(e.g. BSD), as long as the licensing doesn't prevent somebody else to
pick it up and relicense it under GPL.

At least, that's how I understand things.


Right. So hakyll is absolutely fine with a BSD3 license, AFAICS.


Seriously, no, this is *totally* wrong reading of the GPL, probably
fostered by a misunderstanding of the term GPL-compatible license.
GPL-compatible means the compatibly-licensed work can be incorporated
into the GPL'd work (the whole of which is GPL'd), *not the other way
around*.  If you are forming a derivative work based on the GPL'd
work, and thus you have to release that derivative work under the GPL.


The combination of haykll and pandoc clearly must be GPL. I don't think it 
automatically follows from that that hakyll taken alone must be GPL. One 
might argue that the hakyll itself must be a derivative work as it builds 
on pandoc, but equally there may well be at least some pieces of hakyll 
that have independent uses; in addition someone might write a 
API-compatible replacement for pandoc that was BSD3. I would therefore 
argue for clearly marking the hakyll source as BSD3, so long as there is 
some way to clearly signal that anything compiled from it will necessarily 
be GPL.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] call for help: FOSDEM devroom

2009-11-08 Thread Ganesh Sittampalam


Hi,

I'm thinking of trying to get a devroom for haskell.org at the next 
FOSDEM, which is Saturday-Sunday February 6th-7th 2010 in Brussels: 
http://www.fosdem.org/2010/call-developer-rooms


The idea would be to try to introduce Haskell to people at FOSDEM who were 
interested, and thus help build our ties with We'd try to have a few 
introductory talks about Haskell, and some demos etc. It would probably 
also make sense to talk about/demo darcs at the same time.


Apparently there's a lot of demand so it's a bit of a long shot, and I 
expect we'd only get one day, which is probably all we'd need.


To make this work, we'll need several reasonably experienced Haskellers to 
turn up to help out with the talks, demos and talking to people in 
general. I've got a couple of people interested already but need more.


So, please could you let me know, preferably within the next week, whether 
you would be interested in coming along and helping. You can email me 
directly or on-list as you prefer.


The deadline for actually making the application for the devroom is 22nd 
November.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Darcs and NFS Resolution

2009-09-12 Thread Ganesh Sittampalam


On Sat, 12 Sep 2009, Brandon S. Allbery KF8NH wrote:


On Sep 12, 2009, at 11:22 , Trent W. Buck wrote:

Jason Dagit da...@codersbase.com writes:

which ensures that when the operating system is not WIN32, that
renaming of files will be performed by the OS shell.


I'm also puzzled as to why this works -- surely mv(1) assumes POSIX
semantics, too?  I would be interested in seeing the exact error
transcript, preferably as an issue on bugs.d.n.  I'm not sure the
problem has been diagnosed correctly.


In order to handle the case where you're moving across filesystems, mv(1) 
gracefully degrades to cp + rm.  rename(2) does not.  This also happens to 
work around compatibility issues with native CIFS (and possibly older HP/UX, 
not that anyone likely cares).


I don't think that darcs is ever likely to want to do a move across 
filesystems - unless someone has actually put a mount point in the middle 
of their darcs repo (and perhaps not even then for the metadata operations 
such as the one that was failing here, as I think those are all inside a 
single directory).


Darcs already has a WIN32-specific workaround for renaming going wrong 
when the new file exists, and my initial guess was that was what was going 
wrong here. The workaround just tries to remove the new file and retries 
the rename. The original poster doesn't make clear whether he tried my 
suggested fix enabling that workaround unconditionally before resorting to 
shelling out.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Darcs 2.3 and NFS

2009-09-09 Thread Ganesh Sittampalam


On Wed, 9 Sep 2009, Lewis-Sandy, Darrell wrote:

Windows Vista, Ubuntu 9.04 32-bit, Ubuntu 64 bit, etc).  I have a 
windows file share that is accessible to all the machines, and has been 
permanently mounted as a CIFS share on the Linux machines.


I have built darcs 2.3 on the Ubuntu 9.04 (Jaunty) 32 bit box and am 
able to execute darcs commands against any local folders, but am 
consistently getting an error message when I try to push or put to the 
NFS:


darcs: ./_darcs/tentative_pristine-0:rename: already exists (File 
exists)


At a guess, Windows filesystem semantics are causing trouble here and 
darcs doesn't know to work around them. There's some code in 
src/Workaround.hs that sets up a custom renameFile function on Windows - 
try changing that so that it's unconditionally enabled?


Following up on darcs-users would be best though you might need to 
subscribe.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Darcs - dependencies between repositories (aka forests)

2009-03-29 Thread Ganesh Sittampalam


On Sun, 29 Mar 2009, Peter Verswyvelen wrote:


Module A requires B. When a new developer wants to get the source code, he
does a darcs get server://program/A, which gives him only the latest
version of A. So he manually needs to do darcs get server://program/B
(that B is required is usually discovered after a compilation error, talking
to other developers to find out what the dependencies are, or by reading the
cabal file). Furthermore it is unclear which version of A required which
version of B (so you can't really roll back to old versions).

Now assume you don't have 2 modules but dozens...

To me, any version control system should be able to track dependencies
between repositories. Something similar like Cabal's dependency system.

So my question is really, how do you solve the dependency tracking between
several Darcs repositories?


There's an (unimplemented) proposal by David Roundy for darcs sub-repos 
that would solve this problem: you have a darcs patch type 
that means depend on this patch from this other darcs repo which will be 
checked out in a given subdirectory. I think that solves precisely the 
problem you describe, and I think it should be implemented :-)


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] manipulating predicate formulae

2008-12-04 Thread Ganesh Sittampalam


Hi,

That sounds like it might be quite useful. What I'm doing is generating 
some predicates that involve addition/subtraction/comparison of integers 
and concatenation/comparison of lists of some abstract thing, and then 
trying to simplify them. An example would be simplifying


\exists p_before . \exists p_after . \exists q_before . \exists q_after . 
\exists as . \exists bs . \exists cs . (length p_before == p_pos  length 
q_before == q_pos  (p_before == as  q_after == cs)  p_before ++ 
p_new ++ p_after == as ++ p_new ++ bs ++ q_old ++ cs  as ++ p_new ++ bs 
++ q_old ++ cs == q_before ++ q_old ++ q_after)


into

q_pos - (p_pos + length p_new) = 0

which uses some properties of length as well as some arithmetic. I don't 
expect this all to be done magically for me, but I'd like as much help as 
possible - at the moment I've been growing my own library of predicate 
transformations but it's all a bit ad-hoc.


If I could look at your code I'd be very interested.

Cheers,

Ganesh

On Thu, 4 Dec 2008, Immanuel Normann wrote:


Hi Ganesh,

manipulating predicate formulae was a central part of my PhD research. I
implemented some normalization and standarcization functions in Haskell -
inspired by term rewriting (like normalization to Boolean ring
representation) as well as (as far as I know) novell ideas (standardization
of quantified formulae w.r.t associativity and commutativity).
If you are interested in that stuff I am pleased to provide you with more
information. May be you can describe in more detail what you are looking
for.

Best,
Immanuel

2008/11/30 Ganesh Sittampalam [EMAIL PROTECTED]


Hi,

Are there any Haskell libraries around for manipulating predicate formulae?
I had a look on hackage but couldn't spot anything.

I am generating complex expressions that I'd like some programmatic help in
simplifying.

Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] manipulating predicate formulae

2008-12-04 Thread Ganesh Sittampalam

Thanks - I'll take a look. One pre-emptive question: if I want to use it, 
it'd be more convenient, though not insurmountable, if that code was 
BSD3-licenced, since it will fit in better with the licence for camp 
http://projects.haskell.org/camp, which I might eventually want to 
integrate my code into. (the predicates I described are intended to be the 
commutation conditions for patches). Is that likely to be possible?


Cheers,

Ganesh

On Fri, 5 Dec 2008, Immanuel Normann wrote:


Hi,

you can browse my code
here.http://trac.informatik.uni-bremen.de:8080/hets/browser/trunk/Search/CommonIt
has become part of
Hets http://www.dfki.de/sks/hets the Heterogeneous Tool Set which is a
parsing, static analysis and proof management tool combining various tools
for different specification languages.
However, let me warn you: the code isn't yet well documented at parts also
ad hoc. Don't know whether it can help to solve your tasks.
The goal of my normalization code is to bring formulae via equivalence
transformations and alpha-renaming into a standard or normal form such that
for instance the following three formulae become syntactically identical
(i.e. not just modulo alpha equivalence or modulo associativity and
commutativity):

\begin{enumeratenumeric}
 \item $\forall \varepsilon . \varepsilon  0 \Rightarrow \exists \delta .
 \forall x. \forall y. 0  |x - y| \wedge |x - y|  \delta \Rightarrow | f
 (x) - f (y) |  \varepsilon$

 \item $\forall \varepsilon . \exists \delta . \forall x, y. \varepsilon 
0
 \Rightarrow (0  |x - y| \wedge |x - y|  \delta \Rightarrow | f (x) - f
(y)  |  \varepsilon)$

 \item $\forall e . \exists d . \forall a,b. e  0
 \wedge |a - b|  d \wedge 0  |a - b| \Rightarrow | f (a) - f (b) |  e$
\end{enumeratenumeric}

Cheers,

Immanuel



2008/12/4 Ganesh Sittampalam [EMAIL PROTECTED]


Hi,

That sounds like it might be quite useful. What I'm doing is generating
some predicates that involve addition/subtraction/comparison of integers and
concatenation/comparison of lists of some abstract thing, and then trying to
simplify them. An example would be simplifying

\exists p_before . \exists p_after . \exists q_before . \exists q_after .
\exists as . \exists bs . \exists cs . (length p_before == p_pos  length
q_before == q_pos  (p_before == as  q_after == cs)  p_before ++ p_new
++ p_after == as ++ p_new ++ bs ++ q_old ++ cs  as ++ p_new ++ bs ++ q_old
++ cs == q_before ++ q_old ++ q_after)

into

q_pos - (p_pos + length p_new) = 0

which uses some properties of length as well as some arithmetic. I don't
expect this all to be done magically for me, but I'd like as much help as
possible - at the moment I've been growing my own library of predicate
transformations but it's all a bit ad-hoc.

If I could look at your code I'd be very interested.

Cheers,

Ganesh


On Thu, 4 Dec 2008, Immanuel Normann wrote:

 Hi Ganesh,


manipulating predicate formulae was a central part of my PhD research. I
implemented some normalization and standarcization functions in Haskell -
inspired by term rewriting (like normalization to Boolean ring
representation) as well as (as far as I know) novell ideas
(standardization
of quantified formulae w.r.t associativity and commutativity).
If you are interested in that stuff I am pleased to provide you with more
information. May be you can describe in more detail what you are looking
for.

Best,
Immanuel

2008/11/30 Ganesh Sittampalam [EMAIL PROTECTED]

 Hi,


Are there any Haskell libraries around for manipulating predicate
formulae?
I had a look on hackage but couldn't spot anything.

I am generating complex expressions that I'd like some programmatic help
in
simplifying.

Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe







___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] manipulating predicate formulae

2008-12-01 Thread Ganesh Sittampalam


On Sun, 30 Nov 2008, Neil Mitchell wrote:


http://www.cs.york.ac.uk/fp/darcs/proposition/

Unreleased, but might be of interest. It simplifies propositional
formulae, and can do so using algebraic laws, custom simplifications
or BDDs. I don't really use this library, so if it is of interest to
you, its all yours :-)


Thanks, but I don't think a propositional library is a good starting point 
for a predicate library - the problems are too different. Sadly my 
predicates are over infinite domains, otherwise BDDs would have been 
really nice :-(


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: howto tuple fold to do n-ary cross product?

2008-11-30 Thread Ganesh Sittampalam


On Sun, 30 Nov 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Nov 30, at 12:43, Max Rabkin wrote:


It seems to me like this would all be easy if (a,b,c,d) was sugar for
(a,(b,(c,d))), and I can't see a disadvantage to that.



No disadvantage aside from it making tuples indistinguishable from lists.


No, they'd still have statically known length and be heterogenous, it 
would just change some strictness properties.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] manipulating predicate formulae

2008-11-30 Thread Ganesh Sittampalam


Hi,

Are there any Haskell libraries around for manipulating predicate 
formulae? I had a look on hackage but couldn't spot anything.


I am generating complex expressions that I'd like some programmatic help 
in simplifying.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Comparing GADTs for Eq and Ord

2008-09-15 Thread Ganesh Sittampalam


On Mon, 15 Sep 2008, Tom Hawkins wrote:


OK.  But let's modify Expr so that Const carries values of different types:

data Expr :: * - * where
 Const :: a - Term a
 Equal :: Term a - Term a - Term Bool

How would you then define:

Const a === Const b  = ...


Apart from the suggestions about Data.Typeable etc, one possibility is to 
enumerate the different possible types that will be used as parameters to 
Const in different constructors, either in Expr or in a new type.


So IntConst :: Int - Expr Int, etc

Or Const :: Const a - Expr a and IntConst :: Int - Const Int etc

Not very pleasant though.

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Top Level -


On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Sep 6, at 18:25, Ashley Yakeley wrote:


2. If the dynamic loader loads an endless stream of different modules
containing initialisers, memory will thus leak.


I think if the issue is this vs. not being able to guarantee any 
once-only semantics, i consider the former necessary overhead for proper 
program behavior.


Not leaking memory is an important part of proper program behaviour.

And that, given that there exists extra-program global state that 
one might want to access, once-only initialization is a necessity.


In what cases? In the case of buffered I/O there's no reason (in theory) 
you couldn't unload libc, do unbuffered I/O for a while, then reload libc 
and start again.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Top Level -


On Sat, 6 Sep 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:
The set of ACIO expressions exp is the static initialisers of M. The 
RTS must note when each static initialiser is run, and cache its result 
val. Let's call this cache of vals the static results cache of M.


When M is loaded, and a static results cache for M already exists, then 
it will be used for the vals of M.


This sounds reachable to me, and therefore static overhead and not a 
leak.


You can call it what you like, but it's still unacceptable behaviour, 
particularly since clients of M will have no way of telling from its 
API that it will happen.


That what will happen?


That memory will be used and not ever be reclaimable.

Suppose I am writing something that I intend to be used as part of a 
plug-in that is reloaded in different forms again and again. And I see 
module K which does something I want, so I use it. It so happens that K 
uses M, which has a -. If I knew that using K in my plug-in would cause a 
memory leak, I would avoid doing so; but since the whole point of - is to 
avoid making the need for some state visible in the API.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Top Level -


On Sun, 7 Sep 2008, Brandon S. Allbery KF8NH wrote:

You seem to think we must never insure that something will only be run 
once, that any program that does require this is broken.  As such, the 
standard Haskell libraries (including some whose interfaces are H98) are 
unfixably broken and you'd better start looking elsewhere for your 
correct behavior.


Data.Unique might be unfixably broken, though perhaps some requirement 
that it not be unloaded while any values of type Unique are still around 
could solve the problem - though it's hard to see how this could be 
implemented sanely. But Data.Unique could (a) probably be replaced with 
something in terms of IORefs and (b) is pretty ugly anyway, since it 
forces you into IO.


I'm sure that for many other examples, re-initialisation would be fine. 
For example Data.HashTable just uses a global for instrumentation for 
performance tuning, which could happily be reset if it got unloaded and 
then reloaded. System.Random could get a new StdGen. I haven't yet had 
time to go through the entire list that Adrian Hey posted to understand 
why they are being used, though.


I'd also point out that if you unload and load libraries in C, global 
state will be lost and re-initialised.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Top Level -


On Sun, 7 Sep 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:
Suppose I am writing something that I intend to be used as part of a 
plug-in that is reloaded in different forms again and again. And I see 
module K which does something I want, so I use it. It so happens that K 
uses M, which has a -. If I knew that using K in my plug-in would cause a 
memory leak, I would avoid doing so; but since the whole point of - is to 
avoid making the need for some state visible in the API.


The results from the - in M will only be stored once for the life of the 
RTS, no matter how many times your plug-ins are reloaded.


Sorry, I keep forgetting that. OK, so you can't get an endless stream of 
leaks unless you use - yourself, or modules on your system keep getting 
upgraded to new versions.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: Top Level -

2008-09-06 Thread Ganesh Sittampalam


On Sat, 6 Sep 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:
But it's limited to the initialisers. An IORef holding an Integer isn't 
much memory, and it only ever gets leaked once.



It happens every time you load and unload, surely?


No. An initialiser is only ever run once per run of the RTS.


Oh, I see. Yes, sorry.

Since it's of the order of the number of uniquely identified 
initialisers, it's arguably not a memory leak so much as a static 
overhead. The only way to get a continuous leak is to load and unload an 
endless stream of _different_ modules, each with their own initialisers.


I would call it a leak if something that is no longer being used cannot be 
reclaimed. The endless stream of different modules is possible in 
long-running systems where the code being run evolves or changes over time 
(e.g. something like lambdabot, which runs user-provided code).


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Top Level -

2008-09-06 Thread Ganesh Sittampalam


On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Sep 6, at 6:10, Ashley Yakeley wrote:


The set of ACIO expressions exp is the static initialisers of M. The RTS 
must note when each static initialiser is run, and cache its result val. 
Let's call this cache of vals the static results cache of M.


When M is loaded, and a static results cache for M already exists, then it 
will be used for the vals of M.


This sounds reachable to me, and therefore static overhead and not a 
leak.


You can call it what you like, but it's still unacceptable behaviour, 
particularly since clients of M will have no way of telling from its API 
that it will happen.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: Top Level -

2008-09-06 Thread Ganesh Sittampalam


On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote:

On 2008 Sep 6, at 11:22, Ganesh Sittampalam wrote:

On Sat, 6 Sep 2008, Brandon S. Allbery KF8NH wrote:

On 2008 Sep 6, at 6:10, Ashley Yakeley wrote:
The set of ACIO expressions exp is the static initialisers of M. The 
RTS must note when each static initialiser is run, and cache its result 
val. Let's call this cache of vals the static results cache of M.
When M is loaded, and a static results cache for M already exists, then 
it will be used for the vals of M.


This sounds reachable to me, and therefore static overhead and not a 
leak.


You can call it what you like, but it's still unacceptable behaviour, 
particularly since clients of M will have no way of telling from its 
API that it will happen.


You want run-once behavior without giving the runtime the ability to 
tell that it's already been run?


I don't want run-once behaviour, other people do. I'm just trying to pin 
down what it would mean.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Functional references

2008-09-05 Thread Ganesh Sittampalam


On Fri, 5 Sep 2008, Jules Bean wrote:

I think it would be worth spending some time (on this mailing list, 
perhaps, or in another forum) trying to hash out a decent API which 
meets most people's requirements, rather than ending up with 4 or 5 
slightly different ones.


This sounds like a good plan, but please make sure the result is as free 
as GHC, rather than GPL like data-accessor is. It's so simple that it 
being GPL just drives people for whom licencing is an issue to write an 
alternative rather than consider complying.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Top Level -

2008-09-05 Thread Ganesh Sittampalam


On Fri, 5 Sep 2008, Ashley Yakeley wrote:


Sittampalam, Ganesh wrote:

Ashley Yakeley wrote:

I really don't know enough about the RTS to know. The alternative 
would be to keep all initialised values when the module is unloaded. 
I'm guessing this is more feasible.


Easier, but a guaranteed memory leak.


But it's limited to the initialisers. An IORef holding an Integer isn't 
much memory, and it only ever gets leaked once.


It happens every time you load and unload, surely?

Also I thought this was a general discussion with Data.Unique as a 
concrete example; something else might leak substantially more memory. 
Your witnesses stuff would leak one Integer per module, wouldn't it?


Finally, any memory leak at all can be unacceptable in some contexts. It's 
certainly not something we should just dismiss as oh, it's only small.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] Top Level -

2008-09-02 Thread Ganesh Sittampalam


On Tue, 2 Sep 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:
I have a feeling it might be non-trivial; the dynamically loaded bit of 
code will need a separate copy of the module in question, since it might be 
loaded into something where the module is not already present.


Already the dynamic loader must load the module into the same address 
space and GC, i.e. the same runtime. So it should be able to make sure 
only one copy gets loaded.


I don't think it's that easy, modules aren't compiled independently of 
each other, and there are lots of cross-module optimisations and so on.


What is the status of dynamic loading in Haskell? What does hs-plugins 
do currently?


I don't know for sure, but I think it would load it twice.

In any case, what I'm trying to establish below is that it should be a 
safety property of - that the entire module (or perhaps mutually 
recursive groups of them?) can be duplicated safely - with a new name, or 
as if with a new name - and references to it randomly rewritten to the 
duplicate, as long as the result still type checks. If that's the case, 
then it doesn't matter whether hs-plugins loads it twice or not.


Let's suppose some other module uses a -, but returns things based on that 
- that are some standard type, rather than a type it defines itself. Is 
module duplication still safe?


In this case, duplicate modules of different versions is as safe as 
different modules. In other words, this situation:


 mypackage-1.0 that uses -
 mypackage-2.0 that uses -

is just as safe as this situation:

 mypackage-1.0 that uses -
 otherpackage-1.0 that uses -

The multiple versions issue doesn't add any problems.


Agreed - and I further claim that duplicating the entire module itself 
can't cause any problems.


Well, let me put it this way; since I don't like -, and I don't 
particularly mind Typeable, I wouldn't accept IOWitness as an example of 
something that requires - to implement correctly, because I don't see any 
compelling feature that you can only implement with -.


Why don't you like -? Surely I've addressed all the issues you raise?


I'm still not happy that the current specification is good enough, 
although I think this thread is getting closer to something that might 
work.


Even with a good specification for -, I would rather see the need for 
once-only state reflected in the type of things that have such a need.


There is an obligation regarding dynamic loading, but it looks like 
dynamic loading might need work anyway.


I think the obligation should be on -, and the obligation is the 
duplication rule I proposed above.


Since this is a matter of aesthetics, I imagine it will end with a list of 
pros and cons.


Agreed.

There's some unsafety somewhere in both Typeable and IOWitnesses, and in 
both cases it can be completely hidden from the user - with Typeable, just 
don't let the user define the typeOf function at all themselves. 


It's worse than that. If you derive an instance of Typeable for your 
type, it means everyone else can peer into your constructor functions 
and other internals. Sure, it's not unsafe, but it sure is ugly.


True. I would argue that this is better solved with a better typeclass 
hierarchy (e.g. one class to supply a witness-style representation that 
only supports equality, then the typereps on top of that if you want 
introspection too).


Sometimes you want to do witness equality tests rather than type equality 
tests. For instance, I might have a foo exception and a bar exception, 
both of which carry an Int. Rather than create new Foo and Bar types, I 
can just create a new witness for each.


This is precisely what newtype is designed for, IMO. We don't need another 
mechanism to handle it.


It's not what newtype is designed for. Newtype is designed to create 
usefully new types. Here, we're only creating different dummy types so 
that we can have different TypeRep values, which act as witnesses. It's 
the TypeReps that actually do the work.


newtype is frequently used to create something that you can make a 
separate set of typeclass instances for. This is no different. You can 
argue that this use of newtype is wrong, but there's no point in 
just providing an alternative in one specific case.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -

2008-09-02 Thread Ganesh Sittampalam


On Tue, 2 Sep 2008, Adrian Hey wrote:


Ganesh Sittampalam wrote:
You see this as a requirement that can be discharged by adding the ACIO 
concept; I see it as a requirement that should be communicated in the type.


Another way of looking at it is that Data.Unique has associated with it 
some context in which Unique values are safely comparable. You want that 
context to always be the top-level/RTS scope, I would like the defining 
that context to be part of the API.


But why pick on Data.Unique as special? Because I just happened to have
pointed out it uses a global variable?


Only because I thought it was the running example.

If you didn't know this I suspect this issue just wouldn't be an issue 
at all. Why haven't you raised a ticket complaining about it's API 
having the wrong type sigs? :-)


Because I don't use it, and even if I did use it I would just live with 
the API it has.



There's shed loads of information and semantic subtleties about pretty
much any operation you care to think of in the IO monad that isn't
communicated by it's type. All you know for sure is that it's weird,
because if it wasn't it wouldn't be in the IO monad.


It does actually claim a specification, namely that no two calls to 
newUnique return values that compare equal.



We have to have something concrete to discuss and this is the simplest.
Like I said there are a dozen or so other examples in the base package
last time I counted


Would you mind listing them? It might help provide some clarity to the 
discussion.


Here's what you can't find in the libs distributed with ghc. Note this
does not include all uses of unsafePerformIO. It only includes uses
to make a global variable.


Thanks. It'd probably be a good addition to the wiki page on this topic 
for these to be catalogued in terms of why they are needed, though I'm 
(probably) not volunteering to do it :-)


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Mon, 1 Sep 2008, Adrian Hey wrote:


Actually all this use of the tainted and derogatory term global
variable is causing me to be imprecise. All MVars/IORefs have global 
main/process scope whether or not they're bound to something at the

top level.


Global variable is exactly the right term to use, if we are following 
the terminology of other languages. We don't call the result of malloc/new 
etc a global variable, unless it is assigned to something with top-level 
scope.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Mon, 1 Sep 2008, John Meacham wrote:


On Mon, Sep 01, 2008 at 10:45:05PM +0100, Ganesh Sittampalam wrote:

Actually all this use of the tainted and derogatory term global
variable is causing me to be imprecise. All MVars/IORefs have global
main/process scope whether or not they're bound to something at the
top level.


Global variable is exactly the right term to use, if we are following
the terminology of other languages. We don't call the result of
malloc/new etc a global variable, unless it is assigned to something
with top-level scope.


global variable is not a very precise term in other languages for
various platforms too a lot of times.  for instance, windows dll's have
the ability to share individual variables across all loadings of said
dll. (for better or worse.)


Interesting, is this just within a single process?

Haskell certainly has more advanced scoping capabilities than other 
languages so we need a more refined terminology. I think 'IO scope' is 
the more precise term, as it implys the scope is that of the IO monad 
state. which may or may not correspond to some external 'process scope'.


Hmm, to me that implies that if the IO monad stops and restarts, e.g. when 
a Haskell library is being called from an external library, then the scope 
stops and starts again (which I presume is not the intention of - ?)


But I don't really care that much about the name, if there is consensus on 
what to call it that doesn't cause ambiguities with OS processes etc.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Mon, 1 Sep 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Sep 1, at 18:08, Ganesh Sittampalam wrote:

On Mon, 1 Sep 2008, John Meacham wrote:



for instance, windows dll's have
the ability to share individual variables across all loadings of said
dll. (for better or worse.)


Interesting, is this just within a single process?


Last I checked, it was across processes; that is, every DLL has its own 
(optional) data segment which is private to the DLL but shared across 
all system-wide loaded instances of the DLL.  This actually goes back to 
pre-NT Windows.


Sounds like a recipe for fun :-)

Haskell certainly has more advanced scoping capabilities than other 
languages so we need a more refined terminology. I think 'IO scope' is the 
more precise term, as it implys the scope is that of the IO monad state. 
which may or may not correspond to some external 'process scope'.


Hmm, to me that implies that if the IO monad stops and restarts, e.g. when 
a Haskell library is being called from an external library, then the scope 
stops and starts again (which I presume is not the intention of - ?)


It tells me the flow of execution has temporarily exited the scope of the IO 
monad, but can return to it.  The state is suspended, not exited.


In that case we could equally call the things library scope, as that's 
the only scope they're visible in unless exported. Anyway, as long as 
we're clear on what it means, the name doesn't really matter.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Mon, 1 Sep 2008, Adrian Hey wrote:


Ganesh Sittampalam wrote:
On Sun, 31 Aug 2008, Adrian Hey wrote: 

Eh? Please illustrate your point with Data.Unique. What requirements
does it place on it's context? (whatever that might mean :-)


It requires that its context initialises it precisely once.


It's context being main? If so this is true, but I don't see why this
is  a problem. [...]  Also ACIO monad properties guarantee that it's
always initialised to the same value regardless of when this occurs.
So I don't see the problem.


You see this as a requirement that can be discharged by adding the ACIO 
concept; I see it as a requirement that should be communicated in the 
type.


Another way of looking at it is that Data.Unique has associated with it 
some context in which Unique values are safely comparable. You want that 
context to always be the top-level/RTS scope, I would like the defining 
that context to be part of the API.


Data.Unique is actually a poor example, as it is actually fine to 
initialise it multiple times as long as the resulting Unique values 
aren't treated as coming from the same datatype.


I just don't see what you're getting at. There's no problem here
and Data.Unique is not special.


See the conversation with Ashley - you can have multiple copies of 
Data.Unique loaded without problem, as long as the resulting Unique 
datatypes aren't comparable with each other.



myCount :: MVar Int
myCount - newMVar 0

In a hypothetical second initialisation, do you mean..
1 - myCount somehow gets rebound to a different/new MVar


I mean this. Or, more precisely, that a *different* myCount gets bound to 
a different MVar.



But equally it can be implemented with IORefs,


Actually it couldn't as IORefs are not an Ord instance.


Well, perhaps one could be added (along with hashing). Or perhaps it's not 
really needed; I don't know as I've never used Data.Unique, and I doubt I 
ever would as when I need a name supply I also want human readable names, 
and I can't think of any other uses for it, though no doubt some exist.



so it's not a good advert for the need for global variables.


Oh please!

We have to have something concrete to discuss and this is the simplest.
Like I said there are a dozen or so other examples in the base package
last time I counted


Would you mind listing them? It might help provide some clarity to the 
discussion.


and plenty of people have found that other libs/ffi bindings need them 
for safety reasons. Or at least they need something that has global 
main/process scope and so far the unsafePerformIO hack is the only known 
way to get that and still keep APIs stable,sane and modular.


Again, some specific examples would help.


Also, AFAICS going the way that seems to be suggested of having all this
stuff reflected in the arguments/types of API is going to make it
practically impossible to have platform independent APIs if all platform
specific implementation detail has to be accounted for in this way.


It can all be wrapped up in a single abstract context argument; the only 
platform bleed would be if one platform needed a context argument but 
others didn't.



I think there are two cases to consider here.

A Data.Unique style library, which requires genuinely *internal* state, and 
which is agnostic to having multiple copies of itself loaded 
simultaneously. In that case, there is no requirement for a process-level 
scope for -, just that each instance of the library is only initialised 
once - the RTS can do this, as can any dynamic loader.


The other is some library that really cannot be safely loaded multiple 
times, because it depends on some lower-level shared resource. Such a 
library simply cannot be made safe without cooperation from the thing that 
controls that shared resource, because you cannot prevent a second copy of 
it being loaded by something you have no control over.


If the - proposal were only about supporting the first of these 
applications, I would have far fewer objections to it. But it would have 
nothing to do with process-level scope, then.


The - proposal introduces no new problems that aren't already with us.
It solves 1 problem in that at least there's no room for the compiler to
get it wrong or for people do use dangerous things when using the
unsafePerformIO hack. I think that is really the only problem that can
be solved at the level of Haskell language definition.


I just want to be clear that the second of the two categories above cannot 
be used to justify the proposal, as it does not make them safe.



I also think we need to be careful about the use of the term process.

IMO when we say the process defined by main, we are talking about an
abstract process that is essentially defined by Haskell and may have
nothing in common with a process as defined by various OS's (assuming
there's an OS involved at all). Perhaps we should try be more clear and
say Haskell process or OS process as appropriate. In particular

[Haskell-cafe] Re: [Haskell] Top Level -


On Mon, 1 Sep 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:
Well, the question of whether multiple copies of a module are ok is still 
open, I guess - as you say later, it seems perfectly reasonable for two 
different versions of Data.Unique to exist, each with their own types and 
global variables - so why not two copies of the same version, as long as 
the types aren't convertible? My feeling is that the the execution of - 
needs to follow the Data.Typeable instances - if the two types are the same 
according to Data.Typeable, then there must only be one - executed.


They will be different types if they are in different package versions.


Right, but they might be the same package version, if one is a dynamically 
loaded bit of code and the other isn't.


Thus they could have different instances of Typeable. But why do we care 
about Typeable?


Because of the coercion operation that follows from it.

So another question following on from that is what happens if there isn't 
any datatype that is an essential part of the module - with Unique, it's 
fine for there to be two -s, as long as the Uniques aren't compared. Does 
this kind of safety property apply elsewhere? It feels to me that this is 
something ACIO (or whatever it would be called after being changed) needs 
to explain.


In the internal implementation of Unique, there must be only one MVar 
constructed with - per Unique type, i.e. per package version. This will 
work correctly, since values of Unique types from different package 
versions have different types, and thus cannot be compared.


Unique values constructed at top level by - will also be unique and will 
work correctly.


My question was actually about what happens with some different library 
that needs -; how do we know whether having two -s is safe or not?


I'd rather use Data.Typeable for this, and make sure (by whatever 
mechanism, e.g. compiler-enforced, or just an implicit contract) that the 
user doesn't break things with dodgy Typeable instances.


You don't think that's rather ugly: a class that needs special deriving 
behaviour? I'd actually like to get rid of all special-case deriving: it 
should be for newtypes only.


No, it seems like the right way to do introspection to me, rather than 
adding some new mechanism for describing a datatype as your paper

suggests.

Implicit contract is worse. I really shouldn't be able to write coerce 
without referring to something marked unsafe or foreign. Have we 
stopped caring about soundness?


We could arrange for the class member of Typeable to be called 
unsafe


In addition, one can only have one Typeable instance per type. By 
contrast, one can create multiple IOWitness values for the same type. 
For example, one can very easily create a system of open exceptions for 
IO, with an IOWitness value for each exception type, witnessing to the 
data that the exception carries.


I don't see what the point of multiple values is, I'm afraid. A single 
instance of Typeable is fine for doing type equality tests.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Mon, 1 Sep 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:
Right, but they might be the same package version, if one is a dynamically 
loaded bit of code and the other isn't.


OK. It's up to the dynamic loader to deal with this, and make sure that 
initialisers are not run more than once when it loads the package into the 
RTS. The scopes and names are all well-defined. How hard is this?


I have a feeling it might be non-trivial; the dynamically loaded bit of 
code will need a separate copy of the module in question, since it might 
be loaded into something where the module is not already present. So it'll 
have a separate copy of the global variable in a separate location, and 
the dynamic loader needs to arrange to do something weird, like copying 
the value of the first run - to the second one instead of running it 
again.




My question was actually about what happens with some different library 
that needs -; how do we know whether having two -s is safe or not?


I don't understand. When is it not safe?


Well, the safety of - being run twice in the Data.Unique case is based 
around the two different Data.Unique types not being compatible. Let's 
suppose some other module uses a -, but returns things based on that 
- that are some standard type, rather than a type it defines itself. Is 
module duplication still safe?


No, it seems like the right way to do introspection to me, rather than 
adding some new mechanism for describing a datatype as your paper

suggests.


Aesthetic arguments are always difficult. The best I can say is, why are 
some classes blessed with a special language-specified behaviour?


Well, let me put it this way; since I don't like -, and I don't 
particularly mind Typeable, I wouldn't accept IOWitness as an example of 
something that requires - to implement correctly, because I don't see any 
compelling feature that you can only implement with -.



We could arrange for the class member of Typeable to be called unsafe


We could, but it's not actually unsafe to call as such. It's only unsafe to 
implement.


That's fine, it can export a non-class member without the unsafe prefix.

And if we're going the implicit contract route, we have to resort to 
unsafe functions to do type representation. It's not necessary, and 
seems rather against the spirit of Haskell.


Time was when people would insist that unsafePerformIO wasn't Haskell, 
though perhaps useful for debugging. Now we have all these little unsafe 
things because people think they're necessary, and there's an implicit 
contract forced on the user not to be unsafe. But it turns out that 
they're not necessary.


There's some unsafety somewhere in both Typeable and IOWitnesses, and in 
both cases it can be completely hidden from the user - with Typeable, just 
don't let the user define the typeOf function at all themselves. I'm not 
actually sure why it is exposed; is it necessary for some use pattern?


I don't see what the point of multiple values is, I'm afraid. A single 
instance of Typeable is fine for doing type equality tests.


Sometimes you want to do witness equality tests rather than type equality 
tests. For instance, I might have a foo exception and a bar exception, 
both of which carry an Int. Rather than create new Foo and Bar types, I can 
just create a new witness for each.


This is precisely what newtype is designed for, IMO. We don't need another 
mechanism to handle it.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] Top Level -


On Sat, 30 Aug 2008, Ashley Yakeley wrote:

OK. Let's call it top-level scope. Haskell naturally defines such a 
thing, regardless of processes and processors. Each top-level - would 
run at most once in top-level scope.


If you had two Haskell runtimes call by C code, each would have its own 
memory allocator and GC; IORefs, Uniques and thunks cannot be shared 
between them; and each would have its own top-level scope, even though 
they're in the same process.


That sounds more feasible - though it does constrain a plugin 
architecture (in which Haskell code can dynamically load other Haskell 
code) to cooperate with the loading RTS and not load multiple copies of 
modules; this might make linking tricky. There's also the problem Duncan 
Coutts mentioned about loading multiple versions of the same module - what 
are the semantics of - in relation to that?


Also, it's no use for mediating access to a resource or library that can 
only be accessed once, right? In fact, even without the problem of two 
Haskell runtimes in one process this can't work, since some library in 
another language might also choose to access that resource or library.


What applications does this leave beyond Data.Unique and Random?

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sat, 30 Aug 2008, Adrian Hey wrote:


Ganesh Sittampalam wrote:

Well, yes, but if I implemented a library in standard Haskell it would 
always be safely serialisable/deserialisable (I think). So the global 
variables hack somehow destroys that property - how do I work out why it 
does in some cases but not others?


This has nothing to do with the use of global variables. If you have
a set of values that are guaranteed to be distinct (unique) and you
add another random/arbitrary value to that set you have no way of
knowing that it is different from any current member (other than
searching the entire set, assuming it's available).


OK, never mind about this. I was thinking that referential transparency 
was violated by remoting, but since unique values can only be constructed 
in IO, I think I was wrong.



Well, I've never seen a convincing use case for global variables :-)


Well apart from all the libs that couldn't be implemented with them...


They can't be implemented with an interface that is completely oblivious 
to the fact that the libraries require some state.


Dynamic loading and plugins work fine with standard Haskell now, because 
nothing in standard Haskell breaks them. The - proposal might well break 
them, which is a significant downside for it.


I don't see how, but if so - bindings are not the cause of the
brokeness. They'd still be broken using the unsafePerformIO hack.


Which places the unsafePerformIO hack at fault, seeing as it's unsafe and 
a hack and all :-) If - was standard then it'd be up to everyone else to 
work round its limitations.


In general, the smaller the world that the Haskell standard lives in, the 
less it can interfere with other concerns. - massively increases that 
world, by introducing the concept of a process scope.


All IORefs,MVars,Chans scope across the entire process defined by main.
Or at least they *should*, if they don't then something is already
badly wrong somewhere. This has nothing to do with whether or not they
appear at top level. This is what an IORef/MVar whatever is defined to
be.


Their scope is where they can be used, and this is something we can 
explicitly track by inspecting the program text. If they are just used in 
one part of the program, their scope is limited to that part of the 
program.



But then again, I'm sure that some that will be adamant that any way
of making global variables is a hack. But they'll still be happy
to go on using file IO, sockets etc regardless, blissfully unaware
of the hacks they are dependent on :-)


I'm not sure of precisely what you mean here, but stdin, stdout and stderr 
are things provided by the OS to a process. That's what defines them as 
having process scope, not something the Haskell language or RTS does.


Those rules aren't actually strong enough to provide a guarantee of 
process level scope.


The rules for - bindings shouldn't have to guarantee this.
This should be guaranteed by newMVar returning a new *MVar*, wherever
it's used (for example).


The issue is whether the - is run multiple times in a single process or 
not, rather than how the thing it calls behaves.



I mean semantic faults, as in the proposal just doesn't do what it
promises for some subtle reason.


It doesn't provide once-only semantics across an entire process in cases 
involving dynamic loading or two Haskell libraries together with RTS 
separately linked into the same C program. I don't know whether you intend 
that it does promise that or not, but it seems to be necessary for many of 
the applications that are used to justify it.


If you consider not giving you thread local variables a fault I guess 
you're entitled to that view, but this was never the intent of the 
proposal in the first place (that's not what people are trying to do 
when they use the unsafePerformIO hack).


The thread-local variables point was a relatively minor issue for me 
compared to the dynamic loading and related issues.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:

I'm not sure of precisely what you mean here, but stdin, stdout and 
stderr are things provided by the OS to a process. That's what defines 
them as having process scope, not something the Haskell language or RTS 
does.


But their representations in Haskell must have the same scope and are 
therefore de facto global variables.


Yep, but this is not Haskell providing a way to make global variables, it 
is just providing an interface to ones that already exist. The point is 
that the RTS can't provide (process-scope) global variables of its own 
invention, because it can't guarantee to be running at the top-level of a 
process, which it needs to be in order to control their construction.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Aug 31, at 10:29, Ganesh Sittampalam wrote:

On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:

On 2008 Aug 31, at 10:20, Ganesh Sittampalam wrote:
I'm not sure of precisely what you mean here, but stdin, stdout and 
stderr are things provided by the OS to a process. That's what defines 
them as having process scope, not something the Haskell language or RTS 
does.


But their representations in Haskell must have the same scope and are 
therefore de facto global variables.


Yep, but this is not Haskell providing a way to make global variables, it 
is just providing an interface to ones that already exist. The point is 
that the RTS can't provide (process-scope)


But that is done the same way as providing general global variables, so you 
can't get away from it.


I don't follow what you mean. stdin, stdout and stderr are just file 
descriptors 0, 1 and 2, aren't they? You can create them as many times as 
you want with using that information without causing any confusion or 
conflict. Whereas the - proposal has a once-only requirement.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sun, 31 Aug 2008, Adrian Hey wrote:

Thanks for taking the time to do this Dan. I think the safety 
requirement has been met, but I think it fails on the improved API. The 
main complaint would be what I see as loss of modularity, in that 
somehow what should be a small irrelevant detail of the implementation 
of some obscure module somewhere has propogated it's way all the way 
upto main.


That's the key point, as I see it - they aren't irrelevant details of the 
implementation, they are requirements the implementation places on its 
context in order for that implementation to be correct. So they should be 
communicated appropriately.



To me this seems completely at odds with what I thought was generally
accepted wisdom of how to write good maintainable, modular software.
Namely hiding as much implemention detail possible and keeping APIs
as simple and stable as they can be. I don't know if I'm alone in
that view nowadays.


It's no problem to hide implementation detail, but I don't think you 
should hide the *requirement* of the implementation that it has 
constraints on how it is called, namely that it requires once-only 
initialisation or whatever.



Purists aren't going to like it, but I think folk *will* be using real
global variables in I/O libs for the forseeable future. Seems a shame
that they'll have to do this with unsafePerformIO hack though :-(


From a purist point of view, it's a shame that they choose to do it at 

all :-)

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Aug 31, at 10:34, Ganesh Sittampalam wrote:


I don't follow what you mean. stdin, stdout and stderr are just file 
descriptors 0, 1 and 2, aren't they? You can create them as many times as 
you want with using that information without causing any confusion or 
conflict. Whereas the - proposal has a once-only requirement.


The convention is to provide buffered versions to improve the performance of 
file I/O.  These buffered filehandles must be created once per runtime 
instance (and ideally once per process so multiple runtimes don't find 
themselves overwriting each others' output).


In that case it seems that any library that might be used from a runtime 
that isn't the top-level of a process should avoid doing IO to those 
handles, for fear of producing output corruption?


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:



Where do the filehandle structures live in the latter case?


The place you clearly think so little of that you need to ask: 
process-global (or process-local depending on how you think about it) 
storage.  And everything in that storage must have locking.


I'm sorry if this makes me seem ignorant, but I'd never heard of such a 
thing before. What is the API for accessing such storage, and/or where can 
I find its documentation?


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sun, 31 Aug 2008, Adrian Hey wrote:


Ganesh Sittampalam wrote:

On Sun, 31 Aug 2008, Adrian Hey wrote:

Thanks for taking the time to do this Dan. I think the safety requirement 
has been met, but I think it fails on the improved API. The main complaint 
would be what I see as loss of modularity, in that somehow what should be 
a small irrelevant detail of the implementation of some obscure module 
somewhere has propogated it's way all the way upto main.


That's the key point, as I see it - they aren't irrelevant details of the 
implementation, they are requirements the implementation places on its 
context in order for that implementation to be correct. So they should be 
communicated appropriately.


Eh? Please illustrate your point with Data.Unique. What requirements
does it place on it's context? (whatever that might mean :-)


It requires that its context initialises it precisely once.

Data.Unique is actually a poor example, as it is actually fine to 
initialise it multiple times as long as the resulting Unique values aren't 
treated as coming from the same datatype. But equally it can be 
implemented with IORefs, so it's not a good advert for the need for global 
variables.



The real irony of your remark is that making APIs this robust is
practically impossible *without* using global variables, and you're
now saying that because they've done this work to eliminate these
constraints they now have to be held to account for this with
an absurd API.


I think there are two cases to consider here.

A Data.Unique style library, which requires genuinely *internal* state, 
and which is agnostic to having multiple copies of itself loaded 
simultaneously. In that case, there is no requirement for a process-level 
scope for -, just that each instance of the library is only initialised 
once - the RTS can do this, as can any dynamic loader.


The other is some library that really cannot be safely loaded multiple 
times, because it depends on some lower-level shared resource. Such a 
library simply cannot be made safe without cooperation from the thing that 
controls that shared resource, because you cannot prevent a second copy of 
it being loaded by something you have no control over.


If the - proposal were only about supporting the first of these 
applications, I would have far fewer objections to it. But it would have 
nothing to do with process-level scope, then.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Top Level -


On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Aug 31, at 12:01, Ganesh Sittampalam wrote:

On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:

On 2008 Aug 31, at 11:20, Ganesh Sittampalam wrote:

Where do the filehandle structures live in the latter case?


The place you clearly think so little of that you need to ask: 
process-global (or process-local depending on how you think about it) 
storage.  And everything in that storage must have locking.



You'll have to look at specific implementations.  One that I can think of off 
the top of my head is Perl 5's ithreads; there is a distinguished 
allocation store which is global to all ithreads, and the interpreter 
instance gives you primitives for locking and mutexing (see use 
threads::shared;).


From what I can see from the source of this, it seems to rely on a global 
variable inside the Perl library that contains a pointer to the shared 
state area (actually a separate Perl interpreter of its own, but that's 
just an implementation detail). However I may be wrong as I was unable to 
fully figure out how the BOOT: mechanism works from a simple grep.


I'm afraid I don't see how this generalises to sharing something across an 
entire process where the things that want to do the sharing are not in or 
controlled by the same shared library. In particular the filehandle 
structures required for buffered I/O need to be common to every single 
piece of code in the process that might want to use them, no matter what 
language or language implementation that code uses.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Top Level -


On Sun, 31 Aug 2008, Brandon S. Allbery KF8NH wrote:


On 2008 Aug 31, at 13:20, Ganesh Sittampalam wrote:


I'm afraid I don't see how this generalises to sharing something across an 
entire process where the things that want to do the sharing are not in or 
controlled by the same shared library. In particular the filehandle 
structures required for buffered I/O need to be common to every single 
piece of code in the process that might want to use them, no matter what 
language or language implementation that code uses.



For that you probably want to look at how ld.so.1 and libc interact to 
share the malloc pool and the stdin/stdout/stderr, among others.


If buffered IO is handled by libc rather than by specific language 
runtimes, then the same mechanism of using global variables inside libc 
would work fine; but this technique doesn't extend to providing 
process-scope shared state for library code that might be loaded multiple 
times with no knowledge of the other instances.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sat, 30 Aug 2008, Adrian Hey wrote:


Ganesh Sittampalam wrote:
Will Data.Unique still work properly if a value is sent across a RPC 
interface?


A value of type Unique you mean? This isn't possible. Data.Unique has 
been designed so cannot be Shown/Read or otherwise 
serialised/deserialised (for obvious reasons I guess).


How do the implementers of Data.Unique know that they musn't let them be 
serialised/deserialised? What stops the same rule from applying to 
Data.Random?



Also what if I want a thread-local variable?


Well actually I would say that threads are bad concurrency model so
I'm not keen on thread local state at all. Mainly because I'd like to
get rid of threads, but also a few other doubts even if we keep
threads.


Even if you don't like them, people still use them.


AFAICS this is irrelvant for the present discussions as Haskell doesn't
support thread local variable thingies. If it ever does being precise
about that is someone elses problem.


The fact that your proposal isn't general enough to handle them is a mark 
against it; standardised language features should be widely applicable, 
and as orthogonal as possible to other considerations.


For the time being the scope of IORefs/MVars/Chans is (and should 
remain) whatever process is described by main (whether or not they 
appear at top level).


And if main isn't the entry point? This comes back to my questions about 
dynamic loading.


(I.E. Just making existing practice *safe*, at least in the sense that 
the compiler ain't gonna fcuk it up with INLINING or CSE and every one 
understands what is and isn't safe in ACIO)


Creating new language features means defining their semantics rather more 
clearly than just no inlining or cse, IMO.


I wouldn't even know how to go about that to the satisfaction of
purists. But global variables *are* being used whether or not the top
level - bindings are implemented. They're in the standard libraries!

So if this stuff matters someone had better figure it out :-)


It's a hack that isn't robust in many situations. We should find better 
ways to do it, not standardise it.


Cheers,

Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sat, 30 Aug 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:
If you want to standardise a language feature, you have to explain its 
behaviour properly. This is one part of the necessary explanation.


To be concrete about scenarios I was considering, what happens if:

 - the same process loads two copies of the GHC RTS as part of two 
completely independent libraries? For added complications, imagine that 
one of the libraries uses a different implementation instead (e.g. Hugs)


 - one Haskell program loads several different plugins in a way that 
allows Haskell values to pass across the plugin boundary


How do these scenarios work with use cases for - like (a) Data.Unique and 
(b) preventing multiple instantiation of a sub-library?


That's a good question. But before you propose these scenarios, you must 
establish that they are sane for Haskell as it is today.


In particular, would _local_ IORefs work correctly? After all, the memory 
allocator must be global in some sense. Could you be sure that different 
calls to newIORef returned separate IORefs?


Yes, I would expect that. Allocation areas propagate downwards from the OS 
to the top-level of a process and then into dynamically loaded modules if 
necessary. Any part of this puzzle that fails to keep them separate (in 
some sense) is just broken.


Perhaps this is the One True Global Scope: the scope in which refs from 
newIORef are guaranteed to be separate.


Every single call to newIORef, across the whole world, returns a different 
ref. The same one as a previous one can only be returned once the old 
one has become unused (and GCed).


It's the scope in which values from newUnique are supposed to be 
different, and it would also be the scope in which top-level - would be 
called at most once.


I don't really follow this. Do you mean the minimal such scope, or the 
maximal such scope? The problem here is not about separate calls to 
newIORef, it's about how many times an individual - will be executed.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sat, 30 Aug 2008, Adrian Hey wrote:


Ganesh Sittampalam wrote:
How do the implementers of Data.Unique know that they musn't let them be 
serialised/deserialised?


Because if you could take a String and convert it to a Unique there
would be no guarantee that result was *unique*.


Well, yes, but if I implemented a library in standard Haskell it would 
always be safely serialisable/deserialisable (I think). So the global 
variables hack somehow destroys that property - how do I work out why it 
does in some cases but not others?



I think the whole thread local state thing is a complete red herring.

I've never seen a convincing use case for it and I suspect the only


Well, I've never seen a convincing use case for global variables :-)


reason these to issues have become linked is that some folk are so
convinced that global variables are evil, they mistakenly think
thread local variables must be less evil (because they are less
global).


I don't think they're less evil, just that you might want them for the 
same sorts of reasons you might want global variables.


If plugins breaks is down to plugins to fix itself, at least until such 
time as a suitable formal theory of plugins has been developed so it can 
become standard Haskell :-)


Dynamic loading and plugins work fine with standard Haskell now, because 
nothing in standard Haskell breaks them. The - proposal might well break 
them, which is a significant downside for it. In general, the smaller the 
world that the Haskell standard lives in, the less it can interfere with 
other concerns. - massively increases that world, by introducing the 
concept of a process scope.


It's a hack that isn't robust in many situations. We should find better 
ways to do it, not standardise it.


Nobody's talking about standardising the current hack. This the whole
point of the top level - proposal,


It just amounts to giving the current hack some nicer syntax and stating 
some rules under which it can be used. Those rules aren't actually strong 
enough to provide a guarantee of process level scope.


which JM seems to think is sound enough for incorporation into JHC 
(correctly IMO). Nobody's found fault with it, other than the usual 
global variables are evil mantra :-)


Several people have found faults with it, you've just ignored or dismissed 
them. No doubt from your perspective the faults are irrelevant or untrue, 
but that's not my perspective.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Re: [Haskell] Top Level -


On Sat, 30 Aug 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:
Every single call to newIORef, across the whole world, returns a different 
ref.


How do you know? How can you compare them, except in the same Haskell 
expression?


I can write to one and see if the other changes.

The same one as a previous one can only be returned once the old one has 
become unused (and GCed).


Perhaps, but internally the IORef is a pointer value, and those pointer 
values might be the same. From the same perspective, one could say that


How can they be the same unless the memory management system is broken? I 
consider different pointers on different machines or in different virtual 
address spaces different too; it's the fact that they don't alias 
that matters.


every single call to newUnique across the whole world returns a different 
value, but internally they are Integers that might repeat.


The thing about pointers is that they are managed by the standard 
behaviour of memory allocation. This isn't true of Integers.


In fact this point suggests an implementation for Data.Unique that should 
actually be safe without global variables: just use IORefs for the actual 
Unique values. IORefs already support Eq, as it happens. That gives you 
process scope for free, and if you want bigger scopes you can pair that 
with whatever makes sense, e.g. process ID, MAC address, etc.


Two IO executions are in the same global scope if their resulting 
values can be used in the same expression. Top-level - declarations 
must execute at most once in this scope.


This brings us back to the RPC question, and indeed to just passing values 
to somewhere else via FFI. I think you can work around some of that by 
talking about ADTs that aren't serialisable (e.g. ban the class Storable), 
but now we have different global scopes for different kinds of values, so 
which scope do we use to define - ?


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] Top Level -


On Sat, 30 Aug 2008, Ashley Yakeley wrote:

Is it the functionality of Data.Unique that you object to, or the fact that 
it's implemented with a global variable?


If the former, one could easily build Unique values on top of IORefs, since 
IORef is in Eq. Thus Data.Unique is no worse than IORefs (ignoring 
hashability, anyway).


If the latter, how do you recommend implementing Data.Unique? 
Implementing them on IORefs seems ugly.


This seems fine to me. It's based on something that already does work 
properly across a process scope, instead of some new language feature that 
is actually hard to implement across the process scope.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] Top Level -


On Sat, 30 Aug 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:
This seems fine to me. It's based on something that already does work 
properly across a process scope,


But you agree that IORefs define a concept of process scope?


I'm not sure that they *define* process scope, because it might be safe to 
use them across multiple processes; it depends on OS-dependent properties. 
But they exist *at least* at process scope.


instead of some new language feature that is actually hard to implement 
across the process scope.


If we have a concept of process scope, how is it hard to implement?


Because memory allocation is already implemented, and not in a 
Haskell-dependent way. If two completely separate Haskell libraries are 
present in the same process, linked together by a C program, they don't 
even know about each others existence. But they still don't share memory 
space.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] Top Level -


On Sat, 30 Aug 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:

On Sat, 30 Aug 2008, Ashley Yakeley wrote:


Ganesh Sittampalam wrote:
This seems fine to me. It's based on something that already does work 
properly across a process scope,


But you agree that IORefs define a concept of process scope?


I'm not sure that they *define* process scope, because it might be safe 
to use them across multiple processes; it depends on OS-dependent 
properties. But they exist *at least* at process scope.


How can one use IORefs across multiple processes? They cannot be serialised.


Firstly, that's a property of the current implementation, rather than a 
universal one, IMO. I don't for example see why you couldn't add a 
newIORef variant that points into shared memory, locking issues aside.


Also, the issue is not whether you can *use* them across multiple 
processes, but whether they are unique across multiple processes. 
Uniqueness has two possible definitions; aliasing, and representational 
equality. No two IORefs will ever alias, so by that definition they exist 
at global scope. For representational equality, that exists at least at 
process scope, and perhaps more.


Ganesh
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] Top Level -