- Libraries - Haskell.org

RE: build-depends harmful (was RE: import resolution)
by Simon Marlow 19 Apr '05

19 Apr '05

On 18 April 2005 21:18, S. Alexander Jacobson wrote: > I just reread my prior post and realized that it was not entirely in > english. Trying again... > > Module names in import statements refer to module specifications not > module implementations. e.g. if Prelude refers to a spec not an > implementation, then use of any module that uses the Prelude must also > refer to a spec rather than an implementation. > > Module users select hardware platform, operating system, compiler, > etc. They should also be selecting the best modules implementations > for their context. Module packagers lack enough information about user > context to do so. > > The problem with build-depends and the Package Overlap Restriction is > that they move decision making from module users to module packagers. > Build-depends is far more egregious than POR and far more optional. I think you misunderstand build-depends. It allows the author of a library to specify which implementations of a dependency are compatible with the source code of the current package; i.e. which packages will satisfy the dependency. (I'd be happier if you'd call the Package Overlap Restriction the Module Overlap Restriction, since it really has nothing to do with packages: Haskell 98 contains this restriction). > Packages should simply be collections of module implementations with > meta-data about how/where those implementations are best used. > > Users should then select implementations from (Hackage) catalogs of these > (Cabal) packages as needed. > > Therefore, we need to remove build-depends tags from Cabal files (or > change their semantics), and make Hackage a full catalog > serving/replication protocol. Removing build-depends would impose the restriction that a module can never change its interface, ever. Additionally, users are required to choose between available implementations, whether they want to or not. This appears to be the nub of the issue: I'm opposed to adding this restriction. Perhaps you could elaborate on how you would implement versioning in that scenario, and how we could add to or change existing interfaces? Cheers, Simon

2 1

RE: Cabal compiling with profiling
by Simon Marlow 19 Apr '05

19 Apr '05

On 19 April 2005 03:25, Isaac Jones wrote: > I have a patch from Arthur Baars to build profiling libraries for GHC. > I'm wondering how people think it should be integrated? Should we > have a --prof option that JUST builds profiling libraries, or which > builds both non profiling and profiling? I know that the makefile > system has some "ways" that I think are related to profiling. Should > we have something more flexible, or is --prof or --with-prof flexible > enough? --with-prof sounds good, which would build (and install etc.) the prof way in addition to the normal way. In the future we might need more of these (eg. --with-smp), but since each one needs a different flag to GHC I don't think there's anything more general we can reasonably do. Cheers, Simon

3 2

RE: import resolution (was RE: exposed packages and cabal depends)
by Simon Marlow 19 Apr '05

19 Apr '05

On 15 April 2005 23:45, S. Alexander Jacobson wrote: > On Thu, 14 Apr 2005, Simon Peyton-Jones wrote: >> The Right Thing to >> do must be to regard the "full module name" as being the package name >> pre-pended to the module name. > > I don't think that is right. As far as I understand, module names in > import statements identify specifications not implementations. > Otherwise, it would be incorrect for different compilers to implement > the Prelude differently. Resolution of imported module names to > meanings or specifications is fundamentally different from resolution > of module names to implementations. The former is the domain of the > programmer and the later is the domain of the compiler/interpreter. No, a module name specifies a module, that's all. A Haskell program currently consists of a collection of modules, each with a distinct name. If the overlap restriction were lifted, a Haskell program would consist of a collection of modules, each of which is identified by a distinct (module name, package name) pair. This is what Simon is referring to in the comment above. You apparently want to impose a further restriction: that a module name identifies an interface. The same interface, for all time. That sounds like a pretty restrictive world to live in! We can't ever change the interface of a module without changing its name, which would lead to lots of weird module names and probably version numbers cluttering up the module namespace. >> b) We worry about error messages like "cannot unify M.T with M.T" >> (meaning different M's!) > > I think the Haskell report is pretty clear that M.T always means M.T. > So, I interpret this as an error in the status quo that can result > from multiple packages requiring conflicting implementations of M. If we lifed the module overlap restriction (what this discussion was about), then a program could contain multiple Ms, and therefore multiple M.Ts, which would be incompatible. [ rest of post deleted.. I'll answer the later version ] Cheers, Simon

1 0

RE: Cabal compiling with profiling
by Simon Marlow 19 Apr '05

19 Apr '05

On 19 April 2005 11:33, Malcolm Wallace wrote: >>> I have a patch from Arthur Baars to build profiling libraries for >>> GHC. I'm wondering how people think it should be integrated? >>> Should we have a --prof option that JUST builds profiling >>> libraries, or which builds both non profiling and profiling? >> >> --with-prof sounds good, which would build (and install etc.) the >> prof way in addition to the normal way. > > I agree. > >> In the future we might need more of these (eg. --with-smp), but since >> each one needs a different flag to GHC I don't think there's anything >> more general we can reasonably do. > > I can envisage --with-tracing too, to build a Hat-enabled version > of a package, which involves not only extra compiler flags but extra > pre-processor and library dependencies too. > > In general, do you think these flags should combine in a linear > fashion (one of each 'way') or cross-product (all possible > permutations)? In GHC some combinations make sense, and others don't (eg. "unreg" doesn't mix with "smp", but "unreg" works with "prof"). A reasonable approach would be to build all combinations that make sense. (I'm just using "unreg" as an example, I don't think we need --with-unreg). Cheers, Simon

1 0

RE: import resolution (was RE: exposed packages and cabal depends)
by Simon Peyton-Jones 18 Apr '05

18 Apr '05

I've not been following the details of this thread, but I can say this: | PS In my last few posts I assumed you had rejected removing the | overlap restriction because that is what I interperted you to have | said e.g. here: | | We're not going to support this, at least for the forseeable future. | It's a pretty big change: every entity in the program becomes | parameterised by the package name as well as the module name, because | module names can overlap. Simon and I regard this as a shortcoming of Haskell, and of GHC in particular. Just because package A happens to use a module called Foo.Baz should not prevent package B from doing so. The Right Thing to do must be to regard the "full module name" as being the package name pre-pended to the module name. There is no difficulty in principle. But a) There are engineering considerations here. Notably, we are already concerned about the length of symbol names (in binaries, connected up by the linker), and this'd make them longer still. b) We worry about error messages like "cannot unify M.T with M.T" (meaning different M's!) c) We could probably do GHC, but what about Hugs and NHC?? d) It would be a fair amount of work, and there are plenty of competing things we'd like to do. Furthermore e) While this is the Right Thing, the workaround is easy: in package P, make your (internal) module names start "P.", to keep them out of other people's hair. (The fact that package names don't have the same lexical syntax as module names is a fly in this ointment.) I think that summarises the reasons why there has been no movement on this particular front, at least as I understand it. Simon

3 3

Re: Environment variable does not work (especially DARCS_EDITOR)
by Benedikt Schmidt 16 Apr '05

16 Apr '05

[ crossposted to libraries(a)haskell.org ] Tommy Pettersson <ptp(a)lysator.liu.se> writes: > A likely source of the problem can be that pico aborts if its > stdin or stdout isn't a tty. I have that problem with nvi. > If you run darcs 1.0.2 you can try and set DARCS_EDITOR to > "pico </dev/tty >/dev/tty". If you run a later build you > may have to write a wrapper script like > > #!/bin/sh > pico </dev/tty >/dev/tty > > since the to-be-next stable darcs not always perform the > redirection on the system call any longer. > > Or, if this turns out to be the problem, and if you know how > to make darcs do this redirection of stdin/out in a portable > way, fix it in the darcs source. The problem seems to be related to rawSystem and the ghc RTS (at least GHC 6.4). GHC sets stdin/stdout/stderr to nonblocking mode on startup and nvi doesn't like that. There is a comment in ghc/rts/RtsUtils.c that resetNonBlockingFd is called before exiting because leaving standard file descriptors in nonblocking mode confuses some shells. module Main where import System.Cmd main = rawSystem "nvi" [] The test program works after applying the following patch to GHC that disables nonblocking mode after the fork and before the exec. diff -u -r1.7 runProcess.c --- libraries/base/cbits/runProcess.c 27 Mar 2005 13:41:19 -0000 1.7 +++ libraries/base/cbits/runProcess.c 16 Apr 2005 19:08:52 -0000 @@ -62,6 +62,10 @@ dfl.sa_handler = (void *)quithandler; (void)sigaction(SIGQUIT, &dfl, NULL); } + + resetNonBlockingFd(fdStdInput); + resetNonBlockingFd(fdStdOutput); + resetNonBlockingFd(fdStdError); dup2 (fdStdInput, STDIN_FILENO); dup2 (fdStdOutput, STDOUT_FILENO); I'm not sure how to handle that in darcs without copying/reimplementing the parts of System.Cmd we need. Benedikt

1 0

Cryptography Library Licensing
by Dominic Steinitz 16 Apr '05

16 Apr '05

As you may be aware, I have collected together a set of coding / decoding and cryptographic functions written in Haskell and put them together in one package. I have just modified the package and am on the point of announcing the new much improved version using cabal and darcs. A pre-release of the package is available at http://www.haskell.org/Codec/. One of the final things I need to do is ensure that the licenses are correct. It would be very helpful to me as the package maintainer if you, the authors, could agree on one license otherwise I will have to write a special license file (something I am keen to avoid as I am not a lawyer). My suggestion is that that we all use the Modified BSD license from http://www.fsf.org/licensing/licenses/license-list.html#ModifiedBSD which I reproduce below. This would be prepended by a copyright notice for the authors. Please can you either a) email with your acceptance of this or b) send me a license for your portion of the package which would be acceptable to you. I would much prefer the former as it would significantly reduce the amount of work for me. Many thanks, Dominic. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

1 0

StateT example (an encore performance)
by Isaac Jones 16 Apr '05

16 Apr '05

I noticed a few bits lacking in the Control.Monad.State documentation. I think an example of using StateT to encapsulate IO would be a useful addition... In order to make StateT more interesting, the trick is to use a lift inside a function that returns StateT, so you can actually perform IO. I would guess that this is the kind of use case that most people would want to use StateT, but lift isn't mentioned in the docs. Also, the types of "runStateT" and "runState" are a little confusing, since they're actually field accessor functions, so I'd like to make a note on that. So how 'bout I add an example like the following to the State documentation? module Main where import Control.Monad.State type MyState a = StateT Int IO a stateFun :: MyState String stateFun = do modify (+100) liftIO (putStrLn "Hello!") return "foo" main = do (s, n) <- runStateT (stateFun >> stateFun) 0 putStrLn $ "n: " ++ (show n) ++ " s: " ++ s peace, isaac

2 2

Cabal Installing Executables
by Dominic Steinitz 16 Apr '05

16 Apr '05

When I run ./Setup install, the executables end up in /usr/local/bin which is not where I want them and not with the right permissions. Can someone tell me what I have to do to install the executables in the current directory or my home directory and also set the permissions (and ownership) to be that of the installer? Thanks, Dominic. Here's part of the cabal file: Executable: BERTest Main-Is: BERTest.hs Other-modules: Codec.ASN1, Codec.ASN1.BER and here's what happens to the executables in /usr/local/bin: -rwxr--r-- 1 root root 1317323 Apr 16 07:40 X509Example* -rwxr--r-- 1 root root 1555872 Apr 16 07:40 SymmetricTest* -rwxr--r-- 1 root root 1584127 Apr 16 07:40 RSAEncryptionExample* -rwxr--r-- 1 root root 1351135 Apr 16 07:40 PKCS8Example* -rwxr--r-- 1 root root 915278 Apr 16 07:40 BERTest*

1 0

Do you use GHC?
by Simon Peyton-Jones 15 Apr '05

15 Apr '05

Dear Haskell folk, PLEASE READ THIS IF YOU USE THE Glasgow Haskell Compiler (GHC). I virtually never send messages to overlapping sets of lists, but I'm doing so this time, because I'd really like to get to everyone who uses GHC. Here at GHC HQ, we are often asked how many people use GHC, and what kind of folk they are. Since GHC is free software, we have no clue. Download stats tell us a bit, but not much, because GHC gets out through a variety of other routes too (e.g. Debian). We also have little idea about which aspects of GHC are most valued, nor of what enhancements would be most sought after, or which platforms are most important to you. We hear quite a bit from the bleeding-edge folk who push the limits, but much less from people who just want to get the job done. Thus motivated, Tomasz Zielonka kindly put together a (WASH-powered) survey for us, which asks you to tell us a bit yourself and how you use GHC. We've had about 230 responses so far; thank you to those 230 folk. But I'm pretty certain there are more than 230 people in the world who use GHC! THIS MESSAGE IS TO ASK YOU TO TAKE 5 MINS TO COMPLETE THE SURVEY http://www.haskell.org/ghc/survey/start.cgi We'd like to hear from *absolutely everyone* who uses GHC: whether you are a first-year undergraduate or a famous professor; whether you use GHC for industrial applications or recreation; whether you use higher-rank polymorphism or have only just learned what functional programming is. Everyone! We'll use the information to guide our future priorities, and we'll publish some kind of summary of what we learn in due course. It's all anonymous, of course, unless you choose to say who you are. If you think it's appropriate, please circulate this announcement locally, e.g. to your students who may not be on the Haskell mailing list Many thanks Simon PJ and Simon Marlow

1 0