gmane.comp.lang.haskell.libraries

Re: Safe Haskell at the export symbol granularity?

David Terei — 2012-05-17T19:14:16

Sure, the proposed syntax wasn't a serious proposal as it has
backwards compatibility issues so pragmas are the better choice. It's
just a clearer syntax when discussing the semantics of the idea.


Thanks, I'll keep that in mind. Let me know how Antoine's suggestion
works out for you and any other feedback you have please.


I think so. I'm not very familiar with the type checker in GHC or
typechecking in general but looking through the code just then it
seems doable. There doesn't seem anything other than maybe some hard
engineering work that would prevent this.

~ David

Re: Safe Haskell at the export symbol granularity?

Ryan Newton — 2012-05-17T14:53:23

Good point, Antoine!

I think that does the trick.

On Thu, May 17, 2012 at 10:48 AM, Antoine Latter <aslatter< at >gmail.com> wrote:

_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: Safe Haskell at the export symbol granularity?

Antoine Latter — 2012-05-17T14:48:45

You can still do this at the module level, with the down-side of
potentially not being able to implement a class with the safe version:




I think this works.

Antoine

_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: Safe Haskell at the export symbol granularity?

Ryan Newton — 2012-05-17T13:50:59

Thanks David.

I'm glad to see it was discussed in the wiki.  (Btw, my 2 cents is that I
like the comment pragmas more than new keywords.)

The issue that I think doesn't make it into the wiki is of splitting, not
modules, but* type-classes*. That's where I think it becomes a more serious
issue.

Do you think a symbol-level Safe Haskell would be able to distinguish one
method of a type class as unsafe, while the others are safe?

  -Ryan

P.S. In my two examples --
   There's only one "Acc" type and Accelerate's "fold" can pretty easily be
moved into an .Unsafe module, though it breaks the
one-giant-module-for-the-whole-programming-model thing it has going now.
 In the Par example on the other hand type classes are used to abstract
over different implementations, so that's where we run into the safe/unsafe
factoring problem.
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: parallel containers dependency

Simon Marlow — 2012-05-16T15:30:57

I just uploaded 3.2.0.3 with the relaxed dep, thanks for the nudge.

Cheers,
Simon

Re: Proposal: To add 2 new lower-level concurrency constructs andrebuild Concurrent.Chan using them

Simon Marlow — 2012-05-16T15:23:58

These kinds of data structures are fiendishly hard to get right, as we 
know from bitter experience.  I'm not suggesting that your 
implementation is wrong in any way - but it's hard to tell whether it is 
right.  For instance, are you sure that it is robust to asynchronous 
exceptions?

I think to replace Chan we would need at the very least plenty of tests. 
  I realise this might sound a bit hypocritical given that we never had 
many tests for Chan, and we've discovered a number of bugs in it over 
the years, but it's a "devil you know" argument.  Let's be sure we're 
not making anything worse.

Personally speaking, I'm not keen on the overly point-free style in your 
code, which I find hard to read.

Again you can take this as my opinion if you want, but I think STM is 
the way forward.  Correctness is *far* easier, and performance is 
surprisingly good (and we could improve it if necessary).  If you're 
avoiding STM for performance reasons, show me the numbers.

Cheers,
Simon

Safe Haskell at the export symbol granularity?

Ryan Newton — 2012-05-14T15:18:20

Separate from whether or not we actually want this -- is it feasible?

Here's my situation.  When working on parallel programming libraries in
Haskell there are very often unsafe operations one wants to do within an
otherwise pure model.  For example, Accelerate currently violates safe
haskell because it trusts the user to provide an associative function to
parallel "fold".  No associativity, no referential transparency.

The solution is to put fold in a separate namespace and mark that module as
Unsafe.  Likewise for certain monad-par operations that are unsafe.  But
this factoring can have a serious impact.  Not only are extra modules
required, but extra type classes as well.  For example, if Accelerate is
ever refactored for "Safe Haskell" then the following ParAccelerate type
class probably should be as well:

https://github.com/simonmar/monad-par/blob/5cc656bc45dc473d7a185ec99bb156192f54d520/abstract-par-accelerate/Control/Monad/Par/Accelerate.hs#L75

I.e. ParAccelerate & ParAccelerateUnsafe for the "un

Re: On the Haskell Platform

Magnus Therning — 2012-05-13T21:24:27

[...]

This is exactly what I try to do with the few packages I've written
and put on Hackage.

[...]

Luckily I've never had to deal with the first issue.  The second on
the other hand I have a rather lazy process for: *I* release packages
with the dependencies that I've tested, then I'm happy to accept
patches that relax the dependencies downwards (and sometimes upwards,
when I'm slow) from users, as long as they claim to have run the test
suites.

/M

Re: On the Haskell Platform

Henning Thielemann — 2012-05-13T20:52:19

On Sun, 13 May 2012, Joachim Breitner wrote:


Defending myself: I had already updated my packages to transformers-0.3 in 
the repositories, but I have not released all of them to Hackage 
immediately. Updating a dependency in 30 packages needs some time although 
I did even not need to alter any code.

_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: On the Haskell Platform

Joachim Breitner — 2012-05-13T20:04:40

Hi,

Am Sonntag, den 13.05.2012, 21:36 +0200 schrieb Heinrich Apfelmus:

yes, always supporting the latest version available on hackage is a good
idea. If everyone would be doing that I would not have to send „please
upgrade your package to mtl-2.1 / transformers-0.3“ mails now.

Having the lower version include other common versions (i.e. the latest
platform release and/or versions found in distribution releases you care
about) is a good idea as well.


Well, for a distro package user, he is expected to first blame the
distro (unless he is knowledgable enough to know that a certain
bug/problem is caused by upstream). Not all users know that, though, and
it does not help if there is a conflict between a distribution-provided
package and code taken from somewhere else.


I would suggest to exclude the broken versions from your dependency.
cabal-install users will then hopefully get your package built against
an older, non-buggy version.


This is a general problem in the Haskell ecosystem that not all
bui

Re: On the Haskell Platform

Heinrich Apfelmus — 2012-05-13T19:36:40

 >

I see. Thinking about this, it appears to me that the only way to meet 
the "one-version-per-package" constraint is the following approach on my 
part:

A. Always support the latest version of a dependency (compiler, library, 
...), i.e. the upper bounds of my version constraints have to match the 
latest stuff.

B. If desired, support older versions of a dependency by adjusting the 
lower bounds of my version constraints.

This way, my package can never be blamed when it fails to install; 
rather, "the blame" falls on the user for not upgrading his system.

(Package management is probably best seen as a "blame game". Scenario: 
"This package fails to install, who is to blame?" Usually, the user can 
only assign responsibility to the author of the package, even though the 
latter may not have direct control over the problem. Of course, the 
overall goal of package management is to route responsibility to the 
right person who can fix it.)


However, this approach is not without problems.

The first probl

Re: On the Haskell Platform

Joachim Breitner — 2012-05-13T17:35:06

[Re-Sending, the mailing list is picky about sender e-mail addresses.]

Hi Heinrich,


Am Freitag, den 11.05.2012, 10:23 +0200 schrieb Heinrich Apfelmus:

the problem with packaging the platform is that distributions have a
one-version-per-package policy, so we can not always have exactly the
version present in the latest platform, e.g. because other packages
require a newer version, or just because the old version is too old and
buggy and our users want newer versions. Therefore, we take the liberty
to diverge a bit. You can see the current status for Debian on 
http://people.debian.org/~nomeata/platform.html

Furthermore, in the development brach of Debian, unstable, we prepare
the next releases and currently package the versions that we expect for
the platform 2012.2.0.0. You can see that the version you linked to is
such an prerelease by the version number (2012.1.0.0~debian1).

In Debian, we would avoid having such a prerelease in a stable release
(but might decide that it could still be better than hav

Re: On the Haskell Platform

Yitzchak Gale — 2012-05-13T12:22:24

That Ubuntu package is just a direct port from Debian.
So I am adding a CC to Joachim, our resident Debian
packaging hero, hoping for comment on the issue.

Thanks,
Yitz

transforming xhtml attributes

Chris Dornan — 2012-05-11T20:49:53

Folks,
 
I am proposing to extend the xhtml package slightly to better support
attribute munging.
 
Currently you would use (!) to add a bunch of attributes to an element,
thus:
 
                b1 = button noHtml ! [name "go", value "go"]
 
The problem, as pointed out by mistuke[1]  is that there is no way to safely
add attributes as this could result in an attribute being bound ambiguously
and illegally [2] thus:
 
                b2 = b1 ! [value "oops"]
 
Apparently this can lead Haddock to generate illegal (X)HTML [1].
 
My proposed solution is to add a new CHANGEATTRS class with the overloaded
function:
 
                changeAttrs :: CHANGEATTRS a => a -> ([HtmlAttr] ->
[HtmlAttr]) -> a
 
and to export a function for analysing the (abstract) HtmlAttr type:
 
                htmlAttrPair :: HtmlAttr -> (String, String)
 
CHANGEATTRS/changeAttrs/htmlAttrPair works just like ADDATTRS/(!) except
that the attributes can be analysed and transformed. 
 
                extend_name :: Html -> Html

On the Haskell Platform

Heinrich Apfelmus — 2012-05-11T08:23:21

Dear list,

I have written a package, reactive-banana-wx, which seems to be quite 
enticing to Haskell beginners. It's an implementation of the fabled 
functional reactive programming (FRP), so it's natural that people want 
to play around with it to see what it is all about. I imagine that the 
latest parallelism packages also serve a similar audience.

Of course, to play around with a package, you have to be able to install 
it, hopefully painlessly. As the maintainer, I have adopted the 
following principles as they appeared sound to me:

1. My package installs and works without any hitch on the latest Haskell 
Platform.

This is easier said than done, because one of my dependencies is 
wxHaskell, which tends to have hitches at times. Occasionally, I 
restrict the version number to a specific, older wxHaskell version that 
I know to be bug free.

In other words, the idea is that a complete Haskell beginner will be 
able to install my package with the standard setup even if he knows 
nothing about the Hask

[PATCH] Fix typo in documentation of GHC.Exts.groupWith

Simon Hengel — 2012-05-10T08:44:36

---
 GHC/Exts.hs |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/GHC/Exts.hs b/GHC/Exts.hs
index 0bf8f7f..8281895 100755
--- a/GHC/Exts.hs
+++ b/GHC/Exts.hs
< at >< at > -102,7 +102,7 < at >< at > sortWith :: Ord b => (a -> b) -> [a] -> [a]
 sortWith f = sortBy (\x y -> compare (f x) (f y))
 
 -- | The 'groupWith' function uses the user supplied function which
--- projects an element out of every list element in order to to first sort the 
+-- projects an element out of every list element in order to first sort the
 -- input list and then to form groups by equality on these projected elements
 {-# INLINE groupWith #-}
 groupWith :: Ord b => (a -> b) -> [a] -> [[a]]

Re: Proposal: To add 2 new lower-level concurrency constructs andrebuild Concurrent.Chan using them

wren ng thornton — 2012-05-09T21:39:11

Sure. I was just pointing out the paranoia option ;)



I was meaning more that some folks might be concerned about the slowdown 
compared to the current implementation. Which we should really quantify 
before replacing the old implementation. If it's significant, I'm fine 
with having different implementations based on whether you're 
performance crazy vs need those features.


Sounds like a good plan. Let me know if you want any help with the 
bounded and closeable variants, or with benchmarking.

parallel containers dependency

Edward Kmett — 2012-05-09T00:12:13

Would it be possible to relax the upper bound on parallel's dependency on
containers to permit the use of 0.5?

I was able to adjust about 20-30 of my packages to support the new
containers with no change, right up until I ran into packages that use or
transitively use parallel, and now I'm stuck.

-Edward
_______________________________________________
Libraries mailing list
Libraries< at >haskell.org
http://www.haskell.org/mailman/listinfo/libraries

Re: Proposal: To add 2 new lower-level concurrency constructs andrebuild Concurrent.Chan using them

Ivan Tomac — 2012-05-08T07:56:55

Hi Wren,

wren ng thornton<wren at freegeek.org>  wrote:

I'd rather not use atomicModifyIORef - if IORef reads and writes
aren't atomic I could just use MVars. If IORefs are atomic though, I
would think that it's better to only use MVars where a lock would be
required and use IORefs otherwise.
It seems to me MVars have a fair bit of overhead over plain IORefs.


Thanks. I have already, as far as I can tell, fixed the bugs,
hopefully without introducing any new ones.
The code is attached to the original post:
http://www.haskell.org/pipermail/libraries/2012-May/017782.html
It's possible it got stripped from the post by the mail client though?
Alright, so perhaps the way forward is to create a new library on
Hackage, and (eventually) remove concurrent channels from base?

Ivan

Re: Proposal: unify constant functors

wren ng thornton — 2012-05-08T01:33:33

I was meaning issues with bikeshedding rather than with syntax per se.

For instance, what is the significance in distinguishing (via the 
"renaming") the "as" for qualified module renaming from the "as"/"to" 
for term renaming? Why not just:

     import Foo as F (foo as f)

Re: Proposal: To add 2 new lower-level concurrency constructs andrebuild Concurrent.Chan using them

wren ng thornton — 2012-05-08T01:24:38

If you do break off a separate library (or resolve the bugs to 
everyone's satisfaction), to the extent possible it'd be nice to see 
non-STM versions of stm-chans[1] provided. I'd be willing to help out 
with that over the summer, though it certainly won't make it into this 
month's HP.


[1] http://hackage.haskell.org/package/stm-chans/