- Libraries - Haskell.org

working Edison, a couple of collection modules, and typing troubles
by Samuel Bronson 26 May '05

26 May '05

Whatever happened to Edison? I want to play with it and the one in the HFL cvs repository won't build for me (and uses flat names). I was trying my hand at writing some collection classes myself and I can't figure out a good typing for map that will let me make Map an instance of my Collection class... I'm attaching what I have so far. I don't much like the head of Mapping. I expect oleg will have some crazy type-system trick up his sleeve. -- Thankful-in-advance-ly yrs, Sam

2 2

Time library comment
by Eric Etheridge 26 May '05

26 May '05

I have read all of the comments on this list over the last half a year regarding the Time library, and I feel I need to comment. (That was a lot of reading!) I write games, and I use Haskell. I don't need a time library to do anything fancy at all, no timezones, no leap seconds, nothing. I only need two things from a Time library: 1. An absolute assurance that some method of determining current time will give me an actual resolution of at most 1-3 milliseconds, without regard for leap seconds or even the user changing the system clock. 2. A way to set an event (OS signal, IO () function, whatever) to happen a certain amount of time in the future, again without regard to leap seconds or gross alteration of the system clock. #1 is very critical to games, because it is desirable to coordinate the display function with the rate of the screen refresh, which can be 85 Hz or higher on high-end machines. Hopefully, you redraw once and only once for each screen refresh. Currently, #2 means writing my own alarm thread and depending on poll and the like, as others have pointed out. Why can't that be a standard function? All of the other functions such as conversion and the like are frivolous for game design, because everything is measured relatively from game start, since the system clock as-is can't be trusted. Don't take this too seriously. Just know that the current method of achieving that kind of resolution requires using GLUT, which means eating up more memory and CPU than necessary. As always, thanks for a wonderful language, libraries, and compilers. - Eric Etheridge __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

Win32 bindings and the GHC6.4 windows distro
by Philippa Cowderoy 24 May '05

24 May '05

I decided to have a play with the win32 bindings in the hierarchical libraries. The attached program built with ghc --make fails to link with these errors: test.o(.text+0x1c2):fake: undefined reference to `GraphicsziWin32ziMisc_messageB ox_closure' test.o(.text+0x255):fake: undefined reference to `__stginit_GraphicsziWin32ziMis c_' test.o(.data+0x3c):fake: undefined reference to `GraphicsziWin32ziMisc_messageBo x_closure' How can I get this to build for now, and is it possible to set up the package that comes with the binary windows distribution so that no fix is needed in the future? -- flippa(a)flippac.org A problem that's all in your head is still a problem. Brain damage is but one form of mind damage.

2 2

Difference Argument Order
by Ashley Yakeley 24 May '05

24 May '05

Which of these argument orders is more intuitive to you? 1. This one makes more sense when considering the function formed by applying one argument: add :: Diff -> Absolute -> Absolute add d a = a + d subtract :: Diff -> Absolute -> Absolute subtract d a = a - d diff :: Absolute -> Absolute -> Diff diff a b = b - a So "add x", "subtract y" and perhaps "diff z" are intuitively useful functions. And we also have "subtract = add . negate". 2. This one is more familiar for the English language and for the standard operators: add :: Absolute -> Diff -> Absolute add a d = a + d subtract :: Absolute -> Diff -> Absolute subtract a d = a - d diff :: Absolute -> Absolute -> Diff diff a b = a - b -- Ashley Yakeley, Seattle WA

4 7

RFC: general sequences
by Ross Paterson 24 May '05

24 May '05

A general implementation of sequences (based on work with Ralf Hinze) can be found at http://www.soi.city.ac.uk/~ross/software/html/Data.Sequence.html http://www.soi.city.ac.uk/~ross/software/Data/Sequence.hs Our experiments indicate that its performance is comparable to (and sometimes better than) the best known persistent implementations(*). Non-persistent implementations are typically faster, but you need to be more careful when using them. I'd like to propose this for base. Comments welcome. (*) or at least it will be when GHC's SPECIALIZE pragma is fixed for polymorphic specializations (SF bug #1019758).

11 32

RE: GHC Win32 ffi functions as implemented for Pugs
by Simon Marlow 23 May '05

23 May '05

On 22 May 2005 23:32, Max Maischein (Corion) wrote: > The file is (live version) : > > http://svn.openfoundry.org/pugs/src/Pugs/Compat.hs > > The implemented wrappers that are functional and not just stubs are > (as of r3680) : > > For System.Environment: > setEnv :: String -> String -> Bool -> IO () > getEnv :: String -> IO (Maybe String) > unsetEnv :: String -> IO () System.Environment.getEnv should work on Win32. For the others, it would possibly make sense to include these in System.Environment, with implementations for both Unix & Win32. > For Posix.Process > getProcessTimes :: IO ProcessTimes > getProcessID :: IO Int Should probably be in System.Win32 somewhere. > The code itself is dual-licensed under the Artistic License and GPL > and thus should be compatible with whatever license GHC uses. Unfortunately we can't take code under that license into our existing packages - the rule is that each package has a single license, and currently all the packages distributed with GHC have a BSD3 license, with the exception of readline. You can start new packages, of course. > Hope you find my code useful, Contributions are always welcome, even if we can't use the code directly. You've pointed out things that the standard libraries lack. Thanks! Cheers, Simon

2 1

Let the key (digest of contents) _be_ the identity (was: hackage, cabal-get, and security)
by Dimitry Golubovsky 23 May '05

23 May '05

This was inspired by the discussion in [Libraries] on how to validate the contents of a distributed package. John Meacham wrote: > The whole idea of tying a key to an > existential identity is flawed, let the key _be_ the identity and all > problems go away. Let me suggest. Why cannot the following simple approach be used as a basis? Consider some "distribution unit", OK, let's call it "Package". It has a property of being distributed independently, say, as a tar ball (or a zip file). Right before packing, a digest may be computed (say MD5 or whatever else, doesn't really matter at this point) on the contents of a directory (with subdirectories) containing the distribution. Then a tar ball file is created in traditional way. The tarball file itself will be named based on the digest: for example, if we have computed a digest d41d8cd98f00b204e9800998ecf8427e then the file will be named "package_d41d8cd98f00b204e9800998ecf8427e.tar.gz". When a developer wishes to announce a new package, he/she supplies this digest-containing name (digest calculated just before creation of the tarball), and a "descriptive" name (say Package Foo version 8 revision 75) will accompany the announce. Such an announce being placed on one (or several) of many web-enabled mailing lists (such as the haskell mailing list for instance, or fm-announce for freshmeat) will soon be indexed by various search engines, so it will be easy to verify (even in some automated way provided that all announce messages are forced to be formatted uniformly) the identity (digest) of a package given its descriptive name. In any ambiguity, priority must be given to the earliest post found (as it was most likely made by the original developer). Someone willing to use a package, locates and downloads the tarball (by its name which contains the digest). It may then be unpacked, the digest produced: if it matches that in the file name, the file is valid, otherwise not. Additionally, size and checksum of the tarball may be also added to the announce message. So the only question I cannot answer (not being a crypto expert) is whether there exists such a digest algorithm that makes it nearly impossible to supply a distribution file with different contents, same size, and same checksum, but after unpacking, yielding the same digest value. With this approach, there is no need to have a centralized storage for packages: the Internet itself becomes such a storage, and the packages database is replaced by existing search engines given we are able to make search requests programmatically (see my earlier post in [Haskell-cafe] on locating Cabal files with Google). So, to locate a package, one searches (googles) for its descriptive name: result will return URLs of all cabal files indexed by the search engine containing such a name. The next step is downloading the cabal file and finding the distribution tarball file name. So, instead of going into cryptography problems, I am suggesting to use the contents of a package for self-validation (via computed digest), and to use the "public record" such as an internet-archived mailing list message to establish a truth about relationship between "descriptive" name (which is human-readable) and "distribution" name (which contains a digest to verify). Implementation of this approach does not need any extra software (except maybe a wrapper around md5sum or like to digest a whole directory with subdirectories) and few other shell scripts. Perhaps a tag needs to be added to cabal file syntax which would contain the digest (if one does not exist, at least I couldn't find it in the documentation at haskell.org/cabal) Distribution file name may be derived from that digest. -- Dimitry Golubovsky Anywhere on the Web

1 0

RE: Difference Argument Order
by Simon Marlow 23 May '05

23 May '05

On 23 May 2005 01:43, Ashley Yakeley wrote: > Which of these argument orders is more intuitive to you? > > 1. This one makes more sense when considering the function formed by > applying one argument: > > add :: Diff -> Absolute -> Absolute > add d a = a + d > subtract :: Diff -> Absolute -> Absolute > subtract d a = a - d > diff :: Absolute -> Absolute -> Diff > diff a b = b - a > > So "add x", "subtract y" and perhaps "diff z" are intuitively useful > functions. And we also have "subtract = add . negate". > > 2. This one is more familiar for the English language and for the > standard operators: > > add :: Absolute -> Diff -> Absolute > add a d = a + d > subtract :: Absolute -> Diff -> Absolute > subtract a d = a - d > diff :: Absolute -> Absolute -> Diff > diff a b = a - b If you have the second form, then it would make sense to call them "plus", and "minus", because they correspond to the infix operators. BTW, the Prelude already has "subtract" with the opposite argument order to infix "-", but this was provided mainly because (-1) means (negate 1) rather than ((-) 1). For the "diff" functions, the first form seems more natural to me, because the arguments increase left-to-right, ie. in (diff T1 T2) T2 is later than T1. Cheers, Simon

1 0

Licence for time library code?
by Ashley Yakeley 22 May '05

22 May '05

What licence should I grant for code that might become part of the standard libraries? -- Ashley Yakeley, Seattle WA

2 1

Haddock Options in Cabal
by Dominic Steinitz 22 May '05

22 May '05

I want to generate my documentation with the following options: haddock -h -v -i <url>,<base> --source=<source> Is there a way of doing this in Cabal? I didn't think there was as looking at the code, neither prehaddock or posthaddock hooks would help: code <- rawSystemVerbose verbose (fromJust mHaddock) (["-h", "-o", targetDir, "-t", showPkg, "-p", prologName] ++ (if verbose > 4 then ["-v"] else []) ++ outFiles ) I'm happy to have a go at modifying Cabal but would appreciate some guidance on what the best approach is. Dominic.

2 1