Re: [Haskell-cafe] Safe Haskell at the export symbol granularity?
On 17 June 2012 13:30, Gábor Lehel illiss...@gmail.com wrote: Thanks for the long answer! No problem. It was a nice question as it made me think of some new aspects. It just occured to me that Data.Typeable is in basically the same situation. Data.Typeable is a Trustworthy module with a type class, and with functions built on that class, which are safe if they are used with types for which the instances of the class are proper. Using only safe modules and imports, it is not possible to subvert that safety: instances can only be derived, and derived instances are guaranteed to be proper. But if someone makes a Trustworthy module with an improper manual Typeable instance and you import it, suddenly the functions in Data.Typeable can be unsafe, even though nothing in that module has changed. The only difference in my situation is that there's no guaranteed-to-be-safe deriving mechanism, it all rests on whether the Trustworthy modules importing my Unsafe module to write their instances are behaving themselves. I think one way to resolve this might be to say that Safe Haskell's mission is to help prevent bad things from happening in a global sense, but not necessarily to delineate which functions can or cannot be causing the bad things once unsafeness has crept into the program. Trustworthy modules are inherently risky: they declare of themselves that they're trustworthy, but really, they could do anything. The burden is on the administrator to decide what they actually trust. What Safe Haskell says is that if the administrator does this properly and only trusts packages/modules which are actually safe, then programs will not behave unsafely. But if they make a bad decision and trust an unsafe module, then whether it does the bad things directly, or indirectly by breaking the invariants another module depends on, doesn't make much of a practical difference. You've lost either way. Yes. This is exactly how you should think of it. If people aren't thinking of it this way (which there is a good chance they aren't) then Safe Haskell technically is fine but I'm failing at communicating the design. Trustworthy modules by definition are outside the scope of provability. So the safety very much relies on the trust you have of trustworthy modules, that they do what you believe they do. I will have to look at the userguide again as I think it needs a paragraph like the one of yours above but I don't know if it does right now. On Sat, Jun 2, 2012 at 2:28 AM, David Terei dave.te...@gmail.com wrote: So this is a good question, sorry for the late reply. It's tricky as the way typeclasses are imported and exported in Haskell is confusing. Basically, instances are hard to control access to as they aren't part of import or export statements. Importing a module that defines an instances gives you those instances. This works transitively so you have access to all instances defined below you in the dependency graph. Controlling access to a typeclass function is easy though, it works just like a normal function. So in your example, the Safe module wouldn't necessarily become unsafe but there is some unsatisfactory trickiness. - untrusted code still couldn't access the type class as the functions for it aren't exported. - the derived functions may or may not be safe anymore depending on polymorphism: - If the derived functions don't have any polymorphism that would allow consumers of the functions to choose what underlying typeclass is used, then the module is still safe. - If they do, then yes untrusted code could choose what types to use to cause the unsafe instance to be used, thus making the derived functions unsafe. (This assumes the untrusted code has access to the unsafe instance but as I said, this is hard to reason about since instances are somewhat global). there are solutions to this problem but its a tricky situation with the solutions really being to be careful... I don't know how we could do better. Tracking safety at the symbol level doesn't seem like it would change this situation. Basically you want closed type classes or a way to control what instances can be used (maybe by simply making instances part of import/export lists) both of which are big changes to Haskell. I wrote some example code and a note about this stuff: https://github.com/dterei/SafeHaskellExamples/tree/master/typeclasses Cheers, David On 18 May 2012 06:58, Gábor Lehel illiss...@gmail.com wrote: I have a related-seeming question: Say I have a type class with methods, and some functions implemented on top of it. The class methods are inherently unsafe. Instances of the class are supposed to satisfy some conditions, and if those conditions are met, the functions built on top are safe. So say I put the class in an Unsafe module, and re-export the class without its methods along with the derived functions in a Safe module. For anything unsafe to happen
Re: [Haskell-cafe] Safe Haskell at the export symbol granularity?
So this is a good question, sorry for the late reply. It's tricky as the way typeclasses are imported and exported in Haskell is confusing. Basically, instances are hard to control access to as they aren't part of import or export statements. Importing a module that defines an instances gives you those instances. This works transitively so you have access to all instances defined below you in the dependency graph. Controlling access to a typeclass function is easy though, it works just like a normal function. So in your example, the Safe module wouldn't necessarily become unsafe but there is some unsatisfactory trickiness. - untrusted code still couldn't access the type class as the functions for it aren't exported. - the derived functions may or may not be safe anymore depending on polymorphism: - If the derived functions don't have any polymorphism that would allow consumers of the functions to choose what underlying typeclass is used, then the module is still safe. - If they do, then yes untrusted code could choose what types to use to cause the unsafe instance to be used, thus making the derived functions unsafe. (This assumes the untrusted code has access to the unsafe instance but as I said, this is hard to reason about since instances are somewhat global). there are solutions to this problem but its a tricky situation with the solutions really being to be careful... I don't know how we could do better. Tracking safety at the symbol level doesn't seem like it would change this situation. Basically you want closed type classes or a way to control what instances can be used (maybe by simply making instances part of import/export lists) both of which are big changes to Haskell. I wrote some example code and a note about this stuff: https://github.com/dterei/SafeHaskellExamples/tree/master/typeclasses Cheers, David On 18 May 2012 06:58, Gábor Lehel illiss...@gmail.com wrote: I have a related-seeming question: Say I have a type class with methods, and some functions implemented on top of it. The class methods are inherently unsafe. Instances of the class are supposed to satisfy some conditions, and if those conditions are met, the functions built on top are safe. So say I put the class in an Unsafe module, and re-export the class without its methods along with the derived functions in a Safe module. For anything unsafe to happen, the Unsafe module has to be imported somewhere. But if someone imports it and implements a bad instance, the Safe module *also* becomes potentially unsafe! What's the recommended practice here? (I can't really tell if this is the same question as originally posed by Ryan, but I think it's not.) On Thu, May 17, 2012 at 4:53 PM, Ryan Newton rrnew...@gmail.com wrote: Good point, Antoine! I think that does the trick. On Thu, May 17, 2012 at 10:48 AM, Antoine Latter aslat...@gmail.com wrote: On Thu, May 17, 2012 at 8:50 AM, Ryan Newton rrnew...@gmail.com wrote: 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? 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: module Unsafe where class MyClass a where safeOp :: a - Int - IO () unsafeOp :: a - Int - IO () instance MyClass A where ... module Safe (MyClass(safeOp)) where import Unsafe I think this works. Antoine ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Safe Haskell at the export symbol granularity?
On 17 May 2012 23:50, Ryan Newton rrnew...@gmail.com wrote: 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.) 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. 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. 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. 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? 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 -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. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announce: Hackager - new version of hackage-test
Hi all, I've updated the old hackage-test tool and renamed to hackager. http://hackage.haskell.org/package/hackager Hackager is a tool to automate the compiling of all packages on Hackage. It builds each package on hackage in isolation and records the results. The purpose being to catch regressions caused by changes to GHC (and Cabal although this was not the motivation). Two runs of Hackager can be compared, so the first run is done with a known version of GHC and the next run with a new, experimental version of GHC... ect. The improvements to Hackager over hackage-test are: * Parallelized the build process. Can now specify how many packages to build in parallel, which cuts total run time down greatly (e.g 2 days - 5 hours) * hackage-test and hackage-report are now one tool, 'hackager' that works as a mutli-command tool. * Proper option handling * Fixed some stability issues The new homepage for development can be found here: https://github.com/dterei/Hackager Cheers, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Offer to mirror Hackage
On 19 April 2012 08:12, Ryan Newton rrnew...@gmail.com wrote: Hello all, Right now I'm trying to answer a simple question: Would the current Haskell.org / hackage infrastructure benefit from the donation of a dedicated VM with good bandwidth/uptime? Whoever already knows how to do this could configure it. In trying to answer the above question I found this long email thread from 1.5 years ago. Duncan said the following: On Thu, Dec 9, 2010 at 6:47 PM, Duncan Coutts duncan.cou...@googlemail.com wrote: That's certainly what we've been planning on, that anyone can run a mirror, no permissions needed. The issue people have raised is what about having public mirrors that are used automatically or semi-automatically by clients. Are there any updates to this in the last year? Is anybody running a mirror? I am. http://hackage.scs.stanford.edu/ The other reason I've been thinking about this is the scoutess project. More public testing or continuous integration facilities would require more hardware resources. The computer it's running on has 16 cores and 48GB of ram. I have access to a few other computers like this. Cheers, David -Ryan ___ 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] Offer to mirror Hackage
Oh yes, it's hackage2... not hackage1. On 19 April 2012 11:50, David Terei dave.te...@gmail.com wrote: On 19 April 2012 08:12, Ryan Newton rrnew...@gmail.com wrote: Hello all, Right now I'm trying to answer a simple question: Would the current Haskell.org / hackage infrastructure benefit from the donation of a dedicated VM with good bandwidth/uptime? Whoever already knows how to do this could configure it. In trying to answer the above question I found this long email thread from 1.5 years ago. Duncan said the following: On Thu, Dec 9, 2010 at 6:47 PM, Duncan Coutts duncan.cou...@googlemail.com wrote: That's certainly what we've been planning on, that anyone can run a mirror, no permissions needed. The issue people have raised is what about having public mirrors that are used automatically or semi-automatically by clients. Are there any updates to this in the last year? Is anybody running a mirror? I am. http://hackage.scs.stanford.edu/ The other reason I've been thinking about this is the scoutess project. More public testing or continuous integration facilities would require more hardware resources. The computer it's running on has 16 cores and 48GB of ram. I have access to a few other computers like this. Cheers, David -Ryan ___ 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] feed release plan
There is also: https://github.com/haskell where a bunch of us are hosting librari On 10 January 2012 12:01, Erik de Castro Lopo mle...@mega-nerd.com wrote: Simon Michael wrote: - the repo will be moved to github, under my account since I don't think there's a haskell community one Haskell package janitors might be an appropriate one: https://github.com/haskell-pkg-janitors Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ 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] Improvements to Vim Haskell Syntax file - Is anyone the maintainer?
Hi All, I have made some improvements to the syntax highlighting file for Haskell included with Vim. I'd like to push them upstream. The haskell.vim syntax file included with Vim lists this mailing list as the maintainer. I take that to mean no one. Is this right or does someone actually have responsibility for the Vim Haskell syntax file? here are some screenshots of the changes I've made: http://www.scs.stanford.edu/~davidt/vim-syntax.html Cheers, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why not Darcs?
Good chance you've already read this but if not here is a good post by Linus about his take on the problems with darcs: http://markmail.org/message/vk3gf7ap5auxcxnb I personally think he is right on the money here. The other problem with Darcs is performance. While it has improved a lot its still not good enough. When GHC was using darcs you couldn't use the annotate command because it took far too long to run. If you can't use certain features of your vcs because of performance its a big fail. GHC isn't even really that large a code base, imagine trying to use darcs for say the Linux kernel. I also don't think darcs handles branches and merging well enough. Cheers, David On 21 April 2011 13:29, Andrew Coppin andrewcop...@btinternet.com wrote: I'm sure this must be a VFAQ, but... There seems to be universal agreement that Darcs is a nice idea, but is unsuitable for real projects. Even GHC keeps talking about getting rid of Darcs. Can anybody tell me what the problems with Darcs actually are? ___ 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] ANN: ieee version 0.7
I by pure coincidence was fixing a bug in some code in GHC that involved converting a Haskell float into a hex IEEE form, this is how its done in the code, just to add another way :) castDoubleToWord8Array :: STUArray s Int Double - ST s (STUArray s Int Word8) castDoubleToWord8Array = castSTUArray doubleToBytes :: Double - [Int] doubleToBytes d = runST (do arr - newArray_ ((0::Int),7) writeArray arr 0 d arr - castDoubleToWord8Array arr i0 - readArray arr 0 i1 - readArray arr 1 i2 - readArray arr 2 i3 - readArray arr 3 i4 - readArray arr 4 i5 - readArray arr 5 i6 - readArray arr 6 i7 - readArray arr 7 return (map fromIntegral [i0,i1,i2,i3,i4,i5,i6,i7]) ) The nice thing about this code is it is pure Haskell and doesn't involve using any unsafe methods. You do have to handle the platform endianess with this method though while for the others you don't. On 22 September 2010 05:59, Daniel Fischer daniel.is.fisc...@web.de wrote: On Tuesday 21 September 2010 21:35:21, John Millikin wrote: Oh, I misunderstood the question -- you're asking about architectures on which floating-point and fixed-point numbers use a different endianness? Basically, I wanted to know whether there are such beasts (apparently yes) and if, whether they're numerous enough to worry about (apparently no). ___ 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] Ultra-newbie Question
Here is a more manual way to do it, hopefully this shows the approach required. You don't need to store anything, just keep removing the head of the list until its of the size you want. n_lastn :: Int - [a] - [a] n_lastn n xs = let len = length xs - n drp = if len 0 then 0 else len rmv 0ys = ys rmv m (y:ys) = rmv (m - 1) ys in rmv drp xs Cheers, David On 18 September 2010 17:51, Christopher Tauss ctau...@gmail.com wrote: Hello Haskell Community - I am a professional programmer with 11 years experience, yet I just do not seem to be able to get the hang of even simple things in Haskell. I am trying to write a function that takes a list and returns the last n elements. There may be a function which I can just call that does that, but I am trying to roll my own just to understand the concept. Let's call the function n_lastn and, given a list [1,2,3,4,5], I would like n_lastn 3 = [3,4,5] Seems like it would be something like: n_lastn:: [a]-Int-[a] n_lastn 1 (xs) = last(xs) n_lastn n (x:xs) = The issue is I do not see how you can store the last elements of the list. Thanks in advance. ctauss ___ 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] benchmarking c/c++ and haskell
On 13 September 2010 20:41, Vo Minh Thu not...@gmail.com wrote: ... the post is from 2008. No LLVM goodness. So I thought GHC 6.12.1 (not the latest and greatest HEAD) would be enough. I compiled the two programs myself out of curiosity and got the following times. Linux, 64bit, Ubuntu 10.10: 1e8 clang: 0.180s gcc: 0.179s ghc 6.12.1 (viac): 0.187s ghc 6.12.1 (fasm): 0.218s ghc HEAD (viac): 0.186s ghc HEAD (fasm): 0.179s ghc HEAD (llvm): 0.174s 1e9 clang: 1.657s gcc: 1.647s ghc 6.12.1 (viac): 1.653s ghc 6.12.1 (fasm): 1.975s ghc HEAD (viac): 1.648s ghc HEAD (fasm): 1.658s ghc HEAD (llvm): 1.646s So basically all have the same time except ghc 6.12.1 where fasm is a little slow. On windows xp 32bit I get quite different results which I trust less as the times are jumping around much more then they were on linux: 1e8 gcc: 0.365s ghc 6.12.1 (viac): 5.287s ghc 6.12.1 (fasm): 1.332s ghc HEAD (viac): 5.292s ghc HEAD (fasm): 0.875s ghc HEAD (llvm): 0.359s Not sure why the results on windows are so different. If anyone else wants to run the two programs on Windows and check that would be great. Cheers, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
2010/9/10 kyra ky...@mail.ru: I wonder if llvm-gcc supports it's own (gcc) extensions. If it supports then there is no need to stuck in clang right now. It doesn't support the one I mentioned before of global register variables. I haven't looked for a while so maybe this has changed but llvm-gcc used to incorrectly claim that it supported this feature simply because it supported the syntax. The actual implementation of the extension doesn't work anything like gcc though so most code using the feature will break if compiled with llvm-gcc. Global register variables needs backend support (e.g register allocator) to be implemented so llvm-gcc and clang are in the same boat here, both not supporting it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Will GHC 6.14 with LLVM use LLVM C compiler to compile external C Libraries
On 9 September 2010 22:10, Mathew de Detrich dete...@gmail.com wrote: It should also hopefully make using Haskell packages on windows that use C sources less painful Clang could also make using FFI with C++ much easier (for reasons stated above) Thoughts? I don't think it would make it any easier to use C/C++ from Haskell at the moment. LLVM for static compilation works by compiling to assembly. After that it has no support. So we use gcc to finish off the rest of the job; producing object code and linking. There is a pretty cool project going on in LLVM at the moment of integrating an assembler into LLVM so that it can directly produce object code. This should mean that the LLVM backend wouldn't need gcc anymore (but obviously gcc will still be needed by ghc as a whole). As David Peixotto mentioned though, the ghc runtime can't be built by clang. There is probably a few reason but a main one is that Clang doesn't support gcc's global register variable extension (register pinning). The LLVM guys also have no plans to support this feature so unless we want to stop using this extension we are stuck with using gcc. I think the main advantage to trying to use Clang for compiling C/C++ would be that it would enable us to do whole program optimisation across Haskell and C/C++. It could also make cross compiling slightly easier. These ideas are defiantly something I'd like to investigate more in the future. On 10 September 2010 10:08, John Lask jvl...@hotmail.com wrote: In fact I would like a lot more information on what is being proposed with respect of a LLVM backend and any changes to the compiler tool chain. What would you like to know? If you're talking just about the new LLVM backend for GHC (not the proposal here of using clang) then the effect on the end user is nothing. The LLVM backend compiles an individual Haskell module to LLVM assembly, which is then compiled to native assembly by the 'llc' tool. This gets you now to the same place as the native code generator, where gcc is used to compiled the assembly to an object file. Obviously there is a new dependency on having LLVM 2.7 or greater installed but that should be it. Cheers, David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
