Re: [Haskell-cafe] createProcess fails to find executable in Windows
What if you ran the program from within the directory that contains git.exe? Can you check that the PATH environment variable is set correctly from within the program? On Thu, Oct 25, 2012 at 10:05 PM, José Pedro Magalhães j...@cs.uu.nl wrote: Hi all, Consider the following program: module Test where import System.Process (readProcess) main :: IO () main = readProcess git [describe, --tags] = putStr In Windows I get the following behaviour: git --version git version 1.7.10.msysgit.1 ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.1 runghc Test Test: git: createProcess: does not exist (No such file or directory) The same happens with GHC 7.4.2. In Linux, however, it works as expected: $ git --version git version 1.7.9.5 $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 $ runghc Test.hs Package-2.0-68-gacaf77a Can anyone reproduce this result in Windows? Is this a bug or am I doing something wrong? Thanks, Pedro ___ 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] If you'd design a Haskell-like language, what would you do different?
IIRC, Scite's default configuration is with non-monospace font. I actually found it quite appealing, and in fact forgot about it entirely after some usage. It is much easier on the eyes to read. The difference is really whether you care about aligning things mid-line or not, not to mention editor support (i.e. not Vim or other terminal-based editor). On Wed, Dec 21, 2011 at 8:58 PM, Hans Aberg haber...@telia.com wrote: On 21 Dec 2011, at 04:27, Ashok Gautham wrote: On Tue, Dec 20, 2011 at 11:17:32PM +0100, Hans Aberg wrote: The monospace characters U+1D670-1D6A3 might be used for keywords. Font: http://www.stixfonts.org/ I feel that monospace fonts should be used for all of programming. A language could use Unicode symbols, but if it enforces typography, it is destined to win an award for being really unusable I have some books from the 1980s which does not use monospace; it seems to be a later movement. Using it for all symbols would be awkward. Hans ___ 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] If you'd design a Haskell-like language, what would you do different?
On Tue, Dec 20, 2011 at 8:46 PM, Ben Lippmeier b...@ouroborus.net wrote: On 20/12/2011, at 6:06 PM, Roman Cheplyaka wrote: * Alexander Solla alex.so...@gmail.com [2011-12-19 19:10:32-0800] * Documentation that discourages thinking about bottom as a 'value'. It's not a value, and that is what defines it. In denotational semantics, every well-formed term in the language must have a value. So, what is a value of fix id? There isn't one! Bottoms will be the null pointers of the 2010's, you watch. This ×1000. Errors go in an error monad. Ben. ___ 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] If you'd design a Haskell-like language, what would you do different?
On Tue, Dec 20, 2011 at 9:34 PM, Gregory Crosswhite gcrosswh...@gmail.comwrote: On Dec 20, 2011, at 8:30 PM, Jesse Schalken wrote: On Tue, Dec 20, 2011 at 8:46 PM, Ben Lippmeier b...@ouroborus.net wrote: On 20/12/2011, at 6:06 PM, Roman Cheplyaka wrote: In denotational semantics, every well-formed term in the language must have a value. So, what is a value of fix id? There isn't one! Bottoms will be the null pointers of the 2010's, you watch. This ×1000. Errors go in an error monad. Including all possible manifestations of infinite loops? Definitely. If you think a value might not reduce, return an error in an error monad. Then the caller is forced to handle the case of an error, or propagate the error upwards. The error can also be handled in pure code this way, whereas bottom can only be handled within the IO monad. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On Tue, Dec 20, 2011 at 9:47 PM, Gregory Crosswhite gcrosswh...@gmail.comwrote: On Dec 20, 2011, at 8:40 PM, Jesse Schalken wrote: If you think a value might not reduce, return an error in an error monad. Okay, I'm completely convinced! Now all that we have to do is to solve the halting problem to make your solution work... :-) Why do you have to solve the halting problem? Consider integer division by 0. intDiv x y = if y x then 0 else 1 + (intDiv (x - y) y) This is correct, but does not reduce with y = 0. The Prelude version returns bottom in this case. Here is a version that returns an error in an Either String. intDiv :: (Ord a, Num a) = a - a - Either String a intDiv _ 0 = Left Division by 0! intDiv x y = if y x then Right 0 else intDiv (x - y) y = (Right . (1 +)) This is all I was talking about. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On Tue, Dec 20, 2011 at 10:43 PM, Gregory Crosswhite gcrosswh...@gmail.comwrote: On Dec 20, 2011, at 9:18 PM, Jesse Schalken wrote: Why do you have to solve the halting problem? You have to solve the halting problem if you want to replace every place where _|_ could occur with an Error monad (or something similar), because _|_ includes occasions when functions will never terminate. I think we're talking about different things. By bottom I mean the function explicitly returns error ... or undefined. In those cases, it should go in an error monad instead. In cases where there is an infinite loop, the function doesn't return anything because it never finishes, and indeed this separate problem will never be solved while remaining Turing complete because it is the halting problem. Consider integer division by 0. [...] This is all I was talking about. But imagine there was an occasion where you *knew* that the divisor was never zero --- say, because the divisor was constructed to be a natural number. Then use a separate type for natural numbers excluding 0. Then you can define a total integer division function on it (although the return value may be zero and so needs a different type). Now there is no point in running in the Error monad because there will never such a runtime error; in fact, it is not clear what you would even *do* with a Left value anyway, short of terminating the program and printing and error, which is what would have happened anyway. What you do with a Left value is up to you - that's the point, you now have a choice. In fact, the value might not even be being handled by you, in which case someone else now has a choice. Handling of the error is done in the same place as handling of the result, no IO needed. Furthermore, it is easy to imagine circumstances where you have now forced your entire program to run in the Error monad, which makes everything incredibly inconvenient with no benefit at all. This inconvenience I imagine is the extra code required to compose functions which return values in a monad as opposed to straight values. To me this is a small price to pay for knowing my code won't randomly crash, and I would rather this be handled syntactically to make composing monadic values more concise. The point is your program shouldn't be able to make assumptions about values without proving them with types. It's often easier not to make the assumption and propagate some error in an error monad instead, but that's better than getting away with the assumption and having the program crash or behave erratically because the assumption turned out false. This is the problem with arguments against partial functions; they don't solve any problems at all except in the case where you have untrusted data in which case you should be using a different function or manually checking it anyway, and they add a lot of wasted overhead. The whole term untrusted data baffles me. How often can you actually trust your data? When you send your software out into the wild, what assumptions can you make about its input? What assumptions can you make about the input to a small part of a larger program which is millions of lines? You can often deduce that certain values do/do not occur in small parts of code, but the difficulty of such deductions increases exponentially with the size of the codebase, and is a job done much better by a type system. Also I would like to think this wasted overhead can be optimised away at some stage of compilation, or somehow removed without the programmer needing to think about it. Maybe I'm just dreaming on those fronts, however. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On Wed, Dec 21, 2011 at 1:09 AM, Gregory Crosswhite gcrosswh...@gmail.comwrote: On Dec 20, 2011, at 11:21 PM, Jesse Schalken wrote: On Tue, Dec 20, 2011 at 10:43 PM, Gregory Crosswhite gcrosswh...@gmail.com wrote: On Dec 20, 2011, at 9:18 PM, Jesse Schalken wrote: Why do you have to solve the halting problem? You have to solve the halting problem if you want to replace every place where _|_ could occur with an Error monad (or something similar), because _|_ includes occasions when functions will never terminate. I think we're talking about different things. By bottom I mean the function explicitly returns error ... or undefined. In those cases, it should go in an error monad instead. In cases where there is an infinite loop, the function doesn't return anything because it never finishes, and indeed this separate problem will never be solved while remaining Turing complete because it is the halting problem. Then honestly you should choose a different term because I am pretty certain that my use of the term bottom is the commonly accepted one which (among other places) appears in denotation semantics. I apologize if I was using the wrong terminology. I've seen error ... shown as, and understood it to be, _|_, but it seems _|_ refers to either a value that does not reduce or Haskell's error function depending on the context. Consider integer division by 0. [...] This is all I was talking about. But imagine there was an occasion where you *knew* that the divisor was never zero --- say, because the divisor was constructed to be a natural number. Then use a separate type for natural numbers excluding 0. Then you can define a total integer division function on it (although the return value may be zero and so needs a different type). That would certainly be a lovely idea *if* we were programming in Agda, but I was under the assumption that this conversation was about Haskell. :-) I don't have experience with proof assistants, but maybe my answer to this thread can be summed up as giving Haskell that kind of capability. ;) Now there is no point in running in the Error monad because there will never such a runtime error; in fact, it is not clear what you would even *do* with a Left value anyway, short of terminating the program and printing and error, which is what would have happened anyway. What you do with a Left value is up to you - that's the point, you now have a choice. Yes, but it is a pointless choice because if you had any reason to believe that your value was an invalid input to a function you would have checked it by now or used an alternative non-partial function that did run in an Error monad for that specific purpose. In fact, the value might not even be being handled by you, in which case someone else now has a choice. Handling of the error is done in the same place as handling of the result, no IO needed. Yes, but all that the user of your library knows at this point is that there is a bug somewhere in your library that violated an invariant. Nearly all of the time there is no way to recover from this in a useful way and so all the user will end up doing in response to your Left value is to abort anyway. What if for example the program is a server which is always running. If you use error ..., the server will crash, and someone has to go start it up again. The person who wrote the server has to remember to wrap each request in a try...catch block in the IO monad in the outer layer to make sure the server doesn't crash due to errors in pure code. What if they forget? If you use an error monad, they can't forget, because the type system forces them to handle the error. Maybe they will choose to exit in the case of an error, but at least then the program is crashing because they've explicitly told it to rather than because they forgot something. More likely they will respond to the request with an error response, allowing the server to continue running, but either way the type system has forced them to make a decision. The point is your program shouldn't be able to make assumptions about values without proving them with types. I agree but, again, we aren't talking about Agda here, we are talking about Haskell. :-) Now I really want to look at proof assistants! The whole term untrusted data baffles me. How often can you actually trust your data? All the time! For example, if I create a counter that starts at 1, only increase it, and give nobody else access to it, then I can be as certain as it is possible to be can be that it is not 0. Start your counter at 0 then. Then if you really don't want to deal with 0, treat 0 as 1 and 1 as 2 etc - hence a type for non-zero naturals. I think structuring code such that the types you use contain no useless or impossible values is often easy with a little thought, and worth it because the compiler is now verifying the assumptions you made. In cases where
Re: [Haskell-cafe] A Mascot
I like the idea of a mascot. I like the idea of a lamb called Da, as most of Haskell's strength comes from it's closeness to pure lambda calculus. A few things I'd like to see in a mascot: - Simple. You should be able to draw it in a few seconds. - Look good in black and white. - Have obvious features so it is identifiable from a distance. - Be a little bit cute. I don't see why ⊥ has to be featured. ⊥ means a computation can terminate without returning a value. That is a flaw, not a strength. If a computation may fail, return a Maybe or Either String. If a computation might not terminate, let it not terminate and I can find out why with my debugger. That covers all the use cases of ⊥. It also undermines the type system as beginners often write functions which return ⊥ where they should either be returning a Maybe or Either String, or expressing the violated precondition in the type system so it can be tested at compile time. What am I missing? On Wed, Nov 16, 2011 at 9:47 PM, Bas van Dijk v.dijk@gmail.com wrote: On 16 November 2011 11:05, MigMit miguelim...@yandex.ru wrote: Maybe it's just me, but I've thought that being non-strict just means that it's possible for a function to produce some value even if it's argument doesn't; in other words, that it's possible to have f (_|_) ≠ (_|_). If there was no such thing as (_|_), what would non-strictness mean? Thanks, non-strictness is indeed defined using ⊥ like you mentioned. I think I was confusing non-strict evaluation with coinduction. They have the same advantages but the latter is less powerful but safer than the former. Bas ___ 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] Problem on using class as type.
What about users :: ToJson a = a? On Tue, Oct 4, 2011 at 12:42 AM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hi, I have a function: post :: (ToJson p, FromJson q) = String - String - String - Map.Map String p - IO q Now I'd like to call it like: r - post site token user.addMedia (Map.fromList [ (users, users :: ToJson) , (medias, medias :: ToJson) ]) So I got the problem. If I used things like users :: ToJson, then class used as a type error occurred. But if I did not use them, since users and medias were actually different types, then fromList failed, required the type of medias the same with users. How to resolve the conflict? -- 竹密岂妨流水过 山高哪阻野云飞 ___ 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] Turn GC off
There might be a way to do it, I don't know, but this sounds like an XYhttp://www.perlmonks.org/index.pl?node_id=542341 problem http://mywiki.wooledge.org/XyProblem. Can I ask what you're trying to achieve by doing this, or is it just out of curiosity regarding how much garbage is created? (It's a lot, by the way. Since the only thing a purely functional program can do is create data and read data (as opposed to create, read and update in an impure program) I imagine a purely functional program without GC would hit OOM very, very quickly.) On Thu, Sep 15, 2011 at 2:42 AM, Andreas Voellmy andreas.voel...@gmail.com wrote: Hi everyone, Is there a way to completely turn garbage collection off in the Haskell runtime system? I'm aware of the -A runtime option, but I'd like to completely turn it off, if possible. I'm OK with running the program until it runs out of memory, and I'm willing to recompile GHC if needed. Regards, Andreas ___ 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] Uninstall Haskell Platform on Mac OS X
Simple question which an hour of googling and a question on #haskell couldn't satisfy. :( I have installed the Haskell Platform 2011.2.0.0 on Mac OS X 10.6.6. Now how do I *uninstall* it? Thanks, Jesse ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Uninstall Haskell Platform on Mac OS X
This leaves the symlinks alex, cabal, cabal.real, cabal.wrap and happy in /usr/bin, and also leaves /Library/Frameworks/HaskellPlatform.framework, and while I can remove those myself how can I be certain there isn't something else left behind? On Tue, Mar 15, 2011 at 1:31 AM, Anders Persson anders.cj.pers...@gmail.com wrote: This is what I do. At a terminal prompt: sudo /Library/Frameworks/GHC.framework/Versions/Current/Tools/Uninstaller sudo rm -r /Library/Haskell Cheers, Anders On Mar 14, 2011, at 3:22 PM, Jesse Schalken wrote: Simple question which an hour of googling and a question on #haskell couldn't satisfy. :( I have installed the Haskell Platform 2011.2.0.0 on Mac OS X 10.6.6. Now how do I *uninstall* it? Thanks, Jesse ___ 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] Uninstall Haskell Platform on Mac OS X
I have done this and it has only removed GHC, not the rest of the Haskell Platform. On Tue, Mar 15, 2011 at 1:40 AM, Daniël de Kok m...@danieldk.eu wrote: On Monday, March 14, 2011 at 3:22 PM, Jesse Schalken wrote: Simple question which an hour of googling and a question on #haskell couldn't satisfy. :( I have installed the Haskell Platform 2011.2.0.0 on Mac OS X 10.6.6. Now how do I uninstall it? sudo /Library/Frameworks/GHC.framework/Versions/Current/Tools/Uninstaller ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type System vs Test Driven Development
You need both. A good static type system will tell you whether or not the code is type-correct. It will not tell you whether or not it does what it's supposed to do. Consider: sort :: [a] - [a] If you change sort to be: sort = id It will still type check, but it obviously doesn't do what it's supposed to do anymore. You need tests to verify that. If you then change sort to be: sort _ = 5 Now it's also type-incorrect. Static typing will catch it at compile time (eg. Haskell will now infer the type as Num b = a - b which will not unify with [a] - [a]), and dynamic typing will likely throw some sort of type error at run time in the places it was previously used. (Any error thrown by the language itself, like PHP's Cannot call method on non-object or Python's TypeError or even Java's NullPointerException or C++'s Segmentation Fault can be considered a type error.) So with static typing, the machine will verify type-correctness, but you still need tests to verify the program meets its specification. With dynamic typing, you need tests to verify that the program meets both its specification *and* doesn't throw any type errors - so you need to test more. The fact that most errors in programming are type errors and that Haskell programs therefore tend to just work once you can get them past the type checker may lead you to believe you don't need to test at all. But you still do for the reasons above, you just need to test a hell of a lot less. On Wed, Jan 5, 2011 at 8:44 PM, Jonathan Geddes geddes.jonat...@gmail.comwrote: Cafe, In every language I program in, I try to be as disciplined as possible and use Test-Driven Development. That is, every language except Haskell. There are a few great benefits that come from having a comprehensive test suite with your application: 1. Refactoring is safer/easier 2. You have higher confidence in your code 3. You have a sort of 'beacon' to show where code breakage occurs Admittedly, I don't believe there is any magical benefit that comes from writing your tests before your code. But I find that when I don't write tests first, it is incredibly hard to go back and write them for 'completed' code. But as mentioned, I don't write unit tests in Haskell. Here's why not. When I write Haskell code, I write functions (and monadic actions) that are either a) so trivial that writing any kind of unit/property test seems silly, or are b) composed of other trivial functions using equally-trivial combinators. So, am I missing the benefits of TDD in my Haskell code? Is the refactoring I do in Haskell less safe? I don't think so. I would assert that there is no such thing as refactoring with the style of Haskell I described: the code is already super-factored, so any code reorganization would be better described as recomposition. When recomposing a program, its incredibly rare for the type system to miss an introduced error, in my experience. Am I less confidence in my Haskell code? On the contrary. In general, I feel more confident in Haskell code WITHOUT unit tests than code in other languages WITH unit tests! Finally, am I missing the error beacon when things break? Again I feel like the type system has got me covered here. One of the things that immediately appealed to me about Haskell is that the strong type system gives the feeling of writing code against a solid test base. The irony is that the type system (specifically the IO monad) force you to structure code that would be very easy to test because logic code is generally separated from IO code. I explained these thoughts to a fellow programmer who is not familiar with Haskell and his response was essentially that any language that discourages you from writing unit tests is a very poor language. He (mis)quoted: compilation [is] the weakest form of unit testing [0]. I vehemently disagreed, stating that invariants embedded in the type system are stronger than any other form of assuring correctness I know of. I know that much of my code could benefit from a property test or two on the more complex parts, but other than that I can't think that unit testing will improve my Haskell code/programming practice. Am I putting too much faith in the type system? [0] http://blog.jayfields.com/2008/02/static-typing-considered-harmful.html ___ 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] getting last char of String
On Sat, Jan 1, 2011 at 8:54 AM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Fri, Dec 31, 2010 at 6:43 PM, aditya siram aditya.si...@gmail.com wrote: -- untested and won't work on an infinite list last :: [a] - a last = head . reverse No definition for last works with infinite lists =). Unless you make the result nullable, of course. maybeLast :: [a] - Maybe a maybeLast [] = Nothing maybeLast [x] = Just x maybeLast (_:xs) = maybeLast xs Cheers, -- Felipe. ___ 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] getting last char of String
On Sat, Jan 1, 2011 at 8:39 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sat, 1 Jan 2011, Jesse Schalken wrote: On Sat, Jan 1, 2011 at 8:54 AM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: No definition for last works with infinite lists =). Unless you make the result nullable, of course. maybeLast :: [a] - Maybe a maybeLast [] = Nothing maybeLast [x] = Just x maybeLast (_:xs) = maybeLast xs How would this work for infinite lists? If your list is infinitely big, then reaching its end will take infinitely long. ;) It will loop forever, just like `last [1...]` does. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] getting last char of String
On Sat, Jan 1, 2011 at 10:06 PM, Jesse Schalken jesseschal...@gmail.comwrote: On Sat, Jan 1, 2011 at 8:39 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: On Sat, 1 Jan 2011, Jesse Schalken wrote: On Sat, Jan 1, 2011 at 8:54 AM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: No definition for last works with infinite lists =). Unless you make the result nullable, of course. maybeLast :: [a] - Maybe a maybeLast [] = Nothing maybeLast [x] = Just x maybeLast (_:xs) = maybeLast xs How would this work for infinite lists? If your list is infinitely big, then reaching its end will take infinitely long. ;) It will loop forever, just like `last [1...]` does. Oh, sorry. My participation in this thread can be safely ignored. I read No definition of last works for infinite lists as No definition of last works for empty lists, sorry. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ByteString or Text version of getDirectoryContents
Is there a ByteString or Text version of getDirectoryContents? I am writing a program which scans a filesystem and it runs out of memory using Strings for all the file names, and I would like to avoid the overhead of calling ByteString.pack on the results of getDirectoryContents. I don't mind if it only works on POSIX, but System.Posix.Directory.readDirStream returns a String as well, and looking at how readDirStream is implemented I am left puzzled as it looks like it is using calls to native C functions but I can't find where the C string is turned into a String so I can change it to a ByteString or Text. Thanks, Jesse ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Serialization of (a - b) and IO a
2010/11/11 Gábor Lehel illiss...@gmail.com Obviously there are questions here with regards to the functions which the to-be-serialized function makes use of -- should they be serialized along with it? Required to be present when it is deserialized? Is it OK for the function to do something different when it is loaded compared to when it was stored if its environment is different, or not OK? I would have say Yes, No, No. At the moment, when you serialise data structure A which references data structure B which references data structure C, using Data.Binary for example, the whole lot (A, B, and C) gets serialised, so that the resulting deserialization of A is denotationally equivalent to the original, regardless of the environment. I don't see why this shouldn't be the case for functions also. So a serialized function should include all its direct and indirect callees. This might result in potentially simple functions ending up enormous when serialized, simply because the call graph, including all it's libraries and their libraries etc, is that size, but such would be pure function serialization. This raises the question of what is left. The assembled machine code? For the architecture of the serializer or of the deserializer? Or LLVM IR for architecture independence? C--? Core? I don't know, but it would be awesome for the serialized representation to be both low-level and architecture independent, then having it JIT compiled when it is deserialized. To me, this means a virtual machine, which I guess is what you need when you want fast mobile code, but I'm just musing here as I know little about programming language implementation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Serialization of (a - b) and IO a
Is it possible to serialize and deserialize a function to/from binary form, perhaps using Data.Binary, for example? What about an IO action? If so, is there a way the serialized representation could be architecture-independent? I have been shown how useful it can be to store functions inside data structures, and while looking at data serialization for the purpose of persistence I wondered since functions are just values in Haskell, why can't we persist them, too?. To me the idea has interesting implications. For example, an arbitrary program could simply be represented by a serialization of `IO ()`. In fact, you could load any program into memory from a file and use Control.Concurrent.forkIO to run it, and later kill it, giving you the beginnings of an operating environment. If such a serialization is architecture independent then to my understanding you have the beginnings of a virtual machine. You could break your program into pieces and store them in a database and load them when needed, or even pull updates to each piece individually from down the web etc, enabling interesting methods of software distribution. It would make very cool stuff possible. I have had a look at hs-plugins, but it is unclear how to derive a simple pair of functions `(a - b) - ByteString` and `ByteString - Either ParseError (a - b)`, for example, from the functionality it provides, if it is possible at all. I guess such a thing requires thorough digging into the depths of GHC, (or maybe even LLVM if an architecture independent representation is sought, but I don't know enough to say.). Perhaps this is more a question for those interested and knowledgable in Haskell compilation (and, to some extent, decompilation). If not Haskell, are there any languages which provide a simple serialization and deserialization of functions? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code that writes code
I would also like to strongly discourage code generators. Any code that has to be generated can and should have its common characteristics separated out with only unique characterstic remaining typically with an interface (i.e. type class) or polymorphic type dividing the two, creating a separation of concerns (this is really just abstraction). Every software project which I've worked on that used a code generator turned into a nightmare, because when we find we need to change something about the generator's output, all the already generated code has to be updated manually while at the same time maintaining all of the unique modifications that have been since the code was first generated. It's a horrible duplication of program logic and maintenance work. Of course code generation is perfectly fine when the output is not intended to be read and maintained by a human. For example, a compiler is technically a code generator, but it is purely for optimization purposes and the output is not intended to then be maintained by a human manually. A compiler might unroll a loop repeating the loop body a hundred times causing obvious duplication of logic, but it's fine because the assembler output is not intended to be maintained by a human, only the source input is. Efficiency and maintainability cannot be satisfied at the same time, which is why assembly sucks (not maintainable) and so do dynamic/scripting languages (not efficient), and compiled languages like Haskell are awesome (source code is highly maintainable, compiler output is highly efficient). Anyway, from my experience if you're generating code intended to be maintained by a human, you're doing it wrong. Though I am very interested to hear counter examples. Jesse On 20/08/2010 6:17 PM, Graham Klyne wrote: Maybe not helpful to you at this stage, but... An alternative to generating source code is to factor out the common boilerplate elements into separate functions, suitably parameterized, and to use higher order functions to stitch these together. An example of this kind of approach, which is handled by code generation in some other languages (e.g. lex, yacc, etc), is the Parsec combinator-based parsing library (http://www.haskell.org/haskellwiki/Parsec) - instead of generating code, the syntax rules are written directly using Haskell functions and assemble the common underlying repeated logic dynamically, behind the scenes. I adopted a development of this approach for a programme with a built-in scripting language that I implemented some time ago: the scripting language was parsed using Parsec, not into a syntax tree, but directly into a dynamically assembled function that could be applied to some data to perform the scripted function (http://www.ninebynine.org/RDFNotes/Swish/Intro.html). What I'm trying to point out here that, rather than go through the step of generating source code and feeding it back into a Haskell compiler, it may be possible to use higher order functions to directly assemble the required logic within a single program. For me, this is one of the great power-features of functional programming, which I now tend to use where possible in other languages that support functions as first class values. #g -- Andrew Coppin wrote: I'm working on a small Haskell package. One module in particular contains so much boilerplate that rather than write the code myself, I wrote a small Haskell program that autogenerates it for me. What's the best way to package this for Cabal? Just stick the generated file in there? Or is there some (easy) way to tell Cabal how to recreate this file itself? ___ 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
