RE: [Haskell-cafe] libffi mystery

[Sittampalam, Ganesh]

Conor McBride wrote:

> Is there some way I can get some more static linking to happen?
> I did poke about online a bit and found some remarks to the effect
> that GHC got so much more portable after switching to the dynamic
> libffi. That sounds great, but tough luck for me.  
> 
> So, being both powerless and clueless, I can only ask:
> 
>how hosed am I?
> 
> I'd be grateful for any glimmers of light.

Have you tried passing -optl-static to ghc (which causes -static to be
passed to ld)?

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

___
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)

[Sittampalam, Ganesh]

Bit Connor wrote:
> On Sat, Oct 16, 2010 at 10:29 AM, Claus Reinke
>  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've tried contacting him a few times about getting the base dependencies in 
HTTP bumped and an upload made, without success. This is a widely used package 
that's in the platform and that won't work with GHC 7.0 with the current 
dependencies, so it really needs to get fixed soon.

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?

Cheers,

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

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

RE: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation

[Sittampalam, Ganesh]

Vincent Hanquez wrote:
> On Fri, Oct 08, 2010 at 12:54:48PM +0100, Sittampalam, Ganesh wrote:
>> What's the motivation for this?
> 
> Well, I wanted to have a tls/ssl module that integrate nicely with
> haskell. 
> until then the 2 solutions were:
> 
> - shelling out to curl: that's not great, usually works until you
> have an error, and then you're greeted with a curl command line
> error. the control is pretty poor, what if you want a fancy
> certificate control ? Also you have absolutely no server support in
> this case, this is client only.
> 
> - using either gnutls or openssl bindings: there's multiples reasons
> this is not great. 
> depending on huge C libraries (security wise, platform wise), massive
> usage of IO even in place where it shouldn't, low hacking potential
> (adding ciphers/hash, etc).  
> 
> Apart from that, we all know here why programming in haskell is
> better than doing the same thing in says, C or python. I think it
> apply even more when the focus of this is a secure library.  

While I agree with the potential benefits, I also worry that you will
end up making something that is far less well tested in practice. For
widely used and fairly low-level libraries like gnutls, openssl and
zlib, I'm just skeptical that the benefits outweigh the risks and costs.

Anyway, it's just a feeling. Please do prove me wrong :-)

Cheers,

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

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

RE: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation

[Sittampalam, Ganesh]

Vincent Hanquez wrote:
> On Fri, Oct 08, 2010 at 11:14:01AM +0530, C K Kashyap wrote:
>> Does native mean "Haskell only" - without FFI?
> 
> Native means the implementation is in haskell, and the library is not
> using another implementation (in another language) to do the work:
> either through FFI as a binding, or as a wrapper to an external
> program.   

What's the motivation for this?

One thing I can see is that it would make things easier to install on
Windows.

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

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

RE: [Haskell-cafe] base-3 -> base-4

[Sittampalam, Ganesh]

Johannes Waldmann wrote:
> Is there a "conversion guide" for switching from base-3 to base-4?
> 
> I noticed that ghc-HEAD (6.13) comes with base-4.3 (and no base-3).
> This will break an awful lot of packages (?), in fact the breakage
> starts with cabal-install (since it depends on HTTP which depends on
> base-3).  

HTTP can build and seems to work with base 4 if you bump the dependency.
I contacted Sigbjorn about making a new release a while ago, but nothing
has happened yet.

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

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

RE: [Haskell-cafe] cabal, Setup.lhs example

[Sittampalam, Ganesh]

Mark Wotton wrote:

> Perhaps cabal should print a warning if you have a Setup.hs file,
> _and_ try to use Simple? It'd at least give the hint that they're
> unhappy together.  

I think it should instead verify that Setup.hs is consistent with a
Simple build. I don't know how much variation exists, but I believe
"import Distribution.Simple\nmain = defaultMain\n" is all such a
Setup.hs file actually needs.

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

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

RE: [Haskell-cafe] Page rank and GHC docs directory organization

[Sittampalam, Ganesh]

Ketil Malde wrote:
> Robin KAY  writes:
> 
>> the redirects and ignore the original URLs [2]. Using a "302 Found"
>> redirect instead might produce better results, at least for Google
> 
> But the page you point to suggests 302 is discouraged, and says they
> don't help for the other search engines.  Perhaps 'latest' could just
> be a symlink to the latest version instead of a redirect?  
> 
> In addition, all versions could have a blurb saying this is for
> version x.y.z, the latest version can be found (-> url with /latest).
> I believe this should boost the page rank of the 'latest' URL.  

If you both implement 'latest' as a symlink and have this blurb, then
the "latest" page will always have a rather silly looking link to
itself.

If the latest numbered version and latest could be generated separately,
then I think this would work very well.

The quick-n-dirty thing to do would be to switch to the 302 redirects,
which given the dominance of google, may well be good enough.

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

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

RE: [Haskell-cafe] Ocaml for Haskellers tutorial

[Sittampalam, Ganesh]

Stephen Tetley wrote:

> I suspect the difference between the ML module system vs. typeclasses
> will be as important as lazy vs. strict. As a style point, Ocaml
> programmers don't seem too prone to combinator mania - so I think
> golf is a bit less popular over there.   

Both the lack of laziness and the value restriction can sometimes force
combinator definitions to be eta-expanded, which I think makes this
style of programming much less attractive.

Cheers,

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

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

RE: [Haskell-cafe] Re: Asynchronous exception wormholes kill modularity

[Sittampalam, Ganesh]

Simon Marlow wrote:

> I came to the conclusion that counting nesting layers doesn't solve
> the problem: the wormhole still exists in the form of nested unmasks.
> That is, a library function could always escape out of a masked
> context by writing
> 
>unmask $ unmask $ unmask $ ...
> 
> enough times.
[...]
> mask :: ((IO a -> IO a) -> IO b) -> IO b
> mask io = do
>b <- blocked
>if b
>   then io id
>   else block $ io unblock
> 
> to be used like this:
> 
> a `finally` b =
>mask $ \restore -> do
>  r <- restore a `onException` b
>  b
>  return r
> 
> So the property we want is that if I call a library function
> 
>mask $ \_ -> call_library_function
> 
> then there's no way that the library function can unmask exceptions. 
> If all they have access to is 'mask', then that's true.
[...]
> It's possible to mis-use the API, e.g.
> 
>getUnmask = mask return

Given that both the "simple" mask/unmask and your alternate proposal
have backdoors, is the extra complexity really worth it?

The problem with the existing API is that it's not possible even for
well-behaved library code to use block/unblock without screwing up
callers. With the simple mask/unmask, the rule is simply that you don't
call unmask except within the context of your own mask calls.

Ganesh

=== 
Please access the attached hyperlink for an important electronic communications 
disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=== 

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

RE: [Haskell-cafe] Re: Hackage accounts and real names

[Sittampalam, Ganesh]

Ivan Miljenovic wrote:

> 5) No-one is convincing anyone else to their point of view, so we
> have a stale mate. 

Would allowing pseudonyms but requiring them to be explicitly marked as
such be an acceptable compromise?

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: Where are the haskell elders?

[Sittampalam, Ganesh]

Günther Schmidt wrote:

> Is there a listing of sorts for all Haskell-relevant blogs?

http://planet.haskell.org

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Lazy language on JVM/CLR

[Sittampalam, Ganesh]

Tom Lokhorst wrote:

> Also, I wonder if there is some efficient way of implementing the
> Lazy class, perhaps by having the Force method using runtime code
> generation to override itself. I don't know if this is possible, but
> I vaguely remember the Dynamic Language Runtime on .NET doing
> something like that.

.NET 4 (final release due in the next few months) will have a built-in
lazy type.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Anyone up for Google SoC 2010?

[Sittampalam, Ganesh]

Gwern Branwen wrote:
> On Wed, Feb 3, 2010 at 8:14 PM, Henk-Jan van Tuyl 
> wrote: 
>> On Wed, 03 Feb 2010 23:34:34 +0100, Neil Mitchell
>> 
>> wrote:
>> 
>>> Hi Gwern,
>>> 
>>> Please update: "haskell-src-exts -> haskell-src" **Unknown**
>>> 
>>> This project was an unqualified success.  haskell-src-exts is now
>>> one 
>>> of the most commonly used Haskell libraries, achieved the goals in
>>> the project proposal, and is an essential piece of Haskell
>>> infrastructure. 
>> 
>> You can see this using Roel van Dijk's reversed dependencies
>> overview [1]: 23 direct and 57 indirect dependencies on
>> haskell-src-exts-1.8.0 
>> 
>> Regards,
>> Henk-Jan van Tuyl
> 
> And how many of those used haskell-src-exts *before* the SoC project?
> And would have used it regardless? You can't point to a popular
> project which got a SoC student, and say look at how popular it is -
> obviously the SoC student was hugely successful.  

Regardless of that, is there any reason to disregard Neil's summary and not 
update your page?

Ganesh


=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] How to fulfill the "code-reuse" destiny of OOP?

[Sittampalam, Ganesh]

The problem with interfaces as a replacement for type classes is that
they only provide dispatch based on the specific type of the first
argument (i.e. the receiver).
 
Type classes allow you to dispatch based on return type, and on the
instantiations of generic parameters. Neither of these things is
reasonably possible with interfaces.
 
For example you can't directly implement the Read type class with
interfaces. Neither can you implement a function of type [a] -> ...
where the dispatch is based on the instantiation of a - even if you can
add an interface to the [] generic type, you might not have a concrete
object of type a to dispatch from if the empty list is passed as an
argument.
 



From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Peter Verswyvelen
Sent: 13 January 2010 09:52
To: Gregory Collins
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] How to fulfill the "code-reuse" destiny of
OOP?


On Sun, Nov 1, 2009 at 2:57 AM, Gregory Collins
 wrote:


Doing OO-style programming in Haskell is difficult and
unnatural, it's
true (although technically speaking it is possible). That said,
nobody's
yet to present a convincing argument to me why Java gets a free
pass for
lacking closures and typeclasses.



I might be wrong, but doesn't Java's concepts of inner classes and
interfaces together with adapter classes can be used to replace closures
and typeclasses in a way?

An inner class allows you to implicitly capture the parent object
("environment"), just like a closure does in a sense.

Interfaces group together methods, like type classes do. 

Although I'm actually a C# fanboy for doing "industrial" programming, I
think the Java designers did an excellent job, finding a good balance in
language features, ease of use and readability, and although C# does
offer closures and many more FP constructs, I really miss the above Java
constructs.



=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] mtl and transformers

[Sittampalam, Ganesh]

Ivan Lazar Miljenovic wrote:
> Martijn van Steenbergen  writes:
>> Another solution is to build your applications using Cabal and
>> specify your dependency on mtl in the cabal file.
> 
> But until we have "cabal ghci", this completely fails for actual
> hacking purposes... 

Just do cabal build -v, then cut and paste the ghc --make command-line and 
replace --make with --interactive.

Obviously rather a hack, but remarkably usable in practice, in my experience.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] darcs 2.4 beta 1 release

[Sittampalam, Ganesh]

Obviously source code documentation would be nice, but why is it 
"show-stopping"?

Ivan Lazar Miljenovic wrote:
> I really feel that bug 1720 [1] is a show-stopping bug for darcs,
> especially since it means that building Haddock for darcs with
> GHC-6.12.* isn't possible. 
> 
> [1] http://bugs.darcs.net/issue1720
> 
> I tried to make a fix, but didn't know enough of how darcs is
> documented to be able to do anything. 
> 
> 
> Reinier Lamers  writes:
> 
>> Hi all,
>> 
>> The darcs team would like to announce the immediate availability of
>> darcs 2.4 beta 1. darcs 2.4 will contain many improvements and
>> bugfixes compared to darcs 2.3.1. Highlights are the fast index-based
>> diffing which is now used by all darcs commands, and the interactive
>> hunk-splitting in darcs record. This beta is your chance to
>> test-drive 
>> these improvements and make darcs even better.
>> 
>> If you have installed the Haskell Platform or cabal-install, you can
>> install this beta release by doing:
>> 
>>   $ cabal update
>>   $ cabal install --reinstall darcs-beta
>> 
>> Alternatively, you can download the tarball from
>> http://darcs.net/releases/darcs-2.3.98.1.tar.gz , and build it by
>> hand 
>> as explained in the README file.
>> 
>> A list of important changes since 2.3.1 is as follows (please let me
>> know if there's something you miss!):
>> 
>>* Use fast index-based diffing everywhere (Petr)
>>* Interactive patch splitting (Ganesh)
>>* An 'optimize --upgrade' option to convert  to hashed format
>> in-place  (Eric) 
>>* Hunk matching (Kamil Dworakowski, tat.wright)
>>* Progress reporting is no longer deceptive (Roman Plášil)
>>* A 'remove --recursive' option to remove a directory tree from
>> revision  control (Roman Plášil) 
>>* A '--remote-darcs' flag for pushing to a host where darcs isn't
>> called  darcs 
>>* Many miscellaneous Windows improvements (Salvatore, Petr and
>> others) 
>>* 'darcs send' now mentions the repository name in the email body
>> (Joachim) 
>>* Handle files with boring names in the repository correctly
>> (Petr) 
>>* Fix parsing of .authorspellings file (Tomáš Caitt)
>>* Various sane new command-line option names (Florent)
>>* Remove the '--checkpoint' option (Petr)
>>* Use external libraries for all UTF-8 handling (Eric, Reinier)
>>* Use the Haskell zlib package exclusively for compression (Petr)
>> 
>> Kind Regards,
>> the darcs release manager,
>> Reinier Lamers
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe


=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: no sparks?

[Sittampalam, Ganesh]

\a b -> Left a `amb` Right b



From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Jamie Morgenstern
Sent: 21 December 2009 16:50
To: Benedikt Huber
Cc: haskell-cafe@haskell.org
Subject: [Haskell-cafe] Re: no sparks?


Thank you for all of the responses! The amb package is something like
what I want; though, as aforementioned, the right and left rules won't
return the same proof and so we can't really use it here. 

I've been thinking about this problem generally, not just in the Haskell
setting. It makes sense (in the very least, with theorem proving)
to allow 
 
a p|| b 

to return the value of a or b, whichever returns first, wrapped in a
constructor which would allow you to case analyze which result returned

case (a p|| b) of 
 (1, Xa) = ...
 (2, Xb) = ...



On Sun, Dec 20, 2009 at 8:52 PM, Benedikt Huber  wrote:


Daniel Fischer schrieb:


Am Sonntag 20 Dezember 2009 23:25:02 schrieb Jamie
Morgenstern:


Hello;


Also, I was wondering if something akin to a
"parallel or" exists. By this,
I mean I am looking for a function which, given
x : a , y : a, returns
either, whichever computation returns first.



This wouldn't be easy to reconcile with referential
transparency.
You can do that in IO, roughly

m <- newEmptyMVar
t1 <- forkIO $ method1 >>= putMVar m
t2 <- forkIO $ method2 >>= putMVar m
rs <- takeMVar m
killThread t1
killThread t2
return rs



And in this case (returning (Maybe Proof)), you are not happy
with any of the results, but with one of the proofs. So you would need
something like

solve :: Ctx -> Prop -> Int -> IO (Maybe Proof)
solve ctx goal n = amb leftRight rightLeft
 where
   leftRight = m1 `mplus` m2
   rightLeft = m2 `mplus` m1 

   m1 = (tryRight ctx goal n)
   m2 = (tryLeft ctx goal n)


I think the idea of directly supporting this kind of thing is
quite interesting.

benedikt




=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Sittampalam, Ganesh]

Gregory Crosswhite wrote:
>> Tom Tobin wrote:
>> 
>> The 3 clause BSD license is officially a GPL compatible license. 
>> See: 
>> 
>>   
>> http://www.gnu.org/licenses/license-list.html#GPLCompatibleLicenses 
>> 
>> It is within the terms of the GPL to link GPL code to a bunch of BSD3
>> code as long as you abide by both the GPL and the BSD3 license.
> 
> That really just means that BSD3 code can be used in GPL code;  you
> still have to release your own code as GPL if you are including any
> GPL code.  

The main licence of darcs is GPL, but I've licensed all my contributions
to it as BSD3. My view of this is that while darcs as a whole is
obviously still GPL, any of my contributions that can be extracted
independently can be used in other projects under BSD3.

I'd say that with hakyll, the library itself can be under BSD3 but any
executable you produce from it at the moment will necessarily be GPL.
Not sure if there's any good way to communicate this fact in the
metadata, though.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Working with multiple projects

[Sittampalam, Ganesh]

To install a package from local sources, just run 'cabal install' in the
directory with the package's .cabal file.

Tony Morris wrote:
> I don't want to have to upload every time I make a minor change as I
> am working. Surely there is an easier way. 
> 
> Martijn van Steenbergen wrote:
>> Tony Morris wrote:
>>> I have two projects that I intend to put on hackage soon. One
>>> depends on the other. I have "cabaled" both. I am wondering how
>>> others work with this kind of set up where changes are made to both
>>> libraries as they work.
>> 
>> You just update and re-upload the packages as necessary. It really
>> helps here if you follow the versioning guidelines:
>> 
>> http://www.haskell.org/haskellwiki/Package_versioning_policy
>> 
>> HTH,
>> 
>> Martijn.


=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Why MTL and Transformers?

[Sittampalam, Ganesh]

Gregory Crosswhite wrote:
> Something that I have been wondering for a while is:  why are there
> *still* two monad transformer libraries with seemingly identical
> functionality, especially given that they have conflicting
> namespaces?  It creates stupid problems like the one that Erik
> encountered and had to work around.   
> 
> I recognize that this situation most likely came about via historical
> accident rather than by intention, but why does it continue to be
> true?  

The intention is to migrate to transformers, which has a slightly better
design and separates out the functional dependencies into a separate
package (monads-fd), thus allowing use of the type families variant
(monads-tf) instead.

This has been discussed to some extent on the libraries list and a
workable strategy involving making a new mtl 2.0 that re-exports
transformers has been suggested. However the migration from extralibs to
the Haskell Platform put the brakes on further progress for a bit.

Now that this migration is essentially complete I have been intending to
revive the proposal but haven't got round to it yet. Please do jump in
and do so yourself if you feel motivated!

Cheers,

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] A proposals

[Sittampalam, Ganesh]

Martijn van Steenbergen wrote:
> wren ng thornton wrote:
>> Another nice
>> thing this suggests is the ability to use underscore as a pattern for
>> when you know the compiler will infer the type but it's too complex
>> to want to write out (e.g. while experimenting).
> 
> I'd love this!

F# has this and I find it very useful.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Haskell -> .NET

[Sittampalam, Ganesh]

I think Sigbjorn's binding (http://haskell.forkio.com/dotnet/
  as linked below) is the most
complete and likely to work, but it's still just a binding not a
compiler backend.



From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Matthew
Podwysocki
Sent: 16 September 2009 15:25
To: Peter Verswyvelen
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Haskell -> .NET


There was in fact another attempt as well, Salsa:
http://haskell.org/haskellwiki/Salsa

This showed quite a bit of promise but unfortunately was not more than
just an experiment.

Matt


On Wed, Sep 16, 2009 at 10:21 AM, Peter Verswyvelen 
wrote:


Yes, but interop only touches the surface of what is possible.

When a Haskell compiler could create IL code, it would be
possible to
use the generated code inside a sandbox, e.g. to be used on the
web as
loadable Silverlight code.

Of course the same could be said about other virtual machines,
such as
Flash or Java, but I don't know about the tail call issue here.

I guess for now F# would be the best option, but it would be
awesome
if Haskell compilers could have more backends.

I realize this is a very big undertaking, and has been mentioned
before, but it doesn't hurt to refresh the cache lines once in a
while, so maybe some bright student picks this up and hacks
together
something cool during the summer :)


On Wed, Sep 16, 2009 at 4:03 PM, Paul Sujkov 
wrote:
> Hi Peter,
>
> it seems that this question has been already raised before:
>
>
http://www.haskell.org/pipermail/haskell-cafe/2005-January/008244.html
>
> and there are some .Net interop implementations on the net (it
is a question
> how mature they are, however):
>
> http://php.cin.ufpe.br/~haskell/haskelldotnet/
 
> http://haskell.forkio.com/dotnet/
>
> 2009/9/16 Peter Verswyvelen 
>>
>> I heard that compiling Haskell to Java is not obvious since
tail calls
>> are not supported.
>>
>> .NET's intermediate language (IL) does support tail calls,
however it
>> is currently slower than regular calls, and is not always
supported by
>> all JITs.
>>
>> But given that F# will soon be officially released, I hope
that
>> eventually tail calls will work as expected, and fast
>>
>> See e.g.
>>
http://blogs.msdn.com/clrcodegeneration/archive/2009/05/11/tail-call-imp
rovements-in-net-framework-4.aspx
>>
>> So, might it be worth considering a .NET backend for a
Haskell compiler?
>>
>> Peter Verswyvelen
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> --
> Regards, Paul Sujkov
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe




=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Control.Exception base-3/base-4 woes

[Sittampalam, Ganesh]

Neil Brown wrote:

> Can anyone tell me how to fix this?  I don't think that changing to
> always use Control.Exception would fix this, because I need to give a
> different type for catch in base-3 to base-4, so there's still the
> incompatibility to be dealt with.   

http://hackage.haskell.org/package/extensible-exceptions ?

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Credit Suisse is hiring

[Sittampalam, Ganesh]

Hi,

Just to chime in with the spate of job advertisements, the Global Modelling and 
Analytics Group (GMAG) at Credit Suisse is once again looking to hire 
functional programmers.

The group consists of about 130 people worldwide. The majority of the group are 
mathematicians engaged in developing mathematical models for financial products 
traded by the division. Approximately 20 people are primarily computing 
experts, based in the Architecture and Delivery (AD) subgroup within GMAG, and 
successful candidates will also be based in this group.

We are already making heavy use of functional programming within the group, and 
we expect to increase this in the future. Some information about our Haskell 
projects can be found here: 
http://www.haskell.org/communities/05-2009/html/report.html#creditsuisse ; more 
recently we have adopted F# for implementing and deploying models on the .NET 
platform and we are currently ramping up our F# usage. 

Our team works closely with the modellers to help them leverage functional 
programming to improve the design of their code.

Key requirements:

At least one of:
 - An academic track record in functional programming.
 - Significant experience of "real-world" computing environments, preferably 
using functional programming. 
Excellent communication skills in order to convey new ideas to our modelling 
team. 

Location: London or New York 

Contact: 
Howard Mansell  

Myself (Ganesh Sittampalam ) and Tobias 
Gedell  will be attending ICFP 2009 and 
associated workshops in Edinburgh - if you'd like to discuss this in person, 
get in touch with us by email, or just grab one of us there.

Background information: 

As one of the world's leading banks, Credit Suisse provides its clients with 
investment banking, private banking and asset management services worldwide. 
Founded in 1856, Credit Suisse has a long tradition of meeting the complex 
financial needs of a wide range of clients, offering advisory services, 
comprehensive solutions and innovative products to companies, institutional 
clients and high-net-worth private clients globally. Credit Suisse is active in 
over 50 countries and employs approximately 46,000 people. Further information 
can be found at www.credit-suisse.com. 
Cultural diversity is essential to our success. As such, we employ people from 
more than 100 countries. Credit Suisse empowers employees to work openly and 
respectfully with each other and with clients, ultimately striving to deliver 
superior results while offering initiatives and programs to assist employees 
achieve a healthy work-life balance.

The Global Modelling and Analytics Group (GMAG) is responsible for producing 
state-of-the-art pricing, trading and risk management models for Credit Suisse. 
These models are used across a range of businesses in the Fixed Income and 
Equity departments. The group performs the full spectrum of quantitative work, 
from mathematical modelling through software implementation and delivery, to 
risk analysis of trades and existing portfolios. The group's mandate covers all 
major asset classes, including Credit Derivatives, Commodities, Emerging 
Markets, Equity Derivatives and Convertibles, Exotics, Foreign Exchange, Fund 
Linked Products, Interest Rate Products and Mortgage Derivatives. GMAG operates 
globally with members located in London, New York, Hong Kong, Tokyo, Zurich and 
São Paolo.

Established in 1990, GMAG stands out as a unified quant group that has been 
covering all major product areas since its inception. The group has always 
enjoyed a strong relationship with Trading, Structuring and Sales, assisting 
them with trade pricing and risk management. As the group is based on the 
trading floor, it is ideally placed to respond to the financial modelling needs 
of the businesses it supports. The breadth of GMAG's mandate makes it uniquely 
positioned to leverage the skills and experience of its members, and to provide 
a consistent modelling approach across all areas. Over time, the group has 
developed an extensive suite of pricing models on a common platform with 
complete integration across all asset classes.

Quantitative Analysts in GMAG carry out a range of activities which include the 
creation of sophisticated mathematical models for the valuation of complex 
derivatives, development of the technology platform used to deliver models and 
driving the use of these models throughout the bank. Our Quantitative Analysts 
typically hold an advanced quantitative degree, have excellent analytical and 
problem-solving skills, demonstrate creative thinking, have strong programming 
skills, and are confident communicators.




=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
==

RE: [Haskell-cafe] Re: DDC compiler and effects; better than Haskell?

[Sittampalam, Ganesh]

What would preOrder foldr/foldl mean? What about preOrder (reverse . map) and 
preOrder (map . reverse) ?

Another option would be for map to take a "strategy" as a parameter, sort of 
like Control.Parallel.Strategies.

Peter Verswyvelen wrote:
> Well, in DDC I believe the order is left to right.
> 
> But you guys are right, many orders exist.
> 
> On the other hand, a language might offer primitives to convert
> pure-to-effectfull functions no, in which you indicate the order you
> want.  
> 
> e.g. preOrder map
> 
> No?
> 
> (anyway Oleg's reply seems to give a definite answer to this thread
> no? :-) 
> 
> On Thu, Aug 13, 2009 at 11:06 AM, Heinrich
> Apfelmus wrote: 
>> Russell O'Connor wrote:
>>> Peter Verswyvelen wrote:
>>> 
 I kind of agree with the DDC authors here; in Haskell as soon as a
 function has a side effect, and you want to pass that function to a
 pure higher order function, you're stuck, you need to pick the
 monadic version of the higher order function, if it exists. So
 Haskell doesn't really solve the modularity problem, you need two
 versions of each higher order function really,
>>> 
>>> Actually you need five versions: The pure version, the pre-order
>>> traversal, the post-order traversal, the in-order traversal, and the
>>> reverse in-order traversal.  And that is just looking at syntax.  If
>>> you care about your semantics you could potentially have more (or
>>> less). 
>> 
>> Exactly! There is no unique choice for the order of effects when
>> lifting a pure function to an effectful one.
>> 
>> For instance, here two different versions of an effectful  map :
>> 
>>   mapM f []     = return []
>>   mapM f (x:xs) = do
>>       y  <- f x
>>       ys <- mapM f xs
>>       return (y:ys)
>> 
>>   mapM2 f []     = return []
>>   mapM2 f (x:xs) = do
>>       ys <- mapM2 f xs
>>       y  <- f x
>>       return (y:ys)
>> 
>> Which one will the DCC compiler chose, given
>> 
>>   map f []     = []
>>   map f (x:xs) = f x : map f xs
>> 
>> ? Whenever I write a pure higher order function, I'd also have to
>> document the order of effects.
>> 
>> 
>> Regards,
>> apfelmus
>> 
>> --
>> http://apfelmus.nfshost.com
>> 
>> ___
>> 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


=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?

[Sittampalam, Ganesh]

Sebastian Fischer wrote:
> On Jul 28, 2009, at 11:06 AM, Sittampalam, Ganesh wrote:
> 
>>> perms = sortByM (const [True,False])
>> 
>> and moreover the results will depend on the sorting algorithm chosen.
> 
> Is it only that different sorting algorithms enumerate all
> permutations in different orders or is there a sorting algorithm,
> such that the above definition does not enumerate all permutations?  
> 
[..]
> Hence, perm as defined above can yield a list that contains all
> permutations of the input (at least once) regardless of the sorting
> algorithm.  
> 
> Where is the hitch?

The "at least once" bit - unless your non-determinism is based on set
rather than bag semantics, it's wrong to duplicate results.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?

[Sittampalam, Ganesh]

> perms = sortByM (const [True,False])

This doesn't seem right, since the comparison function is inconsistent
and moreover the results will depend on the sorting algorithm chosen.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Proposal: TypeDirectedNameResolution

[Sittampalam, Ganesh]

(To be clear, this about Cale's proposal, not simonpj's one)

Johannes Waldmann wrote:
> Sittampalam, Ganesh wrote:
> 
>> ... it would make it substantially less likely that subexpressions
>> could be abstracted into a separate declaration without giving a type
>> signature to fix the type of the new declaration.
> 
> OK, then give a type signature to fix the type of (really, to
> document) the new declaration. 
> 
> I can't understand why declarative programmers insist they should be
> able to omit (type) declarations ... 

I find type inference a valuable feature. Generally at some point I
annotate top-level declarations, but while developing it's nice not to
have to worry about it. Having to annotate every single declaration
would be painful.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Proposal: TypeDirectedNameResolution

[Sittampalam, Ganesh]

Cale Gibbard wrote:

> There was a great related idea on #haskell the other day: Make
> explicit qualification unnecessary whenever there is a *unique*
> choice of module qualifications from those imported which would make
> the expression typecheck. Ambiguities would still need to be
> qualified, but I feel that this would eliminate 99% of all ugly
> qualified names from code. It would be especially good in the case of
> infix operators, which as far as I know, nobody actually enjoys
> qualifying explicitly.   
> 
[...]
> What do people think of this idea? Personally, it really annoys me
> whenever I'm forced to give explicit module qualifications, and I
> think this would really help. It would also subsume the
> DisambiguateRecordFields extension rather handily.   

I think this idea would severely damage compositionality. One example of
this is that it would make it substantially less likely that
subexpressions could be abstracted into a separate declaration without
giving a type signature to fix the type of the new declaration.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Implicit concatenation in list comprehensions

[Sittampalam, Ganesh]

Roel van Dijk wrote:
> On Mon, Jul 20, 2009 at 1:27 PM, Roel van
> Dijk wrote: 
>> I think the tuple sections are a great idea! It also makes tuple
>> types and constructors more alike: 
>> 
>> x :: (,) String Double
>> x = (,) "Pi" 3.14159
> 
> I just realised this is already in GHC :-) But does you patch also
> add the equivalent for tuple type annotations? 
> 
> x :: (String, ) Double
> x = ("Pi", ) 3.14159
> 
> I am also wondering what the following would/should mean:
> 
>   (1, , ( , 2), ) 'a' 'b' 'c'

I would expect it to be a type error, since I think the following is the
only sane type the tuple can have (assuming numeric literals :: Int):

(1, , ( , 2), ) :: a -> b -> (Int, a, c -> (c, Int), b)

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] A small puzzle: inTwain as function of foldr

[Sittampalam, Ganesh]

Martijn van Steenbergen wrote:

> Consider the function inTwain that splits a list of even length
> evenly into two sublists: 
> 
>  > inTwain "Hello world!"
> ("Hello ","world!")
> 
> Is it possible to implement inTwain such that the recursion is done
> by one of the standard list folds? 

Does this help? http://www.brics.dk/RS/02/12/BRICS-RS-02-12.pdf

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Bool as type class to serve EDSLs.

[Sittampalam, Ganesh]

There are multiple possible classes that you might want under different
circumstances (I think the most interesting issue is whether the class
(==), (>) etc is in has a fundep from the type of the thing being
compared to the type of the boolean), but if NoImplicitPrelude (or some
other extension) just desugars if-then-else into ifthenelse (with a
default implementation of ifthenelse somewhere) I think that would be
enough.

Of course once you've got ifthenelse you find yourself wanting explicit
desugaring of pattern matching (could view patterns help here?),
recursion (into an explicit use of fix), etc...

Cheers,

Ganesh

Simon Peyton-Jones wrote:
> You are absolutely right about the tantalising opportunity.  I know
> that Lennart has thought quite a bit about this very point when
> designing his Paradise system.  Likewise Conal for Pan.  
> 
> One difficulty is, I think, that it's easy to get ambiguity.  Eg
> ifthenelse (a > b) e1 e2
> The (a>b) produces a boolean-thing, and ifthenelse consumes it; but
> which type of boolean?  The Expr type?  Real Bools? Or what? 
> 
> If there was a nice design, then GHC's existing -fno-implicit-prelude
> flag could be extended (again) to desugar if-then-else to the new
> thing.  But the design is unclear, to me anyway.  
> 
> Simon
> 
>> -Original Message-
>> From: haskell-cafe-boun...@haskell.org
>> [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Sebastiaan
>> Visser Sent: 27 May 2009 13:32
>> To: Haskell Cafe
>> Subject: [Haskell-cafe] Bool as type class to serve EDSLs.
>> 
>> Hello,
>> 
>> While playing with embedded domain specific languages in Haskell I
>> discovered the Num type class is a really neat tool. Take this simple
>> example embedded language that can embed primitives from the output
>> language and can do function application.
>> 
>>  >data Expr :: * -> * where
>>  >  Prim :: String -> Expr a
>>  >  App  :: Expr (a -> b) -> Expr a -> Expr b
>> 
>> Take these two dummy types to represent things in the output
>> language. 
>> 
>>  >data MyNum
>>  >data MyBool
>> 
>> Now it is very easy to create an Num instance for this language:
>> 
>>  >primPlus :: Expr (MyNum -> MyNum -> MyNum)  >primPlus = Prim
>> "prim+" 
>> 
>>  >instance Num (Epxr MyNum) where
>>  >  a + b = primPlus `App` a `App` b
>>  >  fromInteger = Prim . show
>>  >  ...
>> 
>> Which allows you to create very beautiful expression for your
>> language embedded inside Haskell. The Haskell expression `10 * 5 +
>> 2' produces a nice and well typed expression in your embedded domain.
>> 
>> But unfortunately, not everyone in the Prelude is as tolerant as the
>> Num instance. Take the Eq and the Ord type classes for example, they
>> require you to deliver real Haskell `Bool's. This makes it impossible
>> make your DSL an instance of these two, because there are no `Bool's
>> only `Expr Bool's. 
>> 
>> Which brings me to the point that, for the sake of embedding other
>> languages, Haskell's Prelude (or an alternative) can greatly benefit
>> from (at least) a Boolean type class like this:
>> 
>> class Boolean a where
>>ifthenelse :: a -> b -> b -> b -- Not sure about this
>>representation. ...
>> 
>> And one instance:
>> 
>>  >instance Boolean (Expr MyBool) where  >  ifthenelse c a b = Prim
>> "if-then-else" `App` c `App` a `App` b
>> 
>> Now we can change (for example) the Eq type class to this:
>> 
>>  >class Eq a where
>>  >  (==) :: Boolean b => a -> a -> b
>>  >  (/=) :: Boolean b => a -> a -> b
>> 
>> For which we can give an implementation for our domain:
>> 
>>  >primEq :: Epxr (a -> a -> MyBool)
>>  >primEq = Prim "=="
>> 
>>  >instance Eq (Expr a) where
>>  >  a == b = primEq `App` a `App` b
>> 
>> And now we get all functionality from the Prelude that is based on Eq
>> (like not, &&, ||, etc) for free in our domain specific language! Off
>> course there are many, many more examples of things from the standard
>> libraries that can be generalised in order to serve reuse in EDSLs.
>> 
>> Anyone already working on such a generalized Prelude? I can imagine
>> much more domains can benefit from this than my example above. Any
>> interesting thoughts or pointers related to this subject?
>> 
>> Gr,
>> 
>> --
>> Sebastiaan Visser
>> 
>> ___
>> 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


=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-

RE: [Haskell-cafe] Strange type error with associated type synonyms

[Sittampalam, Ganesh]

Simon Peyton-Jones wrote:

> NoMatchErr.hs:20:11:
> Couldn't match expected type `Memo d'
>against inferred type `Memo d1'
>   NB: `Memo' is a (non-injective) type function
> In the second argument of `(.)', namely `appl'
> In the expression: abst . appl
> In the definition of `f': f = abst . appl
> 
> (Rather than give its kind, I thought it was better to focus on the
> reason for the mis-match, namely the non-injectivity.) 

I'd suggest "is a type function and thus may not be injective" or
similar, otherwise people will think that type functions which are
injective according to the instances they've defined would be ok.

Cheers,

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] I love purity, but it's killing me.

[Sittampalam, Ganesh]

Yes, though we don't bother with weak pointers as we only keep the
stable names map around for the duration of CSE so there's no ongoing
memory leak issue.
 


From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Conal Elliott
Sent: 27 May 2009 16:14
To: Sittampalam, Ganesh
Cc: Haskell Cafe
Subject: Re: [Haskell-cafe] I love purity, but it's killing me.



In my experience [1], observable sharing using GHC's stable
names is a pretty effective solution to this problem.


Plus unsafePerformIO and weak references as in Stretching the storage
manager: weak pointers and stable names in Haskell
<http://citeseer.ist.psu.edu/peytonjones99stretching.html> ?

Lacking a more elegant alternative, that's what I'll probably do again,
as in Pan, Vertigo, and Pajama.

  - Conal


On Wed, May 27, 2009 at 3:51 AM, Sittampalam, Ganesh
 wrote:


Sebastiaan Visser wrote:
> On May 27, 2009, at 1:49 AM, Conal Elliott wrote:
>> Hi Tom,
>>
>> I've been working on another code-generating graphics
compiler,
>> generating GPU code.  As always, I run into the problem of
efficient
>> common subexpression elimination.  In Pan, Vertigo & Pajama,
I used
>> lazy memoization, using stable pointers and weak references,
to avoid
>> the worst-case-exponential behavior you mention below.  I'm
now using
>> a bottom-up CSE method that's slower and more complicated
than I'm
>> going for.
>
> What do you mean with `exponential behavior'? Exponential
related to
> what?
>
> For my FRP EDSL to JavaScript (toy) compiler[1] I've been
> implementing CSE as well. I traverses the expression tree
recursively
> and creates an small intermediate language containing id's
(pointers)
> to expressions instead of real sub-expressions.
>
> Maybe (probably) I am very naive, but I think this trick takes
time
> linear to the amount of sub-expressions in my script. When
using a
> trie instead of a binary tree for the comparisons there should
be no
> more character (or atomic expression) comparisons that the
amount of
> characters in the script.
>
> So the problem seems not to be CSE algorithm, but the fact
that EDSL
> itself tends to blow up because it is hosted in Haskell. Like
Tom's
> example:
>
>  > let d = Add c c
>  > e = Add d d-- "e" now as 16 leaf nodes.
>
> But again, I might be missing some important point here.


That's exactly right. But it's pretty inconvenient to have your
expression tree to blow up exponentially in relation to the code
the
user actually wrote! You can indeed construct an intermediate
language
that collapses this blowup, but the pass to create it must take
exponential time if written completely purely, since it has to
visit
everything at least once.

In my experience [1], observable sharing using GHC's stable
names is a
pretty effective solution to this problem.

Ganesh

[1] http://www.earth.li/~ganesh/research/paradise-icfp08/
<http://www.earth.li/%7Eganesh/research/paradise-icfp08/> 



===
 Please access the attached hyperlink for an important
electronic communications disclaimer:
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html


===





=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] I love purity, but it's killing me.

[Sittampalam, Ganesh]

Sebastiaan Visser wrote:
> On May 27, 2009, at 1:49 AM, Conal Elliott wrote:
>> Hi Tom,
>> 
>> I've been working on another code-generating graphics compiler,
>> generating GPU code.  As always, I run into the problem of efficient
>> common subexpression elimination.  In Pan, Vertigo & Pajama, I used
>> lazy memoization, using stable pointers and weak references, to avoid
>> the worst-case-exponential behavior you mention below.  I'm now using
>> a bottom-up CSE method that's slower and more complicated than I'm
>> going for.
> 
> What do you mean with `exponential behavior'? Exponential related to
> what? 
> 
> For my FRP EDSL to JavaScript (toy) compiler[1] I've been
> implementing CSE as well. I traverses the expression tree recursively
> and creates an small intermediate language containing id's (pointers)
> to expressions instead of real sub-expressions.   
> 
> Maybe (probably) I am very naive, but I think this trick takes time
> linear to the amount of sub-expressions in my script. When using a
> trie instead of a binary tree for the comparisons there should be no
> more character (or atomic expression) comparisons that the amount of
> characters in the script.
> 
> So the problem seems not to be CSE algorithm, but the fact that EDSL
> itself tends to blow up because it is hosted in Haskell. Like Tom's 
> example:
> 
>  > let d = Add c c
>  > e = Add d d-- "e" now as 16 leaf nodes.
> 
> But again, I might be missing some important point here.

That's exactly right. But it's pretty inconvenient to have your
expression tree to blow up exponentially in relation to the code the
user actually wrote! You can indeed construct an intermediate language
that collapses this blowup, but the pass to create it must take
exponential time if written completely purely, since it has to visit
everything at least once.

In my experience [1], observable sharing using GHC's stable names is a
pretty effective solution to this problem.

Ganesh

[1] http://www.earth.li/~ganesh/research/paradise-icfp08/

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: [Haskell] [ANN] Safe Lazy IO in Haskell

[Sittampalam, Ganesh]

Nicolas Pouillard wrote:
> Excerpts from Ryan Ingram's message of Tue May 19 10:23:01 +0200 2009:
>> To be fair, you can do this with some extensions; I first saw this in
>> a paper on Oleg's site [1].  Here's some sample code:
> 
> This seems like the same trick as the rmonad package:
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/rmonad

It's similar, but rmonad uses an associated datatype to wrap up the
constraint, and doesn't split the Monad class up into separate pieces
(which generally makes type inference harder).

rmonad also supplies an embedding to turn any restricted monad into a
normal monad at the cost of using embed/unEmbed to get into and out of
the embedding.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] conflicting variable definitions in pattern

[Sittampalam, Ganesh]

Conor McBride wrote:
> On 15 May 2009, at 09:11, Sittampalam, Ganesh wrote:
>>
>> but then pattern matching can introduce Eq constraints which some
>> might see as a bit odd.
> 
> Doesn't seem that odd to me. Plenty of other language features come
> with constraints attached. 

It's the introduction of a constraint from tweaking a pattern that is
odd, I think. By way of precedent H98 rejected this kind of idea in
favour of putting 'fail' into Monad.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] conflicting variable definitions in pattern

[Sittampalam, Ganesh]

Martin Hofmann wrote:
> It is pretty clear, that the following is not a valid Haskell pattern:
> 
> foo (x:x:xs) = x:xs
> 
> My questions is _why_ this is not allowed. IMHO, the semantics should
> be 
> clear: The pattern is expected to succeed, iff 'x' is each time bound
> to the same term. 

How do you define the "same term"?

One natural way of compiling it would be to

foo (x:y:xs) | x == y = x:xs

but then pattern matching can introduce Eq constraints which some might
see as a bit odd.

> Isn't this allowed, because this would require a strict evaluation of
> the 'x' variables? 

The translation into == would probably introduce some strictness, for
most implementations of Eq. I don't think this is a huge problem in
itself.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Removing mtl from the Haskell Platform

[Sittampalam, Ganesh]

rocon...@theorem.ca wrote:

> I think that use of the mtl should be deprecated so that we move on
> to improved monad transformer libraries.  Having the mtl in the
> Haskell Platform does the opposite by further entrenching its use,
> possibly to the point where we may not be able to get rid of it for
> years.

> 
> If I had to recommend a replace library, I would pick monadLib. 
> However, there are other libraries, such as the mmtl and transformers
> and it's related packages that I haven't looked at, and may also make
> fine replacements for the mtl.   

We've discussed replacing it with transformers+monads-fd+an mtl
compatiblity layer on librar...@. Ross and I plan to propose doing this
for the second release of the platform - it's not fair to disrupt the
first release at this stage.

transformers+monads-fd is quite a small evolution over mtl - it factors
out the fundeps into a separate package, tightens up some of the class
constraints, and makes State = StateT Identity etc rather than a
separate type. Even this breaks a few packages, but doing anything more
substantial would be quite disruptive. That's not to say that we
shouldn't do it, though.

I guess the libraries@ list will continue to be the place that such
decisions get made, but I think it's a bit up in the air at the moment.

Cheers,

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [darcs-users] [Haskell-cafe] Darcs as undo/redo system?

[Sittampalam, Ganesh]

Wolfgang Jeltsch wrote:
> Am Freitag, 8. Mai 2009 18:43 schrieb Jason Dagit:
>> If you wanted to work on this, I would encourage you to read more
>> about patch theory[1,2,3,4] and also try out libdarcs[5].
> 
> Is libdarcs the same as the darcs library package on Hackage (which
> exports the darcs API)? 

Yes.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] is value evaluated?

[Sittampalam, Ganesh]

Brandon S. Allbery KF8NH wrote:
> On May 8, 2009, at 16:31 , Sittampalam, Ganesh wrote:
>> Brandon S. Allbery KF8NH wrote:
>>> Unless it catches exceptions itself (which strikes me as a bad idea;
>>> it becomes a trivial way to ignore exceptions, leading to bad
>>> programming practices) either they're handled inside the _|_ (in
>>> which case it isn't _|_ from the standpoint of our test) or in an
>>> outer scope (in which case our test produces _|_ from the standpoint
>>> of the exception handler).
>> 
>> Surely it just needs to inspect the thunk to decide whether it's _|_
>> or not, rather than entering it?
> 
> 
> The point is it can never be given a thunk that is _|_ because
> exception handling will have either converted it to a non-_|_ or
> shunted past the test.

You can set up a thunk in one place, enter it wrapped in a catch in
another place, and then inspect it in a third place, e.g. (somewhat
pseudo-code):

do let x = if 1==1 then error "foo" else 3
   y <- catch (evaluate x) (\_ -> 2)
   b <- isEvaluated x

Cheers,

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] is value evaluated?

[Sittampalam, Ganesh]

Brandon S. Allbery KF8NH wrote:
> On May 8, 2009, at 13:08 , Sittampalam, Ganesh wrote:
>> Brandon S. Allbery KF8NH wrote:
>>> and therefore must be in IO.  You may be thinking that it would
>>> return a result for _|_, but as described if you fed it _|_ it could
>>> only produce False (if the _|_ has been evaluated you would not be
>>> able to reach the test).
>> 
>> It could probably return True in GHC since you can catch exceptions.
>> That still doesn't mean it solves the halting problem, of course.
> 
> Unless it catches exceptions itself (which strikes me as a bad idea;
> it becomes a trivial way to ignore exceptions, leading to bad
> programming practices) either they're handled inside the _|_ (in
> which case it isn't _|_ from the standpoint of our test) or in an
> outer scope (in which case our test produces _|_ from the standpoint
> of the exception handler). 

Surely it just needs to inspect the thunk to decide whether it's _|_ or
not, rather than entering it?

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] is value evaluated?

[Sittampalam, Ganesh]

Brandon S. Allbery KF8NH wrote:
> On May 8, 2009, at 01:33 , Joe Fredette wrote:
>> That strikes me as being bad in a "I'm violating the Halting Problem"
>> sort of way- but I'm not sure how. Is there some contradictory
>> construction that could be built from such a function?
> 
> I don't think it is; surely the Haskell runtime knows which thunks it
> has evaluated.  It just explicitly violates referential transparency,
> and therefore must be in IO.  You may be thinking that it would
> return a result for _|_, but as described if you fed it _|_ it could
> only produce False (if the _|_ has been evaluated you would not be
> able to reach the test). 

It could probably return True in GHC since you can catch exceptions.
That still doesn't mean it solves the halting problem, of course.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Why is Bool no instance of Num and Bits?

[Sittampalam, Ganesh]

Stephan Friedrichs wrote:

> When looking for an xor function, I found one in Data.Bits but
> couldn't use it for Bool, because Bool is no instance of Bits and of
> Num (which would be necessary, because it's "class (Num b) => Bits
> b"). My question is: Why not?  
> 
> [...]
> quite trivial... Why is this not part of base? Or am I missing
> something? 

One reason would be that we don't want 1 + True to typecheck, even if it
does have a sensible interpretation.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Data.Map and strictness (was: Is Haskell a GoodChoice for WebApplications?(ANN: Vocabulink))

[Sittampalam, Ganesh]

seq something like size map that will force a traversal of the entire
tree, and ensure that the result is actually demanded, e.g. when writing
to a TVar:

do ...
   let map' = Data.Map.delete key map
   size map' `seq` writeTVar tvar map'
   ...

(Not tested)

Note that this also won't force any of the values; it sounds like in
this case you don't want them forced.


-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Tim Docker
Sent: 07 May 2009 09:46
To: haskell-cafe@haskell.org
Subject: [Haskell-cafe] Data.Map and strictness (was: Is Haskell a
GoodChoice for WebApplications?(ANN: Vocabulink))


Actually, I'm unsure how to fix this. For an expression like this:

Data.Map.delete key map

how can I use seq (or something else) to sufficiently evaluate the above
to ensure that the value associated with key can be garbage collected?
My
knowledge of Data.Map is limited to it's haddock documentation.


-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Tim Docker
Sent: Thursday, 7 May 2009 6:04 PM
To: haskell-cafe@haskell.org
Subject: RE: [Haskell-cafe] Is Haskell a Good Choice for
WebApplications?(ANN: Vocabulink)

I think that multi-threading in combination with laziness makes space
usage harder to manage. In fact, just today I have discovered a problem
with a long running server process with a subtle space leak.

With a regular process that communicates with the outside world via IO,
I know that the act of communicating a value causes it to be fully
evaluated. However, with a multi threaded process, communication occurs
via writes to TVars/IOVars and nothing gets evaluated. This gives lots
of opportunities for space leaks. In this particularly case cleanup code
was removing a large entry from a map stored in a Tvar. Because that map
is only read infrequently, however, the memory release is delayed.

This is the second such problem I've found. The profiling tools do help
in discovering them, but it still needs a bit of thought and analysis. I
wonder if, for my application, I should work out some means of
deepseqing every value written to a Tvar.

Tim

-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of wren ng thornton
Sent: Thursday, 7 May 2009 2:06 PM
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Is Haskell a Good Choice for Web
Applications?(ANN: Vocabulink)

FFT wrote:
> Anton van Straaten wrote:
> 
> > The app is written for a client under NDA, so a blog about it would 
> > have to be annoyingly vague.
> 
> > No doubt the potential for encountering space leaks goes up as one 
> > writes less pure code, persist more things in memory, and depend on
more libraries.
> 
> Exactly. I'm worried about, e.g. needing to use something as simple as

> a stream of prime numbers (see the recent thread about leaks there)

The issues here are going to be the same in Haskell as in every other
language. There's always a tradeoff between the memory of caching old
results vs the time of recalculating them. At present no language's
RTS/GC is smart enough to make that tradeoff for you, and so memoization
must be done manually.

There are some tricks to help make this easier (e.g. weak pointers), but
the problem will always remain. The only thing that makes this perhaps
trickier than in other languages is that, AFAIK/R, the reflection API to
ask the RTS how it's feeling about memory at any given point isn't
terribly portable (between Haskell compilers) or polished/pretty. Then
again, the other GC languages I've dealt with aren't much better and are
often worse.

--
Live well,
~wren
___
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
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] compilation to C, not via-C

[Sittampalam, Ganesh]

Ryan Ingram wrote:
 
> There was
> another talk about compiling Haskell into Excel spreadsheets for
> finance, but I can't seem to locate it right now.   

It was an ICFP experience report.
http://www.earth.li/~ganesh/research/paradise-icfp08

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Template Haskell + Profiling

[Sittampalam, Ganesh]

Do your profiling builds with "-osuf p_o -hisuf p_hi", and then run a 
non-profiling build first. This means that both sets of object/hi files are 
available which placates TH.
 
Ganesh



From: haskell-cafe-boun...@haskell.org 
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Krzysztof Skrzetnicki
Sent: 24 April 2009 16:28
To: Haskell Cafe
Subject: [Haskell-cafe] Template Haskell + Profiling


Hi

I'm trying to build some modules that use TH with profiling enabled.

The normal build works:

$ ghc -fforce-recomp --make -cpp -O -DXQUERY2_TEST Main
[1 of 8] Compiling Text.XML.Expat.FormatCustom ( 
Text/XML/Expat/FormatCustom.hs, Text/XML/Expat/FormatCustom.o )
[2 of 8] Compiling DataStructures   ( DataStructures.hs, DataStructures.o )
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package syb ... linking ... done.
Loading package array-0.2.0.0 ... linking ... done.
Loading package packedstring-0.1.0.1 ... linking ... done.
Loading package containers-0.2.0.1 ... linking ... done.
Loading package pretty-1.0.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package mtl-1.1.0.2 ... linking ... done.
Loading package filepath-1.1.0.2 ... linking ... done.
Loading package old-locale-1.0.0.1 ... linking ... done.
Loading package old-time-1.0.0.2 ... linking ... done.
Loading package unix-2.3.2.0 ... linking ... done.
Loading package directory-1.0.0.3 ... linking ... done.
Loading package process-1.0.1.1 ... linking ... done.
Loading package random-1.0.0.1 ... linking ... done.
Loading package derive-0.1.4 ... linking ... done.
[3 of 8] Compiling Utils( Utils.hs, Utils.o )
[4 of 8] Compiling Semantics.Pure   ( Semantics/Pure.hs, Semantics/Pure.o )
[5 of 8] Compiling Database ( Database.hs, Database.o )
[6 of 8] Compiling XPathDSL ( XPathDSL.hs, XPathDSL.o )
[7 of 8] Compiling QueryParse   ( QueryParse.hs, QueryParse.o )
[8 of 8] Compiling Main ( Main.hs, Main.o )
Linking Main ...

But profiling one fails:

$ ghc -prof -auto -auto-all -fforce-recomp --make -cpp -O -DXQUERY2_TEST Main
[1 of 8] Compiling Text.XML.Expat.FormatCustom ( 
Text/XML/Expat/FormatCustom.hs, Text/XML/Expat/FormatCustom.o )
[2 of 8] Compiling DataStructures   ( DataStructures.hs, DataStructures.o )
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
DataStructures.hs:1:0:
Dynamic linking required, but this is a non-standard build (eg. prof).
You need to build the program twice: once the normal way, and then
in the desired way using -osuf to set the object file suffix.

The error message is somewhat cryptic to me. Does anyone know how to perform 
profiling build when using TH?

Regards

Christopher Skrzętnicki


=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) --firstrelease

[Sittampalam, Ganesh]

Jon Fairbairn wrote:
> "Sittampalam, Ganesh"  writes:

>> So I would say that {Haskell 98 - (n+k)} is itself a worthwhile
>> standard to implement.
> 
> It's not a standard. You have to document the difference (waste of
> time), programmers have to notice the difference (waste of time),
> books that describe H 98 no longer apply (waste of effort).

Interestingly, the removal discussion from Haskell'
(http://hackage.haskell.org/trac/haskell-prime/wiki/RemoveNPlusK)
explicitly mentions "some Haskell books use it (this was the main reason
it was kept in Haskell 98)" and also points out that the report
explicitly warned that they might be removed in future.

Presumably those were books about Haskell 1.4 or before. If n+k was only
kept to keep those books still valid, then they certainly shouldn't
survive any longer; any H98 books that used them deserve their fate,
IMO.

> You can
> argue that the wastes here are individually small, but you have to
> multiply them by the number of times they happen (and again, I'm
> taking n+k as an example of a general problematic attitude that's
> been with us since FORTRAN I*, rather than really arguing about n+k
> specifically).   

> [*] The FORTRAN IV standard contains some really quite entertaining
> examples of what happens when you try to standardise the intersection
> of divergent implementations of a programming language.  

I'd be much more inclined to agree with you if the example in question
was not n+k. Also, divergence by omission of features is much easier to
recover from than mutually incompatible implementation of the same
feature.

Ganesh


=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) --first release

[Sittampalam, Ganesh]

Jon Fairbairn wrote:
> "John A. De Goes"  writes:
> 
>> That's absurd. You have no way to access private source code, so any
>> decision on what features to exclude from future versions of Haskell
>> must necessarily look at publicly accessible source code.
> 
> This is all entirely beside the point. The question is not whether
> n+k patterns should be in the language, it's whether an
> implementation of Haskell 98 should include them.  

>> The only alternative is to continuously add, and never remove,
>> features from Haskell, even if no one (that we
>> know) uses them.
> 
> But we can remove them in future language versions. The point I was
> trying to make at the beginning of this subthread was that
> implementations should follow the definition, because having a core
> language (Haskell 98) that can be relied on is simpler and wastes
> less time than the alternative.

There has to be a bit of give and take here between standards and
implementations. The Haskell 98 standard is now very old and becoming
increasingly less relevant, hence the Haskell' effort. (n+k) patterns
were always controversial and the decision to include them has indeed
been reversed by the Haskell' committee. So I would say that {Haskell 98
- (n+k)} is itself a worthwhile standard to implement. UHC is clear that
this is what it has implemented, so it's not as if they are
misrepresenting themselves.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] (n+k) patterns

[Sittampalam, Ganesh]

Richard O'Keefe wrote:
 
> The thing is that it really seems bizarre to see this one feature
> singled out for non-implementation. 
> 
> If I can do the equivalent of n+k patterns by programming in the
> *type system*, why *not* in a pattern? 

Do you mean by something like the following?

data Z = Z
data S n = S n

type Plus2 a = S (S a)

minus2 :: Plus2 a -> a
minus2 _ = undefined -- or actually use the values, or whatever

If so, I'd say that n+k patterns go well beyond this kind of "pattern
aliases", particularly since they operate on arbitrary Nums, not just an
inductively defined natural number type.

Cheers,

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: ANNOUNCE: Utrecht Haskell Compiler (UHC) --first release

[Sittampalam, Ganesh]

Miguel Mitrofanov wrote:
> Jon Fairbairn wrote on 20.04.2009 13:59:
>> Achim Schneider  writes:
>> 
>>> Jon Fairbairn  wrote:
>>> 
 a...@cs.uu.nl writes:
 
>   Utrecht Haskell Compiler -- first release, version 1.0.0
>   
> 
> 
> The UHC team is happy to announce the first public release of the
> Utrecht Haskell Compiler (UHC). UHC supports almost all Haskell98
> features
 Why? Is there something about Haskell 98 that's hard to implement?
 
>>> Insanity. I doubt anyone is going to miss n+k patterns:
>> 
>> That (taken with the followup from Richard O'Keefe saying he does use
>> them) underlines my point, really. What follows is specific to
>> Haskell, but the general point applies to most languages I've
>> encountered. 
>> 
>> I have no love for n+k patterns, but they are part of
>> Haskell98 -- and were the subject of protracted arguments for and
>> against them before the Report was finished (I was against them, if I
>> remember correctly). Any implementation claiming to be of Haskell98
>> should have them, whether or not the implementor likes them, because
>> otherwise someone will come along with a valid Haskell98 programme
>> and it won't compile, so they'll have to hack it around. This sort of
>> thing (and resulting #ifdef all over the place) wastes far more
>> programmer time in the end (assuming the compiler becomes popular)
>> than it would take to implement the feature.
>> 
>> It's not an implementor's place to make such decisions -- they can
>> legitimately say "this feature sucks" and tell the next Haskell
>> committee so. If they care enough about it, they can lobby or get on
>> that next committee, but the arguments for n+k patterns /in
>> Haskell98/ were done long ago. 
>> 
>> 
> I disagree. First of all, UHC states explicitly that some features
> are not supported (and probably never would be). Secondly, it seems
> like almost nobody uses (n+k)-patterns, and when they are used, they
> make the code less readable; so it's good NOT to support them, in
> order to make programmers avoid them as much as possible. I don't
> think #ifdef's would be really "all over the place"; it's more likely
> that a minor refactoring would take place so that (n+k)-patterns
> would disappear.   

In addition, (n+k) patterns will be removed from the standard as soon as
the Haskell prime process produces a new one, so people who want to make
their code support that new standard should be removing them right now.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] ANNOUNCE: vacuum-cairo: a cairo frontend to vacuumfor live Haskell data visualization

[Sittampalam, Ganesh]

I have this problem too, but I don't understand it because
librsvg-2-2.dll is in the same directory as the rest of the gtk2hs DLLs
- c:/gtk2hs/0.10.0/bin on my system. Yesterday I was also having trouble
with not being able to find the glib DLL but that problem has
mysteriously vanished today leaving me with just the rsvg one.

The problem happens with 'ghci -package svgcairo' so it's nothing
specific to vacuum-cairo (unsurprisingly). This might be best asked
about on the gtk2hs mailing list
(https://lists.sourceforge.net/lists/listinfo/gtk2hs-users).

Mark Wassell wrote:
> Great work. However I am have a problem running on windows - it needs
> librsvg:
> 
> Prelude System.Vacuum.Cairo> view [1]
> Loading package mtl-1.1.0.2 ... linking ... done.
> Loading package parallel-1.1.0.0 ... linking ... done.
> Loading package glib-0.10.0 ... linking ... done.
> Loading package cairo-0.10.0 ... linking ... done.
> Loading package svgcairo-0.10.0 ... can't load .so/.DLL for:
> librsvg-2-2 (addDLL: could not load DLL)
> Prelude System.Vacuum.Cairo>
> 
> Anyone know where I can get this? I have googled around and whilst
> there is the librsvg development site, there is no sign of a windows
> DLL.  All I can find is some generic site which seems to provide
> DLLs. I don't trust it.   
> 
> Cheers
> 
> Mark
> 
> Don Stewart wrote:
>> I am pleased to announce the release of vacuum-cairo, a Haskell
>> library for interactive rendering and display of values on the GHC
>> heap using Matt Morrow's vacuum library.
>> 
>> This library takes vacuum's output, generates dot graph format from
>> it, renders it to SVG with graphviz, and displays the resulting
>> structure using the gtk2hs Cairo vector graphics bindings ... all at
>> the GHCi command line. 
>> 
>> This tool is useful for examining Haskell data structures as they are
>> represented directly in the heap. In particular, it makes sharing
>> visible for the first time, as well as unboxed values. It should be
>> useful for teaching Haskell, or for library authors debugging the
>> design of their data structures.
>> 
>> You can see pictures of the rendered display here:
>> 
>> http://code.haskell.org/~dons/images/vacuum/intmap.png
>> 
>> And youtube screencasts of vacuum-cairo in action:
>> 
>> http://www.youtube.com/watch?v=oujaqo9GAmA
>> 
>> Get it:
>> 
>> cabal install vacuum-cairo
>> 
>> And on Hackage:
>> 
>> 
>>
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/vacuum-cair
>> o 
>> 
>> -- Don
>> ___
>> 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


=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Conditional compilation

[Sittampalam, Ganesh]

Robin Green wrote:
> I am writing some code for citation support in gitit, and all the
> #ifdefs I'm using to do conditional compilation are a bit tiresome.
> 
> Suppose you have the requirement that a certain feature of your
> software be disable-able at compile time, to avoid having to pull in
> certain dependencies (which may not be available on all platforms).
> Disabling a feature may entail removing certain fields from certain
> constructors (again, to avoid pulling in certain dependencies), and/or
> removing certain functions from certain modules. What is the best way
> to do this in Haskell?

I would parameterise over the functionality (i.e. use type parameters to
datatypes and HOF parameters to functions where appropriate), and
instantiate the types with () or some useful type as appropriate. Some
CPP would still be required but hopefully only at the top level.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: Haskell Logo write-in candidate

[Sittampalam, Ganesh]

Jon Fairbairn wrote:

> 
> semi-rant warning:
> 
> This whole badge/logo business seems to me to be an excellent example
> of Parkinson's law of triviality (choosing the colour of the
> bikeshed). We have a large (too large) number of variations on
> relatively few themes and a really sophisticated voting system, but
> no very clear idea of what they're for and no explanation (such as my
> "of type Haskell" 
> above) of why the candidates are the way they are.
> 
> I didn't join in much to the earlier discussion because I thought
> things would work out to something sensible in the end, but it
> doesn't look like that happened. Work out what the problem is before
> putting the solution up for election!   

I agree with this. I have voted, but as with many others I found the
process very cumbersome, and I don't think it really expresses my
opinions
properly. I'm concerned that this process may well end up producing a
outcome that's worse than the current situation but will have some aura
of legitimacy because of the vote.

Cheers,

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Crash in GHCI - what is the correct behavior here?

[Sittampalam, Ganesh]

I also see a segfault on Windows XP SP2 and GHC 6.10.1, very quick so
I'm fairly sure it's not memory.
 
I agree this should be a bug report.
 


From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Luke Palmer
Sent: 19 March 2009 05:00
To: Zachary Turner
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Crash in GHCI - what is the correct behavior
here?


On Wed, Mar 18, 2009 at 10:55 PM, Zachary Turner
 wrote:


Regarding the "black hole detection", is GHCI supposed to exit
after printing ?  Or is just supposed to print  then return
to a GHCI prompt?  Here's a transcript:

C:\Documents and Settings\Zach>ghci
GHCi, version 6.10.1: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude> let f x = let p = x*x in let p = x*p in p
Prelude> f 7

C:\Documents and Settings\Zach>


Hmm, that's weird.  I note that here on linux, this expression gobbles
up memory like nobody's business.  Maybe it's being killed for eating
too much?  (I dunno)

Luke


=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Does anybody dislike implicit params as much asI do?

[Sittampalam, Ganesh]

Jules Bean wrote:
> Thomas Hartman wrote:
>>
http://blog.patch-tag.com/2009/03/09/implicitparams-are-evil-thoughts-
>> on-adapting-gitit/ 
>> 
>> I understand there are arguments for using IPs, but after this
>> experience, the ImplicitParams extension is a "code smell" for me.
> 
> It's not just you. Implicit parameters are a scourge on the language.

I think they have a useful place in propagating semi-global
configuration
information without imposing huge syntactic overhead. I think using them
like
in the code referred to in the URL above, where their values are
frequently
changed down the call stack, is dangerous.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Request: warn about language extensions that are not used

[Sittampalam, Ganesh]

As I understand it the current scheme is that you vote for a bug by
adding yourself to the CC list.



From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Peter Verswyvelen
Sent: 12 March 2009 14:27
To: Conal Elliott
Cc: haskell mailing list
Subject: Re: [Haskell-cafe] Request: warn about language extensions that
are not used


Thanks Conal. 


For people interested, here's the ticket. 


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



Martijn Van Steenbergen indirectly revealed a feature request to the
feature request feature of the feature database :-) Okay, I'll stop the
nonsense: it would be nice if the community could rate the popularity of
a feature request, which Martijn now just did by adding a comment.



On Thu, Mar 12, 2009 at 3:12 PM, Conal Elliott  wrote:


Thanks Peter.  I'd love to have this feature also.  I go back
every so often and try removing each of the extensions listed in my
LANGUAGE pragma.  Didn't occur to me that the compiler could be doing it
for me.  Regards,  - Conal


2009/3/11 Peter Verswyvelen 


Okay, I submitted it as a GHC feature request. Thanks
for the feedback. 

On Wed, Mar 11, 2009 at 5:16 PM, Creighton Hogg
 wrote:


2009/3/11 Peter Verswyvelen :

> When I put
> {-# OPTIONS_GHC -Wall -Werror #-}
> in my source file, I don't get compiler (GHC)
warnings about redundant
> language extensions that I enabled.
> It would be nice if the compiler gave warnings
about this, since after
> refactoring, some language extensions might
not be needed anymore, and hence
> should be removed since fewer language
extensions mean more stable and
> portable code no?
> What do you think?


So you mean something like if you put {-#
LANGUAGE
GeneralizedNewtypeDeriving #-} in a file, but
never do newtype
deriving, it would warn you?

I have no idea how hard that'd be to implement,
but that sounds kind
of cool.  Useful for both refactoring and when
you've inherited old
code.

Cheers,
C




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org

http://www.haskell.org/mailman/listinfo/haskell-cafe






=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Performance question

[Sittampalam, Ganesh]

Ben Lippmeier wrote:
 
>>> The first thing I would do is replace your isInCircle :: (Floating
>>> a, Ord a)  => (a,a) -> Bool with isInCircle :: (Double, Double) ->
>>> Bool 
>> 
>> Can you point me to why that matters?
> 
> At the machine level, GHC treats the (Floating a, Ord a) as an extra
> argument to the function. This argument holds function pointers that
> tell it how to perform multiplication and <= for the unknown type
> 'a'. If you use Double instead of 'a', then it's more likely to use
> the actual machine op.   

I'd recommend use of a SPECIALIZE pragma instead of rewriting the code
itself:

http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html
(section 8.13.8)

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Memoization local to a function

[Sittampalam, Ganesh]

Dusan Kolar wrote:
> Nevertheless, local version does not
> work.  

Restructure your code like this:

> fibL m =
>   let
> allfib = 0:1:[allfib!!n + allfib!!(n+1) | n <- [0..]]
>   in allfib !! m

fibL = let allfib = 0:1:[allfib!!n + allfib!!(n+1) | n <- [0..]]
 in \m -> allfib !! m

i.e. move the definition of the memo table outside the scope of
the specific parameter you want to memoise over.

Cheers,

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Re: Hoogle and Network.Socket

[Sittampalam, Ganesh]

Jonathan Cast wrote:
> On Wed, 2009-02-25 at 10:23 +, John Lato wrote:
>> 4.  Cross-platform concerns are something that responsible developers
>> need to consider, just like localization and i18n.  I.e., why
>> *shouldn't* you think of that?
> 
> Sorry, wtf?  I have a *responsibility* to design software for a
> miserably poorly-designed God-awful platform I'd have to pay *extra*
> for, and even then couldn't get source to or *fix* if I found a bug?

I think there's a distinction between actively trying to support a
specific platform, and simply trying to work in a cross-platform way,
i.e. using the appropriate cross-platform APIs and packages where
possible. Other people will already have done the work of making those
things work on a specific platform, and if they don't work the issue can
be raised with those people rather than you.

> No.  You don't control me, to the best of my knowledge you haven't
> done squat for me, and by trying to force me to develop to *that*
> platform you are actively attempting to harm me.
> 
> *plonk*

Please could you moderate your tone? The original post wasn't aimed at
you personally, it just expressed a general opinion about development
practices, and certainly made no mention of forcing you or anyone else
to do anything. By making it personal and expressing your response in
rather intemperate language, you are adding more heat than light.

In addition, the original subject of this thread is Hoogle, and if we
take your comments in that context (and I do realise that your comments
may have been generic rather than specific to Hoogle), then you have the
choice of not using it at all, in which case you are not affected at all
by its design choices; but if you do use it then the author certainly
has 
done something for you, and his feeling that people should be encouraged

to use cross-platform APIs where possible should certainly be accorded 
some respect.

Cheers,

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] Hac5 projects page

[Sittampalam, Ganesh]

Wolfgang Jeltsch wrote:

> on , you can list a
> project under "Project descriptions" and under "Experiences". What's
> the difference?  

A project description is something you plan to work on, and an
experience
is something you could help other people with if they were to work on
it.

Ganesh

=== 
 Please access the attached hyperlink for an important electronic 
communications disclaimer: 
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
 
=== 
 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl

[Sittampalam, Ganesh]

Henning Thielemann wrote:
> On Mon, 16 Feb 2009, Louis Wasserman wrote:
> 
>> Overnight I had the following thought, which I think could work
>> rather well.  The most basic implementation of the idea is as
>> follows: 
>> 
>> class MonadST s m | m -> s where
>> liftST :: ST s a -> m a
>> 
>> instance MonadST s (ST s) where ...
>> instance MonadST s m => MonadST ...
> 
> Like MonadIO, isn't it?

I think it should be, except that you need to track 's' somewhere.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl

[Sittampalam, Ganesh]

Dan Doel wrote:
> 
> Someone already mentioned using Dynamic as an alternate base (for
> instance, use a Map of dynamics for underlying storage). Of course,
> the implementation of Dynamic in GHC uses unsafeCoerce, just like ST,
> so you may not count that.   
> However, using GADTs, you can implement Dynamic safely for a closed
> universe of types. So you could create a polymorphic reference monad
> for whatever such universe you wished. Further, if you actually had
> open GADTs, you could actually add the relevant type-rep constructor
> for every type you declared. For instance, jhc's implementation of
> type classes internally uses such a GADT, so one could theoretically
> make a safe Dynamic, and thus a safe polymorphic reference monad. 

Apart from the other inconveniences, all of these solutions involve
runtime overhead, which is a shame.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl

[Sittampalam, Ganesh]

Oh, I see, every derived monad has to have an 's' in its type somewhere.



From: Louis Wasserman [mailto:wasserman.lo...@gmail.com] 
Sent: 16 February 2009 16:17
To: Sittampalam, Ganesh
Cc: Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl


But the m -> s dependency will have been removed by the time runST gets
a hold of it!  It works, I just tested it.

*Control.Monad.Array.ArrayM> :t runST (runArrayT 5 Nothing getContents)
runST (runArrayT 5 Nothing getContents) :: [Maybe a]
*Control.Monad.Array.ArrayM> runST (runArrayT 5 Nothing getContents)
[Nothing,Nothing,Nothing,Nothing,Nothing]

There is, unfortunately, one last key point needed in this approach: the
transformer cannot implement MonadTrans, which requires that it work for
all monads.  The hack I added is

class MonadSTTrans s t where
stLift :: MonadST s m => m a -> t m a

instance MonadTrans t => MonadSTTrans s t where
stLift = lift

which, as a side effect, makes explicit the distinction between normal
monad transformers and ST-wrapped monad transformers.

Louis Wasserman
wasserman.lo...@gmail.com



On Mon, Feb 16, 2009 at 10:04 AM, Sittampalam, Ganesh
 wrote:


I don't think this can be right, because the m -> s dependency
will contradict the universal quantification of s required by runST. In
other words, unwrapping the transformers will leave you with an ST
computation for a specific s, which runST will reject.



From: Louis Wasserman [mailto:wasserman.lo...@gmail.com] 
Sent: 16 February 2009 16:01
To: Sittampalam, Ganesh
Cc: Dan Doel; Henning Thielemann; haskell-cafe@haskell.org 

Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl


Overnight I had the following thought, which I think could work
rather well.  The most basic implementation of the idea is as follows:

class MonadST s m | m -> s where

liftST :: ST s a -> m a


instance MonadST s (ST s) where ...
instance MonadST s m => MonadST ...

newtype FooT m e = FooT (StateT Foo m e)

instance (Monad m, MonadST s m) => Monad (FooT m) where ...

instance (Monad m, MonadST s m) => MonadBar (FooT m) where




instance (Monad m, MonadST s m)  => MonadST s (FooT m) where ...

The point here is that a MonadST instance guarantees that the
bottom monad is an ST -- and therefore single-threaded of necessity --
and grants any ST-based monad transformers on top of it access to its
single state thread.

The more fully general approach to guaranteeing an underlying
monad is single-threaded would be to create a dummy state parameter
version of each single-threaded monad -- State, Writer, and Reader --
and add a typeclass called MonadThreaded or something.

The real question with this approach would be how to go about
unwrapping ST-based monad transformers in this fashion: I'm thinking
that you would essentially perform unwrapping of the outer monad using
an ST computation which gets lifted to the next-higher monad.  So, say,
for example:

newtype MonadST s m => ArrayT e m a = ArrayT {execArrayT ::
StateT (STArray s Int e) m a}

runArrayT :: (Monad m, MonadST s m) => Int -> ArrayT e m a -> m
a
runArrayT n m = liftST (newArray_ (0, n-1)) >>= evalStateT
(execArrayT m)

Key points: 
- A MonadST s m instance should always imply that the
bottom-level monad is of type ST s, preferably a bottom level provided
when defining a monad by stacking transformers.  The fact that the
bottom monad is in ST should guarantee single-threaded, referentially
transparent behavior.
- A non-transformer implementation of an ST-bound monad
transformer would simply involve setting the bottom monad to ST, rather
than Identity as for most monad transformers.
- Unwrapping an ST-bound monad transformer involves no universal
quantification on the state type.  After all transformers have been
unwrapped, it should be possible to invoke runST on the final ST s a.
- Both normal transformers and ST-bound transformers should
propagate MonadST.

I'm going to go try implementing this idea in stateful-mtl
now...

Louis Wasserman
wasserman.lo...@gmail.com
    


On Mon, Feb 16, 2009 at 3:07 AM, Sittampalam, Ganesh
 wrote:


Well, I think a type system like Clean's that had
linear/uniqueness types could "fix" the issue by actually checking that
the state is single-threaded (and thus stop you from applying it to a
"forking" monad). But there's a fundamental operat

RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl

[Sittampalam, Ganesh]

I don't think this can be right, because the m -> s dependency will
contradict the universal quantification of s required by runST. In other
words, unwrapping the transformers will leave you with an ST computation
for a specific s, which runST will reject.



From: Louis Wasserman [mailto:wasserman.lo...@gmail.com] 
Sent: 16 February 2009 16:01
To: Sittampalam, Ganesh
Cc: Dan Doel; Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl


Overnight I had the following thought, which I think could work rather
well.  The most basic implementation of the idea is as follows:

class MonadST s m | m -> s where

liftST :: ST s a -> m a


instance MonadST s (ST s) where ...
instance MonadST s m => MonadST ...

newtype FooT m e = FooT (StateT Foo m e)

instance (Monad m, MonadST s m) => Monad (FooT m) where ...

instance (Monad m, MonadST s m) => MonadBar (FooT m) where




instance (Monad m, MonadST s m)  => MonadST s (FooT m) where ...

The point here is that a MonadST instance guarantees that the bottom
monad is an ST -- and therefore single-threaded of necessity -- and
grants any ST-based monad transformers on top of it access to its single
state thread.

The more fully general approach to guaranteeing an underlying monad is
single-threaded would be to create a dummy state parameter version of
each single-threaded monad -- State, Writer, and Reader -- and add a
typeclass called MonadThreaded or something.

The real question with this approach would be how to go about unwrapping
ST-based monad transformers in this fashion: I'm thinking that you would
essentially perform unwrapping of the outer monad using an ST
computation which gets lifted to the next-higher monad.  So, say, for
example:

newtype MonadST s m => ArrayT e m a = ArrayT {execArrayT :: StateT
(STArray s Int e) m a}

runArrayT :: (Monad m, MonadST s m) => Int -> ArrayT e m a -> m a
runArrayT n m = liftST (newArray_ (0, n-1)) >>= evalStateT (execArrayT
m)

Key points: 
- A MonadST s m instance should always imply that the bottom-level monad
is of type ST s, preferably a bottom level provided when defining a
monad by stacking transformers.  The fact that the bottom monad is in ST
should guarantee single-threaded, referentially transparent behavior.
- A non-transformer implementation of an ST-bound monad transformer
would simply involve setting the bottom monad to ST, rather than
Identity as for most monad transformers.
- Unwrapping an ST-bound monad transformer involves no universal
quantification on the state type.  After all transformers have been
unwrapped, it should be possible to invoke runST on the final ST s a.
- Both normal transformers and ST-bound transformers should propagate
MonadST.

I'm going to go try implementing this idea in stateful-mtl now...

Louis Wasserman
wasserman.lo...@gmail.com



On Mon, Feb 16, 2009 at 3:07 AM, Sittampalam, Ganesh
 wrote:


Well, I think a type system like Clean's that had
linear/uniqueness types could "fix" the issue by actually checking that
the state is single-threaded (and thus stop you from applying it to a
"forking" monad). But there's a fundamental operational problem that ST
makes destructive updates, so to support it as a monad transformer in
general you'd need a type system that actually introduced fork
operations (which "linear implicit parameters" used to do in GHC , but
they were removed because they were quite complicated semantically and
noone really used them).



From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Louis Wasserman
Sent: 16 February 2009 03:31
To: Dan Doel
Cc: Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl


Okay, I tested it out and the arrow transformer has the same
problem.  I realized this after I sent the last message -- the point is
that at any particular point, intuitively there should be exactly one
copy of a State# s for each state thread, and it should never get
duplicated; allowing other monads or arrows to hold a State# s in any
form allows them to hold more than one, violating that goal.

I'm not entirely convinced yet that there isn't some really
gorgeous type system magic to fix this issue, like the type-system magic
that motivates the type of runST in the first place, but that's not an
argument that such magic exists...it's certainly an interesting topic to
mull.

Louis Wasserman
wasserman.lo...@gmail.com



On Sun, Feb 15, 2009 at 9:20 PM, Dan Doel 
wrote:


On Sunday 15 February 2009 9:44:42 pm Louis Wasserman
wrote:
> Hello all,
   

RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl

[Sittampalam, Ganesh]

Well, I think a type system like Clean's that had linear/uniqueness
types could "fix" the issue by actually checking that the state is
single-threaded (and thus stop you from applying it to a "forking"
monad). But there's a fundamental operational problem that ST makes
destructive updates, so to support it as a monad transformer in general
you'd need a type system that actually introduced fork operations (which
"linear implicit parameters" used to do in GHC , but they were removed
because they were quite complicated semantically and noone really used
them).



From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Louis Wasserman
Sent: 16 February 2009 03:31
To: Dan Doel
Cc: Henning Thielemann; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl


Okay, I tested it out and the arrow transformer has the same problem.  I
realized this after I sent the last message -- the point is that at any
particular point, intuitively there should be exactly one copy of a
State# s for each state thread, and it should never get duplicated;
allowing other monads or arrows to hold a State# s in any form allows
them to hold more than one, violating that goal.

I'm not entirely convinced yet that there isn't some really gorgeous
type system magic to fix this issue, like the type-system magic that
motivates the type of runST in the first place, but that's not an
argument that such magic exists...it's certainly an interesting topic to
mull.

Louis Wasserman
wasserman.lo...@gmail.com



On Sun, Feb 15, 2009 at 9:20 PM, Dan Doel  wrote:


On Sunday 15 February 2009 9:44:42 pm Louis Wasserman wrote:
> Hello all,
>
> I just uploaded stateful-mtl and pqueue-mtl 1.0.1.  The ST
monad
> transformer and array transformer have been removed -- I've
convinced
> myself that a heap transformer backed by an ST array cannot be
> referentially transparent -- and the heap monad is now
available only as a
> basic monad and not a transformer, though it still provides
priority queue
> functionality to any of the mtl wrappers around it.
stateful-mtl retains a
> MonadST typeclass which is implemented by ST and monad
transformers around
> it, allowing computations in the the ST-bound heap monad to
perform ST
> operations in its thread.
>
> Since this discussion had largely led to the conclusion that
ST can only be
> used as a bottom-level monad, it would be pretty uncool if ST
computations
> couldn't be performed in a monad using ST internally because
the ST thread
> was hidden and there was no way to place ST computations
'under' the outer
> monad.  Anyway, it's essentially just like the MonadIO
typeclass, except
> with a functional dependency on the state type.
>
> There was a question I asked that never got answered, and I'm
still
> curious: would an ST *arrow* transformer be valid?  Arrows
impose
> sequencing on their operations that monads don't...  I'm going
to test out
> some ideas, I think.


Your proposed type:

 State (Kleisli []) x y = (s, x) -> [(s, y)]

is (roughly) isomorphic to:

 x -> StateT s [] y = x -> s -> [(s, y)]

The problem with an ST transformer is that the state parameter
needs to be
used linearly, because that's the only condition under which the
optimization
of mutable update is safe. ST ensures this by construction, as
opposed to
other languages (Clean) that have type systems that can express
this kind of
constraint directly. However, with STT, whether the state
parameter is used
linearly is a function of the wrapped monad. You'd have to give
a more fleshed
out version of your proposed state arrow transformer, but off
the top of my
head, I'm not sure it'd be any better.

-- Dan




==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] ANNOUNCE: pqueue-mtl, stateful-mtl

[Sittampalam, Ganesh]

> Stateful-mtl provides an ST monad transformer, 

Is this safe? e.g. does it work correctly on [], Maybe etc?

If not this should be flagged very prominently in the documentation.

Cheers,

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Monad explanation

[Sittampalam, Ganesh]

> My bad, I restate:  a value cannot be both static and dynamic.  Or an
> object and a morphism.  Or an element and a function.  Sure, you can
> treat a morphism as an object, but only by moving to a higher (or
> different) level of abstraction.  That doesn't erase the difference
> between object and morphism.  If you do erase that difference you end
> up with mush.  getChar /looks/ like an object, but semantically it
> must be a morphism.  But it can't be a function, since it is
> non-deterministic.   So actually the logical contradiction comes from
> the nature of the beast.
> 
> Another reason it's confusing to newcomers:  it's typed as "IO Char",
> which looks like a type constructor.  One would expect getChar to
> yield a value of type IO Char, no?  But it delivers a Char instead. 
> This is way confusing.  So I take "type IO foo" to mean "type foo,
> after a side effect".  In a sense "getChar :: IO Char" isn't even a
> true type signature. 

It does yield a value of type IO Char, which it also happens that you
can ask the Haskell runtime to interpret by combining it with other
IO values using >>= and invoking it from the top-level.
*When interpreted in this way* it delivers a Char, but that's precisely
the point at which we move to the different level of abstraction you
mention above.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

[Sittampalam, Ganesh]

Don Stewart wrote:
> ganesh.sittampalam:
>> Don Stewart wrote:

>>> So, wind...@haskell.org anyone? Get the wiki going, get the set of
>>> tasks created.
>> 
>> Isn't the Haskell Platform going to do all this? Shouldn't
>> interested people just help out there? 
>> 
> 
> The platform is a set of blessed libraries and tools. The distros
> will still need to package that. 
> 
> To do that for Windows, we're still going to need a windows packaging
> team, along side Debian, Arch, Gentoo, Mac etc. 

http://www.haskell.org/haskellwiki/Haskell_Platform section 4
talks about making distributions.

So what should people be trying to do? Focus on (a) general
infrastructure
for packaging any Haskell library/binary on Windows (etc), or on (b) the
specific task of packaging the Haskell Platform?

If (b) then I don't think a whole new mailing list/wiki etc is
worthwhile.
(a) would obviously be nicer but is no doubt a much harder problem - I
guess
we'd want to start with Bamse and perhaps make use of the
"nestedInstalls"
feature somehow.

Ganesh


==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Re: 1,000 packages, so let's build a few!

[Sittampalam, Ganesh]

Don Stewart wrote:

> GHC doesn't  bundle with cabal-install on any system.
> 
> What is needed is not for the GHC team to be doing Windows platform
> packages, but for the Windows Haskell devs to build their own system,
> as happens on all the Unices.  
> 
> Take GHC's release, wrap it up with native installers, throw in
> useful libraries and executables like cabal. Done. 
> 
> It's not the GHC compiler team's job to build distro-specific bundles.
> 
> So, wind...@haskell.org anyone? Get the wiki going, get the set of
> tasks created. 

Isn't the Haskell Platform going to do all this? Shouldn't interested
people just help out there?

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Re: list choices

[Sittampalam, Ganesh]

Malcolm Wallace wrote:
 
> As for Reply-to: munging - I agree that _changing_ an existing header
> would be bad, but would be very happy if mailing lists were to
> _introduce_ one on messages where none already existed.  

That would IMO be the worst of both worlds, as people might use
Reply-To for reasons entirely unconnected with the mailing list.
So you'd end up with a confusing situation where the default target
of replies varied depending on some completely irrelevant factor.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Employment

[Sittampalam, Ganesh]

Andrew Coppin wrote:
> Andrew Wagner wrote:
>> http://www.haskell.org/haskellwiki/Haskell_in_industry could be of
>> interest to you
> 
> Hmm, interesting... So lots happening in Portland, Oregon. Lots in
> Cambridge, MA. A few things in Europe. And nothing at all in the
> UK...  

We (Credit Suisse) have Haskell developers in both London and NY,
although the page only listed NY (I've now corrected it).

Two other companies without locations listed - Barclays Capital and
Standard Chartered - also have at least some Haskell development in
the UK, and I think that's where Amgen's development is based too.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Sittampalam, Ganesh]

Lennart Augustsson wrote:
> Most people don't understand pure functional programming either. 
> Does that mean we should introduce unrestricted side effects in
> Haskell?  

No, just that we should seek to minimise the new stuff they have
to get to grips with.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Sittampalam, Ganesh]

Lennart Augustsson wrote:
> I think the documentation should be reasonably newbie-friendly too.
> But that doesn't mean we should call Monoid Appendable.
> Appendable is just misleading, since Monoid is more general than
> appending. 

Then why does it have a member named 'mappend'? :-)

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Sittampalam, Ganesh]

Lennart Augustsson wrote:
> a name that anyone can figure out with just a little effort.

I think the problem is that all these pieces of "little effort"
soon mount up. It's not just the cost of looking it up, but also
of remembering it the next time and so on. It's fine when you
only encounter the occasional unfamiliar term, but a barrage of
them all at once can be quite disorienting.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Comments from OCaml Hacker Brian Hurt

[Sittampalam, Ganesh]

Lennart Augustsson wrote:
> I have replied on his blog, but I'll repeat the gist of it here.
> Why is there a fear of using existing terminology that is exact?
> Why do people want to invent new words when there are already
> existing ones with the exact meaning that you want? If I see Monoid I
> know what it is, if I didn't know I could just look on Wikipedia. 
> If I see Appendable I can guess what it might be, but exactly what
> does it mean? 

I would suggest that having to look things up slows people down 
and might distract them from learning other, perhaps more useful,
things about the language.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] The problem with Monads...

[Sittampalam, Ganesh]

Jonathan Cast wrote:
> On Tue, 2009-01-13 at 12:56 -0200, Rafael Gustavo da Cunha Pereira
> Pinto wrote:
>>
>> Inspired by the paper "Functional Programming with Overloading and
>> Higher-Order Polymorphism", Mark P Jones
>> (http://web.cecs.pdx.edu/~mpj/pubs/springschool.html)
>>   Advanced School of Functional Programming, 1995.
>> 
>> SO WHAT?
> 
> So have you read Jones' paper?  Or do you have a *concrete*
> explanation of how it differs from your desired `guided tour'? 

To give a specific example, a few weeks ago I wanted an explanation of
the 'pass' function and couldn't find it in that paper.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] mailing list choices?

[Sittampalam, Ganesh]

The Yahoo mailing list server is notoriously unreliable and randomly
drops mails and/or drops people from lists because their email server
was temporarily refusing mails (4xx SMTP responses not 5xx). I also find
the Yahoo groups web interface absolutely awful; mailman's list archives
aren't great, but are ok for casual browsing, and you can download the
entire archives and load them up locally if you need to.
 
A quick look around Google groups suggests that my initial assumption
that it'd be as bad as Yahoo groups is probably unfounded. But if I
hadn't already given in and created a Google account for other things,
I'd be unhappy about doing so just for your list, given the way it
tracks your web browsing in ways that I don't entirely understand while
you are logged into it.



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Conal Elliott
Sent: 08 September 2008 12:52
To: Sittampalam, Ganesh
Cc: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] mailing list choices?


In what ways?


2008/9/8 Sittampalam, Ganesh <[EMAIL PROTECTED]>


I would call Yahoo and Google groups a major step backwards from
mailman.



==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

RE: [Haskell-cafe] mailing list choices?

[Sittampalam, Ganesh]

I would call Yahoo and Google groups a major step backwards from mailman.



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Conal Elliott
Sent: 08 September 2008 11:34
To: Haskell Café
Subject: [Haskell-cafe] mailing list choices?


I want to set up some kind of mailing list for reactive (which I plan to 
release soon).  The most obvious thing is to set up a mailman-based list on 
haskell.org, but I wonder -- do people really want to keep using mailman 
technology?  Or something more modern like Yahoo or Google groups.  

I use my email reader also with Yahoo & Google groups, so my day-to-day 
experience is the same as with mailman-based lists.  For less regular 
operations like searching archives, I prefer the experience on Yahoo & Google 
group.  And I like some of the other modern features, like personal profiles 
and polls.

I've been wondering if haskellers really like mailman or are just used to it.  
Maybe people make new mailman lists simply because others did it before them.

Any thoughts/preferences?  Thanks,

  - Conal


==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] RE: [Haskell] Top Level <-

[Sittampalam, Ganesh]

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.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

[Haskell-cafe] RE: [Haskell] Top Level <-

[Sittampalam, Ganesh]

 
Ashley Yakeley wrote:
> Sittampalam, Ganesh wrote:
>>> Oh dear. To fix this, I suppose the RTS would have to be able to
keep 
>>> track of all static initialisers. But it shouldn't otherwise affect 
>>> program optimisation.
>> 
>> What would the RTS actually do?

> I don't know enough about the RTS to say. I imagine initialisers would

> have to be marked in object files, so the RTS could link them
separately
> when dynamically loading. The RTS would also keep a list of
initialisers
> in the main program.

Sounds plausible, although dynamic relocations do slow down linking.

Unloading is another interesting problem. Are we allowed to re-run <-
if the module that contained it is unloaded and then reloaded? I'm not
quite sure what the conditions for allowing a module to be unloaded
in general should be, though.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

[Haskell-cafe] RE: [Haskell] Top Level <-

[Sittampalam, Ganesh]

Ashley Yakeley wrote:

> Sittampalam, Ganesh wrote:
> > I talked to Don about this and you're right, that doesn't happen.
> > However
> > he also confirmed that it does load modules a second time if they
are 
> > in the main program as well as the plugin, and it would be difficult

> > to merge the static and dynamic versions of the module.

> Oh dear. To fix this, I suppose the RTS would have to be able to
> keep track of all static initialisers. But it shouldn't otherwise
> affect program optimisation.

What would the RTS actually do?

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

[Haskell-cafe] RE: [Haskell] Top Level <-

[Sittampalam, Ganesh]

Ashley Yakeley wrote:

> Sittampalam, Ganesh wrote:
> > In compiled code module boundaries don't necessarily exist. So how
do 
> > you relink the loaded code so that it points to the unique copy of
the 
> > module?

> hs-plugins loads modules as single .o files, I believe.

Yes, but (a) the loading program doesn't and (b) that's an
implementation
choice, not a necessity.

> Two RTSs? Are you quite sure? How would GC work?

I talked to Don about this and you're right, that doesn't happen.
However
he also confirmed that it does load modules a second time if they are
in the main program as well as the plugin, and it would be difficult to
merge
the static and dynamic versions of the module.

Cheers,

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

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

[Sittampalam, Ganesh]

Yitzchak Gale wrote

> Other applications and libraries that support the pragma - such as
other 
> compilers, and hs-plugins - would be required to respect the
guarantee, and > bugs could be filed against them if they don't.

If hs-plugins were loading object code, how would it even know of the
existence of the pragma? Given such knowledge, how would it implement
it?

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

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

[Sittampalam, Ganesh]

(apologies for misspelling your name when quoting you last time) 
Yitzchak Gale wrote:
>>> For the short term - can we *please* get an ONLYONCE pragma that has

>>> the correct semantics?

> Until a permanent solution is implemented and deployed in the 
> compilers (if ever), can we please have a pragma that allows
> the current hack to really work?

How do you propose that this pragma would be implemented?

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

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

[Sittampalam, Ganesh]

Yitzhak Gale wrote:

> Right. It would not be a bug in hs-plugins. That is
> the most urgent problem right now.
[...]
> For the short term - can we *please* get an ONLYONCE
> pragma that has the correct semantics?

So the purpose of this pragma would solely be so that
you can declare hs-plugins buggy for not respecting it?
Or do you have some way to "fix" hs-plugins so that it
does do so?

(Assuming that my belief about how hs-plugins works is
correct, of course)

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

[Haskell-cafe] RE: [Haskell] Top Level <-

[Sittampalam, Ganesh]

Ashley Yakeley wrote:

> I think it's bad design for a dynamic loader to load a module more 
> than once anyway.

In compiled code module boundaries don't necessarily exist. So how
do you relink the loaded code so that it points to the unique copy
of the module?

> It's a waste of memory, for a start. We already 
> know that hs-plugins won't for modules it already loaded itself
> (apparently it crashes the RTS), and I suspect it doesn't at all.

It crashes the RTS of the plugins loader, which is based on ghci, which
is built around loading modules independently. I believe there's a
separate RTS running at the top level of the program which has no
knowledge of the plugin loader.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

[Haskell-cafe] RE: [Haskell] Top Level <-

[Sittampalam, Ganesh]

Ashley Yakeley wrote:

> Sittampalam, Ganesh wrote:
> > I am suggesting that this duplication process, whether conducted by 
> > the dynamic loader or something else, should behave as if they did
not 
> > have the same package name or version.
> 
> > This is certainly a valid transformation for Data.Unique, I am
simply 
> > saying that it should be a valid transformation on any module.

> So if I dynamically load module M that uses base, I will in fact
> get a completely new and incompatible version of Maybe, IO, [], 
> Bool, Char etc. in all the type-signatures of M?

I think it treats them as compatible, using the fact that 
Data.Typeable returns the same type reps (which was why I initially
mentioned Data.Typeable in this thread). This is fine for "normal"
modules. There's a bit of description in the "Dynamic Typing" section of
http://www.cse.unsw.edu.au/~dons/hs-plugins/hs-plugins-Z-H-5.html#node_s
ec_9

It's clearly the wrong thing to do for Data.Unique and any anything
else that might use <-; but if there are no such types in the interface
of the plugin, then it won't matter. I can't see how to make it
safe to pass Data.Unique etc across a plugin interface without
severely restricting the possible implementation strategies for
a plugin library and its host.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

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

[Sittampalam, Ganesh]

Ashley Yakeley wrote:

> "To solve this the hs-plugins dynamic loader maintains
> state storing a list of what modules and packages have
> been loaded already. If load is called on a module that
> is already loaded, or dependencies are attempted to load,
> that have already been loaded, the dynamic loader ignores
> these extra dependencies. This makes it quite easy to 
> write an application that will allows an arbitrary number
> of plugins to be loaded."
> 

My recollection from using it a while ago is that if a
module is used in the main program it will still be
loaded once more in the plugin loader. This is because
the plugin loader is basically an embedded copy of ghci
without much knowledge of the host program's RTS.

Cheers,

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

[Haskell-cafe] RE: [Haskell] Top Level <-

[Sittampalam, Ganesh]

Ashley Yakeley wrote:

> I don't understand. If the dynamic loader were to load the same
package
> name and version, and it duplicated the MVar, then Unique values would
> have the same type and could be compared.

I am suggesting that this duplication process, whether conducted by the
dynamic loader or something else, should behave as if they did not have
the
same package name or version.

This is certainly a valid transformation for Data.Unique, I am simply
saying that it should be a valid transformation on any module.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

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

[Sittampalam, Ganesh]

Dave Menendez wrote: 

> The Haskell 98 report includes NOINLINE, but 
> also states that environments are not required
> to respect it. So hs-plugins wouldn't necessarily
> be at fault if it didn't support Data.Unique.

Also, the definition of NOINLINE in the report doesn't
preclude copying both the MVar *and* its use sites,
which is what I am proposing should be considered
generally safe.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

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

[Sittampalam, Ganesh]

Ashley Yakeley wrote: 

>Ganesh Sittampalam wrote:
>> 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.

> That's not acceptable. This would cause Unique to break, 
> as its MVar would be created twice. It would also mean 
> that individual Unique and IOWitness values created by
> <- would have different values depending on which bit 
> of code was referencing them. It would render the extension
> useless as far as I can see.

The result wouldn't typecheck if two Unique values that now pointed to
the two different modules were compared.

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Top Level <-

[Sittampalam, Ganesh]

 
David Roundy wrote:
> On Tue, Sep 02, 2008 at 10:10:31AM +0100, Sittampalam, Ganesh wrote:

>> Arguably both of these cases are not ACIO simply because of the 
>> non-termination effects, but it's not obvious to me how you tell just

>> by looking at either one's code together with the declared API of the

>> other. Is anything strict automatically forbidden by ACIO?

> Isn't this just a pure infinite loop? Why is it a problem that ACIO
> allows you the flexibility that's present in any pure code?

ACIO promises that you can remove anything unused without changing
the behaviour.

The same problem doesn't arise in pure code because you can't write
top-level strict bindings. The GHC extension to have strict bindings
(bang patterns) is explicitly disallowed at top-level:
http://www.haskell.org/ghc/docs/latest/html/users_guide/bang-patterns.ht
ml

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Top Level <-

[Sittampalam, Ganesh]

> > Contrived example follows:
> 
> > module Module1 (mod1) where
> > import Module2
> >
> > glob1 :: IORef Int
> > glob1 <- mod2 >>= newIORef
> 
> > mod1 :: IO Int
> > mod1 = readIORef glob1
> 
> > module Module2 (mod2) where

> > import Module1

> > glob2 :: IORef Int
> > glob2 <- mod1 >>= newIORef
> 
> > mod2 :: IO Int
> > mod2 = readIORef glob2

> This is illegal because you're only allowed to use ACIO
> in top level <- bindings and readIORef isn't (and clearly
> could not be) ACIO.

(made a couple of changes to quoted example; added import
statements and explicit export lists)

Even though I never call writeIORef on glob1 or glob2, and
can change the example as above so we don't export them, so
it's impossible to ever do so?

As an alternative, consider

module Module1 (mod1) where
import Module2

glob1 :: Int
glob1 <- return $! mod2

mod1 :: Int
mod1 = glob1
 
module Module2 (mod2) where

import Module1

glob2 :: Int
glob2 <- return $! mod1
 
mod2 :: Int
mod2 = glob2

Even more artificial, of course.

Arguably both of these cases are not ACIO simply because
of the non-termination effects, but it's not obvious to
me how you tell just by looking at either one's code together
with the declared API of the other. Is anything strict
automatically forbidden by ACIO?

Cheers,

Ganesh




==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Top Level <-

[Sittampalam, Ganesh]

John Meacham wrote:
On Fri, Aug 29, 2008 at 04:33:50PM -0700, Dan Weston wrote:

>> C++ faced this very issue by saying that with global data,
>> uniqueness of initialization is guaranteed but order of
>> evaluation is not. Assuming that the global data are 
>> merely thunk wrappers over some common data source, this 
>> means that at minimum, there can be no data dependencies 
>> between plugins where the order of evaluation matters.

> Fortunately, we can do a whole lot better with haskell, the 
> type system guarentees that order of evaluation is irrelevant
> :) no need to specify anything about implementations.

Can't you write two recursive modules with <- that depend on
each other, so that there's no valid initialisation order?

Contrived example follows:

module Module1 where

glob1 :: IORef Int
glob1 <- mod2 >>= newIORef 

mod1 :: IO Int
mod1 = readIORef glob1

module Module2 where

glob2 :: IORef Int
glob2 <- mod1 >>= newIORef 

mod2 :: IO Int
mod2 = readIORef glob2

It might need some strictness annotations to actually cause
non-termination at initialisation rather than just make the results
of mod1 and mod2 be _|_.

I think those initialisers do satisfy ACIO, though I'm not certain -
from the point of view of dataflow, you can certainly remove them
both together if the rest of the code doesn't use mod1 or mod2, and
likewise they commute with any other IO operations. But on the other
hand there's no way to actually put them in an order that doesn't
cause non-termination.

Cheers,

Ganesh


==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] Mutually recursive modules and google protocol-buffers

[Sittampalam, Ganesh]

Hi,

> module A(A) where
> data A
>   deriving Show

I think you should use "instance Show A" rather than "deriving Show".
All the boot file needs to do is say that the instance exists, not
explain how it is constructed.

Cheers,

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] More on performance

[Sittampalam, Ganesh]

> I wonder what can be said about "stable" optimizations which are
insensitive to their environments in some sense.

http://citeseer.ist.psu.edu/veldhuizen02guaranteed.html

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] looking for examples of non-full Functional Dependencies

[Sittampalam, Ganesh]

> > Why not instead transform single-range FDs into multi-range ones where 
> > possible?

> That's a perfectly reasonable assumption and would establish the logical 
> property that

> a -> b /\ a -> c   iff a -> b /\ c

> for FDs (by definition).

> But what about programmers who'd like that

> C [x] y z   yields the improvement y = [b], z =[b]

> where

> class C a b c | a -> b c
> instance C a b b => C [a] [b] [b]

Isn't that precisely what you earlier said would happen with multi-range FDs?
Either I'm missing some difference or we're talking at cross-purposes.

My suggestion is that

"class C a b c | a -> b c" and "class C a b c | a -> b, a -> c" be both
treated as the former case, leading to both cases having the y=[b],z=[b]
improvement as above.

Cheers,

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] looking for examples of non-full Functional Dependencies

[Sittampalam, Ganesh]

Martin Sulzmann wrote:
> Mark P Jones wrote:

> > In fact, the two sets of dependencies that you have given here are 
> > provably equivalent, so it would be decidedly odd to have a "type 
> > improvement" system that distinguishes between them.

> Based on the FD-CHR formulation, for the single-range FD case we
> get [...] which is clearly weaker.
> [...]
> So, I conclude that in the Haskell type improvement context 
> there's clearly a difference among single-range and multi-range FDs.

This seems like a flaw in FD-CHR, rather than a fundamental difference 
between the dependencies.

> Of course, we could define multi-range FDs in terms of single-range FDs
> which then trivially solves the "equivalence" problem (but some user 
> may be disappointed that their multi-range FDs yield weaker improvement).

Why not instead transform single-range FDs into multi-range ones where
possible?

Ganesh

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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

RE: [Haskell-cafe] type families and type signatures

[Sittampalam, Ganesh]

OK, thanks. I think I'm finally understanding :-)

Cheers,

Ganesh

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sulzmann
Sent: 09 April 2008 07:21
To: Ganesh Sittampalam
Cc: Manuel M T Chakravarty; haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] type families and type signatures

Manuel said earlier that the source of the problem here is foo's ambiguous type 
signature (I'm switching back to the original, simplified example).
Type checking with ambiguous type signatures is hard because the type checker 
has to guess types and this guessing step may lead to too many (ambiguous) 
choices. 
But this doesn't mean
that this worst case scenario always happens.

Consider your example again

type family Id a

type instance Id Int = Int

foo :: Id a -> Id a
foo = id

foo' :: Id a -> Id a
foo' = foo

The type checking problem for foo' boils down to verifying the formula

forall a. exists b. Id a ~ Id b

Of course for any a we can pick b=a to make the type equation statement hold.
Fairly easy here but the point is that the GHC type checker doesn't do any 
guessing at all. The only option you have (at the moment, there's still lots of 
room for improving GHC's type checking process) is to provide some hints, for 
example mimicking System F style type application by introducing a type proxy 
argument in combination with lexically scoped type variables.

foo :: a -> Id a -> Id a
foo _ = id

foo' :: Id a -> Id a
foo' = foo (undefined :: a)


Martin


Ganesh Sittampalam wrote:
> On Wed, 9 Apr 2008, Manuel M T Chakravarty wrote:
>
>> Sittampalam, Ganesh:
>
>>> No, I meant can't it derive that equality when matching (Id a) 
>>> against (Id b)? As you say, it can't derive (a ~ b) at that point, 
>>> but (Id a ~ Id b) is known, surely?
>>
>> No, it is not know.  Why do you think it is?
>
> Well, if the types of foo and foo' were forall a . a -> a and forall b 
> . b -> b, I would expect the type-checker to unify a and b in the 
> argument position and then discover that this equality made the result 
> position unify too. So why can't the same happen but with Id a and Id 
> b instead?
>
>> The problem is really with foo and its signature, not with any use of 
>> foo. The function foo is (due to its type) unusable.  Can't you 
>> change foo?
>
> Here's a cut-down version of my real code. The type family Apply is 
> very important because it allows me to write class instances for 
> things that might be its first parameter, like Id and Comp SqlExpr 
> Maybe, without paying the syntactic overhead of forcing client code to 
> use Id/unId and Comp/unComp. It also squishes nested Maybes which is 
> important to my application (since SQL doesn't have them).
>
> castNum is the simplest example of a general problem - the whole point 
> is to allow clients to write code that is overloaded over the first 
> parameter to Apply using primitives like castNum. I'm not really sure 
> how I could get away from the ambiguity problem, given that desire.
>
> Cheers,
>
> Ganesh
>
> {-# LANGUAGE TypeFamilies, GADTs, UndecidableInstances, 
> NoMonomorphismRestriction #-}
>
> newtype Id a = Id { unId :: a }
> newtype Comp f g x = Comp { unComp :: f (g x) }
>
> type family Apply (f :: * -> *) a
>
> type instance Apply Id a = a
> type instance Apply (Comp f g) a = Apply f (Apply g a) type instance 
> Apply SqlExpr a = SqlExpr a type instance Apply Maybe Int = Maybe Int 
> type instance Apply Maybe Double = Maybe Double type instance Apply 
> Maybe (Maybe a) = Apply Maybe a
>
> class DoubleToInt s where
>castNum :: Apply s Double -> Apply s Int
>
> instance DoubleToInt Id where
>castNum = round
>
> instance DoubleToInt SqlExpr where
>castNum = SECastNum
>
> data SqlExpr a where
>   SECastNum :: SqlExpr Double -> SqlExpr Int
>
> castNum' :: (DoubleToInt s) => Apply s Double -> Apply s Int castNum' 
> = castNum
>
> ___
> 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

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==

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