[Haskell] ANN: Haskell for Mac trials & educational discount

[Manuel M T Chakravarty]

Haskell for Mac, the Haskell IDE with interactive playgrounds, now offers a 
free 14 day trial and educational discounts:

  http://haskellformac.com

Manuel

___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: Reconsidering -Wall and -Wcompat

[Manuel M T Chakravarty]

Just as one data point, the Swift compiler is by default showing warnings about 
upcoming changes. Just like deprecation warnings, I do find that helpful. Based 
on that experience, including -Wcompat in -Wall seems like a good plan to me.

Manuel

> Ben Gamari :
> 
> tl;dr. GHC has a new set of warnings, -Wcompat, intended to give users
>   advance notice of coming library changes. We want to know whether
>   you think this set should be included in -Wall. See the Wiki [4]
>   and voice your opinion via the linked poll.
> 
> 
> Hello everyone,
> 
> GHC 8.0.1 will include a new warning group, -Wcompat, which arose out of
> the MonadFail proposal discussion [1] late last year. This warning set
> is intended to provide a means of informing users of coming changes in
> GHC's core libraries.
> 
> We would like to solicit the community's feedback on whether this new
> flag set should be implied by -Wall.
> 
> This proposal is motivated by concern expressed by some that -Wcompat
> would see little usage unless it is placed in one of the warning sets
> typically used during development. One such set is -Wall, which enables
> a generous fraction of GHC's warning collectionand is is intended [2]
> for use during development.
> 
> Unfortunately, despite the (albeit only recently stated) intent of
> flag, -Wall is widely used outside of development [3], often with the
> expectation that the result be warning-clean across multiple GHC
> versions. While we hope that -Wall will see less use in this context in
> the future, given its current role we wouldn't want to add options to it
> that would cause undue burden for users.
> 
> So, we are asking for your opinion: should -Wcompat be implied by -Wall?
> You can find a more thorough description of the precise proposal on the
> GHC Wiki [4]. It would be very much appreciated if you could take a few
> minutes familiarize yourself with the options and provide your thoughts
> via this quick poll,
> 
>
> https://docs.google.com/forms/d/1BmIQvhHcnDB79LgBvaWl_xXpS1q0dMHe3Gq9JeU9odM/viewform
> 
> Feel free to discuss the issue further in this thread.
> 
> Thank you for sharing,
> 
> - Ben
> 
> 
> 
> [1] https://mail.haskell.org/pipermail/ghc-devs/2015-October/010101.html
> 
> [2] https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html
> 
> [3] In a rather unscientific study, nearly half of packages on Hackage
>include it in ghc-options,
> 
>$ tar -xf ~/.cabal/packages/00-INDEX.tar
>$ (for pkg in $(ls); do ls $pkg/*/*.cabal | sort -r | head -n1; done) 
> | xargs grep -L '\-Wall' | wc -l
>4352
>$ ls | wc -l 
>9347
>   
> [4] https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings/Wcompat
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

[Haskell] ANNOUNCE: Haskell for Mac, 1.1

[Manuel M T Chakravarty]

Haskell for Mac, the interactive Haskell development environment for OS X, has 
just received a significant update. In particular, the new command line tool 
integration essentially turns it into a full GHC distribution for OS X.

For details, please see

  http://haskellformac.com/news.html

Cheers,
Manuel

___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] Learning Haskell — a new tutorial

[Manuel M T Chakravarty]

For those getting started with Haskell, you might like to have a look at our 
new Haskell tutorial ”Learning Haskell”: 

  http://learn.hfm.io/

It features a mix of text and screencasts and will be extended over time. There 
is a bit on the background at

  http://blog.haskellformac.com/blog/learning-haskell

Enjoy!
Manuel

___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

[Haskell] ANNOUNCE: Haskell for Mac, 1.0

[Manuel M T Chakravarty]

It is my great pleasure to announce Haskell for Mac

  http://haskellformac.com

Haskell for Mac is an interactive Haskell development environment for OS X 
Yosemite that is trivial to install, easy to use, and that features Haskell 
playgrounds. 

Haskell playgrounds are very much like a persistent, constantly re-evaluated 
GHCi session. All Haskell commands are evaluated as you edit them, constantly 
displaying up-to-date results and type information. Moreover, Haskell 
playgrounds support rich interactive graphics and animations (based on the 
Rasterific, Diagram, and Chart packages as well as Apple’s 2D animation and 
games framework SpriteKit).

Haskell for Mac is an advanced programming environment for an advanced language.

Enjoy!
Manuel

PS: The focus of the first release is on learning and prototyping with minimal 
project management support (essentially equivalent to Cabal files with one 
executable section).
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [Haskell] [Haskell-cafe] [accelerate-haskell] [ANN] accelerate-0.15

[Manuel M T Chakravarty]

[Sorry for duplicates, but I first had the wrong sender address.]

We always very gladly accept pull requests! :)

In any case, please add feature requests as tickets to the GitHub issue tracker 
(so they don’t get lost):

 https://github.com/AccelerateHS/accelerate/issues

We are trying our best to add requested functionality, but our resources are 
also very limited — hence, any contributions are most welcome.

Manuel

Niklas Hambüchen m...@nh2.me:
 Excellent!
 
 Now here comes my number 1 feature request for the next version:
 
 IO/ST arrays/computations in accelerate, so that I can implement stuff
 that can work on a 1GB device array with interleaved IO, without having
 to download and-re-upload that array every time.
 
 Keep up the good work!
 ___
 Haskell-Cafe mailing list
 haskell-c...@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: Associated type instances

[Manuel M T Chakravarty]

Simon,

I’m not sure when this ”feature” was added, but I’m pretty sure that my 
original implementation of associated types was exactly what you describe in 
the solution. Or did I miss anything?

Manuel

Simon Peyton Jones simo...@microsoft.com:
 Friends
 
 I want to make withdraw (or, rather, simplify) a little-known feature in GHC, 
 but before I do so I want to check that no one is going to have a heart 
 attack.
 
 Relevant bits of the user manual: 
 http://www.haskell.org/ghc/docs/latest/html/users_guide/type-families.html#assoc-decl
 
 All of this arose when thinking about fixing Trac #9063.
 
 I believe that this change will affect essentially nobody, and I propose to 
 implement forthwith in HEAD (and hence 7.10). 
 
 Does anyone object?
 
 Thanks
 
 Simon
 
  
 
 The issue
 
 Consider this:
 
 class C a where
type T a b :: *
  
 instance C [x] where
type T [x] b = x - b
 That is just what you’d expect.  But currently this is allowed too:
 
 instance C [x] where
type T [x] Int = x - Int
type T [x] Bool = Bool - x
 That is, GHC 7.8 allows many associated type instances, provided they don’t 
 overlap.  But, oddly you can’t further instantiate the instance pattern. This 
 would make just as much sense, but isn’t allowed:
 
 instance C [x] where
type T [Int] b = b - Int
type T [Bool] b = Bool - b
 Moreover, as the user manual says, for an open kind like *, none of this 
 really makes sense. It really only makes sense for a closed kind. Something 
 like
 
 class D a where
type S (b :: Bool) a :: *
 Now this would make some kind of sense:
 
 instance D [x] where
type S True [x] = x - x
type S False [x] = x
 But for closed kinds, you really want a closed type family.  So this would be 
 better:
 
 instance D [x] where
type S b [x] = SHelp x b
  
 type family SHelp x b where
   SHelp x True = x - x
   SHelp x False = x
  
 So yes, you do have to declare a named helper type, but you get something 
 much more perspicuous and explicit in exchange.
 
 All of this also applies to the default declaration(s) which you can supply 
 for an associated type (see 7.7.3.2 in the link above), only it’s a bit more 
 complicated and indirect.
 
 My solution
 
 I propose to simplify substantially, as follows:
 
 · The “shared arguments” of an associated type are the argument 
 positions that mention a type variable from the class header.  So in class C 
 above, the first argument position of T is “shared”; and in class D, the 
 second argument position of S is shared.
 
 · A instance for an associated type (in a class instance declaration) 
 cf 7.7.3.1 must have
 
 o   type variables in the non-shared argument positions, and
 
 o   an exact copy of the corresponding instance header type in the shared 
 positions
 
 · For each associated type you can have
 
 o   at most one default declaration in the class declaration
 
 o   at most one type instance declaration in the class instance declaration
 
  
 
  
 
 ___
 ghc-devs mailing list
 ghc-d...@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8.3 release

[Manuel M T Chakravarty]

I believe #9078 affects all EDSLs that use Andy Gill’s stable name method to 
implement observable sharing. It certainly crashes Accelerate.

I would very much appreciate if 7.8.3 would be released in time to make it into 
the upcoming Haskell Platform. (If the platform would ship with 7.8.2., that 
would be a quite bad for all affected EDSL libraries.)

Do we know the projected release date for the platform?

Manuel

PS: For Accelerate, the situation is actually rather awkward right now. Due to 
the changes re ambiguous signatures in GHC 7.8, Accelerate needs to introduce a 
breaking API change to compile with 7.8. However, we can’t really fully 
transition to 7.8 until #9078 is fixed.

Austin Seipp aus...@well-typed.com:
 Hello all,
 
 After a long week, I've finally gotten a little time to reply to
 emails, and I mainly have one question I'd like to ask.
 
 First, please direct your attention to this:
 
 https://ghc.haskell.org/trac/ghc/query?status=closedstatus=mergestatus=patchmilestone=7.8.3group=resolutioncol=idcol=summarycol=ownercol=typecol=prioritycol=componentcol=versionorder=priority
 
 This is the 7.8.3 milestone, but it only considers things that are:
 
 - 1) Fixed
 - 2) Going to be merged
 - 3) Are a patch to be still merged.
 
 That is, it is a solid representation of the difference between 7.8.2
 and the 7.8 branch tip.
 
 The question is: when should we do the release? There are several bugs
 there that seem quite problematic for users - #9045, #7097, #9001,
 #8768 and #9078 in particular.
 
 If these bugs are really problematic (and I sort of feel they are)
 then the release can happen soon. I can do it within a week from now,
 and we could punt more to a 7.8.4 release.
 
 I ask this because my time to dedicate to GHC is a bit thin right now,
 so you must help me decide what's important! So please let me know -
 just a general vote in favor of doing it within some X timeframe (even
 'real soon' or 'a week would be great') would be nice.
 
 PS: I apologize for the lack of status updates and brief email - my
 time for GHC has been in very short order the past two weeks in
 particular, and I've finally just returned to a computer (not mine)
 for right now to ask this.
 
 PPS: This might also impact the 7.10 schedule, but last Simon and I
 talked, we thought perhaps shooting for ICFP this time (and actually
 hitting it) was a good plan. So I'd estimate on that a 7.8.4 might
 happen a few months from now, after summer.
 
 -- 
 Regards,
 
 Austin Seipp, Haskell Consultant
 Well-Typed LLP, http://www.well-typed.com/
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell] The future of array-oriented computing in Haskell — a survey

[Manuel M T Chakravarty]

In the Programming Languages  Systems (PLS) group @ UNSW, we have spent a lot 
of energy on developing methods for high-performance array programming in a 
purely functional style. We are curious how our work is being used and what 
else the community would like to be able to achieve with libraries, such as 
Repa and Accelerate. Please help us by completing this survey:

  
https://docs.google.com/forms/d/1qXPUR19kjKghrdxvE7P767HNy9-Lj81VSDS-l5MfN8M/viewform

We will post the survey results.

Thanks!
Manuel

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

Re: Proposal: NoImplicitPreludeImport

[Manuel M T Chakravarty]

Ian Lynagh i...@well-typed.com:
 On Tue, Jun 04, 2013 at 01:15:58PM +1000, Manuel M T Chakravarty wrote:
 
 If a module contains an import of the form
 
  import Prelude.XYZ
 
 then it also automatically uses the NoImplicitPrelude language pragma. 
 Otherwise, the Prelude remains to be implicitly defined as before.
 
 What about these?:
 
import Prelude.XYZ as Foo

In that case, I think, we should also have NoImplicitPrelude, but in case of

import qualified Prelude.XYZ as Foo

they might to explicitly want to avoid clashes with the implicit Prelude. This 
would be an argument to not have NoImplicitPrelude in this case. On the other 
hand, simpler is better; so, maybe it shouldn't depend on the way a 
'Prelude.XYZ' module is imported and we should use NoImplicitPrelude regardless.

import Foo as Prelude.XYZ

I would say that doesn't qualify for having NoImplicitPrelude, but I don't feel 
strongly about that.

Summary
~~~

If and only if a module has at least one impdecl of the form

  'import' ['qualified'] Prelude.XYZ ['as' modid] [impspec]

then this implies {-# LANGUAGE NoImplicitPrelude #-}.

That is a simple rule with no surprises.

Manuel




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

Re: Proposal: NoImplicitPreludeImport

[Manuel M T Chakravarty]

I agree with Bryan. Such an invasive change should have a great payoff.

Simon Marlow (in a different discussion) proposed the following (IMO much 
better) idea: 

If a module contains an import of the form

  import Prelude.XYZ

then it also automatically uses the NoImplicitPrelude language pragma. 
Otherwise, the Prelude remains to be implicitly defined as before.

This simplifies using an alternative Prelude with no cost for modules that do 
not make use of that feature.

Manuel

Bryan O'Sullivan b...@serpentine.com:
 On Tue, May 28, 2013 at 8:23 AM, Ian Lynagh i...@well-typed.com wrote:
 I have made a wiki page describing a new proposal,
 NoImplicitPreludeImport, which I intend to propose for Haskell 2014:
 http://hackage.haskell.org/trac/haskell-prime/wiki/NoImplicitPreludeImport
 
 What do you think?
 
 This is a truly terrible idea.
 
 It purports to be a step towards fixing the backwards compatibility problem, 
 but of course it breaks every module ever written along the way, and it means 
 that packages that try to be compatible across multiple versions of GHC will 
 need mandatory CPP #ifdefs for years to come.
 
 The current model that we have, of opting out of the Prelude explicitly, 
 provides the same capability without damning the entire Haskell world to a 
 months-long edit-recompile cycle.
 
 Of course being able to evolve the language and its libraries is important, 
 but experience from other languages (e.g. Python, Ruby) offer the lesson that 
 ignoring the if it ain't broke, don't fix it rule is very perilous: it 
 risks hobbling language growth and development for years. This proposal takes 
 that rule and maximally flouts it, while offering scant payoff in return.
 ___
 Haskell-prime mailing list
 Haskell-prime@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-prime

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

Re: [Haskell-cafe] Interfacing Java/Haskell

[Manuel M T Chakravarty]

CJ van den Berg c...@vdbonline.com:
 I have successfully written Java/Haskell programs using the Java
 Native Interface. You can find my JNI to Haskell binding library at
 https://github.com/neurocyte/foreign-jni. I am primarily using it to
 write Android Apps with Haskell,

Just out of curiosity, have you got any complete apps that you built that way? 
Are they in the Google Store?

Manuel


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

Re: [Haskell-cafe] install cuda

[Manuel M T Chakravarty]

Geoffrey Mainland mainl...@apeiron.net:
 Fantastic, glad you got it working! Maybe it's time for me to send
 Trevor a pull request...

That sounds like an excellent idea!

Manuel

 On 04/01/2013 04:27 PM, Peter Caspers wrote:
 indeed, not very helpful ...
 
 When I installed Cuda the latest driver (296.0) that was running on my
 laptop (a W520 ThinkPad) was not sufficient for version 5.0. However
 as I noticed today in February Lenovo released a driver update (311.0)
 and with that 5.0 is in fact running. :-)
 
 With that the Haskell bindings work well.
 
 Thanks again very much, Geoff
 Peter
 
 
 
 Am 01.04.2013 12:25, schrieb Geoffrey Mainland:
 That is not a very elucidating crash message, so I don't see how to
 proceed. After ghci print Loading package cuda-0.5.0.0 ... linking
 ... done. it just exits? No error dialog, nothing? Did you try building
 any of the examples in the cuda package that don't require ghci?
 
 Is your graphics card incompatible with CUDA 5.0, or do you just not
 want to update your driver?
 
 Geoff
 
 On 04/01/2013 10:33 AM, Peter Caspers wrote:
 yes, the installation seems to work fine now. However, doing the
 following test in ghci
 
 Prelude :m +Foreign.CUDA
 Prelude Foreign.CUDA props 0
 Loading package bytestring-0.9.2.1 ... linking ... done.
 Loading package cuda-0.5.0.0 ... linking ... done.
 
 results in a crash. The CUDA version I am using is 4.1.28. You think
 there is something I could try to analyze this further ?
 Thanks a lot for your help
 Peter
 
 Am 31.03.2013 21:48, schrieb Geoffrey Mainland:
 You need to generate the configure script using autoconf:
 
 
 
 https://www.gnu.org/software/autoconf/manual/autoconf.html#autoconf-Invocation
 On 03/31/2013 08:27 PM, Peter Caspers wrote:
 Hmm, I get
 
 Configuring cuda-0.5.0.0...
 setup.exe: configure script not found.
 
 can you help ?
 
 Peter
 
 I was able to install the cuda package under 32-bit GHC 7.4.2
 using the
 5.0 SDK and use it from within ghci. This required using my fork
 of the
 cuda repo and following the instructions in my WINDOWS.md. Make sure
 nvcc is in your path (the CUDA installer should have made this
 so) and
 try 'cabal configure'.
 
 
 
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: GHC 7.8 release?

[Manuel M T Chakravarty]

Simon Peyton-Jones simo...@microsoft.com:
 |   You may ask what use is a GHC release that doesn't cause a wave of 
 updates?
 |  And hence that doesn't work with at least some libraries.  Well, it's a 
 very useful
 |  forcing function to get new features actually out and tested.
 |  
 |  But the way you test new features is to write programs that use them,
 |  and programs depend on libraries.
 
 That is of course ideal, but the ideal carries costs.  A half way house is a 
 release whose library support will be patchy.  Not such good testing, but 
 much lower costs.  But still (I think) a lot more testing than compile HEAD 
 gives us.

I don't think so. In my experience, library support is not patchy, but 
virtually non-existent as some of the very widely used libraries (like Text) 
break, and everything else depends on them in one way or another.

If we don't make sure that the commonly used libraries work with these 
preview releases, I don't think those releases are worth the effort.

I understand that we can't really guarantee API backwards compatibility for the 
GHC API (but that's ok as few packages depend on that). Critical are all the 
libraries bundled with GHC. Adding to them is fine, but no API definitions 
should change or be removed.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

[Manuel M T Chakravarty]

Simon Peyton-Jones simo...@microsoft.com:
 If there's a path to having a release strategy as Manuel suggests, and having 
 an intermediate release  with the new vector primops, type extensions and 
 such goodness, then I'm all for it.  A lot of these bits are things ill start 
 using almost immediately in production / real software, esp if I'm not 
 needing to patch every stable library beyond maybe relaxing versioning 
 constraints.
 
 Let me suggest once more a possible path, along the lines you suggest
 ·For people who value stability: use the Haskell Platform.  Ignore 
 GHC releases.
 ·For people who want as many features as possible: use GHC releases.
 ·For people who want to live on the bleeding edge: build HEAD from 
 source
  
 The Haskell Platform decides which GHC release to use, advertises that to 
 package authors who do whatever updates are needed.  HP may perfectly 
 sensibly skip an entire release entirely.
  
 In short, I think we already have the situation that you desire.  Perhaps we 
 just need to market it better? 
  
 Or am I mistaken?

There is one kink: for GHC releases to be *useful* substitutes for the HP for 
people who want medium stability, they must not change (expect maybe add to) 
the APIs in GHC versions that do not coincide with HP releases. 

Why? If they change APIs, many of the packages on Hackage will not build with 
these intermediate GHC releases, which makes them useless for anything, but 
testing GHC.

Otherwise, I am perfectly happy with your suggestion. However, this is not the 
status quo. All (major) GHC releases do break critical packages on Hackage.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

[Manuel M T Chakravarty]

Simon Marlow marlo...@gmail.com:
 I agree too - I think it would be great to have non-API-breaking releases 
 with new features.  So let's think about how that could work.
 
 Some features add APIs, e.g. SIMD adds new primops.  So we have to define 
 non-API-breaking as a minor version bump in the PVP sense; that is, you can 
 add to an API but not change it.
 
 As a straw man, let's suppose we want to do annual API releases in September, 
 with intermediate non-API releases in February.  Both would be classed as 
 major, and bump the GHC major version, but the Feb releases would only be 
 allowed to bump minor versions of packages. (except perhaps the version of 
 the GHC package, which is impossible to keep stable if we change the 
 compiler).
 
 So how to manage the repos.  We could have three branches, but that doesn't 
 seem practical.  Probably the best way forward is to develop new features on 
 separate branches and merge them into master at the appropriate time - i.e. 
 API-breaking feature branches could only be merged in after the Feb release.
 
 Thoughts?

That sounds sensible to me. 

Related to this, then, is the management of branches, which, I think, we can 
improve in two ways:

(1) Make all library packages into submodules.
(2) Fork-instead-of-branch and use GitHub pull requests.

Re (1): submodules make tracking of synchronised branches across multiple repos 
simpler. Yes, they also have their pitfalls, but given that we are already 
using submodules extensively, we need to deal with those pitfalls anyway. So, 
why not reap the benefits, too?

Re (2): we should encourage contributors to fork the GHC repos on GitHub and 
work in those. That makes it easy for everybody to build forks (which will be 
longer-lived under the above policy) and creating a fork doesn't require any 
special privileges in GHC repos. Finally, we can use GitHub pull requests to 
track contributions that are pending integration. This is IMHO also much nicer 
than attaching patches at Trac tickets.

Manuel

 On 09/02/13 02:04, Manuel M T Chakravarty wrote:
 I completely agree with Johan. The problem is to change core APIs too
 fast. Adding, say, SIMD instructions or having a new type extension
 (that needs to be explicitly activated with a -X option) shouldn't break
 packages.
 
 I'm all for restricting major API changes to once a year, but why can't
 we have multiple updates to the code generator per year or generally
 release that don't affect a large number of packages on Hackage?
 
 Manuel
 
 Johan Tibell johan.tib...@gmail.com mailto:johan.tib...@gmail.com:
 On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com
 mailto:marlo...@gmail.com wrote:
 
For a while we've been doing one major release per year, and 1-2
minor releases.  We have a big sign at the top of the download
page directing people to the platform.  We arrived here after
various discussions in the past - there were always a group of
people that wanted stability, and a roughly equally vocal group of
people who wanted the latest bits.  So we settled on one
API-breaking change per year as a compromise.
 
Since then, the number of packages has ballooned, and there's a
new factor in the equation: the cost to the ecosystem of an
API-breaking release of GHC.  All that updating of packages
collectively costs the community a lot of time, for little
benefit.  Lots of package updates contributes to Cabal Hell.  The
package updates need to happen before the platform picks up the
GHC release, so that when it goes into the platform, the packages
are ready.
 
So I think, if anything, there's pressure to have fewer major
releases of GHC.  However, we're doing the opposite: 7.0 to 7.2
was 10 months, 7.2 to 7.4 was 6 months, 7.4 to 7.6 was 7 months.
We're getting too efficient at making releases!
 
 
 I think we want to decouple GHC major releases (as in, we did lots
 of work) from API breaking releases. For example, GCC has lots of
 major (or big) releases, but rarely, if ever, break programs.
 
 I'd be delighted to see a release once in a while that made my
 programs faster/smaller/buggy without breaking any of them.
 
 -- Johan
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 parallel-haskell group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to parallel-haskell+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GHC 7.8 release?

[Manuel M T Chakravarty]

I completely agree with Johan. The problem is to change core APIs too fast. 
Adding, say, SIMD instructions or having a new type extension (that needs to be 
explicitly activated with a -X option) shouldn't break packages.

I'm all for restricting major API changes to once a year, but why can't we have 
multiple updates to the code generator per year or generally release that don't 
affect a large number of packages on Hackage?

Manuel

Johan Tibell johan.tib...@gmail.com:
 On Fri, Feb 8, 2013 at 6:28 AM, Simon Marlow marlo...@gmail.com wrote:
 For a while we've been doing one major release per year, and 1-2 minor 
 releases.  We have a big sign at the top of the download page directing 
 people to the platform.  We arrived here after various discussions in the 
 past - there were always a group of people that wanted stability, and a 
 roughly equally vocal group of people who wanted the latest bits.  So we 
 settled on one API-breaking change per year as a compromise.
 
 Since then, the number of packages has ballooned, and there's a new factor in 
 the equation: the cost to the ecosystem of an API-breaking release of GHC.  
 All that updating of packages collectively costs the community a lot of time, 
 for little benefit.  Lots of package updates contributes to Cabal Hell.  The 
 package updates need to happen before the platform picks up the GHC release, 
 so that when it goes into the platform, the packages are ready.
 
 So I think, if anything, there's pressure to have fewer major releases of 
 GHC.  However, we're doing the opposite: 7.0 to 7.2 was 10 months, 7.2 to 7.4 
 was 6 months, 7.4 to 7.6 was 7 months.  We're getting too efficient at making 
 releases!
 
 I think we want to decouple GHC major releases (as in, we did lots of work) 
 from API breaking releases. For example, GCC has lots of major (or big) 
 releases, but rarely, if ever, break programs.
 
 I'd be delighted to see a release once in a while that made my programs 
 faster/smaller/buggy without breaking any of them.
 
 -- Johan

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Mailing list reorganisation

[Manuel M T Chakravarty]

Good plan!

Ian Lynagh i...@well-typed.com:
 Hi all,
 
 Following a recent discussion, we propose to reorganise the GHC-related
 mailing lists so that we end up with:
 
glasgow-haskell-users
For user discussions
 
ghc-devs
For developer discussions
 
ghc-commits
For automated commit messages from the git repositories
 
ghc-builds
For automated nightly build reports
 
ghc-tickets
For automated messages from trac
 
 We would remove
cvs-ghc cvs-libraries cvs-other glasgow-haskell-bugs
 but leave the archives in place, and for now forwarding messages to
 cvs-* to ghc-devs, and glasgow-haskell-bugs to ghc-tickets.
 (cvs-libraries and cvs-other are included in this list, because we think
 they are mainly used by libraries that GHC HQ maintains, or by GHC's
 lagging repos of libraries that other people maintain).
 
 The initial subscriber lists for ghc-devs, ghc-commits and ghc-builds
 would be the union of the subscribers of cvs-ghc, cvs-libraries and
 cvs-other. For ghc-tickets it would be the subscriber list for
 glasgow-haskell-bugs.
 
 Does that sound reasonable? Does anyone have any further questions or
 comments?
 
 
 Thanks
 Ian
 
 
 ___
 Glasgow-haskell-users mailing list
 glasgow-haskell-us...@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Mailing list reorganisation

[Manuel M T Chakravarty]

Good plan!

Ian Lynagh i...@well-typed.com:
 Hi all,
 
 Following a recent discussion, we propose to reorganise the GHC-related
 mailing lists so that we end up with:
 
glasgow-haskell-users
For user discussions
 
ghc-devs
For developer discussions
 
ghc-commits
For automated commit messages from the git repositories
 
ghc-builds
For automated nightly build reports
 
ghc-tickets
For automated messages from trac
 
 We would remove
cvs-ghc cvs-libraries cvs-other glasgow-haskell-bugs
 but leave the archives in place, and for now forwarding messages to
 cvs-* to ghc-devs, and glasgow-haskell-bugs to ghc-tickets.
 (cvs-libraries and cvs-other are included in this list, because we think
 they are mainly used by libraries that GHC HQ maintains, or by GHC's
 lagging repos of libraries that other people maintain).
 
 The initial subscriber lists for ghc-devs, ghc-commits and ghc-builds
 would be the union of the subscribers of cvs-ghc, cvs-libraries and
 cvs-other. For ghc-tickets it would be the subscriber list for
 glasgow-haskell-bugs.
 
 Does that sound reasonable? Does anyone have any further questions or
 comments?
 
 
 Thanks
 Ian
 
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Dynamic libraries by default and GHC 7.8

[Manuel M T Chakravarty]

Simon Marlow marlo...@gmail.com:
 This has some advantages and some disadvantages, so we need to make a
 decision about what we want to do in GHC 7.8. There are also some policy
 questions we need to answer about how Cabal will work with a GHC that
 uses dynamic libraries by default. We would like to make these as soon
 as possible, so that GHC 7.6.2 can ship with a Cabal that works
 correctly.
 
 The various issues are described in a wiki page here:
 http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
 
 Thanks for doing all the experiments and putting this page together, it
 certainly helps us to make a more informed decision.
 
 If you have a few minutes to read it then we'd be glad to hear your
 feedback, to help us in making our decisions
 
 My personal opinion is that we should switch to dynamic-by-default on all 
 x86_64 platforms, and OS X x86. The performance penalty for x86/Linux is too 
 high (30%), and there are fewer bugs affecting the linker on that platform 
 than OS X.
 
 I am slightly concerned about the GC overhead on x86_64/Linux (8%), but I 
 think the benefits outweigh the penalty there, and I can probably investigate 
 to find out where the overhead is coming from.

I agree with your opinion.

Firstly, correctness is more important than performance. (It's Haskell, after 
all.) Secondly, the RTS linker is an unnecessary time sink, and developer 
cycles are precious. Thirdly, when shipping production systems, people can 
always link statically to get best performance.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell-cafe] Which advanced Haskell topics interest you

[Manuel M T Chakravarty]

Most existing Haskell books and similar teaching material is aimed at 
programmers who are new to Haskell. This survey is to assess the community 
interest in teaching material covering advanced topics beyond the commonly 
taught introductory material.

 
https://docs.google.com/spreadsheet/viewform?formkey=dE1QZFNRLTFMdkllYWIyR2FkYnRzZHc6MQ

Manuel


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

Re: [Haskell-cafe] Which advanced Haskell topics interest you

[Manuel M T Chakravarty]

Kristopher Micinski krismicin...@gmail.com:
 On Thu, Oct 4, 2012 at 1:21 PM, Stephen Tetley stephen.tet...@gmail.com 
 wrote:
 As for an advanced book, maybe limiting the subject to one domain
 (concurrency / DSLs for graphics / pick a favourite ...) might
 make a better book than one targeting a mix of advanced topics.
 
 Another problem is that the topics in these domains don't simply deal
 with Haskell, they deal with real computer science that is not to be
 understated.
 
 Concurrency for Haskell involves tackling the real implementation
 issues inherent in making things work, but also a good taste of
 semantics, and actual concurrency.

Those are very good points.

Thanks,
Manuel


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

Re: Comparing StableNames of different type

[Manuel M T Chakravarty]

Emil Axelsson e...@chalmers.se:
 2012-08-26 08:03, Manuel M T Chakravarty skrev:
 Emil Axelsson e...@chalmers.se:
 2012-08-24 11:08, Simon Marlow skrev:
 On 24/08/2012 07:39, Emil Axelsson wrote:
 Hi!
 
 Are there any dangers in comparing two StableNames of different type?
 
   stEq :: StableName a - StableName b - Bool
   stEq a b = a == (unsafeCoerce b)
 
 I could guard the coercion by first comparing the type representations,
 but that would give me a `Typeable` constraint that would spread
 throughout the code.
 It should be safe even if the types are
 different, but I presume you expect the types to be the same, since
 otherwise the comparison would be guaranteed to return False, right?
 
 No, I want to do observable sharing of heterogeneously typed expressions 
 which means I will be comparing expressions of different type.
 
 You may like to have a look at how we have done this in the Accelerate EDSL:
 
   
 https://github.com/AccelerateHS/accelerate/blob/master/Data/Array/Accelerate/Smart.hs
 
 In particular, the Eq instance for stable names of AST nodes is at
 
   
 https://github.com/AccelerateHS/accelerate/blob/master/Data/Array/Accelerate/Smart.hs#L763
 
 Hm, doesn't this impose a `Typeable` constraint on all AST nodes (which is 
 what I'm trying to avoid)?

Yes, you need Typeable, but arguably that is cleaner than unsafeCoerce.

In any case, as I am not aware of any other system than Accelerate that 
implements observable sharing on typed ASTs, you may find the Accelerate code 
to be a helpful source of inspiration.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Comparing StableNames of different type

[Manuel M T Chakravarty]

Emil Axelsson e...@chalmers.se:
 2012-08-24 11:08, Simon Marlow skrev:
 On 24/08/2012 07:39, Emil Axelsson wrote:
 Hi!
 
 Are there any dangers in comparing two StableNames of different type?
 
   stEq :: StableName a - StableName b - Bool
   stEq a b = a == (unsafeCoerce b)
 
 I could guard the coercion by first comparing the type representations,
 but that would give me a `Typeable` constraint that would spread
 throughout the code.
 It should be safe even if the types are
 different, but I presume you expect the types to be the same, since
 otherwise the comparison would be guaranteed to return False, right?
 
 No, I want to do observable sharing of heterogeneously typed expressions 
 which means I will be comparing expressions of different type.

You may like to have a look at how we have done this in the Accelerate EDSL:

  
https://github.com/AccelerateHS/accelerate/blob/master/Data/Array/Accelerate/Smart.hs

In particular, the Eq instance for stable names of AST nodes is at

  
https://github.com/AccelerateHS/accelerate/blob/master/Data/Array/Accelerate/Smart.hs#L763

You may be able to use our entire scheme. (We have started to write it up as a 
paper, but the write up isn't in a coherent state yet.)

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: GADTs in the wild

[Manuel M T Chakravarty]

Most academic papers do use the eval example, but it is a practical example. 
This use of GADTs is nice for embedded languages. For example, Accelerate uses 
a supercharged version of it to catch as many errors as possible during Haskell 
host program compile-time (as opposed to Accelerate compile time, which is 
Haskell runtime).

Manuel


Simon Peyton-Jones simo...@microsoft.com:
 Friends
 
 I’m giving a series of five lectures at the Laser Summer School (2-8 Sept), 
 on “Adventures with types in Haskell”.  My plan is:
 1.   Type classes
 2.   Type families [examples including Repa type tags]
 3.   GADTs
 4.   Kind polymorphism
 5.   System FC and deferred type errors
  
 This message is to invite you to send me your favourite example of using a 
 GADT to get the job done.  Ideally I’d like to use examples that are (a) 
 realistic, drawn from practice (b) compelling and (c) easy to present without 
 a lot of background.  Most academic papers only have rather limited examples, 
 usually eval :: Term t - t, but I know that GADTs are widely used in 
 practice.
  
 Any ideas from your experience, satisfying (a-c)?  If so, and you can spare 
 the time, do send me a short write-up. Copy the list, so that we can all 
 benefit.
  
 Many thanks
 
 Simon
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Haskell Platform - BSD License?

[Manuel M T Chakravarty]

Thomas Schilling nomin...@googlemail.com:
 You may concatenate the licenses of all the packages you are using. GHC 
 includes the LGPL libgmp. The license file for each package is mentioned in 
 the .cabal file.
 
 

If you need a version of GHC free of the LGPL, you can build GHC from source 
using the package 'integer-simple' instead of 'integer-gmp'.

Manuel

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

Re: Proposal: Scoping rule change

[Manuel M T Chakravarty]

Nitpick: Your example actually does not lead to an error with GHC, as you 
define, but do not use 'foo' in M. Names (like classes) only clash when you 
look them up.

Manuel

Lennart Augustsson lenn...@augustsson.net:
 It's not often that one gets the chance to change something as
 fundamental as the scoping rules of a language.  Nevertheless, I would
 like to propose a change to Haskell's scoping rules.
 
 The change is quite simple.  As it is, top level entities in a module
 are in the same scope as all imported entities.  I suggest that this
 is changed to that the entities from the module are in an inner scope
 and do not clash with imported identifiers.
 
 Why?  Consider the following snippet
 
 module M where
 import I
 foo = True
 
 Assume this compiles.  Now change the module I so it exports something
 called foo.  After this change the module M no longer compiles since
 (under the current scoping rules) the imported foo clashes with the
 foo in M.
 
 Pros: Module compilation becomes more robust under library changes.
 Fewer imports with hiding are necessary.
 
 Cons: There's the chance that you happen to define a module identifier
 with the same name as something imported.  This will typically lead to
 a type error, but there is a remote chance it could have the same
 type.
 
 Implementation status: The Mu compiler has used the scoping rule for
 several years now and it works very well in practice.
 
   -- Lennart
 
 ___
 Haskell-prime mailing list
 Haskell-prime@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-prime


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

Re: Proposal: Scoping rule change

[Manuel M T Chakravarty]

If Lennart's suggestion is combined with GHC's lazy checking for name clashes 
(i.e., only check if you ever look a name up in a particular scope), it would 
also work in your example.

Manuel

Sittampalam, Ganesh ganesh.sittampa...@credit-suisse.com:
 If you’re using unqualified and unrestricted imports, there’s still the risk 
 that another module will export something you care about, e.g.
  
 module M where
 import I  -- currently exports foo
 import J  -- might be changed in future to export foo
  
 … foo …
  
 So I think you need to use import lists or qualified anyway to avoid any risk 
 of future name clashes – given that, does this change buy much?
  
 From: haskell-prime-boun...@haskell.org 
 [mailto:haskell-prime-boun...@haskell.org] On Behalf Of Lennart Augustsson
 Sent: 24 July 2012 02:29
 To: Haskell Prime
 Subject: Proposal: Scoping rule change
  
 It's not often that one gets the chance to change something as
 fundamental as the scoping rules of a language.  Nevertheless, I would
 like to propose a change to Haskell's scoping rules.
  
 The change is quite simple.  As it is, top level entities in a module
 are in the same scope as all imported entities.  I suggest that this
 is changed to that the entities from the module are in an inner scope
 and do not clash with imported identifiers.
  
 Why?  Consider the following snippet
  
 module M where
 import I
 foo = True
  
 Assume this compiles.  Now change the module I so it exports something
 called foo.  After this change the module M no longer compiles since
 (under the current scoping rules) the imported foo clashes with the
 foo in M.
  
 Pros: Module compilation becomes more robust under library changes.
 Fewer imports with hiding are necessary.
  
 Cons: There's the chance that you happen to define a module identifier
 with the same name as something imported.  This will typically lead to
 a type error, but there is a remote chance it could have the same
 type.
  
 Implementation status: The Mu compiler has used the scoping rule for
 several years now and it works very well in practice.
  
   -- Lennart
  
 
 ==
 Please access the attached hyperlink for an important electronic 
 communications disclaimer:
 http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
 ==
 
 ___
 Haskell-prime mailing list
 Haskell-prime@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-prime

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

Re: [Haskell-cafe] DPH matrix product

[Manuel M T Chakravarty]

Firstly, especially when you are talking about performance, please provided 
detailed information on (a) the versions of the compiler and libraries that you 
used and (b) of the command line options that you used for compilation.

Secondly, your function 'transposeP' doesn't make for a good nested 
data-parallel program. I haven't looked at the generated code, but I wouldn't 
be surprised if it doesn't optimise very well.

The core benefit of nested data parallelism is that the sub-arrays in a nested 
array of arrays can be of varying size leading to irregular parallelism. 
However, that flexibility comes at a price, namely that it is a fairly 
inefficient representation for *rectangular arrays*, such as regular 
two-dimensional matrices (as in your example). It shouldn't be quite as 
inefficient as what you report, but it will never be competitive with a 
dedicated regular representation.

Hence, for code, such as yours, we recommend to use our Repa library: 
http://hackage.haskell.org/package/repa

It generates very fast code for regular array problems, see also 
http://www.cse.unsw.edu.au/~chak/papers/LCKP12.html

Manuel


mblanco blanco...@gmail.com:
 Hi, I'm trying to implement a matrix product example using DPH. This is the 
 code:
 ---
 type MMultType = Double
 type Matrix = [:[:MMultType:]:]
 type MVector = [:MMultType:]
 type Matrix_wrapper = PArray (PArray MMultType)
 
 {-# NOINLINE matMult_wrapper #-}
 matMult_wrapper :: Matrix_wrapper - Matrix_wrapper - Matrix_wrapper
 matMult_wrapper mA mB = toPArrayP (mapP toPArrayP (matMult (fromNestedPArrayP 
 mA) (fromNestedPArrayP mB)))
 
 matMult :: Matrix - Matrix - Matrix
 matMult mA mB = mapP (\row - mapP (\col - dotp row col) (transposeP mB)) mA
 
 dotp :: MVector - MVector - MMultType
 dotp row col = D.sumP (zipWithP (D.*) row col)
 
 transposeP :: Matrix - Matrix
 transposeP m = 
 let
 h = lengthP m
 w = lengthP (m !: 0)
 rh = I.enumFromToP 0 (h I.- 1)
 rw = I.enumFromToP 0 (w I.- 1)
 in
 if h I.== 0 then [: :]
 else mapP (\y - mapP (\x - m !: x !: y) rh) rw
 ---
 
 My problem is at execution time, on matrices of size 300*300 the program does 
 finish (although it is very slow), but on 700*700 it consumes GBs of RAM 
 until the process is aborted.
 
 In the paper Work Efficient Higher-Order Vectorisation it is explained that 
 a work complexity problem (wich involved unnecesary array replication) was 
 recently treated. So at first I thought the code implementation related to 
 the paper had not been uploaded to hackage. But as I understand it must have 
 been, as that seems to be the motive of the dph-lifted-vseg package.
 
 Does anybody notice the problem with the example or if the problem is related 
 to the subject treated in the paper?
 
 Thanks in advance!
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe

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

Re: parallel garbage collection performance

[Manuel M T Chakravarty]

I wonder, do we have a Repa FAQ (or similar) that explain such issues? (And is 
easily discoverable?)

Manuel


Ben Lippmeier b...@ouroborus.net:
 On 19/06/2012, at 24:48 , Tyson Whitehead wrote:
 
 On June 18, 2012 04:20:51 John Lato wrote:
 Given this, can anyone suggest any likely causes of this issue, or
 anything I might want to look for?  Also, should I be concerned about
 the much larger gc_alloc_block_sync level for the slow run?  Does that
 indicate the allocator waiting to alloc a new block, or is it
 something else?  Am I on completely the wrong track?
 
 A total shot in the dark here, but wasn't there something about really bad 
 performance when you used all the CPUs on your machine under Linux?
 
 Presumably very tight coupling that is causing all the threads to stall 
 everytime the OS needs to do something or something?
 
 This can be a problem for data parallel computations (like in Repa). In Repa 
 all threads in the gang are supposed to run for the same time, but if one 
 gets swapped out by the OS then the whole gang is stalled.
 
 I tend to get best results using -N7 for an 8 core machine. 
 
 It is also important to enable thread affinity (with the -qa) flag. 
 
 For a Repa program on an 8 core machine I use +RTS -N7 -qa -qg
 
 Ben.
 
 
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: parallel garbage collection performance

[Manuel M T Chakravarty]

Bryan O'Sullivan b...@serpentine.com:
 On Mon, Jun 18, 2012 at 9:32 PM, John Lato jwl...@gmail.com wrote:
 
 I had thought the last core parallel slowdown problem was fixed a
 while ago, but apparently not?
 
 Simon Marlow has thought so in the not too distant past (since he did the 
 work), if my recollection is correct.

It may very well be fixed for non-dataparallel programs. For dataparallel 
programs the situation is more tricky as we rely on all threads participating 
in a DP computation to be scheduled simultaneously. If one Core is currently 
tied up by the OS, then GHC's RTS can't do anything about that.  As it has no 
concept of gang scheduling (but treats the threads participating in a DP 
computation individually), it also doesn't know that scheduling a subset of the 
threads in the gang is counterproductive.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell] announce: language-objc

[Manuel M T Chakravarty]

That is a great contribution!

Thanks!
Manuel

John Lato jwl...@gmail.com:
 Hello,
 
 I am pleased to announce the initial release to hackage of
 language-objc, an objective-C AST, parser, and pretty-printer.  More
 details and short examples are available at
 http://johnlato.blogspot.sg/2012/06/language-objc-released.html
 
 This package is a fork of language-c, and I am most grateful to the
 work of Benedikt Huber, Manuel Chakravarty, Duncan Coutts, Bertram
 Felgenhauer, and all other contributors; they did the bulk of the
 coding.  Bugs and infelicities are mine.
 
 The version number is rather high for a beta release as I started from
 a recent language-c number.  The Objective-C extensions are rather
 less well tested at this time.
 
 Feedback and comments are welcome.
 
 Cheers,
 John Lato
 
 ___
 Haskell mailing list
 Haskell@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell


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

[ANN] Accelerate version 0.12: GPU computing with Haskell

[Manuel M T Chakravarty]

We just released version 0.12 of Data.Array.Accelerate, the GPGPU[1] library 
for Haskell:

  http://justtesting.org/gpu-accelerated-array-computations-in-haskell

This is a beta release. The library is not perfect, but it is definitely 
usable, and we are looking for early adopters.

Manuel

[1] Currently only NVIDIA GPUs are supported via NVIDIA's CUDA framework.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

[Haskell-cafe] [ANN] Accelerate version 0.12: GPU computing with Haskell

[Manuel M T Chakravarty]

We just released version 0.12 of Data.Array.Accelerate, the GPGPU[1] library 
for Haskell:

  http://justtesting.org/gpu-accelerated-array-computations-in-haskell

This is a beta release. The library is not perfect, but it is definitely 
usable, and we are looking for early adopters.

Manuel

[1] Currently only NVIDIA GPUs are supported via NVIDIA's CUDA framework.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Can Haskell outperform C++?

[Manuel M T Chakravarty]

Ryan Newton:
 But, anyway, it turns out that my example above is easily transformed from a 
 bad GHC performance story into a good one.  If you'll bear with me, I'll show 
 how below.
First, Manuel makes a good point about the LLVM backend.  My 6X anecdote 
 was from a while ago and I didn't use llvm [1].  I redid it just now with 
 7.4.1+LLVM, results below.  (The below table should read correctly in fixed 
 width font, but you can also see the data in the spreadsheet here.)
 
Time (ms)   Compiled File size   Comple+Runtime (ms)
 GHC 7.4.1 O0 24441241K
 GHC 7.4.1 O2 925 1132K1561
 GHC 7.4.1 O2 llvm  931 1133K
 GHC 7.0.4 O2 via-C 684 974K
 
 So LLVM didn't help [1].  And in fact the deprecated via-C backend did the 
 best!  

I would classify that as a bug.

 [1] P.P.S. Most concerning to me about Haskell/C++ comparisons are David 
 Peixotto's findings that LLVM optimizations are not very effective on 
 Haskell-generated LLVM compared with typical clang-generated LLVM.

There is some work underway to improve the situation, but I am sure more could 
be done.

Manuel

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

Re: [Haskell-cafe] Can Haskell outperform C++?

[Manuel M T Chakravarty]

Ryan Newton:
 As a community I think we have to face the fact that writing the hot inner 
 loop of your application as idiomatic Haskell is not [yet] going to give you 
 C/Fortran performance off the bat.  Though in some cases there's not really 
 anything stopping us but more backend/codegen work (I'm thinking of 
 arithmetically intensive loops with scalars only).  For example, the 
 following Mandel kernel is in many ways the *same* as the C version:
 
 https://github.com/simonmar/monad-par/blob/662fa05b2839c8a0a6473dc490ead8dd519ddd1b/examples/src/mandel.hs#L24H
 
 We have the types; we've got strictness (for this loop); but the C version 
 was 6X faster when I tested it.

Did you use the LLVM backend? I am asking because I have seen dramatic 
differences between the code generators in similar example. Have a look at

  https://wiki.cse.unsw.edu.au/cs3141/12s1/Parallelism%20notes

With GHC's native code generator, the C version is much faster than the Haskell 
version (by a factor of 2 or 3 IIRC), but using GHC's LLVM backend, the Haskell 
version is even a few percent faster than the C version on my machine. (This is 
on OS X using llvm-gcc to compile the C code — that is, the code generator for 
the C and Haskell version goes via LLVM.)

I think that is an interesting example, because it shows (a) just how much of a 
difference a good code generator can make and (b) that using the same code 
generator, a Haskell compiler has no inherent disadvantage to a C compiler. 
(Nevertheless, especially for small examples, it is much easier to write a slow 
Haskell than to write a slow C program.)

Manuel

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

Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper

[Manuel M T Chakravarty]

Stefan Monnier:
 I think, Apple has made their stance quite clear by releasing the
 command line dev tools:
 
 I'm not sure what you mean by that, but looking at the history of Apple
 devices, especially the recent history with iPad, iPhone, etc... it's
 pretty clear to me where this is headed: keep as tight a control on the
 machine as possible without alienating too many users.

It means that Apple likes to accommodate devs who prefer a traditional Unix 
environment over using IDEs (such as Xcode) and devs that use alternative tool 
chains (such as GHC).

Manuel


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

Re: [Haskell-cafe] Data.Array.Accelerate initialization timings

[Manuel M T Chakravarty]

Martin Dybdal:
 On 20 February 2012 16:39, Paul Sujkov psuj...@gmail.com wrote:
 Ah, it seems that I see now what's going wrong way. I'm not using the 'run'
 function from the CUDA backend, and so by default I guess the code is
 interpreted (the test backend used for semantics check). However, it's not
 perfectly clear how to use CUDA backend explicitly.
 
 Neither the interpreter or the CUDA code are used in your example.
 Everything in Data.Array.Accelerate are front-end stuff, your arrays
 are allocated on the host, so it is here there is an inefficiency.
 
 The use method inserts a statement in the syntax tree generated by
 the front-end, which the back-end can use as a hint to transfer that
 array to the GPU, while compiling the rest of the program into CUDA
 code. The Data.Array.Accelerate.CUDA.run function is the one that
 actually moves the arrays to the GPU.
 
 I haven't tried executing your code and I'm not sure why the front-end
 is that slow.

The 'fromList' function is mostly meant for testing or to initialise small 
arrays.  It is not particularly optimised.  (Going via a vanilla list is just a 
bad idea if you want performance.)

For efficient data marshalling have a look at the modules under 
Data.Array.Accelerate.IO.

Manuel


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

Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper

[Manuel M T Chakravarty]

Austin Seipp:
 The only two things not clear at this point, at least to me, are:
 
 1) Will Apple require the paid development program, as opposed to the
 free one, if you only want to self-sign applications with a cert they
 trust?

You can self-sign applications with a certificate that you get with a free 
developer ID.

Cf. http://daringfireball.net/2012/02/mountain_lion
 Apple is calling it “Gatekeeper”. It’s a system whereby developers can sign 
 up for free-of-charge Apple developer IDs which they can then use to 
 cryptographically sign their applications. If an app is found to be malware, 
 Apple can revoke that developer’s certificate, rendering the app (along with 
 any others from the same developer) inert on any Mac where it’s been 
 installed. In effect, it offers all the security benefits of the App Store, 
 except for the process of approving apps by Apple.

 2) What will the default Gatekeeper setting in Mountain Lion be?

The default is the middle option — i.e., AppStore and self-signed apps run.

From the same source,
 The default for this setting is, I say, exactly right: the one in the 
 middle, disallowing only unsigned apps. This default setting benefits users 
 by increasing practical security, and also benefits developers, preserving 
 the freedom to ship whatever software they want for the Mac, with no 
 approval process.

 In an ideal world, you won't require the paid dev ID (I
 don't know the expense of giving out certs however,) and the default
 setting would be App store + Dev signed.

It is an ideal world :)

Manuel


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

Re: [Haskell-cafe] Haskell development in Mac OS X after Gatekeeper

[Manuel M T Chakravarty]

Austin Seipp:
 On Sun, Feb 19, 2012 at 8:39 PM, Tom Murphy amin...@gmail.com wrote:
 On the other hand,
 it's impossible for a software company to maintain a sense of
 professionalism, when a user has to know a weird secret handshake to
 disable what they may perceive as equivalent to antivirus software.
 
 I'll also just add that if you're an actual software company, large or
 small, the $100 for the developer ID, certificate, ability to do
 iOS/App store apps, whatever, is a business expense, that is utterly
 dominated by a million other factors, as developing high quality
 applications isn't exactly cheap, and the price of a license is really
 the last thing you're going to worry about.
 
 If you're more worried about the potential to impact individual
 developers and small open source teams who want to get their work out
 there, you are right it's a concern.

I think, Apple has made their stance quite clear by releasing the command line 
dev tools:

  http://kennethreitz.com/xcode-gcc-and-homebrew.html

Manuel


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

Fwd: GHC, Clang XCode 4.2

[Manuel M T Chakravarty]

I think, you meant to reply to the list and not just to me.

 Von: B. Scott Michel scooter@gmail.com
 Betreff: Re: GHC, Clang  XCode 4.2
 Datum: 15 October 2011 12:32:36 
 An: Manuel M T Chakravarty c...@cse.unsw.edu.au
 Antwort an: scooter@gmail.com
 
 Simon:
 
 What are the performance penalties, specifically? I ask because I might still 
 have commit privs to llvm from the errors of a misspent post-doc era, so 
 could probably help push a patch to llvm if needed.
 
 That said, though, FreeBSD moved to llvm because itKs not GPL and it 
 generates better code.
 
 -scooter
 Sent from my Verizon Wireless BlackBerry
 
 -Original Message-
 From: Manuel M T Chakravarty c...@cse.unsw.edu.au
 Sender: glasgow-haskell-users-boun...@haskell.org
 Date: Thu, 13 Oct 2011 13:11:40 
 To: Simon Marlowmarlo...@gmail.com
 Cc: GHC Users Mailing Listglasgow-haskell-users@haskell.org
 Subject: Re: GHC, Clang  XCode 4.2
 
 Just FYI, Xcode 4.2 is live in the Mac App Store now, and it has some nice 
 goodies (i.e., many who develop for iOS and probably also OS X will probably 
 adopt it soon).
 
 Manuel
 
 PS: Sorry for not having participated in the discussion on how to solve this, 
 but I have too many loose ends right now.
 
 
 Simon Marlow:
 On 11/10/2011 18:45, David Peixotto wrote:
 Ok, I have attached a set of patches to support building the GHC
 runtime with llvm-gcc. The patches are based off of commit
 29a97fded4010bd01aa0a17945c84258e285d421 which was last Friday's HEAD.
 These patches are also available from my github repository on the
 llvm-gcc branch at
 
   git://github.com/dmpots/ghc.git
 
 There are three patches:
 
 0001- Uses pthread_getspecific and pthread_setspecfic to
access gct when the `llvm_CC_FLAVOR` CPP macro is
set
 
 0002- Modifies the configure scripts to set the
`llvm_CC_FLAVOR` macro when compiling with an llvm
based compile (either llvm-gcc or clang)
 
 0003- Passes the gct variable as a parameter in the GC. This
change is parameterized with CPP macros so that it
is only in effect when compiling for an llvm-based
compiler.
 
 The patches 0001 and 0002 provide the minimal support needed to build
 GHC with llvm-gcc. The 0003 patch is there to limit the performance
 hit we get by going through pthread functions to access the gct. I
 think the 0001 and 0002 patches should not be very controversial, but
 the 0003 patch is a more invasive change and perhaps Simon Marlow will
 want to clean it up before it is applied.
 
 Thanks, I'll take a look at these soon.
 
 Just a thought, but someone might want to write a blog post about how 
 Apple's choice to move to llvm-gcc is imposing a performance penalty on us 
 here, and get it up on Reddit.  That would give the issue some publicity 
 (they love that sort of thing on Reddit), and might result in some action.  
 I'd be happy to proof read a blog post before publication.  Some simple 
 benchmarks would be needed - one option is to use GHC itself with the 
 various combinations of compilers + RTS changes, or there are a small set of 
 GC benchmarks in nofib/gc.
 
 Cheers,
  Simon
 
 
 
 I ran a validate with the patches, and found one additional failure
 when going through an llvm-based compiler. There were no additional
 failures when using a gcc compiler even with my patches applied. The
 additional failure is the cgrun071 test which tests the popCnt
 primitives. I'm going to look into why that test fails, but I think
 the patches should be safe to apply as it would only show up when
 compiling with llvm-gcc, which is currently impossible without these
 patches.
 
 -David
 
 
 
 
 
 
 On Oct 7, 2011, at 10:30 AM, David Peixotto wrote:
 
 
 On Oct 6, 2011, at 7:32 AM, Simon Marlow wrote:
 
 On 05/10/2011 09:46, austin seipp wrote:
 There has been recent discussion on the Homebrew bug tracker
 concerning the upcoming XCode 4.2 release by Apple, which has
 apparently just gone GM (meaning they're going to make a real release
 on the app store Real Soon Now.)
 
 The primary concern is that XCode will no longer ship GCC 4.2 at all,
 it seems. XCode 4.0   4.1 merely set 'llvm-gcc' as the default
 compiler, and GHC's `configure` script was adjusted to find the
 `gcc-4.2` binary. If you have old XCode's installed, then you may have
 the binaries laying around, but I doubt they'll be on your $PATH, and
 anybody doing a fresh install is SOL.
 
 It seems Clang 3.0 will now be the default compiler, with llvm-gcc as
 a deprecated option, probably removed in XCode 4.3. It doesn't matter
 really, because both of them do not work with GHC, because of its use
 of either A) Global register variables of any kind, or B) the __thread
 storage modifier.
 
 David Peixotto did some work on this not too long ago as the issue of
 compiling with Clang was raised. His branches include changes which
 make the 'gct' variable use

Re: GHC, Clang XCode 4.2

[Manuel M T Chakravarty]

Just FYI, Xcode 4.2 is live in the Mac App Store now, and it has some nice 
goodies (i.e., many who develop for iOS and probably also OS X will probably 
adopt it soon).

Manuel

PS: Sorry for not having participated in the discussion on how to solve this, 
but I have too many loose ends right now.


Simon Marlow:
 On 11/10/2011 18:45, David Peixotto wrote:
 Ok, I have attached a set of patches to support building the GHC
 runtime with llvm-gcc. The patches are based off of commit
 29a97fded4010bd01aa0a17945c84258e285d421 which was last Friday's HEAD.
 These patches are also available from my github repository on the
 llvm-gcc branch at
 
git://github.com/dmpots/ghc.git
 
 There are three patches:
 
  0001- Uses pthread_getspecific and pthread_setspecfic to
 access gct when the `llvm_CC_FLAVOR` CPP macro is
 set
 
  0002- Modifies the configure scripts to set the
 `llvm_CC_FLAVOR` macro when compiling with an llvm
 based compile (either llvm-gcc or clang)
 
  0003- Passes the gct variable as a parameter in the GC. This
 change is parameterized with CPP macros so that it
 is only in effect when compiling for an llvm-based
 compiler.
 
 The patches 0001 and 0002 provide the minimal support needed to build
 GHC with llvm-gcc. The 0003 patch is there to limit the performance
 hit we get by going through pthread functions to access the gct. I
 think the 0001 and 0002 patches should not be very controversial, but
 the 0003 patch is a more invasive change and perhaps Simon Marlow will
 want to clean it up before it is applied.
 
 Thanks, I'll take a look at these soon.
 
 Just a thought, but someone might want to write a blog post about how Apple's 
 choice to move to llvm-gcc is imposing a performance penalty on us here, and 
 get it up on Reddit.  That would give the issue some publicity (they love 
 that sort of thing on Reddit), and might result in some action.  I'd be happy 
 to proof read a blog post before publication.  Some simple benchmarks would 
 be needed - one option is to use GHC itself with the various combinations of 
 compilers + RTS changes, or there are a small set of GC benchmarks in 
 nofib/gc.
 
 Cheers,
   Simon
 
 
 
 I ran a validate with the patches, and found one additional failure
 when going through an llvm-based compiler. There were no additional
 failures when using a gcc compiler even with my patches applied. The
 additional failure is the cgrun071 test which tests the popCnt
 primitives. I'm going to look into why that test fails, but I think
 the patches should be safe to apply as it would only show up when
 compiling with llvm-gcc, which is currently impossible without these
 patches.
 
 -David
 
 
 
 
 
 
 On Oct 7, 2011, at 10:30 AM, David Peixotto wrote:
 
 
 On Oct 6, 2011, at 7:32 AM, Simon Marlow wrote:
 
 On 05/10/2011 09:46, austin seipp wrote:
 There has been recent discussion on the Homebrew bug tracker
 concerning the upcoming XCode 4.2 release by Apple, which has
 apparently just gone GM (meaning they're going to make a real release
 on the app store Real Soon Now.)
 
 The primary concern is that XCode will no longer ship GCC 4.2 at all,
 it seems. XCode 4.0   4.1 merely set 'llvm-gcc' as the default
 compiler, and GHC's `configure` script was adjusted to find the
 `gcc-4.2` binary. If you have old XCode's installed, then you may have
 the binaries laying around, but I doubt they'll be on your $PATH, and
 anybody doing a fresh install is SOL.
 
 It seems Clang 3.0 will now be the default compiler, with llvm-gcc as
 a deprecated option, probably removed in XCode 4.3. It doesn't matter
 really, because both of them do not work with GHC, because of its use
 of either A) Global register variables of any kind, or B) the __thread
 storage modifier.
 
 David Peixotto did some work on this not too long ago as the issue of
 compiling with Clang was raised. His branches include changes which
 make the 'gct' variable use pthread_getspecific rather than __thread
 for TLS and then as an optimization use inline ASM to grab the value
 out of the variable, with an impact of about 9% it seems, but that's
 on nofib and I don't know if it was -threaded. He also included a
 version which passes the 'gct' around as a parameter to all GCC
 functions which is a bit uglier but may give some better performance I
 guess. (The discussion is from here IIRC.) I suppose the real perf
 killer here is probably -threaded code.
 
 https://github.com/dmpots/ghc
 
 Was there ever any decision on which route to take for this issue? The
 parameter passing solution looks quite uglier IMO but it may be
 necessary for performance.
 
 I'm happy to incorporate the parameter-passing changes if necessary.  I 
 think it should only be important in the inner loop of the GC 
 (scavenge_block/evacuate and the functions called from there).  If someone 
 sends me a working patch, I 

Re: Two Proposals

[Manuel M T Chakravarty]

Roman Leshchinskiy:
 Simon Peyton-Jones wrote:
 
 I'm not sure if this plan would support [(fred,45), (bill,22)] :: Map
 String Int.  Probably not.   Maybe that's a shortcoming... but such Maps
 are a rather surprising use of list literals.
 
 What data structures other than lists do we want to construct using list
 literals? I'm not really sure what the use cases are.

Parallel arrays! (I want to get rid of our custom syntax.)

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Two Proposals

[Manuel M T Chakravarty]

Roman Leshchinskiy:
 Manuel M T Chakravarty wrote:
 Roman Leshchinskiy:
 
 What data structures other than lists do we want to construct using list
 literals? I'm not really sure what the use cases are.
 
 Parallel arrays! (I want to get rid of our custom syntax.)
 
 Why? Don't you think it is useful to have a visual indication of which
 data structure you are using and what is going to be evaluated in
 parallel?

Whether a computation is parallel depends on the type.  That is still the case.

In Haskell, it is usually hard to reason about performance without a good 
understanding of the involved types and their representation.  Syntax alone is 
usually not very helpful.  I think it is fine if that is the same for data 
parallelism.

 In any case, if we want to get rid of the parallel array syntax, we have
 to overload list literals, enumerations and list comprehensions. We have
 the generic monadic desugaring for the latter but recovering an efficient
 DPH program from that sn't trivial.

At ICFP, George suggested that we might use RULES to transform the patterns of 
generic monadic desugaring into the form that we need for parallel arrays.  We 
need to check whether that really works out, of course.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC version 7.2.1

[Manuel M T Chakravarty]

At the request of the Haskell Platform folks, we are shipping the Data Parallel 
Haskell libraries separately from GHC (i.e., they are not bundled in the GHC 
distribution, nor will they be bundled in any Haskell Platform distribution).  
To use DPH with GHC 7.2.1, you need to install the DPH libraries separately 
from Hackage — for details, see

  http://pls.posterous.com/data-parallel-haskell-and-repa-for-ghc-721

Manuel

Ian Lynagh:
 
   =
The (Interactive) Glasgow Haskell Compiler -- version 7.2.1
   =
 
 The GHC Team is pleased to announce a new major release of GHC, 7.2.1.
 
 The 7.2 branch is intended to be more of a technology preview than
 normal GHC stable branches; in particular, it supports a significantly
 improved version of DPH, as well as new features such as compiler
 plugins and safe Haskell. The design of these new features may evolve
 as we get more experience with them. See the release notes for more
 details of what's new and what's changed.
 
 We are also using this branch as an opportunity to work out the best
 workflows to use with git.
 
 We expect the 7.2 branch to be short-lived, with 7.4.1 coming out
 shortly after ICFP as normal.
 
 
 Full release notes are here:
 
  http://www.haskell.org/ghc/docs/7.2.1/html/users_guide/release-7-2-1.html
 
 How to get it
 ~
 
 The easy way is to go to the web page, which should be self-explanatory:
 
http://www.haskell.org/ghc/
 
 We supply binary builds in the native package format for many
 platforms, and the source distribution is available from the same
 place.
 
 Packages will appear as they are built - if the package for your
 system isn't available yet, please try again later.
 
 
 Background
 ~~
 
 Haskell is a standard lazy functional programming language.
 
 GHC is a state-of-the-art programming suite for Haskell.  Included is
 an optimising compiler generating good code for a variety of
 platforms, together with an interactive system for convenient, quick
 development.  The distribution includes space and time profiling
 facilities, a large collection of libraries, and support for various
 language extensions, including concurrency, exceptions, and foreign
 language interfaces (C, whatever).  GHC is distributed under a
 BSD-style open source license.
 
 A wide variety of Haskell related resources (tutorials, libraries,
 specifications, documentation, compilers, interpreters, references,
 contact information, links to research groups) are available from the
 Haskell home page (see below).
 
 
 On-line GHC-related resources
 ~~
 
 Relevant URLs on the World-Wide Web:
 
 GHC home page  http://www.haskell.org/ghc/
 GHC developers' home page  http://hackage.haskell.org/trac/ghc/
 Haskell home page  http://www.haskell.org/
 
 
 Supported Platforms
 ~~~
 
 The list of platforms we support, and the people responsible for them,
 is here:
 
   http://hackage.haskell.org/trac/ghc/wiki/Contributors
 
 Ports to other platforms are possible with varying degrees of
 difficulty.  The Building Guide describes how to go about porting to a
 new platform:
 
http://hackage.haskell.org/trac/ghc/wiki/Building
 
 
 Developers
 ~~
 
 We welcome new contributors.  Instructions on accessing our source
 code repository, and getting started with hacking on GHC, are
 available from the GHC's developer's site run by Trac:
 
  http://hackage.haskell.org/trac/ghc/
 
 
 Mailing lists
 ~
 
 We run mailing lists for GHC users and bug reports; to subscribe, use
 the web interfaces at
 
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
 
 There are several other haskell and ghc-related mailing lists on
 www.haskell.org; for the full list, see
 
http://www.haskell.org/mailman/listinfo/
 
 Some GHC developers hang out on #haskell on IRC, too:
 
http://www.haskell.org/haskellwiki/IRC_channel
 
 Please report bugs using our bug tracking system.  Instructions on
 reporting bugs can be found here:
 
http://www.haskell.org/ghc/reportabug
 
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1

[Manuel M T Chakravarty]

Ian Lynagh:
 On Sat, Jul 30, 2011 at 10:57:40PM +1000, Manuel M T Chakravarty wrote:
 
 The RC unfortunately doesn't build on Lion (OS X 10.7).
 
 I've put the latest 7.2 source here, along with OS X builds:
http://www.haskell.org/ghc/dist/7.2.1-rc2/
 
 My guess is that the bindists will work on Lion, but that the installers
 will use the wrong gcc.

I tested the 64-bit bindists and compiled the source from scratch on Lion.  It 
all works.  You are right that the bindists use the default gcc (i.e., the one 
with the LLVM backend).  That is ok, though, as GHC supplies the stack 
unwinding linker option.

When compiling the source, the build system picks gcc-4.2 (as it should, 
otherwise the RTS wouldn't compile).

I still think that the bindists should use gcc-4.2 as well.  However, that's 
nothing that should hold up the 7.2.1 release.

Cheers,
Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1

[Manuel M T Chakravarty]

Ian Lynagh:
 On Mon, Aug 08, 2011 at 11:20:18PM +1000, Manuel M T Chakravarty wrote:
 Ian Lynagh:
 You are right that the bindists use the default gcc (i.e., the one with the 
 LLVM backend).  That is ok, though, as GHC supplies the stack unwinding 
 linker option.
 
 Do you really mean the bindists (i.e. the .tar.bz2 files), rather than
 the installers (.pkg)?

Yes, I mean the tar.bz2 file.  When I unpack it on Lion and run ./configure, 
configure picks '/usr/bin/gcc' and not '/usr/bin/gcc-4.2' as the C compiler.  
(I can force it to use gcc-4.2 with '--with-gcc=/usr/bin/gcc-4.2'.)

Manuel

P.S.: The .pkg package uses a bindist internally. (At least, that was how my 
original implementation of the packaging worked.)  So, the two should usually 
behave the same.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] XCode Dependency for HP on Mac

[Manuel M T Chakravarty]

In addition to the excellent reasons that Mark outlined, there is another 
important reason to *not* include gcc and friends in the HP.  Every software 
developer (as opposed to friend of a friend who just wanted to try to learn 
programming with Haskell on a road trip) will already have Xcode installed on 
their Mac.

Having two versions of gcc, make, lots of other tools, library headers, library 
objects, etc is going to lead to subtle bugs and headaches; at the latest, when 
you compile your first multi-language project.  (This is where this is not 
comparable to the situation on Windows with mingw.  A software developer on 
Windows, will have Visual Studio installed, but usually not some flavour of the 
GNU tools.)

Manuel

PS: I am sure there is demand for a self-contained, lightweight 
beginners/teaching Haskell environment, but let's not confuse that with the 
main distribution.


Mark Lentczner:
 Hiho - I'm the maintainer of the Mac installer for HP. I thought I'd
 chime in a bit:
 
 On Mac OS X, developer tools is essentially synonymous with Xcode.
 That is, to get the set of standard utilities needed for development
 on compiled executables (notably the binutils), you install Xcode.
 True, it also includes the IDE called Xcode, but the vast bulk of that
 installation are things like headers, link libraries, command line
 tools, and other utilities for development of compiled executables in
 general.
 
 As several have pointed out, you can download Xcode for free. If you
 have Lion, you can get Xcode 4 for free from the Mac Store. Xcode 3
 for 10.6 and 10.5. Traditionally, Apple has included Xcode on one of
 the CD-ROMs that came with a new computer, and/or as an installer
 already present on the hard disk. (I haven't bought a new Air...
 yet... but perhaps someone can check to see if the Xcode installer is
 one the SSD volume already?)
 
 It is conceivably possible to build and distribute some of those
 tools, but not the whole bundle. But the difficulty of getting such a
 build just right, and all the pieces in the right place, seems absurd
 to attempt to recreate when Apple has done it, and gives it away for
 free. Apple's versions of bintools also includes many extensions extra
 options for the OS X environment (like supporting multi-arch binaries)
 Finally, there is also licensing questions regarding the parts
 supplied by the OS vendor (headers, stub libs, debug libs, etc)
 
 Given the above, perhaps it is a little more clear why we choose to
 not include the system development tools in the Haskell Platform
 installer.
 
 - Mark
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: ANNOUNCE: GHC 7.2.1 Release Candidate 1

[Manuel M T Chakravarty]

Ian,

The RC unfortunately doesn't build on Lion (OS X 10.7).  It needs two patches I 
recently pushed to the master branch (and suggested to be merged into stable).  
They are the following patches:

  eb01af6ba964fe74375e461723b83597ef97155d (On OS X, use gcc-4.2 with Xcode 4 
and up)
  30ccc9f39dd2cf1ad14e6116778aa1fd94526c19 (On OS X x86_64, use -Wl,-no_pie 
and -Wl,-no_compact_unwind to avoid linker warnings)

Manuel


Ian Lynagh:
 
 We are pleased to announce the first release candidate for GHC 7.2.1:
 
http://www.haskell.org/ghc/dist/7.2.1-rc1/
 
 This includes the source and testsuite tarballs, installers for OS X and
 Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and
 i386/FreeBSD.
 
 Please test as much as possible; bugs are much cheaper if we find them
 before the release!
 
 
 Thanks
 Ian, on behalf of the GHC team
 
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Software patents covered in GHC?

[Manuel M T Chakravarty]

Erik de Castro Lopo:
 Manuel M T Chakravarty wrote:
 
 In fact, you are better of not to know.  Given that GHC (like all
 non-trivial software) surely infringes on some patents, the damages
 that a patent holder can sue you for are less if you do not know about
 the patents you are infringing on.  IIRC, a plaintiff can triple the
 charges if they can reasonably show that you have been aware of the
 patents that you are infringing on.  Nasty business!
 
 ON the up side, the fact that GHC is Open Source software available
 from a public repository and a lot of what is in GHC is published
 in papers which are widely and freely available on the internet
 means that stuf fthat was in GHC first can never be patented (or
 at least can be successfully challenged when it is).

That's right, but it doesn't help any of us anything.  The costs of defending 
against a patent claim (even if the claim can eventually be overturned) are 
much to high to bear for anybody, but major corporations.  In other words, it 
doesn't matter if you are right or wrong if you can't pay the legal bill.  This 
is not just theory as a fair number of mobile app developer recently found out:

 
http://fosspatents.blogspot.com/2011/05/lodsys-sues-7-app-developers-in-eastern.html

Manuel


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

Re: [Haskell-cafe] Software patents covered in GHC?

[Manuel M T Chakravarty]

austin seipp:
 *sigh* CC'ing to the rest of haskell-cafe for completeness. I need to
 change 'reply all' to a default in my email I guess.
 
 On Mon, Jun 20, 2011 at 12:19 PM, austin seipp a...@hacks.yi.org wrote:
 Hello,
 
 Realistically, there probably is. Considering everything down to
 linked lists are patented by the USPO, I'd be willing to bet (at least
 a dollar or two) that there are many patents out there that apply to
 the code used in GHC. I don't know if you could say anything different
 about *any* nontrivial software, to be quite honest.
 
 IANAL however, so I won't attempt to claim in what countries these
 patents apply, nor could I cite you patent numbers (legalese being
 terse and software patents so seemingly open to interpretation
 sometimes, it would be hard to narrow down anyway I think.)

In fact, you are better of not to know.  Given that GHC (like all non-trivial 
software) surely infringes on some patents, the damages that a patent holder 
can sue you for are less if you do not know about the patents you are 
infringing on.  IIRC, a plaintiff can triple the charges if they can reasonably 
show that you have been aware of the patents that you are infringing on.  Nasty 
business!

Manuel

 On Mon, Jun 20, 2011 at 12:10 PM, Shakthi Kannan shakthim...@gmail.com 
 wrote:
 Hi,
 
 I would like to know if there are any software algorithms used in the
 Glasgow Haskell Compiler that have been patented? If yes, in which
 countries do they apply?
 
 Just curious to know.
 
 SK
 
 --
 Shakthi Kannan
 http://www.shakthimaan.com
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
 
 
 
 
 --
 Regards,
 Austin
 
 
 
 
 -- 
 Regards,
 Austin
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: [Haskell-cafe] Haskell *interpreter* on iPad? (Scheme and Ocaml are there)

[Manuel M T Chakravarty]

And while we are dreaming, in an iOS port of GHCi (meaning GHCi runs on iOS and 
doesn't just generate code for it), it would be great to make bytecode 
persistent — ie, the bytecode that GHCi currently generates internally to 
interpret programs should be serialized to save and load it.  (Note that iOS 
apps are not allowed to generate binary code, so we wouldn't need the gcc tool 
chain etc, but just have a stripped down GHCi that generates bytecode only.  
All pre-compiled libraries that are part of the GHCi app can of course still be 
native code and load and interact with the interpreter as usual.)

Manuel


Don Stewart:
 Oh, Scheme is trivial to implement, when compared with Haskell. So
 people write it from scratch as a tutorial exercise.
 
 Haskell isn't trivial to implement from scratch, so instead we port
 existing implementations mostly.
 
 That means really, porting Hugs or GHC. And you've been pointed at examples.
 
 I think people are clearly keen for this, now it is a small matter of
 programming talent and will.
 
 -- Don
 
 On Sat, Jun 18, 2011 at 3:03 PM, John Velman vel...@cox.net wrote:
 On Sat, Jun 18, 2011 at 10:44:01PM +0400, MigMit wrote:
 
 Well, this is my point.  THERE ARE 3 SCHEME INTERPRETERS in the iPad app
 store.
 
 They run on factory iPads, not jailbroken.
 
 The GUI for the gambitREPL  (Read, Evaluate, Print, Loop) is just like a
 console.   Input a scheme expression.  CR. Answer appears, new prompt.
 
 In haskell we need to allow for some way to input layout.  I don't recall
 how Hugs handles this, if at all.
 
 There are probably 5 or 10 people out there who want to learn functional
 programming, and they are studying Scheme on their iPads.  Or Ocaml.
 
 I don't forsee doing production programming ON THE IPAD, but experimenting,
 testing some functions, and, by the way, learning Haskell.
 
 While I'm fantasizing, something like Hugs or ghci with SOE would really be
 neat.
 
 Sorry for shouting  :-)
 
 John Velman
 
 Well, Haskell is fun, isn't it? And that's what iPhone is perfect for: fun.
 
 Back when I had iPod Touch 1G (jailbroken, of course), I used to run Hugs 
 on it. Now I would love to see a Haskell interpreter in the App Store -- 
 which, by the way, is possible; as there are Scheme interpreters there, why 
 not Haskell?
 
 Отправлено с iPhone
 
 Jun 18, 2011, в 22:27, Jack Henahan jhena...@uvm.edu написал(а):
 
 I suppose you could make a GUI, by why? Given that you'll have to be 
 working on a jailbroken device, anyway, one could just as well use one of 
 the numerous terminal emulators now floating around for jailbroken iOS. 
 That said, the idea of people writing Haskell on phones and iPads and so 
 on makes me just a little bit grinny.
 
 On Jun 18, 2011, at 2:17 PM, Alexander Solla wrote:
 
 
 
 On Sat, Jun 18, 2011 at 10:46 AM, John Velman vel...@cox.net wrote:
 To further emphasize, I'd like to type in (or paste in) Haskell code and
 have it executed on the iPad.  To reiterate:  Something like Hugs, or ghci
 on the iPad.
 
 Since the iPhone OS is pretty much OS X for ARM, and GHC apparently now 
 supports cross-compilation, you can compile GHC for iOS.  I guess you 
 could cross compile Hugs with GCC.  Doing so probably isn't trivial, but 
 it should be straightforward.
 
 I bet you could even use Xcode to make a graphical user interface to GHCi.
 ___
 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
 
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: How to install GhC on a Mac without registering?

[Manuel M T Chakravarty]

malcolm.wallace:
 For use at high school level, I would imagine that you would want to build a 
 special distribution anyway. One that for example already includes packages, 
 such as Gloss, that would be useful in teaching children programming in 
 Haskell without they having to go through learning to use cabal (which is a 
 bigger hurdle than installing Xcode IMHO).
 
 But I wonder, would those students not use school equipment (which 
 supposedly would have all software pre-installed)? Do they bring their own 
 Macs? (I'd be surprised to find a whole class of 6th graders all owning 
 Macs...)
  
 
 As a further data point, yesterday one of my colleagues gave his 17-yr-old 
 daughter a copy of the Learn you a Haskell for Great Good book.  She 
 started to read it, and wanted to play with Haskell on her MacBook Air.  
 First step, download ghc.  Discover that it will not install on Leopard.  
 Step two: upgrade the operating system to Snow Leopard.  One hour later, 
 attempt to install ghc again.  Discover that it requires XCode.  Step three: 
 buy XCode from the mac App Store, and wait two hours for the 4Gb download 
 over a hotel wifi connection  Step four: hotel wifi access runs out before 
 the download is complete, so give up and go back to watching the movie she 
 downloaded earlier, but has not been able to watch whilst all this 
 downloading and upgrading has been happening.

That is a nice story, but it doesn't change what I wrote earlier:

* It would be nice to have a lightweight Haskell learner's distro (for your 
colleagues 17-yr-old daughter and others), preferably with libraries like a web 
framework, Gloss, etc included — an all in one package.

* The standard, production-ready Haskell distro shouldn't duplicate tools 
already provided by the platform vendor, especially not C compiler and 
libraries that quickly lead to subtly hard to find bugs in projects that use 
these tools also directly (and not just via GHC).

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: How to install GhC on a Mac without registering?

[Manuel M T Chakravarty]

Malcolm Wallace:
 On 10 Jun 2011, at 02:15, Manuel M T Chakravarty wrote:
 
 Anybody who is halfway serious about developing software on a Mac will have 
 Xcode installed anyway.
 
 As the original poster clarified, the motivating use-case is education 
 (specifically a class of 12-13 year olds.)  These are not serious 
 developers, but they have the potential to become serious.  Placing 
 unnecessary hurdles in their way will diminish the chances of their 
 discovering Haskell to be a beautiful language.

For use at high school level, I would imagine that you would want to build a 
special distribution anyway.  One that for example already includes packages, 
such as Gloss, that would be useful in teaching children programming in Haskell 
without they having to go through learning to use cabal (which is a bigger 
hurdle than installing Xcode IMHO).

But I wonder, would those students not use school equipment (which supposedly 
would have all software pre-installed)?  Do they bring their own Macs?  (I'd be 
surprised to find a whole class of 6th graders all owning Macs...)

 Having said that, I do think that Hugs (or maybe Helium) would be a more 
 appropriate environment for teaching the basics to young students.

That or a customised version of GHC with the right libraries pre-installed etc, 
and editor included, etc.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: How to install GhC on a Mac without registering?

[Manuel M T Chakravarty]

Sean Leather:
 On Fri, Jun 10, 2011 at 03:15, Manuel M T Chakravarty wrote:
 Ian Lynagh:
  On Mon, Jun 06, 2011 at 03:47:57PM +0100, Malcolm Wallace wrote:
  On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote:
  I would be fantastic if XCode wasn't a dependency.  ...
 
  Not to detract at all from the work of the wonderful GHC and Haskell
  Platform contributors in any way. For me it would just make it that
  much easier to convince mac-using friends to give Haskell a try.
 
  The ghc team already bundle a copy of gcc in their Windows distribution, 
  precisely because it can be fiddly to get a working copy of gcc for that 
  platform otherwise.  I wonder if they would consider the possibility of 
  shipping gcc on Mac too?  (There may be good reasons not to do that, but 
  let's have the discussion.)
 
  I'm pretty sure we aren't allowed to redistribute XCode.
 
  As well as gcc and friends, I think XCode also includes various headers
  and/or libraries that we need.
 
  If there is an alternative - especially one that allows us to support
  multiple versions of OS X more easily - then using it may make sense.
 
 You are right, the Xcode install includes many tools as well as headers etc.
 
 What would be the advantage of including gcc and all these other things in 
 GHC?
 
 To simplify the process of installing GHC and to support people with versions 
 of Mac OS X older than the most current. We want to spread the Haskell love 
 as far as possible.

The only simplification is that people who haven't got Xcode yet need to 
install two packages instead of just one.

However, for people who already have got Xcode installed, it means that they 
get two versions of all the dev tools, headers, etc.  Then, compiling a C file 
(eg, as part of a Haskell project) by directly invoking gcc or by compiling it 
via ghc will use different compilers, headers, etc.  That quickly leads to 
annoying and hard to debug problems.

Given that almost every developer on a Mac will be in the second group, you are 
not simplifying matters, you are complicating them.

 Anybody who is halfway serious about developing software on a Mac will have 
 Xcode installed anyway.
 
 You could say the same about people halfway serious about developing software 
 on Windows. But GHC doesn't require you to install MinGW, Cygwin, or Virtual 
 Studio.

No.  A serious Windows dev will have Visual Studio installed.  That won't help 
with installing GHC at all AND the GHC-bundled Unix tools do not interfere with 
Visual Studio in the same way that custom installs of Unix tools interfere with 
Xcode.

 Besides, as Xcode updates are now available from the Mac App Store,
 
 Not for older versions of Mac OS X.

Well, then get the DVDs bundled with your Mac and install Xcode from those, or 
sign up at developer.apple.com and get it there.   BTW, Mac users (and esp 
devs) upgrade very quickly, much faster than, say, Windows users.

 you don't even need to register as a developer with Apple anymore — yes, you 
 need to pay the nominal $5 for the 4GB download.  If you don't want to do 
 that, install the (probably older) version of Xcode that came with the 
 install DVDs of your Mac.
 
 This doesn't solve the problem if the GHC package only supports later 
 versions of Xcode. There has already been at least one difference between 
 Xcode 3 and 4 ( http://hackage.haskell.org/trac/ghc/ticket/5011 ) that caused 
 a problem and there may be others in the future.

That was arguably a bug in GHC's build setup.  It hardcoded a particular SDK 
version and died when Apple didn't ship that with the default install anymore.  
Nevertheless, new versions of Xcode will require adaptations in GHC, just like 
new gcc and GNU tool/lib versions require fixes in GHC on Linux.

Bundling doesn't solve that problem; it shifts it due to the mismatch of 
system-wide and GHC-installed compilers, tools, and libs.

 I don't think you can compare this with the situation on Windows.  Microsoft 
 does not distribute a canonical set of Unix tools that all developers use.
 
 No, but Cygwin and MinGW are available for free and have been around for a 
 long time. Why does GHC bundle MinGW instead of expecting the user to install 
 it herself? Convenience?

Again, this is a different situation.  Window's standard dev environment is 
Visual Studio, you cannot expect devs to have MinGW installed.  Mac OS X's 
standard dev environment is Xcode and you can expect devs to have that 
installed.

 I think there is a clear benefit to supporting older versions of Mac OS X. 
 Not everybody upgrades at the same rate that Apple releases new versions. 
 Indeed, Apple's updates occasionally change architecture requirements or 
 break applications, so some people cannot upgrade.

Most people upgrade quickly on the Mac platform and, anyway, it does not matter 
if they have Xcode already installed, which is the case for the majority of 
devs.  In fact, that majority is inconvenienced by the additional complexity

Re: How to install GhC on a Mac without registering?

[Manuel M T Chakravarty]

Lars Viklund:
 On Fri, Jun 10, 2011 at 09:24:41PM +1000, Manuel M T Chakravarty wrote:
 Well, then get the DVDs bundled with your Mac and install Xcode from those, 
 or sign up at developer.apple.com and get it there.   BTW, Mac users (and 
 esp devs) upgrade very quickly, much faster than, say, Windows users.
 
 I disagree with the assumption that OS X people are quick to upgrade.
 The last set of figures I saw on adoption were something along the lines
 of 15% on 10.6, with almost a third of the users on 10.4 and below,
 taken from some article I read the other week on the rising wave of OS X
 viruses and countermeasures.

Those numbers sound completely wrong and I'd like to see a credible source 
before I believe them.  As just one data point on Snow Leopard adoption, have a 
look at

 http://daringfireball.net/2009/09/snow_leopard_adoption_rate

I would say that readers of Daring Fireball are fairly tech savvy people with 
an above average percentage of developers.  But consider this, 

 it took about five days for 10.6 to pass 10.5

Five days from the release of the OS for 50% of the DF readers to upgrade to 
Snow Leopard.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: How to install GhC on a Mac without registering?

[Manuel M T Chakravarty]

[Ian, sorry for the duplicate — wrong sender email at first.]

Ian Lynagh:
 On Mon, Jun 06, 2011 at 03:47:57PM +0100, Malcolm Wallace wrote:
 
 On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote:
 
 I would be fantastic if XCode wasn't a dependency.  ...
 
 Not to detract at all from the work of the wonderful GHC and Haskell
 Platform contributors in any way. For me it would just make it that
 much easier to convince mac-using friends to give Haskell a try.
 
 The ghc team already bundle a copy of gcc in their Windows distribution, 
 precisely because it can be fiddly to get a working copy of gcc for that 
 platform otherwise.  I wonder if they would consider the possibility of 
 shipping gcc on Mac too?  (There may be good reasons not to do that, but 
 let's have the discussion.)
 
 I'm pretty sure we aren't allowed to redistribute XCode.
 
 As well as gcc and friends, I think XCode also includes various headers
 and/or libraries that we need.
 
 If there is an alternative - especially one that allows us to support
 multiple versions of OS X more easily - then using it may make sense.

You are right, the Xcode install includes many tools as well as headers etc.

What would be the advantage of including gcc and all these other things in GHC? 
 Anybody who is halfway serious about developing software on a Mac will have 
Xcode installed anyway.  Besides, as Xcode updates are now available from the 
Mac App Store, you don't even need to register as a developer with Apple 
anymore — yes, you need to pay the nominal $5 for the 4GB download.  If you 
don't want to do that, install the (probably older) version of Xcode that came 
with the install DVDs of your Mac.

I don't think you can compare this with the situation on Windows.  Microsoft 
does not distribute a canonical set of Unix tools that all developers use.

Manuel


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Status of Haskell + Mac + GUIs graphics

[Manuel M T Chakravarty]

Jurriën Stutterheim:
 A few weeks ago I set out to build a GUI app using wxHaskell. Long story 
 short, we ditched the entire idea of a desktop GUI and went for a web 
 application instead, because it was easier to develop a front-end for it and 
 it was easier to style it.
 So here's my (perhaps slightly provoking) question: do we need to care at all 
 about good GUI toolkits being available? Web applications, especially with an 
 HTML 5 front-end, have become increasingly more powerful. If we can also find 
 a good, standardized way to generate JS from our Haskell code, we're pretty 
 much all set.

For cross-platform apps, I have to agree.  The effort required to build and 
maintain a cross-platform GUI toolkit is hard to justify given HTML 5 and 
related technologies.

Nevertheless, there are good reasons to develop native applications (especially 
on the Mac with its user-base spoiled by high-end UX).  Luckily, the choice of 
toolkit is trivial in this case.  For Mac OS, we need a Haskell-Cocoa binding.  
I don't think there are any serious technical obstacles to develop one.  
Somebody would just have to spend the time and effort to write one.

Manuel

 On 18 May, 2011, at 08:29 , Tom Murphy wrote:
 
 I still haven't found any way to do GUIs or interactive graphics in Haskell
 on a Mac that isn't plagued one or more of the following serious problems:
 
 * Incompatible with ghci, e.g., fails to make a window frame or kills the
 process the second time one opens a top-level window,
 * Goes through the X server, and so doesn't look or act like a Mac app,
 * Doesn't support OpenGL.
 
 
If there doesn't currently exist something without these
 handicaps, that's a serious problem for the use of Haskell for
 developing end-user software.
If we as a community want to be able to develop software for
 end-users (i.e. people who'll be thrown off by gtk widgets or x11
 windows)*, then it would be a very good idea to focus our energies on
 one or two promising pre-existing libraries, and hammer them into
 completion. A roadmap for this could be worked on at Hac Phi?
 
 Just my 2¢,
 Tom
 
 *This, of course, would NOT be avoiding success at all costs. :)
 
 ___
 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

Re: [Haskell-cafe] Is Harper right that Haskell cannot model the natural numbers?

[Manuel M T Chakravarty]

In this context, I'd suggest to have a look at the POPL'06 paper Fast and 
Loose Reasoning is Morally Correct

 http://www.comlab.ox.ac.uk/people/jeremy.gibbons/publications/fast+loose.pdf

The paper is quite technical, so here the gist.  It says that if you formally 
proof that two Haskell expressions do the same thing by reasoning *as if* you 
were using a total language (one without non-termination), then the two 
expressions are also morally the same in Haskell.[1]  They formally define 
what morally the same means.  In particular, the Introduction says: Our 
results justify the hand reasoning that functional programmers already perform, 
and can be applied in proof checkers and automated provers to justify ignoring 
⊥-cases much of the time.

In other words, yes, 'Nat' in Haskell is not the same as the natural numbers as 
axiomised by Peano.  Does it matter?  Not really.

Manuel

PS: Given that ML is impure, a lot of equational reasoning in ML is also no 
more than morally correct.

[1] The paper doesn't show that statement for the entirety of Haskell, but for 
a core language with a comparable semantics using lifted types.

Richard O'Keefe:
 In one of his blog posts, Robert Harper claims that the natural numbers
 are not definable in Haskell.
 
 SML   datatype nat = ZERO | SUCC of nat
 Haskell   data Nat = Zero | Succ Nat
 
 differ in that the SML version has strict constructors, and so only
 finite instances of nat can be constructed, whereas Haskell has
 lazy constructors, so
   inf = Succ inf
 is constructible, but that's not a natural number, and it isn't
 bottom either, so this is not a model of the natural numbers.
 
 Fair enough, but what about
 
   data Nat = Zero | Succ !Nat
 
 where the constructors *are* strict?  It's perfectly good Haskell 98
 as far as I can see.  Now Nat itself isn't _quite_ a model of the
 naturals because it includes bottom, but then an SML function
 returning nat can also fail, so arguably SML's nat could or should be
 thought of as including bottom too.
 
 What am I missing?
 
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: [Haskell-cafe] Robert Harper on monads and laziness

[Manuel M T Chakravarty]

I completely agree that laziness enables a number of nice coding idioms and, as 
Lennart described so eloquently, it does facilitate a combinator-based coding 
style among other things:

  http://augustss.blogspot.com/2011/05/more-points-for-lazy-evaluation-in.html

(Note that even Bob admits that this is an advantage.)

What I meant is that if asked what is more important about Haskell, its 
laziness or purity, I think most people would pick purity.  (But then it's a 
strange decision to make as laziness implies a need for purity as discussed.)

Manuel

Jan-Willem Maessen:
 On Tue, May 3, 2011 at 1:32 AM, Manuel M T Chakravarty
 c...@cse.unsw.edu.au wrote:
 ...  Interestingly, today (at least the academic fraction of) the Haskell 
 community appears to hold the purity of the language in higher regard than 
 its laziness.
 
 As someone who implemented Haskell with quite a bit less laziness, I'm
 inclined to agree.
 
 That said, I think it's easy to underestimate just how much of the
 structure of the language really encourages a lazy evaluation
 strategy.  One example: where blocks scope over groups of conditional
 RHSs.  This is very handy, in that we can bind variables that are then
 used in some, but not all, of the disjuncts.  Grabbing the first
 example that comes to hand from my own code:
 
tryOne (gg, uu) e
  | not (consistent uu)  = (gg', uu)
  | uu==uu' = (gg, uu)
  | otherwise = (gg', uu')
  where gg' = gg `addEquation` e
uu' = uu `addEquation` e
 
 This kind of thing happens all over the place in Haskell code -- it's
 a very natural coding style -- but if you want to preserve purity it's
 tough to compile without laziness.
 
 -Jan-Willem Maessen


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

Re: [Haskell-cafe] Robert Harper on monads and laziness

[Manuel M T Chakravarty]

Tony Morris:
 Interesting how I have been authoring and subsequently using monads in
 scala for several years and it is strictness that gets in the way more
 than anything.

Just to make sure that I understand you correctly.  You are saying that when 
you use monads in Scala, then strictness makes that more awkward than 
necessary.  (I assume that you are *not* saying that strictness is the most 
awkward language feature of Scala.)

Why is that?

Manuel


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

Re: [Haskell-cafe] Robert Harper on monads and laziness

[Manuel M T Chakravarty]

For a historical perspective, I highly recommend The Definitive Account of the 
History of Haskell:

  
http://research.microsoft.com/en-us/um/people/simonpj/papers/history-of-haskell/index.htm

Section 7 clearly and directly cites the desire to have pure I/O as the 
motivation for adopting monads.  As you are saying that doesn't directly 
contradict the statement of Bob that you cite.  In fact, Section 3.2 of the 
above paper supports the opinion that purity is a consequence of choosing to be 
lazy, but it also claims that the combination of power and beauty of a pure 
language motivated the language designers.  Interestingly, today (at least the 
academic fraction of) the Haskell community appears to hold the purity of the 
language in higher regard than its laziness.

Manuel


Ketil Malde:
 I'm following Harper's blog, Existential Type¹, which I find to be an
 enjoyable and entertainingly written tirade about the advantages of
 teaching functional programming - specifically ML - to students.  Of
 course, he tends to be critical of Haskell, but it's nice to get some
 thought provoking opinion from somebody who knows a bit about the
 business.
 
 Recently, he had a piece on monads, and how to do them in ML, and one
 statement puzzled me:
 
  There is a particular reason why monads had to arise in Haskell,
   though, which is to defeat the scourge of laziness.
 
 My own view is/was that monads were so successful in Haskell since it
 allowed writing flexible programs with imperative features, without
 sacrificing referential transparency.  Although people are quick (and
 rightly so) to point out that this flexibility goes way beyond IO, I
 think IO was in many ways the killer application for monads.  Before IO,
 we had very limited functionality (like 'interact' taking a 'String -
 String' function and converting it into an exectuable program) to build
 real programs from.
 
 Laziness does require referential transparency (or at least, it is
 easier to get away with the lack of RT in a strict language), so I can
 see that he is indirectly correct, but RT is a goal in itself.  Thus, I
 wonder if there are any other rationale for a statement like that?
 
 -k
 
 ¹ http://existentialtype.wordpress.com/
 -- 
 If I haven't seen further, it is by standing in the footprints of giants
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe


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

Re: RFC: migrating to git

[Manuel M T Chakravarty]

I agree with Roman's position.  I would prefer to stay with darcs (it has its 
advantages and disadvantages, but has definitely been improving much in the 
past).

In any case, all of GHC including all dependencies must be available and 
patchable with a *single* VCS.  Mixing VCS' will lead to madness.

Manuel

PS: This talk about contributing to a project if it changes its VCS seems a bit 
lame to me.  You contribute to a project in a serious way because you care 
about the project and because you need whatever improvements you are 
implementing, not because you like the VCS.


Roman Leshchinskiy:
 On 10/01/2011, at 13:27, Simon Marlow wrote:
 
 On 10/01/2011 13:02, Max Bolingbroke wrote:
 However, I remember the last time this came up there were some issues
 that might make migration painful. From the top of my head:
 
 1) Some people expressed concern that they would have to use two
 revision control systems to work on GHC, because not all GHC
 dependencies would be git-based.
 
 It would be a prerequisite to switching that a GHC developer only has to use 
 one VCS.  So we either migrate dependencies to git, or mirror them in 
 GHC-specific git branches.
 
 I'm not sure how that is going to work. It might well be possible to build 
 GHC using only git. But most GHC developers also contribute to various 
 libraries which are often quite intimately linked to GHC. In particular, GHC 
 patches are often accompanied by library patches. Unless all those libraries 
 switch to git, too, we'll have to use both git and darcs which would be 
 *really* annoying.
 
 Personally, I rather dislike git, mostly for the reasons that Malcolm already 
 mentioned. Compared to darcs, it seems to get in the way much too often. It 
 also seems to make finding buggy patches rather hard. But maybe I just don't 
 know how to use it properly. In any case, a switch to git wouldn't deter me 
 from contributing to GHC, but neither would a switch to any other VCS. I 
 would certainly swear more often while developing, though.
 
 Roman
 
 
 
 ___
 Glasgow-haskell-users mailing list
 Glasgow-haskell-users@haskell.org
 http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell] haskell.org migration complete

[Manuel M T Chakravarty]

http://www.haskell.org/haskell-symposium/ is missing, too!

Manuel

Am 02/12/2010 um 20:58  schrieb kyra:
 On 12/1/2010 12:47 AM, Ian Lynagh wrote:
 
 Hi all,
 
 The haskell.org server migration is now complete.
 
 Please let us know if you have any problems.
 
 
 Thanks
 Ian
 
 Now we have neither http://haskell.org/ghc/dist/current nor 
 http://haskell.org/ghc/dist/stable.
 
 Kyra


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

Re: packaging options for Mac OS X

[Manuel M T Chakravarty]

Ian Lynagh:
 On Sun, Nov 28, 2010 at 12:56:00PM -0800, Mark Lentczner wrote:
 
 Outstanding question is what should this framework be called? I would like 
 to continue to call it GHC.framework, but change the version to something 
 like 7.0.1+HP-i386,
 
 I think it ought to be called Haskell-Platform.framework.

The GHC.framework inside the Haskell Platform should still be the 
GHC.framework.  The rest of the Haskell Platform might be in a different 
framework (or further, more specific frameworks identifying the individual 
components inside).  A Mac OS X framework is *not* a unit of distribution.  It 
is more like a library with associated meta data and tools.  You wouldn't 
rename glibc to, say, ubuntulibc just because you happen to get it via an 
Ubuntu install.

 [*] The binary GHC distribution could be
  - built by the GHC team, and asking them for a tarball (as Duncan 
 suggested)
 
 I do make framework-pkg to build the OS X installer, but it's
 essentially a black box to me. We're happy to accept patches that make
 this also produce a bindist, though.
 
 Now that we have the Haskell Platform, perhaps we should stop making GHC
 OS X installers, and only make plain old unix bindists.

Especially given that the Haskell Platform is released many months after GHC, 
please keep making GHC OS X installers.  At the very least, that will lead to 
more GHC installs and *testing* on OS X between the GHC release and Haskell 
Platform release.

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] DPH and GHC 7.0.1

[Manuel M T Chakravarty]

Andrew Coppin:
 On 19/11/2010 11:39 PM, David Peixotto wrote:
 There were some problems getting DPH to work well with the changes in GHC 7. 
 There is more info in this mail:
 
 http://www.haskell.org/pipermail/cvs-ghc/2010-November/057574.html
 
 The short summary is that there will be a patch level release of GHC (7.0.2) 
 that works well with DPH and the DPH packages will then be available for 
 installation from Hackage.
 
 If you want to play with DPH now you can do so on GHC HEAD.
 
 -David
 
 I was wondering about this myself, actually. I'm especially surprised since I 
 thought the DPH implementation was hard-wired into the compilter itself (in 
 which case, how can you distribute it seperately?)
 
 Then again, I've never yet even tried using DPH. (The wiki page looks very 
 out of date, so I don't know how much to trust its information.)

As David said, we will release the DPH libraries separately, but at the same 
time as GHC 7.0.2.  DPH consists essentially of two components (a) the 
vectoriser, a program transformer hardwired into GHC and (b) the DPH libraries. 
 At the request of the Haskell Platform people we separated the DPH library 
packages from the standard GHC distribution and will distribute them via 
Hackage.

The wiki page will be updated in time for that release.

Manuel

PS: We didn't release DPH with GHC 7.0.1 as we still had bugs to fix from 
recent major changes at the time of the 7.0.1 release and didn't want to hold 
up the GHC release.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Re: [Haskell] Proposal: Form a haskell.org committee

[Manuel M T Chakravarty]

Ian Lynagh:
 To fix this problem, we propose that we create a haskell.org
 committee, which is responsible for answering these sorts of questions,
 although for some questions they may choose to poll the community at
 large if they think appropriate.
[..]
 Unfortunately, this gives us a bootstrapping problem, so we suggest that
 the initial committee be chosen from open nominations by some of the
 people who currently de-facto end up making the decisions currently:
 Duncan Coutts, Isaac Jones, Ian Lynagh, Don Stewart and Malcolm Wallace.
 These 5 would still be elligible to nominate themselves. Two of the
 initial members will stand down after one year, and two after two years,
 in order to bootstrap rolling membership turnover.

Good plan!

Manuel

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

ANN: Data.Array.Accelerate 0.8.0.0 — an EDSL for accelerated array computations

[Manuel M T Chakravarty]

Data.Array.Accelerate defines an embedded language of array computations for 
high-performance computing. Computations on multi-dimensional, regular arrays 
are expressed in the form of parameterised collective operations (such as maps, 
reductions, and permutations).  Version 0.8.0.0 of Accelerate includes a mostly 
feature-complete backend generating code for NVIDIA's CUDA language for 
general-purpose GPU computing.  More on this release is at

 http://justtesting.org/second-beta-release-for-the-cuda-backend-of-a

On Hackage: http://hackage.haskell.org/package/accelerate

If you are keen on Haskell on GPUs, give this a spin!

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Multidimensional Matrices in Haskell

[Manuel M T Chakravarty]

Hi Mihai,

 A friend of mine wanted to do some Cellular Automata experiments in
 Haskell and was asking me what packages/libraries are there for
 multidimensional matrices. I'm interested in both immutable and
 mutable ones but I don't want them to be trapped inside a monad of any
 kind.

You may like to have a look at the recently released Repa library:

 http://hackage.haskell.org/package/repa

There is a draft paper about it:

 http://www.cse.unsw.edu.au/~chak/papers/KCLPL10.html

Manuel

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

Re: [Haskell-cafe] Proposal: Australian Hackathon

[Manuel M T Chakravarty]

 1) Who's interested

Interest, yes, but time is a very scarce resource these days...

 2) What dates are good

Midyear break is 29 Jun to 18 Jul at UNSW, but I'm away for a week in that time 
period.

 3) What projects people want to work on

To be honest, I'd probably be in and out and, on a weekend, have one or two 
kids running around me.  So, working with and maybe coaching some people on 
code I'm familiar with is probably the most realistic.  That could be 
Accelerate, GHC, or DPH.

 4) Where we can host this

As Ben said, we should be able to organise a room at UNSW.  Exactly how we get 
people on the network here (esp on a weekend), I'm less sure, but we could try 
to organise some guest accounts on the wireless or wired net — unless people 
want to bring 3G dongles or iPhones to tether.

 OK, so we have a fair number of people indicating interest... so which
 weekend would be preferred?
[..]
 Or should we take this to the wiki rather than the mailing list?

I'd suggest to do the planning of details on a wiki page.

Manuel

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

Re: Removing/deprecating -fvia-c

[Manuel M T Chakravarty]

Simon Marlow:
 [..]
 But let's face it, all of this code is crappy.  It should be a tiny little 
 loop rather than a tail-call with argument passing, and that's what we'll get 
 with the new backend (eventually).  LLVM probably won't turn it into a loop 
 on its own, that needs to be done before the code gets passed to LLVM.

I fully agree with Simon.  There is no point in doctoring around with an 
inherently broken approach, and to waste developer cycles tracking changes to 
gcc and so forth.  Gladly, we have two technologies ready (the new backend and 
LLVM) that have the potential to significantly improve the current situation.  
Let's spend developer cycles on these instead.

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] How many Haskell Engineer I/II/IIIs are there?

[Manuel M T Chakravarty]

John Van Enk:
  consider presenting at CUFP this year
 
 Any word on when this will be?

It'll be before or after (I suspect the later) ICFP 
http://www.icfpconference.org/icfp2010/, which is September 27-29 in 
Baltimore, Maryland.

Manuel

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

Re: DPH and CUDA status

[Manuel M T Chakravarty]

Scott Michel wrote,
 Are you also planning a LLVM backend for ghc, in a general sense, or just for 
 the accelerated work you're doing? It seems to me that ghc itself could be 
 well served with a LLVM backend, especially if one relies on the JIT mode. 
 That could help identify code paths in the core and runtime that are 
 infrequently used, further optimizing ghc's overall performance.

I had a student implementing a LLVM backend for GHC last year.  You can find 
the details at

  http://www.cse.unsw.edu.au/~pls/thesis/davidt-thesis.pdf

We are planning to merge this work into the main GHC repository.

(At the moment, this is not using the JIT, but that would be another 
interesting project.)

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: DPH and CUDA status

[Manuel M T Chakravarty]

Felipe Lessa:
 I would suggest that any GSoC project in this space should be based
 on D.A.Accelerate (rather than DPH), simply because the code base is
 much smaller and more accessible.  There is not much point in
 writing a CUDA backend, as we already have a partially working one
 that we are going to release in due course.  However, I repeatedly
 had people asking for an OpenCL backend.  So, there appears to be
 some demand for that (and it's the right thing to do, given that
 CUDA is tied to a single company).  An OpenCL backend for
 D.A.Accelerate also appears to be in the scope of what a good coder
 can achieve in the timeframe of a GSoC project.  (To be precise, I
 think, a good coder can implement a working backend in that
 timeframe, but it will probably require more work to generate well
 optimised code.)
 
 Thanks, that's very interesting.  What about an LLVM backend, would it
 be useful?  Perhaps it would be possible to use its vector operations
 to use SIMD instructions of modern CPUs (I think GHC isn't there yet,
 right?).  This is just a thought :).

I'm currently implementing an LLVM backend.  I'm not planning on using SIMD 
instructions in the first version, but it is an interesting idea for when a 
basic LLVM works.

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: DPH and CUDA status

[Manuel M T Chakravarty]

Felipe Lessa:
 On Wed, Feb 03, 2010 at 11:37:09AM -0600, Donnie Jones wrote:
 Hello Felipe,
 
 I copied this email to Sean Lee  Manuel M T Chakravarty as they
 worked on Haskell+CUDA, maybe they can comment on the current status?
 
 Here's their paper...
 GPU Kernels as Data-Parallel Array Computations in Haskell
 http://www.cse.unsw.edu.au/~chak/papers/gpugen.pdf
 
 As far as I could look for on Hackage and on Chakravarty's web
 site the code from the paper isn't released.  So now he has DPH,
 Data.Array.Accelerate and GPU monad for array processing :).

It's really only two things, as the GPU monad from the cited paper has been 
superseded by Data.Array.Accelerate — ie, the latter is a revision of the 
former.  So, the code from the cited paper will eventually be released as a 
CUDA backend for D.A.Accelerate.

 I wonder if he has any plans of gluing things?

Our intention is to bring the two together eventually, but at the moment, each 
project on its own is already rather challenging.  As far as

  http://hackage.haskell.org/trac/summer-of-code/ticket/1537

is concerned, I think it is a huge amount of work, well beyond what even a 
group GSoC project could achieve, especially as it is not just an 
implementation project, but requires a large amount of research.  Things may 
get a bit easier with the recently announced Fermi architecture, but I don't 
think that is going to change the picture fundamentally.

I would suggest that any GSoC project in this space should be based on 
D.A.Accelerate (rather than DPH), simply because the code base is much smaller 
and more accessible.  There is not much point in writing a CUDA backend, as we 
already have a partially working one that we are going to release in due 
course.  However, I repeatedly had people asking for an OpenCL backend.  So, 
there appears to be some demand for that (and it's the right thing to do, given 
that CUDA is tied to a single company).  An OpenCL backend for D.A.Accelerate 
also appears to be in the scope of what a good coder can achieve in the 
timeframe of a GSoC project.  (To be precise, I think, a good coder can 
implement a working backend in that timeframe, but it will probably require 
more work to generate well optimised code.)

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] OpenCL target for DPH?

[Manuel M T Chakravarty]

Marcus Daniels wrote,
 I'm wondering if anyone has looked at OpenCL as target for Data Parallel
 Haskell?  Specifically, having Haskell generate CL kernels, i.e. SIMD
 vector type aware C language backend, as opposed to just a Haskell
 language binding.

The short answer is that there is currently no plan to directly target OpenCL 
from DPH.  (That is the DPH team doesn't have any such plans, but if anybody 
else wants to give it a shot, the latest, bleeding edge DPH code is always 
available in the GHC HEAD repository.)

The long answer is that we are currently working on two separate data-parallel 
extensions for Haskell.

Data Parallel Haskell http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell
~
Here the focus is *expressiveness*.  In particular, we support arbitrarily 
deep, dynamic nesting of dataparallel computations with full support of 
higher-order functions (ie, parallel arrays of functions are fine).  However, 
to keep the work manageable, we only target multicore CPUs for the moment 
(using the multi-threading support in GHC's RTS).

Data.Array.Accelerate http://www.cse.unsw.edu.au/~chak/project/accelerate/
~
Here the focus is on targeting *exotic, high-performance hardware*.  We are 
currently working on a CUDA backend targeting CUDA-capable NVIDIA GPUs, but it 
shouldn't be too hard to re-target that to OpenCL.  Support for the Cell BE and 
FPGAs appears feasible, too (but we lack local expertise and hardware to write 
such backends ourselves).  However, to keep the work manageable, we only 
consider regular, multi-dimensional array codes encoded in an embedded DSL 
where functions are not first-class (ie, we use Haskell's first-class functions 
to implement the EDSL, but the embedded language is first-order).

Longer term future
~~
At some point, we would of course like to bring the above two projects 
together, but at the moment, each is already rather challenging just by itself.

Manuel

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

Re: [Haskell-cafe] university courses on type families/GADTs?

[Manuel M T Chakravarty]

Tom Schrijvers wrote,
 I was wondering whether there are any universities that teach about Haskell 
 type families or GADTs?

I do in my course Language-based Software Safety (both TFs and GADTs).  It's 
an advanced, research-oriented course for 4th year undergraduate and for 
postgraduate students.  (It wasn't offered last year and this year, but will be 
again offered next year.)

Manuel

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

Re: GHC 6.12 + zlib + Mac OS 10.6

[Manuel M T Chakravarty]

Antoine Latter:
 On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto nonow...@gmail.com wrote:
 I think you installed zlib without proper flags to link with 32-bit
 libraries. configuring with ./Setup configure
 --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks.
 
 See also http://hackage.haskell.org/trac/ghc/ticket/3681.
 
 HTH
 -~nwn
 
 The following worked like a charm:
 
 cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32'

Which version of 6.12 are you running?  These options or manually patching the 
hsc2hs wrapper should not be necessary with 6.12 anymore.  (They are only a 
temporary workaround to use the old 6.10 release on Snow Leopard.)

Manuel___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Bulding a library for C users on OS X

[Manuel M T Chakravarty]

Chris Eidhof:
I'm trying to call a Haskell function from C, on OS X. There's an  
excellent post [1] by Tomáš Janoušek that explains how to do this on  
Linux. However, on OS X, it's different. First of all, it looks like  
the -no-hs-main flag is ignored, because I get the following error:


 ghc -O2 --make   -no-hs-main -optl '-shared' -optc '- 
DMODULE=Test'   -o Test.so Test.hs module_init.c

 [1 of 1] Compiling Main ( Test.hs, Test.o )

 Test.hs:1:0: The function `main' is not defined in module `Main'''


The flag -no-hs-main is a link-time flag that allows you to link  
without a main function, but you are getting a compile time error.   
It's as if you try to export main, but don't define it.


Have you had a look at http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#foreign-export-ghc 
 ?


Manuel

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

Re: 6.12.1 release

[Manuel M T Chakravarty]

Simon Marlow:
Or, we could just make a 6.12.1 RC2, and advertise it with the same  
caveats, putting out 6.12.1 when cabal-install works and we've had a  
chance to see the state of Hackage and alert package authors.


Simon and I favour the RC2 option.  What do others think?


I agree.  I don't think anybody benefits from an earlier, but buggier  
release.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ANNOUNCE: GHC 6.12.1 Release Candidate 1

[Manuel M T Chakravarty]

Barney Stratford:

this one built and installed fine on Mac OS X 10.6 :).

Interesting, I thought there were still problems there.
I assume that's a 32-bit version. The problems manifest themselves  
only when you compile a 64-bit GHC.


That's incorrect.  The 32-bit version is only partially working.  GHCi  
dies with a bus error (after package loading) and various features  
that need the interpreter/dynamic loading (such as TH and annotations)  
die under certain circumstances.


Disclaimer: I didn't actually test this with 6.12.1RC1, but with  
6.13.  However, there shouldn't be any difference as I am not aware of  
any 6.12.1-specific Mac fixes.


Manuel

PS: I am chasing these bugs, but I don't have a lot of time for that  
at the moment, they are tricky bugs, and my Mac-fu is still pretty  
limited.  So, if anybody else likes to have a go with gdb and dtrace,  
please do so.

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Type-level naturals multiplication

[Manuel M T Chakravarty]

Reid Barton:

On Sat, Oct 10, 2009 at 02:59:37PM -0400, Brad Larsen wrote:

Suppose we implement type-level naturals as so:

data Zero
data Succ a

Then, we can reflect the type-level naturals into a GADT as so (not
sure if ``reflect'' is the right terminology here):

data Nat :: * - * where
 Zero :: Nat Zero
 Succ :: Nat a - Nat (Succ a)

Using type families, we can then proceed to define type-level  
addition:


type family Add a b :: *
type instance Add Zero b = b
type instance Add (Succ a) b = Succ (Add a b)

Is there any way to define type-level multiplication without  
requiring

undecidable instances?


I hesitate to contradict Manuel Chakravarty on this subject... but I
posted a type-level multiplication program without undecidable
instances on this list in June:

http://www.haskell.org/pipermail/haskell-cafe/2009-June/062452.html

If you prefer to use EmptyDataDecls, you can replace the first four
lines by

data Z
data S n

data Id :: * - *
data (:.) :: (* - *) - (* - *) - (* - *)

And I still don't understand why that definition works while
the obvious one doesn't :)


Ok, I should have been more precise.  It's not that anything about  
multiplication as such is a problem.  However, when you look at the  
standard definitions for addition



type family Add a b :: *
type instance Add Zero b = b
type instance Add (Succ a) b = Succ (Add a b)


and multiplication


type family Mul a b :: *
type instance Mul Zero b = Zero
type instance Mul (Succ a) b = Add (Mul a b) b


then the difference is that multiplication uses nested applications of  
type families (namely, Add (Mul a b) b).  It is this nested  
application of type families that can be abused to construct programs  
that lead to non-termination of type checking (by exploiting the  
openness of type families in combination with local equalities  
introduced either by equality constraints in type signatures or GADT  
pattern matches).  Unfortunately, there doesn't seem to be a simple  
syntactic criterion that would let GHC decide between harmless and  
problematic uses of nested *open* family applications in family  
instances.  Hence, we need to rule them all out.


You circumvent that problem cleverly by the use of higher-kinded types.

Manuel

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

Re: [Haskell-cafe] Graph Library Using Associated Types

[Manuel M T Chakravarty]

Lajos Nagy:
I understand that one of the original motivations for introducing  
associated types to Haskell was the survey of support for generic  
programming done by Garcia et al. where they compared the  
implementation of the Boost Graph Library in various languages (C++,  
Java, Haskell, ML, C#, Eiffel).  Haskell got full marks in all  
categories, except for associated types which made the resulting  
implementations more verbose than necessary (and exposed  
implementation details).  Since then GHC added support for  
associated types but I was wondering if anybody re-did the  
experiment with the new features enabled (the original code is  
available at: http://www.osl.iu.edu/research/comparing/).


No, we actually didn't do that.  It would be interesting, though.

Manuel

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

Re: [Haskell-cafe] Type-level naturals multiplication

[Manuel M T Chakravarty]

Brad Larsen:

Suppose we implement type-level naturals as so:

data Zero
data Succ a

Then, we can reflect the type-level naturals into a GADT as so (not
sure if ``reflect'' is the right terminology here):

data Nat :: * - * where
 Zero :: Nat Zero
 Succ :: Nat a - Nat (Succ a)

Using type families, we can then proceed to define type-level  
addition:


type family Add a b :: *
type instance Add Zero b = b
type instance Add (Succ a) b = Succ (Add a b)

Is there any way to define type-level multiplication without requiring
undecidable instances?


No, not at the moment.  The reasons are explained in the paper Type  
Checking with Open Type Functions (ICFP'08):


  http://www.cse.unsw.edu.au/~chak/papers/tc-tfs.pdf

We want to eventually add closed *type families* to the system (ie,  
families where you can't add new instances in other modules).  For  
such closed families, we should be able to admit more complex  
instances without requiring undecidable instances.


Manuel

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

Re: GHC on Snow Leopard: best practices?

[Manuel M T Chakravarty]

David Menendez:

Is there any consensus about what needs to be done to get a working
ghc installation on a Snow Leopard (Mac OS X 10.6) system? The Mac OS
X wiki page[1] currently links to a blog post[2] that recommends
manually patching /usr/bin/ghc, but I have also seen recommendations
that people patch ghci, runhaskell, runghc, and hsc2hs. Is that also
recommended? If so, there should probably be an updated how-to on the
wiki.


Patching /usr/bin/ghc is sufficient to get a version of GHC that  
passes the regression tests suite in fast mode (the same setting  
that the validate script uses).  If you want to use hsc2hs, you need  
to patch that, too.  I haven't found a need to patch the interpreter,  
though.


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Snow Leopard GHC

[Manuel M T Chakravarty]

Simon Marlow:

On 24/09/2009 23:54, Barney Stratford wrote:

I've tried just letting the dynamic linker (dyld) sort everything out
for us, but this failed because not all symbols are dynamically  
linked,

and the statically linked ones are invisible to it.

One change that will be necessary in any case: towards the end of
rts/Linker.c, change
case X86_64_RELOC_SIGNED:
ASSERT(reloc-r_pcrel);
thing += value - baseValue;
break;

to

case X86_64_RELOC_SIGNED:
case X86_64_RELOC_SIGNED_1:
case X86_64_RELOC_SIGNED_2:
case X86_64_RELOC_SIGNED_4:
ASSERT(reloc-r_pcrel);
thing += value - baseValue;
break;


Manuel, maybe you could validate and push this one?


I am happy to take care of funnelling Barney's changes into the main  
repo.  However, I think there was at least one more mentioned in  
another email.


Barney, do you have a comprehensive set of the changes that you made  
(ideally against the HEAD repo, or a nightly snapshot, but if that's  
difficult, then against 6.10)?  And did you try to run the testsuite http://darcs.haskel.org/testsuite 
 with the compiler that you generated?


Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Strongly Specify Alignment for FFI Allocation

[Manuel M T Chakravarty]

Thomas DuBuisson:

Aside from section 5.7 (storable) and comments on 'alignPtr', the only
mention of alignment in the FFI addendum is on
mallocBytes/allocaBytes:

The block of memory is sufficiently aligned for any of the basic
foreign types (see Section 3.2) that fits into a memory block of the
allocated size

It would be beneficial if this wording was applied to all allocation
routines - such as mallocForeignPtrBytes, mallocForeignPtrArray, etc.
For the curious, this proposal was born from the real-world issue of
pulling Word32's from a ByteString in an efficient but portable manner
(binary is portable but inefficient, a straight forward
unsafePerformIO/peek is efficient but need alignment).


I agree that we should be more precise here.


If no glaring issue comes up then I'll formalize / make a ticket,


Can you please summarise the exact additions that you would like to  
see as a follow-up email?  I will collect all changes that we want to  
make to the existing FFI Addendum before it goes into the 2009 issue  
of Haskell'.


Cheers,
Manuel



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

Re: #3485: Illegal type synonym family application in instance error is unnecessary, should be removed

[Manuel M T Chakravarty]

Ashley Yakeley:

On Mon, 2009-09-14 at 00:40 +1000, Manuel M T Chakravarty wrote:

I don't see what the problem is. instance C (Fam Int) has an
unambiguous, and logically acceptable, meaning to the compiler. Why
do we force the programmer to make an ugly workaround involving
introducing a type variable?


I think the proposed change is confusing.  Two instances

  instance C (Fam Int)
  instance C (Fam Bool)

appear to be syntactically distinct, but they semantically overlap.
The explicit form

  instance (Fam Int ~ famint) = C famint

is IMHO much clearer and really not much more verbose.


It's really no different from this

 type Syn a = ()

 instance C (Syn Int)
 instance C (Syn Bool)


It's quite different.  A type synonym can always be unfolded.  That is  
not the case for a type family; e.g.,


  type family F a
  type instance F [Int] = ...

  instance C (F [a])

Whereas `instance C (Syn Int)' is synonymous to `instance C ()', there  
is no such normal form for `instance C (F [a])'.


This is a fundamental difference between type synonyms and type  
families and the reason for most of the restrictions that we impose on  
type families over type synonyms (e.g., synonyms may be partially  
applied in some situations, whereas families may never be applied  
partially).


Manuel

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: #3485: Illegal type synonym family application in instance error is unnecessary, should be removed

[Manuel M T Chakravarty]

Ashley Yakeley:

GHC wrote:
#3485: Illegal type synonym family application in instance error  
is unnecessary,

should be removed
- 
+--
Reporter:  Ashley Yakeley   |   
Owner:   Type:  bug   
| Status:  closed   Priority:   
normal   |  Milestone:   
Component:  Compiler (Type checker)  |Version:   
6.10.4   Severity:  normal   |  
Resolution:  invalid  Keywords:
|   Testcase: Os:  Unknown/ 
Multiple |   Architecture:  Unknown/Multiple
- 
+--

Changes (by chak):
 * status:  new = closed
 * resolution:  = invalid
Comment:
I am not sure what you are suggesting.  We cannot automatically  
transform

{{{
instance C (Fam Int)
}}}
into
{{{
instance (Fam Int ~ famint) = C famint
}}}
This works if there is only one instance, but as soon as there are  
two

such instances, they always overlap.
Maybe you are suggesting that we should do it anyway and programmers
should just take the implicit transformation into account.  I don't  
think
that this is a good idea.  It's confusing for very little benefit  
(as you
can always write the transformed instance yourself with little  
effort).


I don't see what the problem is. instance C (Fam Int) has an  
unambiguous, and logically acceptable, meaning to the compiler. Why  
do we force the programmer to make an ugly workaround involving  
introducing a type variable?


I think the proposed change is confusing.  Two instances

  instance C (Fam Int)
  instance C (Fam Bool)

appear to be syntactically distinct, but they semantically overlap.   
The explicit form


  instance (Fam Int ~ famint) = C famint

is IMHO much clearer and really not much more verbose.

Manuel

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: Haskell 2010: libraries

[Manuel M T Chakravarty]

Ross Paterson:

On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:

1. Just drop the whole libraries section from the report.  The
   Report will still define the Prelude, however.

   There will be some loose ends where the rest of the report
   refers to entities from these libraries, e.g. the Prelude
   refers to Rational from the Ratio library.  We just have to
   fix up these references, moving the appropriate definitions
   into the Report as necessary.


Some of the loose ends:

The defaulting rules (section 4.3.4) apply to any class defined in  
the

Prelude or a standard library.  The non-Prelude classes involved are
Ix and Random.

The FFI spec refers to types Int8, Int16, Int32, Int64, Word8, Word16,
Word32, Word64, Ptr a, FunPtr a and StablePtr a.  Perhaps they  
should move
to the Prelude when the non-library part of the FFI spec is  
incorporated

into the Report?


If we have these types in the Prelude, the associated functions should  
be in the Prelude, too, and I'd be reluctant to include operations  
that are not memory-safe in the Prelude.  So, I think, we need at  
least a standard library for the FFI.  (In the FFI spec, we after all  
went to a lot of trouble to realise as much as possible of the needed  
functionality as libraries, to change the core language as little as  
possible.)


I understand the desire to cut down on the number of library functions  
defined in the report, but ultimately, the language needs to provide a  
basic set of functionality that is the basis for implementing all the  
other libraries.  Otherwise, the usefulness of the standard gets  
undermined.


Apart from the Prelude, I think we should ask the following question  
to decide whether we can omit some library functionality from the  
language definition:


  If we omit the functionality under consideration,
  can we implement it in a portable manner with what remains in the  
definition?


If that is not the case, we ought to include it.

Manuel

PS: As a historical anecdote, it was a major shortcoming of Modula-2  
over C that Modula-2 didn't define it's basic libraries properly with  
the language (whereas C did).

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

Re: Haskell 2010: libraries

[Manuel M T Chakravarty]

Simon Marlow:

On 08/07/2009 22:45, Ian Lynagh wrote:

On Wed, Jul 08, 2009 at 03:09:29PM +0100, Simon Marlow wrote:

 1. Just drop the whole libraries section from the report.  The
Report will still define the Prelude, however.

I'm tending towards (1), mainly because it provides a clean break  
and is
likely to be the least confusing for users: they have one place to  
go

looking for library documentation.


Sounds good to me.

See also http://hackage.haskell.org/trac/haskell-prime/ticket/118


Ian, would you like to take ownership for this proposal, and start  
fleshing out the details in a wiki page?


There seems to be support for removing all the libraries in the  
report.  Whether the report also blesses either the Haskell Platform  
or a set of packages is a separate matter; either way, we still have  
to extract the existing libraries from the report, and there will be  
a set of changes to the report necessary to make that happen.  The  
Report should explicitly list all the library entities that it  
refers to.


I don't mind defining libraries separately, but not defining them at  
all is problematic unless a core set of libraries isn't rigorously  
defined somewhere else.


Manuel

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

Re: GHC API: How to determine Type.Type equality when using type operators?

[Manuel M T Chakravarty]

Christiaan Baaij:
I believe that you are asking about type functions.  Specifically,  
I think what you are asking is this:


How can I normalise a type, by rewriting it exhaustively using
the top-level type-function definitions


That is indeed a better formulation of my original question

I think the function TcTyFuns.tcNormaliseFamInst (rather an odd  
name!) does this.  But it's not very helpful to you because it's in  
the main typechecker monad.


At the moment it is not such a big problem that it is in the  
typechecker
monad, as we run some parts of our compiler in a GHC Monad, and can  
thus

initialize a typechecker monad with the function TcRnMonad.initTc.

However, at the moment I can't get to normalise the types as far as I
had hoped. Here is an example of my debug output:

Before normalisation:
Types.Data.Num.Decimal.Literals.D4
Types.Data.Num.Ops.:*: Types.Data.Num.Decimal.Literals.D3

After normalisation:
Types.Data.Num.Decimal.Digits.Dec
 (Types.Data.Num.Decimal.Digits.DecN
  Types.Data.Num.Ops.:. Types.Data.Num.Decimal.Digits.Dec4)
Types.Data.Num.Ops.:*: Types.Data.Num.Decimal.Digits.Dec
(Types.Data.Num.Decimal.Digits.DecN
 Types.Data.Num.Ops.:.  
Types.Data.Num.Decimal.Digits.Dec3)


So, currently I can normalize the synonyms D4 and D3, but I can't
normalize the type function :*:. Maybe it has something to do with  
how I

load the module and its dependencies.


Yes, it has something to do with module loading and the type-checker  
monad.  It's not enough to load the modules, you also need to  
initialise those components of the type-checker monad that contain the  
environment of visible type instance declarations.  The component is  
called tcg_fam_inst_env and you can see in the function  
TcRnDriver.tcRnImports how to extend it.  You did well in remembering  
to load the orphan modules, but you also ought to call  
FamInst.checkFamInstConsistency to check for overlapping instances in  
the modules that you are loading (it's used right at the end of  
TcRnDriver.tcRnImports).


Hope that helps a bit.

Manuel

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: [Haskell-cafe] Type families in export lists

[Manuel M T Chakravarty]

Lee Duhem:
On Sat, May 30, 2009 at 7:35 PM, Maurí cio briqueabra...@yahoo.com  
wrote:

Hi,

How do I include type families (used as associated
types) in a module export list? E.g.:

class MyClass a where
   type T a :: *
   coolFunction :: Ta - a
   (...)

If I just include MyClass and its functions in the
list, instances in other modules complain they don't
know T, but I wasn't able to find how (where) to
include T in the list.



In export list, you can treat 'type T a' as normal type declaration,  
ie, write

T(..)  in export list.


There is also special syntax to export associated types.  You can write

  MyClass (type T)

in the export list; cf,

  http://haskell.org/haskellwiki/GHC/Type_families#Import_and_export

Manuel

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

Re: [Haskell-cafe] haskell cuda?

[Manuel M T Chakravarty]

Dan:
Doesn't look like there's code out there - will try e-mailing the  
authors of the various papers/presentations.


We haven't made any code available yet, but we are planning to do so  
before ICFP this year.


This e-mail also counts as an open plea to those compiler wizards  
working on this stuff: feel free to put beta buggy versions of your  
code online :)


It's not so much the beta bugginess as the several times completely  
ripping apart and putting together in different ways that prevented us  
from putting code out.  Once we put something out, it becomes harder  
to change the API, too, and we are still changing the design of that  
around.  Anyway, thanks for the interest.


Manuel


Scott A. Waterman wrote:

Try reaching Manuel Chakravarty,  http://justtesting.org/
and his colleague Sean Lee at Galois.

Slides from his talk on GPU.gen :
 Just gave my talk on Data Parallelism in Haskell at PSU; here  
the slides: http://bit.ly/17EQcl


and slides from an earlier Galois talk:
http://www.galois.com/blog/2008/08/29/gpugen-bringing-the-power-of-gpus-into-the-haskell-world/


--ts

On May 12, 2009, at 9:18 AM, Dan wrote:


Hi,

Does anyone know if there's a compiler from Data-Parallel Haskell  
to GPU code?  I saw a paper on it a while back, but Google hasn't  
turned up any code.


Cheers,
- Dan


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

Re: [Haskell-cafe] Generating Haskell with associated types (and kind annotations)

[Manuel M T Chakravarty]

Hi Dan,


I was wondering whether anyone had any suggestions on a good way to
generate repetitive code with associated types and kind annotations.
I'd like to use TH but as far as I understand, it doesn't support this
yet (I think associated types are in HEAD but not kinds),


I implemented type families (including associated types) and kinds for  
TH in the HEAD.  If there is anything missing that prevents you from  
using it, please let me know and I'll have a look at it.


Manuel

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

Re: 6.10.3 plans

[Manuel M T Chakravarty]

Ian Lynagh:

On Fri, Apr 24, 2009 at 11:08:38AM +0100, Simon Marlow wrote:


We do have a WARNING pragma, incedentally:

http://www.haskell.org/ghc/docs/latest/html/users_guide/pragmas.html#warning-deprecated-pragma


I don't think that using it for this would be a good idea, though. It
would mean that people who really do want
   Foreign.ForeignPtr.{newForeignPtr,addForeignPtrFinalizer}
would not be able to write warning-free code.


I agree.

Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: No last core parallel slowdown on OS X

[Manuel M T Chakravarty]

Dave Bayer:
In that paper, they routinely benchmark N-1 cores on an N core Linux  
box, because of a noticeable falloff using the last core, which can  
do more harm than good. I had confirmed this on my four core Linux  
box, but was puzzled that my two core MacBook showed no such  
falloff. Hey, two cores isn't representative of many cores, cache  
issues yada yada, so I waited.

[..]
Compared to 2 cores, using 3, 4 cores on an equivalent four core box  
running OS X gives speedups of


1.45x, 1.9x


As another data point, in our work on Data Parallel Haskell, we ran  
benchmarks on an 8-core Xserve (OS X) and an 8-core Sun T2 (Solaris).   
On both machines, we had no problem using all 8 cores.


Manuel
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

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

[Manuel M T Chakravarty]

Matt Morrow:
On Mon, Apr 6, 2009 at 7:39 PM, Manuel M T Chakravarty c...@cse.unsw.edu.au 
 wrote:

Peter Berry:

3) we apply appl to x, so Memo d1 a = Memo d a. unify d = d1

But for some reason, step 3 fails.

Step 3 is invalid - cf, http://www.haskell.org/pipermail/haskell-cafe/2009-April/059196.html 
.


More generally, the signature of memo_fmap is ambiguous, and hence,  
correctly rejected.  We need to improve the error message, though.   
Here is a previous discussion of the subject:


 http://www.mail-archive.com/haskell-cafe@haskell.org/msg39673.html

Manuel

The thing that confuses me about this case is how, if the type sig  
on memo_fmap is omitted, ghci has no problem with it, and even gives  
it the type that it rejected:


Basically, type checking proceeds in one of two modes: inferring or  
checking.  The former is when there is no signature is given; the  
latter, if there is a user-supplied signature.  GHC can infer  
ambiguous signatures, but it cannot check them.  This is of course  
very confusing and we need to fix this (by preventing GHC from  
inferring ambiguous signatures).  The issue is also discussed in the  
mailing list thread I cited in my previous reply.


Manuel

PS: I do realise that ambiguous signatures are the single most  
confusing issue concerning type families (at least judging from the  
amount of mailing list traffic generated).  We'll do our best to  
improve the situation before 6.12 comes out.___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

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

[Manuel M T Chakravarty]

Peter Berry:
{-# LANGUAGE TypeFamilies, TypeSynonymInstances,  
ScopedTypeVariables #-}


The following is a class of memo tries indexed by d:


class Fun d where
   type Memo d :: * - *
   abst :: (d - a) - Memo d a
   appl :: Memo d a - (d - a)
   -- Law: abst . appl = id
   -- Law: appl . abst = id (denotationally)


Any such type Memo d is naturally a functor:


memo_fmap f x = abst (f . appl x)


The type of memo_fmap (as given by ghci) is (Fun d) = (a - c) -
Memo d a - Memo d c. (Obviously this would also be the type of fmap
for Memo d, so we could declare a Functor instance in principle.) If
we add this signature:


memo_fmap' :: Fun d = (a - b) - Memo d a - Memo d b
memo_fmap' f x = abst (f . appl x)


it doesn't type check:

TypeSynonymTest.hs:14:17:
   Couldn't match expected type `Memo d1 b'
  against inferred type `Memo d b'
   In the expression: abst (f . appl x)
   In the definition of `memo_fmap'':
   memo_fmap' f x = abst (f . appl x)

TypeSynonymTest.hs:14:32:
   Couldn't match expected type `Memo d a'
  against inferred type `Memo d1 a'
   In the first argument of `appl', namely `x'
   In the second argument of `(.)', namely `appl x'
   In the first argument of `abst', namely `(f . appl x)'
Failed, modules loaded: none.

As I understand it, the type checker's thought process should be along
these lines:

1) the type signature dictates that x has type Memo d a.
2) appl has type Memo d1 a - d1 - a for some d1.
3) we apply appl to x, so Memo d1 a = Memo d a. unify d = d1

But for some reason, step 3 fails.


Step 3 is invalid - cf, http://www.haskell.org/pipermail/haskell-cafe/2009-April/059196.html 
.


More generally, the signature of memo_fmap is ambiguous, and hence,  
correctly rejected.  We need to improve the error message, though.   
Here is a previous discussion of the subject:


  http://www.mail-archive.com/haskell-cafe@haskell.org/msg39673.html

Manuel

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

Re: [Haskell-cafe] Type families and kind signatures

[Manuel M T Chakravarty]

Louis Wasserman:
Mkay.  I get it now.  I was under the impression that, essentially,  
a data family was precisely equivalent to a type family aliasing to  
a separately declared datatype.


No, they are not equivalent.  You can see that as follows.  Assume,

  data family T a
  type family S a

Now, given `T a ~ T b', we know that `a ~ b'.  (We call this  
implication decomposition.)


In contrast, given `S a ~ S b' we do *not* know whether `a ~ b'.  Why  
not?  Consider the instances


  type instance S Int = Bool
  type instance S Float = Bool

Clearly, `S Int ~ S Float', but surely not `Int ~ Float'.  So,  
decomposition does not hold for type synonym families, but it does  
hold for data families.


This is actually, not really a property of type *families* alone.  It  
already distinguishes vanilla data types from vanilla type synonyms.   
We know, say, that if `Maybe a ~ Maybe b', then `a ~ b'.  However, given


  type Const a = Int

we have `Const Int ~ Const Float' (and still not `Int ~ Float').   
Definitions, such as that of `Const', are rarely used, which is why  
this issue doesn't come up much until you use type families.


One more question: is there any way to get the low overhead of  
newtypes for particular instances of a data family?  Is this  
impossible?  That is, is there any way to do something like


data family Foo a
data instance Foo Int = Bar Int -- Bar is actually a newtype


You can use

  newtype instance Foo Int = MkFoo Int

So, the instances of a data family can be data or newtype instances.,  
and you can freely mix them.


Manuel


On Thu, Apr 2, 2009 at 12:47 PM, David Menendez d...@zednenem.com  
wrote:

2009/4/2 Louis Wasserman wasserman.lo...@gmail.com:
 Mkay.  One more quick thing -- the wiki demonstrates a place where  
the
 original attempt worked, with a data family instead. (That is,  
replacing
 'type' with 'data' and adjusting the instance makes this program  
compile

 immediately.)
 a) Is there a type-hackery reason this is different from data  
families?


It's not type hackery. Data families are different from type families,
and the syntax for declaring instances of higher-kinded families is a
consequence of those differences.

An instance of a data family is a new type constructor, so you have to
provide the additional arguments in order to declare the data
constructors.

data family Foo a :: * - *
data instance Foo Bool a = FB a a
-- Foo Bool has kind * - *, like [], so I could make it a Functor

Instance of type families are always pre-existing type constructors.

type family Bar a :: * - *  -- Bar a must equal something of kind *  
- *

type instance Bar () = Maybe

 b) Is there a reason this isn't made a lot clearer in the  
documentation?
  GHC's docs say that higher-order type families can be declared  
with kind
 signatures, but never gives any examples -- which would make it a  
lot

 clearer that the below program doesn't work.

Here's a higher-kinded type family I've used.

type family Sig t :: * - *

class (Traversable (Sig t)) = Recursive t where
   roll :: Sig t t - t
   unroll :: t - Sig t t


The Traversable context wouldn't be valid if I had declared Sig t a ::
*, because type families must always be fully applied.


The difference is analogous to the difference between

type M0 a = StateT Int IO a
type M1   = StateT Int IO

Since type synonyms (like type and data families) must always be fully
applied, you can use M1 in places where you can't use M0, even though
they're effectively the same thing.

foo :: ErrorT String M1 a -- valid
bar :: ErrorT String M0 a -- not valid



--
Dave Menendez d...@zednenem.com
http://www.eyrie.org/~zednenem/

___
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