- Libraries - Haskell.org

#60: Set up Platform Committee to decide Add/Remove decisions]
by Don Stewart 15 Jun '09

15 Jun '09

FWD to libraries, where the policy discussions will take place. ----- Forwarded message from Sven Panne <Sven.Panne(a)aedion.de> ----- Date: Fri, 12 Jun 2009 15:29:35 +0200 From: Sven Panne <Sven.Panne(a)aedion.de> To: haskell-platform(a)community.haskell.org Subject: Re: [haskell-platform] #60: Set up Platform Committee to decide Add/Remove decisions Just a small remark here: The Platform Committee should seriously take the main goal of the HP into consideration, i.e. providing a 1-click-installation resulting in a compiler and tools plus a nice, usable set of libraries for various platforms. Throwing out everything which might lead to trouble at compilation time is completely the wrong way. Having trouble (and solving it) is the main task of people involved in the HP! Only providing packages which are extremely trivial to install (like mtl or html) doesn't help the end user at all. Apart from the boring, mostly academic stuff end users expect shiny things like support for GUIs, graphics and sound. Take the HP and ask yourself: What applications can I program with it alone which I can show to friends to convince them about the usefulness of Haskell? Monad transformers and software transactional memory will convince only very few people, so we really need *more* packages in the HP, not less... Cheers, S. _______________________________________________ Haskell-platform mailing list Haskell-platform(a)projects.haskell.org http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform ----- End forwarded message -----

1 1

Re: Network.URL
by Iavor Diatchki 15 Jun '09

15 Jun '09

Hi, I agree that there is overlap between the two. I specifically wrote Network.URL because of some problems that I encountered while trying to use Network.URI on a project. My biggest problem was that Network.URI does not abstract away from representation issues, so one runs into all the usual PHP type of problems like forgetting to URL encode/decode, or doing it multiple times. It is (alsmost) like just working with Strings. Here is an example: show (URI "http:" Nothing "my?path" "" "") "http:my?path" which is incorrect in a number of different ways. Network.URL uses a different approach where the basic design principle is that programmers work with URLs as ordinary Haskell values, and then there are functions to convert to/from Strings/Bytes, which take care of representation issues. Here is an example: exportURL (URL HostRelative "my?path" []) "/my%3fpath" So, my vote (unsurprisingly) would be to obsolete/replace Network.URI. I am a bit worried that this might break a lot of code. On the other hand, recently we have been a lot more strict about specifying the precise dependencies for packages, so perhaps there won't be much of an issue? -Iavor On Fri, Jun 12, 2009 at 1:21 AM, Simon Marlow<simonmar(a)microsoft.com> wrote: > Hi Iavor, > > I just noticed the url package on Hackage. There seems to be a lot of overlap between this and Network.URI in the network package. Perhaps they should be merged, or one of them deprecated? > > Cheers, > Simon > >

2 1

Proposal: In haskell-src, add Functor, Applicative, Monad, and Monoid instances for ParseResult
by Yitzchak Gale 14 Jun '09

14 Jun '09

In the haskell-src package, add the following instances to ParseResult that make it more convenient to traverse and modify a syntax tree. http://hackage.haskell.org/trac/ghc/ticket/3290 Two weeks discussion period. > instance Functor ParseResult where > fmap f (ParseOk x) = ParseOk $ f x > fmap f (ParseFailed loc msg) = ParseFailed loc msg > > instance Applicative ParseResult where > pure = ParseOk > ParseOk f <*> x = f <$> x > ParseFailed loc msg <*> _ = ParseFailed loc msg > > instance Monad ParseResult where > return = ParseOk > ParseOk x >>= f = f x > ParseFailed loc msg >>= _ = ParseFailed loc msg > > instance Monoid m => Monoid (ParseResult m) where > mempty = ParseOk mempty > ParseOk x `mappend` ParseOk y = ParseOk $ x `mappend` y > ParseOk x `mappend` err = err > err `mappend` _ = err -- left-biased

3 4

Fwd: Re: thread safety.
by Bulat Ziganshin 12 Jun '09

12 Jun '09

the follwoing message forwarded from Lua list and says about non thread-safety of *time and system calls. it may be useful for haskell libs developers This is a forwarded message From: George Neill <georgen(a)neillnet.com> To: Lua list <lua(a)bazar2.conectiva.com.br> Date: Friday, June 12, 2009, 12:29:17 PM Subject: thread safety. ===8<==============Original message text=============== Asko, On Thu, Jun 11, 2009 at 11:54 PM, Asko Kauppi<askok(a)dnainternet.net> wrote: > > The re-entrant gmtime_r() and localtime_r() are not ANSI C, I believe. You > can provide a patch but inclusion of non-ANSI C features has seemed to be a > 'no'. Maybe this will change, eventually. > > "The asctime_r(), ctime_r(), gmtime_r(), and localtime_r() functions are > expected to conform to ISO/IEC 9945-1:1996 (``POSIX.1'')" right, indeed gmtime_r/localtime_r would fall under LUA_USE_POSIX from solaris localtime manpage, The asctime(), ctime(), gmtime(), and localtime() functions are safe to use in multithread applications because they employ thread-specific data. However, their use is discouraged because standards do not require them to be from linux (ubuntu) localtime manpage, The four functions asctime(), ctime(), gmtime() and localtime() return a pointer to static data and hence are not thread-safe. Thread-safe versions asctime_r(), ctime_r(), gmtime_r() and localtime_r() are spec? ified by SUSv2, and available since libc 5.2.5. so gmtime/localtime are not required to be thread-safe by the standard ... but some vendors have made them thread-safe. > Can you post a case where using such functions really presents a hazard, in > a multithreaded application? of course, I will try to put together an example that breaks for you. The idea would be to have two or more threads with their own lua state; and at the same time, have one writing to the static data the other reading from it. > Why do you think 'system' is a problem? Maybe it's been on the warning list > because when you launch external programs, there's no guarantee how > multithread unfriendly they could be? I find no problem with 'system()' > itself. from solaris system(3c) man page, The system() function manipulates the signal handlers for SIGINT, SIGQUIT, and SIGCHLD. It is therefore not safe to call system() in a multithreaded process, since some other thread that manipulates these signal handlers and a thread that concurrently calls system() can interfere with each other in a destructive manner. If, however, no such other thread is active, system() can safely be called concurrently from multiple threads. See popen(3C) for an alternative to system() that is thread-safe. they suggest, int my_system(const char *cmd) { FILE *p; if ((p = popen(cmd, "w")) == NULL) return (-1); return (pclose(p)); } as a system() alternative. Thanks, George. ===8<===========End of original message text=========== -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

2 2

control-timeout: deprecated?
by Erik de Castro Lopo 12 Jun '09

12 Jun '09

Hi all, I found this: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/control-timeout-… which is a dependancy of another module I'm interested in, but its marked deprecated (as is the other module). Is there any reason why its deprecated? If all its missing is a maintainer any one mind if I pick it up? Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

4 10

Re: [Haskell] ANNOUNCE: OpenGLRaw 1.0.0.0
by Isaac Dupree 12 Jun '09

12 Jun '09

Sven Panne wrote: > As a first step to make the OpenGL package easier to install, more modular and > a bit more flexible, a low-level binding for OpenGL has been uploaded to > Hackage. Reminds me of Mauricio's "bindings" efforts, though with some different design decisions. Considering that OpenGL has many many functions that may not be supported, in no linear pattern (EXT, or just binding to an OpenGL 2.x implementation, etc.), dynamic loading might be a good choice. Is it fast enough? (Any amount of performance penalty is probably too much for OpenGL -- I remember one time I resorted to some C in my OpenGL haskell program because I couldn't figure out how to unbox enough things in my Haskell code or maybe GHC 6.4 just wasn't as good as low-level optimizations/code generation.) -Isaac > From OpenGLRaw's package description: > > ------------------------------------------------------------ > OpenGLRaw is a raw Haskell binding for the OpenGL 3.1 graphics system and lots > of OpenGL extensions. It is basically a 1:1 mapping of OpenGL's C API, > intended as a basis for a nicer interface. OpenGLRaw offers access to all > necessary functions, tokens and types plus a general facility for loading > extension entries. The module hierarchy closely mirrors the naming structure > of the OpenGL extensions, making it easy to find the right module to import. > All API entries are loaded dynamically, so no special C header files are > needed for building this package. If an API entry is not found at runtime, a > userError is thrown. > > OpenGL is the industry's most widely used and supported 2D and 3D graphics > application programming interface (API), incorporating a broad set of > rendering, texture mapping, special effects, and other powerful visualization > functions. For more information about OpenGL and its various extensions, > please see http://www.opengl.org/ and http://www.opengl.org/registry/. > ------------------------------------------------------------ > > Version 1.0.0.0 covers the OpenGL 3.1 core, all ARB extensions and all EXT > extensions. Great care has been taken to introduce as few build dependencies > as possible, so neither autoconf is required, nor any OpenGL headers. Future > versions of the OpenGL package will basically be a convenience layer above > this package, but you can always fall back to the raw binding if required. To > get a taste for it, have a look at http://aedion.de/haskell/SmoothRaw.hs, > which should look extremely familiar to anyone who has used OpenGL's C API. > > Any feedback is highly appreciated. > > Cheers, > S. > > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

2 1

Proposal: Add System.FilePath.Cygwin
by Neil Mitchell 12 Jun '09

12 Jun '09

Hi Proposal: Add System.FilePath.Cygwin Ticket at: http://hackage.haskell.org/trac/ghc/ticket/3274 I propose we add the module System.FilePath.Cygwin to the filepath library. This module would be based on System.FilePath.Windows but with '/' as the preferred path separator, rather than '\\' as for Windows. This module would never be available as System.FilePath, and would always have to be imported specifically if wanted. The desire for this module comes from working with the Cygwin shell, which supports Windows syntax but requires the alternative separator. I have been using such a module for a few months, and find it very useful. There are no backward compatibility concerns, as it is a new separate module. Discussion deadline: 18th June 2009. Thanks, Neil

4 5

darcs patch: Control.Monad: add 'ignore' function
by gwern0＠gmail.com 12 Jun '09

12 Jun '09

Thu Jun 11 21:29:53 EDT 2009 gwern0(a)gmail.com * Control.Monad: add 'ignore' function Turns m a -> m (). Lets one call functions for their side-effects without having to get rid of their return values with '>> return ()'. Very useful in many contexts (parsing, IO etc.).

1 0

Re: Adding an ignore function to Control.Monad
by John Lato 11 Jun '09

11 Jun '09

> From: David Menendez <dave(a)zednenem.com> > On Thu, Jun 11, 2009 at 1:53 PM, Sittampalam, > Ganesh<ganesh.sittampalam(a)credit-suisse.com> wrote: >> David Menendez wrote: >>> On Thu, Jun 11, 2009 at 9:37 AM, Sittampalam, >>> Ganesh<ganesh.sittampalam(a)credit-suisse.com> wrote: >> >>>> The main issue (IMO) is that do notation uses (>>) in the desugaring, >>>> which in turn means that it supports statements that just throw away >>>> not () results. >>> >>> How is that a problem? The whole *point* of (>>) is that it discards >>> unneeded return values. >> >> I think we should avoid having syntax that implicitly does this. So >> >> do getLine >> return 3 >> >> should be banned, and users should be forced to write something like >> >> do getLine >> ignore >> return 3 >> >> or >> >> do _ <- getLine >> return 3 >> >> Ganesh > > Again, why do you think that? I much prefer the current syntax. IMO this is a tricky issue. On the one hand, it's clear with do-notation that the result of a line is being ignored because it isn't explicitly handled. On the other hand, this strikes me as antithetical to the spirit of the language. I somewhat grudgingly agree with Henning and Ganesh that the syntax should prevent accidentally ignoring values when possible. I say grudgingly because I also prefer the current syntax. although if it were going to change my next favorite option is do ignore getLine return 3 John

1 0

Re: [Haskell-cafe] nubBy seems broken in recent GHCs
by Cale Gibbard 10 Jun '09

10 Jun '09

2009/6/6 Bertram Felgenhauer <bertram.felgenhauer(a)googlemail.com>: > Interesting. This was changed in response to > > http://hackage.haskell.org/trac/ghc/ticket/2528 > > | Tue Sep 2 11:29:50 CEST 2008 Simon Marlow <marlowsd(a)gmail.com> > | * #2528: reverse the order of args to (==) in nubBy to match nub > | This only makes a difference when the (==) definition is not > | reflexive, but strictly speaking it does violate the report definition > | of nubBy, so we should fix it. > > It turns out that 'elem' differs from the report version and should > have its comparison reversed. Of course that would only ever matter > for broken Eq instances. > > However, the report also states that the nubBy function may assume that > the given predicate defines an equivalence relation. > > http://haskell.org/onlinereport/list.html#sect17.6 > > So I'm not sure there's anything to be fixed here - although backing > out the above patch probably won't hurt anybody. > > Bertram Yeah, while most Eq instances really do define an equivalence relation (at least extensionally), and the Report authors probably thought in terms of an equivalence relation (even going so far as to say that nubBy can assume its parameter is one, which I think was a mistake), I think nubBy has a much more general use. It does a generalised kind of sieving, specifically, nubBy f xs is the unique subsequence of xs that: 1) Has the property that if x and y are elements such that x occurs before y in it, then f x y is False. 2) The sequence of indices of selected elements is lexicographically minimum for all subsequences satisfying condition 1. (That is, it always picks the earliest elements possible.) I think this is how it ought to be specified. Similarly, groupBy f xs is (and should be) the unique list of contiguous sublists of xs such that: 1) concat (groupBy f xs) = xs 2) If x is the head of any of the sublists and y is any other element of that sublist, then f x y 3) The sequence of lengths of the sublists is lexicographically maximum for all lists satisfying the first two properties (That is, it always prefers adding elements to an earlier group to starting a new group.) - Cale

2 1