[Haskell-cafe] Re: DDC compiler and effects; better than Haskell?
John A. De Goes j...@n-brain.net writes: On Aug 15, 2009, at 6:36 AM, Jason Dusek wrote: 2009/08/14 John A. De Goes j...@n-brain.net: Hmmm, my point (perhaps I wasn't clear), is that different effects have different commutability properties. In the case of a file system, you can commute two sequential reads from two different files. I think this is a bad example -- it's not something that's safe in general and discredits your idea. How would the compiler even know that two files are not actually the same file? I don't think the file system is the best example. However, I do think it's a reasonable one. Let's say the type of the function getFilesInDir is annotated in such a way as to tell the effect system that every file in the returned array is unique. Further, let's say the type of the function makeNewTempFile is annotated in such a way as to tell the effect system that the function will succeed in creating a new temp file with a name unique from any other existing file. Sorry, but this example is ridiculuous. While file *names* in this case might be reasonably assumed to be unique, the *files* themselves may not. Any modern filesystem does support file aliasing, and usually several forms thereof. And what does makeNewTempFile function do? Does it create a new file like POSIX mktemp() and return its name, or does it rather behave as POSIX mkstemp()? The first case is a well known security hole, and the second case does not, as it seems to me, fit well into the rest of your reasoning. However, let's consider further file system tree traversal. In some cases you might not care, whether some of the directories you descend into are actually the same directory, so your proposed optimization would be `safe'. However, in other cases sequential traversal would work, while a parallelized version would not, unless special additional measures are taken. E.g. consider a case of a build system. It traverses a source tree, finds sources files and if corresponding object files are non-existent or outdated, does something to regenerate them. Now if you have a directory that's actually a link to another directory, and you do sequential traversal, everything is fine: you descend into the directory the first time, build everything there and when you descend into it the second time, there's just nothing to do. If you do parallel traversal, you may well end up in the situation where two threads check simultaneously for an object file, discover it's outdated and run two build processes simultaneously, with the most likely effect of corrupted object file. Then if you write a recursive function that loops through all files in a directory, and for each file, it parses and compiles the file into a new temp file, then a sufficiently sophisticated compiler should be able to safely transform the recursion into parallel parsing and compilation -- in a way that's provably correct, assuming the original program was correct. The promise of a language with a purely functional part and a powerful effect system for everything else is very great. And very important in the massively concurrent world we are entering. Well, yes -- which sounds like, there are no guarantees in general. Something that works half the time leaves you with two responsibilities -- the old responsibility of the work you did when you didn't have it and the new responsibility of knowing when it applies and when it doesn't. In the other thread, I brought up the example of buffering reads. Library authors make the decision to buffer for one reason: because if some other program is messing with the data, you're screwed no matter what. And yeah, they might be screwing with the data in just the way you need it to be screwed with, (Sebastian), in which case my advice is use C and hope for the best. :-) Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- S. Y. A(R). A. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why does the binary library require so much memory?
Hi Don, I was wondering if perhaps this might be a slightly better instance for Binary [a], that might solve a) the problem of having to traverse the entire list first, and b) the list length limitation of using length and Ints. My version is hopefully a little more lazy (taking maxBound :: Word16 elements at a time), and should potentially allow infinite lists to be stored: import Data.Binary import Data.Binary.Get import Data.Binary.Put import Data.Word newtype List a = List [a] deriving (Show,Eq) instance Binary a = Binary (List a) where put (List xs) = do let (hd,num,tl) = btake maxBound xs putWord16be num if num == 0 then return () else do mapM_ put hd put (List tl) get = do num - getWord16be if num 0 then do xs - sequence (replicate (fromIntegral num) get) List ys - get return (List (xs ++ ys)) else return (List []) btake :: Word16 - [a] - ([a],Word16,[a]) btake n xs = btake' n n xs btake' :: Word16 - Word16 - [a] - ([a],Word16,[a]) btake' 0 m xs = ([],m,xs) btake' n m [] = ([],m-n,[]) btake' !n m (x:xs) = (x:xs',n',ys) where (xs',n',ys) = btake' (n-1) m xs My testing of this version shows that it's terribly bad when it comes to memory usage, but I'm sure someone can find a more efficient way to do what I'm trying here. -- Axman On 01/08/2009, at 07:27, Don Stewart wrote: bos: On Fri, Jul 31, 2009 at 1:56 PM, Jeremy Shaw jer...@n-heptane.com wrote: Using encode/decode from Binary seems to permamently increase my memory consumption by 60x fold. I am wonder if I am doing something wrong, or if this is an issue with Binary. It's an issue with the Binary instance for lists, which forces the entire spine of the list too early. This gives you a gigantic structure to hold onto. This is the current instance instance Binary a = Binary [a] where put l = put (length l) mapM_ put l get= do n - get :: Get Int getMany n -- | 'getMany n' get 'n' elements in order, without blowing the stack. getMany :: Binary a = Int - Get [a] getMany n = go [] n where go xs 0 = return $! reverse xs go xs i = do x - get -- we must seq x to avoid stack overflows due to laziness in -- (=) x `seq` go (x:xs) (i-1) It used to be this, though, xs - replicateM n get -- now the elems. -- Don ___ 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] GSoC profiling project to be wrapped up
2009/8/14 Patai Gergely patai_gerg...@fastmail.fm:
I finally uploaded the profiling tools to Hackage. The package names are
hp2any-{core,graph,manager}. The first two should be possible to install
right away, while the manager needs Gtk2Hs. A bit more on the project
and this update at http://just-bottom.blogspot.com.
Do you have an overview somewhere of the tools and how to use them?
I just added an entry to HaskellWiki:
http://www.haskell.org/haskellwiki/Hp2any
As his mentor, I would like to thank Gergely for all the hard work he
did this summer. I'm very happy with the result. Please try the real
time profiler next time you need to debug a memory issue and send
Gergely your feedback (and bug reports).
Cheers,
Johan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] qsort
On Sat, Aug 15, 2009 at 12:09 PM, Daniel Fischerdaniel.is.fisc...@web.de wrote: It compiles as is, and if it satisfies readability requirements, somebody can put it on the wiki. http://www.haskell.org/haskellwiki/?title=Introduction%2FDirect_Translationdiff=29575oldid=21061 I've done so; it'd be nice if you could add some usage examples and timings (especially of the 80x performance of the original). -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haddock version 2.5.0
2009/8/16 por...@porg.es: George Porges s/Porges/Pollard/; Porges is just an alias :) Oh, sorry about that! I tried to google on your email address but didn't find anything, so I assumed Porges was your surname. I should start sending out my release notes for revivew ;-) David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: DDC compiler and effects; better than Haskell?
On Sunday 16 August 2009, Artem V. Andreev wrote: John A. De Goes j...@n-brain.net writes: On Aug 15, 2009, at 6:36 AM, Jason Dusek wrote: 2009/08/14 John A. De Goes j...@n-brain.net: Hmmm, my point (perhaps I wasn't clear), is that different effects have different commutability properties. In the case of a file system, you can commute two sequential reads from two different files. I think this is a bad example -- it's not something that's safe in general and discredits your idea. How would the compiler even know that two files are not actually the same file? I don't think the file system is the best example. However, I do think it's a reasonable one. Let's say the type of the function getFilesInDir is annotated in such a way as to tell the effect system that every file in the returned array is unique. Further, let's say the type of the function makeNewTempFile is annotated in such a way as to tell the effect system that the function will succeed in creating a new temp file with a name unique from any other existing file. Sorry, but this example is ridiculuous. While file *names* in this case might be reasonably assumed to be unique, the *files* themselves may not. Any modern filesystem does support file aliasing, and usually several forms thereof. And what does makeNewTempFile function do? Does it create a new file like POSIX mktemp() and return its name, or does it rather behave as POSIX mkstemp()? The first case is a well known security hole, and the second case does not, as it seems to me, fit well into the rest of your reasoning. Hi, IMHO, provided with a flexible effect system, the decision on how to do read/write operations on files is a matter of libraries. But I'd like to ask another question: is the effects system you're discussing now really capable of providing significant performance improvements in case of file I/O? Even if we assume some consistency model and transform one correct program to another one -- how do you estimate efficiency without knowledge of physical media characteristics? I kinda see how this could be used to optimize different kinds of media access (reordering socket/file operations or even running some of those in parallel), but I don't see how can we benefit from reordering writes to the same media. Another thing is that not every kind of r/w operation requires the same consistency model -- like when I'm writing a backup for later use I only care about my writes being in the same order. I imagine that such an effect system could help write software for CC-NUMA architectures or shared-memory distributed systems. -- Thanks! Marcin Kosiba signature.asc Description: This is a digitally signed message part. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Calling function with unknown number and type arguments
I have to write a function which calls a function with unknown (i.e. given in runtime) number and type of arguments. 1. Use closure implementation from Gtk2Hs. Pros: Written Cons: Not in haskell 2. Use unsafeCoerce. Something like: f a b = return (a + b) f' = unsafeCoerce (f :: Int - Int - IO Int) :: IO () unsafeCoerce (unsafeCoerce ((unsafeCoerce f' :: Int - IO ()) 5) :: Int - IO ()) 4 :: IO Int (of course it is an example in fact it will be not only Int etc.) Personally I'd prefere in-haskell solution as: - Rts API used by Gtk2Hs is 'semi-public' - It is GHC-specific (?) but I'm not sure if my solution is safe. Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Blank definition list in haddock
I read in haddock documentation that we write
definition lists like this:
-- [...@something@] Definition of something.
However, using that structure to document many
itens, I get a blank list of definitions, like
you can see in this section ('Macros') of the
documentation for a package of mine:
http://hackage.haskell.org/packages/archive/bindings-common/0.2.2/doc/html/Bindings.html#3
However, as can be seen in the source code, there
are many definitions inside 'Macros' section.
http://hackage.haskell.org/packages/archive/bindings-common/0.2.2/doc/html/src/Bindings.html
Did I used those definitons the wrong way?
Thanks,
Maurício
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: DDC compiler and effects; better than Haskell?
I forgot about links. In that case, consider: getUniqueFilesInDirRecursive. Attacking irrelevant details in an argument is often called a strawman attack. Such attacks are pointless because they do not address the real substance of the issue. My example is easily modified to avoid the issues you raise. Consider the fact that many file-based operations _can and are parallelized manually by developers_. The challenge for next generation language and effect system designers is to figure out _how_ such operations can be automatically parallelized, given sufficient constraints, high-level constructs, and a powerful effect system. Saying, I don't know exactly how it will look, is quite a bit different from saying It can't be done. I claim the former. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 16, 2009, at 12:38 AM, Artem V. Andreev wrote: John A. De Goes j...@n-brain.net writes: On Aug 15, 2009, at 6:36 AM, Jason Dusek wrote: 2009/08/14 John A. De Goes j...@n-brain.net: Hmmm, my point (perhaps I wasn't clear), is that different effects have different commutability properties. In the case of a file system, you can commute two sequential reads from two different files. I think this is a bad example -- it's not something that's safe in general and discredits your idea. How would the compiler even know that two files are not actually the same file? I don't think the file system is the best example. However, I do think it's a reasonable one. Let's say the type of the function getFilesInDir is annotated in such a way as to tell the effect system that every file in the returned array is unique. Further, let's say the type of the function makeNewTempFile is annotated in such a way as to tell the effect system that the function will succeed in creating a new temp file with a name unique from any other existing file. Sorry, but this example is ridiculuous. While file *names* in this case might be reasonably assumed to be unique, the *files* themselves may not. Any modern filesystem does support file aliasing, and usually several forms thereof. And what does makeNewTempFile function do? Does it create a new file like POSIX mktemp() and return its name, or does it rather behave as POSIX mkstemp()? The first case is a well known security hole, and the second case does not, as it seems to me, fit well into the rest of your reasoning. However, let's consider further file system tree traversal. In some cases you might not care, whether some of the directories you descend into are actually the same directory, so your proposed optimization would be `safe'. However, in other cases sequential traversal would work, while a parallelized version would not, unless special additional measures are taken. E.g. consider a case of a build system. It traverses a source tree, finds sources files and if corresponding object files are non-existent or outdated, does something to regenerate them. Now if you have a directory that's actually a link to another directory, and you do sequential traversal, everything is fine: you descend into the directory the first time, build everything there and when you descend into it the second time, there's just nothing to do. If you do parallel traversal, you may well end up in the situation where two threads check simultaneously for an object file, discover it's outdated and run two build processes simultaneously, with the most likely effect of corrupted object file. Then if you write a recursive function that loops through all files in a directory, and for each file, it parses and compiles the file into a new temp file, then a sufficiently sophisticated compiler should be able to safely transform the recursion into parallel parsing and compilation -- in a way that's provably correct, assuming the original program was correct. The promise of a language with a purely functional part and a powerful effect system for everything else is very great. And very important in the massively concurrent world we are entering. Well, yes -- which sounds like, there are no guarantees in general. Something that works half the time leaves you with two responsibilities -- the old responsibility of the work you did when you didn't have it and the new responsibility of knowing when it applies and when it doesn't. In the other thread, I brought up the example of buffering reads. Library authors make the decision to buffer for one reason: because if some other program is messing with the data, you're screwed no matter what. And yeah, they might be screwing with the data in just the way you need it to be screwed with, (Sebastian), in which case my advice is use C and hope for the best. :-) Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101
Re: [Haskell-cafe] Blank definition list in haddock
2009/8/16 Maurício CA mauricio.antu...@gmail.com:
I read in haddock documentation that we write
definition lists like this:
-- �...@something@] Definition of something.
However, using that structure to document many
itens, I get a blank list of definitions, like
you can see in this section ('Macros') of the
documentation for a package of mine:
http://hackage.haskell.org/packages/archive/bindings-common/0.2.2/doc/html/Bindings.html#3
However, as can be seen in the source code, there
are many definitions inside 'Macros' section.
http://hackage.haskell.org/packages/archive/bindings-common/0.2.2/doc/html/src/Bindings.html
Did I used those definitons the wrong way?
I think the problem is that you have written normal comments instead
of Haddock comments. Try adding a | in front of the paragraphs, or
just merge them all into one Haddock comment by inserting -- in
front of the blank lines in between your paragraphs.
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: DDC compiler and effects; better than Haskell?
I chose this example specifically because parsing/compiling is not IO- bound. Many build systems today achieve multi-core scaling by parallelizing all the phases: parsing, semantic analysis, and compilation. Your question is a good one and one we face already in auto- parallelization of purely functional code: how do you know when the cost of doing something in another thread is overwhelmed by the benefit? I think JIT compilation provides the ultimate answer to these types of questions, because you can make guesses, and if you get them wrong, simply try again. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 16, 2009, at 2:46 AM, Marcin Kosiba wrote: Hi, IMHO, provided with a flexible effect system, the decision on how to do read/write operations on files is a matter of libraries. But I'd like to ask another question: is the effects system you're discussing now really capable of providing significant performance improvements in case of file I/O? Even if we assume some consistency model and transform one correct program to another one -- how do you estimate efficiency without knowledge of physical media characteristics? I kinda see how this could be used to optimize different kinds of media access (reordering socket/ file operations or even running some of those in parallel), but I don't see how can we benefit from reordering writes to the same media. Another thing is that not every kind of r/w operation requires the same consistency model -- like when I'm writing a backup for later use I only care about my writes being in the same order. I imagine that such an effect system could help write software for CC-NUMA architectures or shared-memory distributed systems. -- Thanks! Marcin Kosiba ___ 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: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Aug 15, 2009, at 5:32 PM, Sebastian Sylvan wrote: On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes j...@n-brain.net wrote: You must think I'm arguing for some kind of low-level analog of C, augmented with an effect system. I'm not. You can't do that. No, I don't. I think you're arguing for making access to mutable state commutative. Are you not? There are many cases when mutation to state _is_ commutative. I can't argue that certain operations are _always_ commutative without talking about the language. Pretend I'm arguing for a mostly functional language and effect system that maximize the opportunities for parallelizing code. I'm not saying you shouldn't parallelise them in very specific circumstances *where it's safe*, I'm just saying that you shouldn't assume that it's safe unless you know it is. If you want to do a transformation that's unsafe in general, but safe in a specific circumstance, then of course, go ahead! To my reading it seems like you're arguing that memory/file access should *always* be considered commutative though, which is what I'm objecting too. In the right language, many times of memory (and possibly file) operations _always_ commute. In the wrong language, they _sometimes_ commute or _never_ provably commute. I'm not arguing for the assumption in any language where it is false. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for Comments - hscurrency 0.0.1
@Jason I'm not sure what you mean about exposing the type information. Unless you mean that each currency would be a separate type somehow. While this is a similar problem to the dimensional issue, the problem is that the FX rates are changing all the time. While the conversion between a meter and a foot is always constant, with FX rates thats not the case. So 2ft + 3m is always a well defined value but something like USD 1 + JPY 1 gives a function of the USDJPY exchange rate, not a constant value. @ Antoine I'll add some comments. you're right that doubles are not typically used nor would they be in a finished product. for the time being, however, I dont know if its better to use Ratio's, Fixed's or what, so just settled on the most straightforward for now. On Aug 16, 2009, at 1:26 AM, Jason Dagit wrote: On Sat, Aug 15, 2009 at 5:15 AM, Max Cantor mxcan...@gmail.com wrote: Hi all, I'm putting together some simple tools to do safe calculations on different currencies. For instance, making sure that you dont add something like 5 USD + 10 JPY without doing a proper conversion. I've put up some code on google code which probably explains what I'm trying to do more succinctly than this email. I'm curious what poeple think about the library, its the first haskell code I've written for the purpose of sharing and I intend to add it to hackage once I finalize the interface a bit more. The code is at: http://bit.ly/1Cjjlj I'm very open to suggestions on improving the interface. RIght now its very simple and straightforward but potentially limited. Right now it looks like you have taken the approach of embedded domain specific language. You have not exposed the currency units to the type system. Therefore you rely on the rules of your embedded language to do proper conversions. Have you considered exposing the type information to the type checker? A similar question came up recently on a Portland functional programming mailing list and my reply can be found here: http://groups.google.com/group/pdxfunc/tree/browse_frm/month/2009-08/5c565768ecf30c57?rnum=1_done=%2Fgroup%2Fpdxfunc%2Fbrowse_frm%2Fmonth%2F2009-08%3F#doc_5c565768ecf30c57 The experimental code which resulted is here: http://gist.github.com/165691 You may also want to look at the dimensional package: http://code.google.com/p/dimensional/ Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Sun, Aug 16, 2009 at 2:50 PM, John A. De Goes j...@n-brain.net wrote: On Aug 15, 2009, at 5:32 PM, Sebastian Sylvan wrote: On Sun, Aug 16, 2009 at 12:18 AM, John A. De Goes j...@n-brain.net wrote: You must think I'm arguing for some kind of low-level analog of C, augmented with an effect system. I'm not. You can't do that. No, I don't. I think you're arguing for making access to mutable state commutative. Are you not? There are many cases when mutation to state _is_ commutative. I can't argue that certain operations are _always_ commutative without talking about the language. Pretend I'm arguing for a mostly functional language and effect system that maximize the opportunities for parallelizing code. I'm not saying you shouldn't parallelise them in very specific circumstances *where it's safe*, I'm just saying that you shouldn't assume that it's safe unless you know it is. If you want to do a transformation that's unsafe in general, but safe in a specific circumstance, then of course, go ahead! To my reading it seems like you're arguing that memory/file access should *always* be considered commutative though, which is what I'm objecting too. In the right language, many times of memory (and possibly file) operations _always_ commute. In the wrong language, they _sometimes_ commute or _never_ provably commute. I'm not arguing for the assumption in any language where it is false. Well now I'm confused. Earlier you said: In the case of a file system, you can commute two sequential reads from two different files. This has no effect on the result of the computation, assuming no interference from other programs -- and if there _is_ interference from other programs, then guarantees go out the window, _with or without_ commuting. It's the assuming no interference form other programs that bugs me, because when you're reading outside data you kind of have to assume that there *is* outside interference because you can't really protect yourself against it. Furthermore, that interference is often more like cooperation/communication so you're actually *counting* on outside interference. E.g. consider durable storage that have to survive random reboots etc., I'm sure there are quite a few very carefully considered sequential steps that need to happen in just the right order to get a consistent view of the data when you read it back in. That earlier quote seems to imply that you're arguing for just treating all file reads as commutative and just ignoring that this is an unsafe assumption. If you no longer think this then I guess we're in agreement. My point is that *if* there is any chance for outside access to anything you're reading, then ordering *does* matter. This is the case for file reads, and may be the case for memory reads. For the latter the compiler could *potentially* figure out when memory can't be touched by other threads and make them commute, but I still think the semantics for mutable code should be sequential (since it unifies the two scenarios), and then the compiler might make them commutative in scenarios where it's guaranteed to be safe. For file reads, I don't think there's a way of knowing that two file reads are independent, especially since this dependency might live *outside* the program (e.g. the dependency might only exist for the human reading the output of the program). So really, if there's any chance something else might touch your data, the only reasonably safe way to deal with it is to enforce sequentiality. -- Sebastian Sylvan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: DDC compiler and effects; better than Haskell?
John A. De Goes j...@n-brain.net writes: I forgot about links. In that case, consider: getUniqueFilesInDirRecursive. Attacking irrelevant details in an argument is often called a strawman attack. Such attacks are pointless because they do not address the real substance of the issue. My example is easily modified to avoid the issues you raise. Consider the fact that many file-based operations _can and are parallelized manually by developers_. The challenge for next generation language and effect system designers is to figure out _how_ such operations can be automatically parallelized, given sufficient constraints, high-level constructs, and a powerful effect system. Saying, I don't know exactly how it will look, is quite a bit different from saying It can't be done. I claim the former. Regards, I am sorry, but it's not about details, but about the essence. My point was that there are a lot of subtle issues when we're dealing with (e.g.) a file system in a real-world manner. I have no doubt that it is possible to develop a sound logical system that would cover them and then encode it as a part of the type system of a language. That will probably lead to compile-time detection of a wider class of errors. But the problem is that one (IMHO) cannot deal with these subtleties in a generic manner. That is, there are things that may be done in parallel, and there are things that may not -- and it depends on the actual task you want to perform. So basically instead of manually parallelizing something, you'll (IMHO) end up writing complex type annotations so that a compiler could parallelize it on its own behalf. As somebody who have a certain experience with formal methods, I doubt that the latter will ever be simplier than the former. John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 16, 2009, at 12:38 AM, Artem V. Andreev wrote: John A. De Goes j...@n-brain.net writes: On Aug 15, 2009, at 6:36 AM, Jason Dusek wrote: 2009/08/14 John A. De Goes j...@n-brain.net: Hmmm, my point (perhaps I wasn't clear), is that different effects have different commutability properties. In the case of a file system, you can commute two sequential reads from two different files. I think this is a bad example -- it's not something that's safe in general and discredits your idea. How would the compiler even know that two files are not actually the same file? I don't think the file system is the best example. However, I do think it's a reasonable one. Let's say the type of the function getFilesInDir is annotated in such a way as to tell the effect system that every file in the returned array is unique. Further, let's say the type of the function makeNewTempFile is annotated in such a way as to tell the effect system that the function will succeed in creating a new temp file with a name unique from any other existing file. Sorry, but this example is ridiculuous. While file *names* in this case might be reasonably assumed to be unique, the *files* themselves may not. Any modern filesystem does support file aliasing, and usually several forms thereof. And what does makeNewTempFile function do? Does it create a new file like POSIX mktemp() and return its name, or does it rather behave as POSIX mkstemp()? The first case is a well known security hole, and the second case does not, as it seems to me, fit well into the rest of your reasoning. However, let's consider further file system tree traversal. In some cases you might not care, whether some of the directories you descend into are actually the same directory, so your proposed optimization would be `safe'. However, in other cases sequential traversal would work, while a parallelized version would not, unless special additional measures are taken. E.g. consider a case of a build system. It traverses a source tree, finds sources files and if corresponding object files are non-existent or outdated, does something to regenerate them. Now if you have a directory that's actually a link to another directory, and you do sequential traversal, everything is fine: you descend into the directory the first time, build everything there and when you descend into it the second time, there's just nothing to do. If you do parallel traversal, you may well end up in the situation where two threads check simultaneously for an object file, discover it's outdated and run two build processes simultaneously, with the most likely effect of corrupted object file. Then if you write a recursive function that loops through all files in a directory, and for each file, it parses and compiles the file into a new temp file, then a sufficiently sophisticated compiler should be able to safely transform the recursion into parallel parsing and compilation -- in a
[Haskell-cafe] simple hsql question
Hi I wanted to see what access to databases HSQL provides and I stumbled in the very beginning. Assume I have a table map1 with attributes i and s interger and varchar() respectively. The following code fails (with segfault) for me. And I see no other way to tell compiler that I am expecting an interger to be found as 'i' in a fetched row. import Database.HSQL import Database.HSQL.MySQL main :: IO () main = do c - connect localhost tx_test sacha s - query c SELECT i FROM map1 print $ getFieldsTypes s i - (getFieldValue s i)::IO Int print i disconnect c -- Alexander Kotelnikov Saint-Petersburg, Russia ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Calling function with unknown number and type arguments
On Aug 16, 2009, at 06:45 , Maciej Piechotka wrote: I have to write a function which calls a function with unknown (i.e. given in runtime) number and type of arguments. Take a look at the implementation of Text.Printf. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Blank definition list in haddock
I read in haddock documentation that we write definition lists like this: [...] Did I used those definitons the wrong way? I think the problem is that you have written normal comments instead of Haddock comments. Try adding a | in front of the paragraphs, or just merge them all into one Haddock comment by inserting -- in front of the blank lines in between your paragraphs. OK. Sent the patch below to haddock maintainer. Thanks, Maurício %%% titleParagraphs/title - paraOne or more blank lines separates two paragraphs in a - documentation comment./para +paraOne or more blank lines separate two paragraphs in a +documentation comment. Such blank lines, though, should +still be commented, or they would interrupt Haddock +documentation./para /section %%% ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Calling function with unknown number and type arguments
On Sun, Aug 16, 2009 at 17:00, Brandon S. Allbery wrote:
On Aug 16, 2009, at 06:45 , Maciej Piechotka wrote:
I have to write a function which calls a function with unknown (i.e.
given in runtime) number and type of arguments.
Take a look at the implementation of Text.Printf.
Or Text.XFormat.Show in xformat while you're at it. (Warning: blatant
self-promoting.)
http://hackage.haskell.org/package/xformat
From the tests in the package:
showf (Show % Int % String) 4.05 20 blah == 4.0520 blah
showf (Wrap '(' Int ')') 24 == (24)
Sean
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: GLUT 2.2.1.0
Thanks Sven! BTW, as an enhancement for 2.2.2.0, you could treat unnamed mouse buttons. Mouses with more axis and more buttons are becoming increasingly common, and unmarshalMouseButton is not prepared to accept them!! Here are exceptions I caught, playing with my Genius Traveler 515 mouse: unmarshalMouseButton: illegal value 5 unmarshalMouseButton: illegal value 6 unmarshalMouseButton: illegal value 7 unmarshalMouseButton: illegal value 8 Anyway, keep the good work! Best Regards, Rafael On Sun, Aug 16, 2009 at 13:12, Sven Panne sven.pa...@aedion.de wrote: A new version of the GLUT package has been uploaded to Hackage. * The package is now autoconf-free. API entries are resolved dynamically at runtime, just like the OpenGLRaw and GLURaw packages. * Support for sRGB framebuffers has been added, just use SRGBMode with initialDisplayMode. To use this functionality, you need the upcoming freeglut 2.6.0 library, older versions and classic GLUT do not support this feature. * Support for context profiles has been added via initialContextProfile. Again, this works with the upcoming freeglut 2.6.0 library only. Cheers, S. ___ Haskell mailing list hask...@haskell.org http://www.haskell.org/mailman/listinfo/haskell -- Rafael Gustavo da Cunha Pereira Pinto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Request for comments - hdnsomatic
Hello haskellers, I just finished my first useful haskell program and I'd be glad if you make me some comments http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8244#a8244 Thank you, and sorry for my english. Piensa y trabaja Jesús Alberto Sánchez Pimienta Estudiante de la Lic. en Estudios Políticos y Gobierno Universidad de Guadalajara ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for comments - hdnsomatic
Hi An easy way to get some instant feedback is to run HLint on it: http://community.haskell.org/~ndm/hlint The results are: C:\Neil\hlinthlint Example.hs Example.hs:42:1: Warning: Use liftM Found: readFile p = return . lines = return . map (second tail . break (== '=') . filter (/= ' ')) Why not: liftM (map (second tail . break (== '=') . filter (/= ' '))) (readFile p = return . lines) Example.hs:42:1: Warning: Use liftM Found: readFile p = return . lines Why not: liftM lines (readFile p) Found 2 suggestions So using liftM instead of = return might be better style. You can also make minor tweaks like: if null args then readConfig defaultConfig else readConfig (head args) == readConfig $ if null args then defaultConfig else head args currentIP - catch (getIPAddress webIP) (\e - syslog Error (show e) return 0) oldIP - catch (S.readFile ipCache) (\e - syslog Error (show e) return 0) == let catch_ x = catch x (\e - syslog Error (show e) return 0) currentIP - catch_ $ getIPAddress webIP oldIP - catch_ (S.readFile ipCache) And there's no need to exitSuccess at the end of main, exitSuccess is the default. Thanks Neil 2009/8/16 Jesús Alberto Sánchez Pimienta jesusalbertosanc...@gmail.com: Hello haskellers, I just finished my first useful haskell program and I'd be glad if you make me some comments http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8244#a8244 Thank you, and sorry for my english. Piensa y trabaja Jesús Alberto Sánchez Pimienta Estudiante de la Lic. en Estudios Políticos y Gobierno Universidad de Guadalajara ___ 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] Request for comments - hdnsomatic
Many Thanks Neil, I tried to build hlint before submitting to the mail list but i couldn't because my haskell-src-exts is version 1.1.1 and the cabal file of hlint requires a version 1.1. Now i modified the cabal depends and successfully installed hlint, it's a great tool. Piensa y trabaja Jesús Alberto Sánchez Pimienta Estudiante de la Lic. en Estudios Políticos y Gobierno Universidad de Guadalajara 2009/8/16 Neil Mitchell ndmitch...@gmail.com Hi An easy way to get some instant feedback is to run HLint on it: http://community.haskell.org/~ndm/hlinthttp://community.haskell.org/%7Endm/hlint The results are: C:\Neil\hlinthlint Example.hs Example.hs:42:1: Warning: Use liftM Found: readFile p = return . lines = return . map (second tail . break (== '=') . filter (/= ' ')) Why not: liftM (map (second tail . break (== '=') . filter (/= ' '))) (readFile p = return . lines) Example.hs:42:1: Warning: Use liftM Found: readFile p = return . lines Why not: liftM lines (readFile p) Found 2 suggestions So using liftM instead of = return might be better style. You can also make minor tweaks like: if null args then readConfig defaultConfig else readConfig (head args) == readConfig $ if null args then defaultConfig else head args currentIP - catch (getIPAddress webIP) (\e - syslog Error (show e) return 0) oldIP - catch (S.readFile ipCache) (\e - syslog Error (show e) return 0) == let catch_ x = catch x (\e - syslog Error (show e) return 0) currentIP - catch_ $ getIPAddress webIP oldIP - catch_ (S.readFile ipCache) And there's no need to exitSuccess at the end of main, exitSuccess is the default. Thanks Neil 2009/8/16 Jesús Alberto Sánchez Pimienta jesusalbertosanc...@gmail.com: Hello haskellers, I just finished my first useful haskell program and I'd be glad if you make me some comments http://hpaste.org/fastcgi/hpaste.fcgi/view?id=8244#a8244 Thank you, and sorry for my english. Piensa y trabaja Jesús Alberto Sánchez Pimienta Estudiante de la Lic. en Estudios Políticos y Gobierno Universidad de Guadalajara ___ 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: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
On Aug 15, 2009, at 2:55 PM, John A. De Goes wrote: If you don't like the file system, consider mutable memory. An effect system will tell me I can safely update two pieces of non- overlapping, contiguous memory concurrently, even in different threads if the complexity so justifies it. The IO monad is a poor man's solution to the problem of effects. In the presence of out-of-order memory writes, write buffers, caches, c, I'm not going to contradict you, but it certainly isn't as _obvious_ as it used to be. I've come across an experimental microprocessor where I _think_ it isn't safe if you have +- data 1 | data 2 ++ cache line whether that's so on any other processor is beyond my expertise. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Calling function with unknown number and type arguments
On Sun, Aug 16, 2009 at 3:07 PM, Sean Leatherleat...@cs.uu.nl wrote:
On Sun, Aug 16, 2009 at 17:00, Brandon S. Allbery wrote:
On Aug 16, 2009, at 06:45 , Maciej Piechotka wrote:
I have to write a function which calls a function with unknown (i.e.
given in runtime) number and type of arguments.
Take a look at the implementation of Text.Printf.
Or Text.XFormat.Show in xformat while you're at it. (Warning: blatant
self-promoting.)
http://hackage.haskell.org/package/xformat
From the tests in the package:
showf (Show % Int % String) 4.05 20 blah == 4.0520 blah
showf (Wrap '(' Int ')') 24 == (24)
But with those, the number of arguments is still known at compile time, correct?
Antoine
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: DDC compiler and effects; better than Haskell? (was Re: [Haskell-cafe] unsafeDestructiveAssign?)
In the presence of _uncontrolled concurrency_, you are correct, but uncontrolled concurrency is a failed paradigm littered with defective software. Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Aug 16, 2009, at 5:32 PM, Richard O'Keefe wrote: On Aug 15, 2009, at 2:55 PM, John A. De Goes wrote: If you don't like the file system, consider mutable memory. An effect system will tell me I can safely update two pieces of non- overlapping, contiguous memory concurrently, even in different threads if the complexity so justifies it. The IO monad is a poor man's solution to the problem of effects. In the presence of out-of-order memory writes, write buffers, caches, c, I'm not going to contradict you, but it certainly isn't as _obvious_ as it used to be. I've come across an experimental microprocessor where I _think_ it isn't safe if you have +- data 1 | data 2 ++ cache line whether that's so on any other processor is beyond my expertise. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Request for Comments - hscurrency 0.0.1
Hello, To let the type checker do some work for you, without getting all the way into the territory of the dimensional package, you can use newtypes and a Units class with methods for wrapping and unwrapping Doubles; we use this approach at work and find it strikes a nice balance between useful (static typechecking) and usable (unobtrusive to introduce to existing codebase). Just as in your code, conversions are written explicitly by us and can change when needed (with a recompile), or can require an IO action to make use of changing data. -Jeff On Sun, Aug 16, 2009 at 9:55 AM, Max Cantormxcan...@gmail.com wrote: @Jason I'm not sure what you mean about exposing the type information. Unless you mean that each currency would be a separate type somehow. While this is a similar problem to the dimensional issue, the problem is that the FX rates are changing all the time. While the conversion between a meter and a foot is always constant, with FX rates thats not the case. So 2ft + 3m is always a well defined value but something like USD 1 + JPY 1 gives a function of the USDJPY exchange rate, not a constant value. @ Antoine I'll add some comments. you're right that doubles are not typically used nor would they be in a finished product. for the time being, however, I dont know if its better to use Ratio's, Fixed's or what, so just settled on the most straightforward for now. On Aug 16, 2009, at 1:26 AM, Jason Dagit wrote: On Sat, Aug 15, 2009 at 5:15 AM, Max Cantor mxcan...@gmail.com wrote: Hi all, I'm putting together some simple tools to do safe calculations on different currencies. For instance, making sure that you dont add something like 5 USD + 10 JPY without doing a proper conversion. I've put up some code on google code which probably explains what I'm trying to do more succinctly than this email. I'm curious what poeple think about the library, its the first haskell code I've written for the purpose of sharing and I intend to add it to hackage once I finalize the interface a bit more. The code is at: http://bit.ly/1Cjjlj I'm very open to suggestions on improving the interface. RIght now its very simple and straightforward but potentially limited. Right now it looks like you have taken the approach of embedded domain specific language. You have not exposed the currency units to the type system. Therefore you rely on the rules of your embedded language to do proper conversions. Have you considered exposing the type information to the type checker? A similar question came up recently on a Portland functional programming mailing list and my reply can be found here: http://groups.google.com/group/pdxfunc/tree/browse_frm/month/2009-08/5c565768ecf30c57?rnum=1_done=%2Fgroup%2Fpdxfunc%2Fbrowse_frm%2Fmonth%2F2009-08%3F#doc_5c565768ecf30c57 The experimental code which resulted is here: http://gist.github.com/165691 You may also want to look at the dimensional package: http://code.google.com/p/dimensional/ Jason ___ 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] Uncontrolled Concurrency, isn't that concept now thread-bare?
-- Regards, Casey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Calling function with unknown number and type arguments
On Sunday 16 August 2009 8:35:19 pm Antoine Latter wrote:
But with those, the number of arguments is still known at compile time,
correct?
{-# LANGUAGE Rank2Types #-}
import Text.Printf
import System.Environment
nprintf :: PrintfType t = Int - Int - t
nprintf n e = aux (printf str) n
where
str = concat $ replicate n %d
aux :: PrintfType t' = (forall t. PrintfType t = t) - Int - t'
aux pf 0 = pf
aux pf n = aux (pf e) (n-1)
main = do (n:e:_) - map read `fmap` getArgs
nprintf n e :: IO ()
% ./Var 2 5
55
% ./Var 6 5
55
Voila.
-- Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Calling function with unknown number and type arguments
On Sun, Aug 16, 2009 at 8:50 PM, Dan Doeldan.d...@gmail.com wrote: On Sunday 16 August 2009 8:35:19 pm Antoine Latter wrote: But with those, the number of arguments is still known at compile time, correct? snip! % ./Var 2 5 55 % ./Var 6 5 55 Voila. Ah! Very nice. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: compose-trans-0.0
Just uploaded compose-trans-0.0 to Hackage. 'compose-trans' is a small library intended to make monad transformers composable. It provides a class TransM, derived from MonadTrans, which is closed under composition - that is, if t1 and t2 are instances of TransM, then (t2 :. t1) is also an instance of TransM (and, therefore, an instance of MonadTrans), and the type ((t2 :. t1) m x) is isomorphic to (t2 (t1 m) x). It's fairly easy to make a new transformer an instance of TransM; it only takes one short line of code. There are also TransP and TransF classes, that help dealing with MonadPlus and MonadFix instances. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
