Re: [Haskell-cafe] Parsers are monadic?
Hi Gregory, First post. I'm a newbie, been using Haskell for about a week and love it. Anyway, this is something I don't understand. Parsers are monadic. I can see this if the parser is reading from an input stream but if there's just a block of text can't you just have the parser call itself recursively feeding the unparsed text down the recursion and tacking nodes onto the tree as the recursions return, finally returning the whole tree to the top level caller. Seems this meets the criteria for pure functionality, same result every time with same args. Your intuition is right - it's definitely possible to write a parser without using a monad. However, some experience has shown that the most convenient way to structure a recursive descent parser library is with monads (or maybe with arrows, a more general concept). I imagine your suspicion is the result of equating monads with effects. Monads serve many purposes besides dealing with effects elegantly. Many new haskell hackers get their first taste of monads with IO, and get the impression that this is the One True Purpose of monadic programming. You might want to have a look at the paper Monadic Parser Combinators by Graham Hutton and Erik Meijer. This paper serves as a great introduction to both parser combinators and monads, and shows how they are related: http://www.cs.nott.ac.uk/~gmh/bib.html#monparsing The first 10 or 12 pages are particularly helpful in figuring out why monads make sense in parsing. Good luck! --Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Organising teams for ICFP 2007
Interested in competing in the ICFP 2007 programming contest -- the hackers contest of choice! http://www.icfpcontest.org There's 2000 people on this mailing list, and 350 people in #haskell, we must be able to put together a few decent teams out of that talent pool To help people get organised, I've created a page on the haskell.org wiki to help Haskell (and FP) people find teams: http://haskell.org/haskellwiki/ICFP_Programming_Contest/Teams_2007 If you've got a team, but need more people, or need a team, add your details, and hopefully people will be able to find you. The more teams the better. Also, drop by the #haskell-icfp07 IRC channel to talk to people and organise. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Abstraction leak
Hello Andrew, Friday, June 29, 2007, 10:39:28 PM, you wrote: I'm writing a whole bunch of data compression programs. me too :) but i never used Haskell for compression itself, only for managing archives. fast compression routines are written in C++ http://www.haskell.org/bz -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Abstraction leak
Bulat Ziganshin wrote: Hello Andrew, Friday, June 29, 2007, 10:39:28 PM, you wrote: I'm writing a whole bunch of data compression programs. me too :) but i never used Haskell for compression itself, only for managing archives. fast compression routines are written in C++ What, you're telling me that fast software cannot be written in Haskell? :-P Well anyway, speed is not my aim. My aim is to play with various textbook algorithms an examine how well they work for various types of data. As long as the code isn't *absurdly* slow that'll be just fine. (I forget who it was, but a while back somebody pointed out the wisdom of using Data.Map. It certainly makes the LZW implementation about 400% faster! To say nothing of Huffman...) BTW, how do the pros do Huffman coding? Presumably not by traversing trees of pointer-linked nodes to process things 1 bit at a time... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Abstraction leak
David Roundy wrote: On Fri, Jun 29, 2007 at 07:39:28PM +0100, Andrew Coppin wrote: Now I have a problem. It's easy enough to pass the entire data stream through an RLE decoder and feed that to the Huffman table deserialize function, and it will give be back the table. But I now have *no clue* where the table ends in the original stream! Sounds to me like you want a parsing monad. Generally, when you want state, you want a monad, and the field of parsing monads is pretty mature. You can either write up a monad of your own, or use one of the existing ones (parsec, frisby, read). Am I missing something or why wouldn't encode, decode :: String - String encode = encodeRLE . encodeHuffman decode = decodeHuffman . decodeRLE do the job? This is probably what Andrew intends to do in his Java version. Note that this not only RLE-encodes the Huffman table but also (needlessly) the data stream. In case you only want to RLE the table, a simple Word32 field tracking the size of the Huffman table should be enough. Regards, apfelmus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language semantics
Hi What's Uniplate? http://www-users.cs.york.ac.uk/~ndm/uniplate/ may help to answer that question. I haven't even finished understanding SYB, yet, though; I'm still mystified by how to use Data.Generics.Twins.gzipWithQ. So, I'm not at a stage where I can usefully contrast Uniplate with the Data.Generics stuff. Uniplate should be easier to understand than SYB. The draft paper on that web page compares Uniplate to SYB (and Compos). It also has plenty of examples of how to use Uniplate to do tasks. The manual on that page has suggested exercises to check that you can understand and extend Uniplate code. Uniplate produces more concise code, has traversal operations that are not present in the SYB library, runs faster and works in Hugs. SYB is capable of many more generic operations than Uniplate, such as gzipWithQ and much much more. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsers are monadic?
Big Chris writes to Gregory, who posts: ... something I don't understand. Parsers are monadic. I can see this if the parser is reading from an input stream but if there's just a block of text can't you just have the parser call itself recursively feeding the unparsed text down the recursion and tacking nodes onto the tree as the recursions return, finally returning the whole tree to the top level caller. Seems this meets the criteria for pure functionality, same result every time with same args. Your intuition is right - it's definitely possible to write a parser without using a monad. However, some experience has shown that the most convenient way to structure a recursive descent parser library is with monads (or maybe with arrows, a more general concept). I imagine your suspicion is the result of equating monads with effects. Monads serve many purposes besides dealing with effects elegantly. Many new haskell hackers get their first taste of monads with IO, and get the impression that this is the One True Purpose of monadic programming. You might want to have a look at the paper Monadic Parser Combinators by Graham Hutton and Erik Meijer. /.../ To make it shorter. The first usage of monads in parsing was *not* related to IO, but to the non-determinism of top-down parsers, the usage of lazy lists to store the possible partial parses (and to signal the possible ambiguities). People who used (or taught) this strategy using before, say, Prolog, found it remarkably clear. The standard, naïve approach to monadic parsing is very nice, but inefficient. So *please read* some material based on HuttonMeijer approach, but don't stay there, read something more modern, for example the PARSEC business http://legacy.cs.uu.nl/daan/download/papers/parsec-paper-letter.pdf http://research.microsoft.com/~emeijer/Papers/Parsec.pdf and also find out a bit about the arrow formalism, as present within the Swierstra Duponcheel approach to parsing (they, themselves didn't use arrows, but they inspired John Hughes. Unless I am confusing things because of my age...). Anyway, concerning what Big Chris calls a more general concept: don't be confused, the parsing strategy of SD is *NOT* monadic. Thera are arrows which are monadic, and others which are not. http://www.cs.uu.nl/people/doaitse/Papers/1996/DetErrCorrComPars.pdf == Jerzy Karczmarczuk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name Decoration and Undefined References
Hello SevenThunders, Saturday, June 30, 2007, 7:45:57 AM, you wrote: My own code is half Haskell and half C. My build process is rather complex i have the same. initially C code was compiled by gcc but finally i switched to ghc-only compilation. it's also important to use the same gcc for compiling both Haskell and C code (and using GHC as driver solves this problem, of course). i use make to control compilation of C code. you can download my program as http://www.haskell.org/bz/FreeArc-sources.tar.gz -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsers are monadic?
The standard, naïve approach to monadic parsing is very nice, but inefficient. So *please read* some material based on HuttonMeijer approach, but don't stay there, read something more modern, since we thereby seem to have left the phase of simple answers to simple questions;-) i'd like to raise a pet issue of mine. my own first combinator parsers (inspired by Wadler's How to replace failure by a list of successes, but adapted to a call-by-value language) were based on continuations. .. ok, now everybody has had time to chime in with monadic parsers are based on continuations or continuations are just one specific monad. so let me return to the particular issue i'm interested in: contrary to monadic parsers, those continuation-based parsers had *two* continuations, one for success, one for failure. and that seemed to be a very natural match for the problem. for all that i like monadic programming in general, i often feel that it is biased towards handling only the success path well, by offering built-in support for a single continuation only. for instance, one can use (Either String) as a parser monad with error messages, but it isn't straightforward to express error handling into that format, preserving both success and failure- related info (such as reporting the error corresponding to the longest partially successful parse). also, negation does not seem to be an easy fit (succeed if a specific parser would not be successful at the current point; this seems to require monad-specific information, so perhaps there's a MonadNegate class missing?). has anyone else had similar experiences with expressive limitations of monadic programming? things that one might be able to work around, but that don't feel as natural or simple as they should be? things that one hasn't been able to express at all (such as Swierstra Duponcheel's static analysis of combinator parsers which inspired Hughes's proposal to use arrows)? claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] advice: instantiating/duplicating modules
Dave Bayer wrote: I've since done some experiments with Template Haskell, and I see that Arie Peterson has suggested how you could proceed. However, are you sure that you can't find a way to get this to work in vanilla Haskell without extensions? Or, for that matter, are you sure there isn't a way to get functional dependencies to work? (I felt pretty dumb for a little while before I found one for my problem, although as usual the issues are clear in hindsight.) Yeah, a class/phantom type approach now seems more natural. At the time, I had just learned about Template Haskell, and this problem seemed like a nice nail :-). The code works for me, so I never bothered to rewrite it. Greetings, Arie ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: Re: [Haskell-cafe] avoiding command window with wxHaskell on Windows?
On Fri, 2007-06-29 at 23:22 -0400, Dean Herington wrote: Date: Mon, 25 Jun 2007 20:19:50 -0400 With gtk2hs, using -optl-mwindows as a command line option for GHC lets me get rid of this window. Perhaps it will do the same for wxHaskell? Yes, that did the trick! Thanks a lot! But now I've discovered that using -optl-mwindows creates a program that doesn't work when invoked from a command line. Is there any way to create a program that can work when invoked either from a command line or through double-clicking? You'll have to be a bit more specific about what you mean. Perhaps you mean that when launched from the command line you cannot interact with the program via that command line interface. That is indeed standard windows behaviour. You can create new terminals at runtime using Win32 functions, but I'm not sure if you can figure out if the program was launched from a terminal and associate with that terminal. But perhaps you meant something else. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: hiccup, a toy tcl impersonator in haskell
Hi, some time ago I started a Tcl-C compiler in Haskell. It should compile Tcl code to an Tcl extension. http://wiki.tcl.tk/17385 http://88.198.17.44/~fridolin/tclc/ (darcs) Few tests (e.g. recursive from shootout) are much faster than Tcl (original) interpreter but a lot of tests are slower. This is, because the variable lookup is done with slow Tcl_GetVar2Ex. But at the moment I'm a bit disapointed (about Tcl, not Haskell ;-) and don't work on it anymore... Regards. Christoph Bauer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsers are monadic?
On Sat, 30 Jun 2007, Claus Reinke wrote: for all that i like monadic programming in general, i often feel that it is biased towards handling only the success path well, by offering built-in support for a single continuation only. Certainly one path gets privileged over the others, I don't know I'd go so far as saying none get treated well though. for instance, one can use (Either String) as a parser monad with error messages, but it isn't straightforward to express error handling into that format, preserving both success and failure- related info (such as reporting the error corresponding to the longest partially successful parse). also, negation does not seem to be an easy fit (succeed if a specific parser would not be successful at the current point; this seems to require monad-specific information, so perhaps there's a MonadNegate class missing?). Have you used Parsec? The error model is not quite as general as it could be (hmm, perhaps this might be worth a day's hacking for Paolo as part of SoC if he's interested?) but it's certainly suitably compositional and I could start sketching out how to generalise it easily enough. Negation pretty much just works. The paper linked to elsethread explains the mechanisms reasonably well IMO. has anyone else had similar experiences with expressive limitations of monadic programming? things that one might be able to work around, but that don't feel as natural or simple as they should be? things that one hasn't been able to express at all (such as Swierstra Duponcheel's static analysis of combinator parsers which inspired Hughes's proposal to use arrows)? The big gain with arrows is those situations where higher-order computations can't be allowed - that's exactly the restriction that makes SD-style parsers work. You can even pull my favourite AST-and-interpreter implementation off again, with the static analysis taking a similar role to the interpreter (but also called /by/ the interpreter). -- [EMAIL PROTECTED] Performance anxiety leads to premature optimisation ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsers are monadic?
On Jun 30, 2007, at 6:31 AM, Claus Reinke wrote: has anyone else had similar experiences with expressive limitations of monadic programming? things that one might be able to work around, but that don't feel as natural or simple as they should be? things that one hasn't been able to express at all (such as Swierstra Duponcheel's static analysis of combinator parsers which inspired Hughes's proposal to use arrows)? When you pretend you've never heard of monads or arrows, and write down the types what do you get? When I finally overcame my resistance to monads, I only had to change names in my code to use the Maybe monad, the functions already had the right type. There's an inevitability to monads and arrows, and perhaps to what you're thinking, if it's a third species in a lazy list we're evaluating of such things. -- Haskell does suffer from misrepresentation to outsiders. Even already familiar with ML and Ocaml, the lazy, pure approach read to me like a fetish, and monads seemed a tainted construct for if one absolutely must venture into the practical. The only reason I could see to learn Haskell was a sense that nevertheless comes through and probably puts some people off, that Haskell programmers are in the highest reading group. (Lisp programmers imagine that they are; one should learn both.) If one must suffer through the drudgery of using a programming language, shouldn't it be a window to enlightenment that Aldous Huxley would admire? Haskell delivers, but I avoided monads to get the pure experience, when in fact Haskell is all about supporting functional idioms like monads. The references cited in this thread are excellent. They certainly gave me more insight into the history of how Haskell evolved: Classes coming from Gofer precisely to make monads more elegant to use, and do notation a mutant form of monad comprehensions. I went chasing references but couldn't substantiate this statement on page 11 of 1996 Hutton, Meijer - Monadic parser combinators http://haskell.readscheme.org/servlets/cite.ss?pattern=hutton- parsers1996 Indeed, the algebraic properties required of the monad operations turn out to be precisely those required for the notation to make sense. How do I reconcile this with the extension of do notation to support arrows? If monads and arrows are two instances of something akin to group theory then the definition of a group is lurking within whatever this quote should have said... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] XmlSerializer.deserialize?
Still struggling with this. If anyone has any constructive ideas? I guess it's not really easy otherwise someone would have come up with a solution by now ;-) The issue is the line in makeConstrM'' where we're trying to read (Data a = a) from (String). read doesnt work, because read needs a to be an instance of Read, and Data a does not enforce this. Whilst the parent class can be enforced to be Read, there's nothing to enforce this on the child. Anyway, took a look at SYB3, which came up with this little bit of code: class Data a = StringParser a where parsestring :: String - a parsestring x = fst $ head $gread(x) instance StringParser Int where parsestring x = read x instance StringParser String where parsestring x = read( \ ++ x ++ \ ) That looks like it should fix the problem with trying to read primitive child data types: we have a function parsestring with various custom methods for each data type we want to handle. On the face of it, it should work with any data type that is an instance of DAta, because of the default parsestring function. Unfortunately (and strangely) not: only data types explicitly added as instances will work with the default function for the Data class, even if the datatypes are in fact members of Data, and logically quite capable of running the default function. So, we cant use this for our Data a= String - a function There's a bunch of ext functions that look potentially useful, but didnt manage to get any of them to work for this. If anyone has any ideas? For the moment, the only functions that build are: return (fromJust $ fst $ head $ gread( ( ++ (fromJust value) ++ ) ) ) or: return ((fromJust . cast) value) ... and neither of these work very well. The second works for strings only, not for other datatypes. The first just plain doesnt seem to work, for some reason. (By the way, if anyone knows how to extract debug information from partially executed functions that would be useful). Here's testConstrM'' at the moment: testConstrM'' :: forall a. (Data a,Read a, Show a) = a - [(String, Maybe String, DataType,Constr)] - a testConstrM'' templateobject fieldvalues = evalState (fromConstrM (do --value - gets head (fieldname,value,datatype,constr) - gets head modify tail --return (fromJust $ (readConstr datatype value) ) --return (parsestring (fromJust value)) --return (extR (fromJust $ fst $ head $ gread( ( ++ (fromJust value) ++ ) ) ) parsestring(fromJust value ) ) return (fromJust $ fst $ head $ gread( ( ++ (fromJust value) ++ ) ) ) --return ((fromJust . cast) value) --case constr of -- (toConstr(3::Int)) - return ((fromJust . cast) value) --IntConstr x - return ((fromJust . cast) value) --_ - return ((fromJust . cast) value) --return (read_helper fieldname value datatype) )(toConstr templateobject)) fieldvalues You feed it a template object with the appropriate type, and an array of tuples with the fieldname, fieldvalue, datatype and constructor (we only use the fieldvalue at the moment, so you can leave the others blank). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsers are monadic?
Have you used Parsec? i read about it when it came out, but i've always defined my own combinators. in case you wonder, there are two reasons for this: (a) the approximation of parsers as monads is close enough that a simple type Parser m a = StateT String m a gives us the basic combinators (sequence,success,failure,alternative) for free. (b) i like my combinator grammars to be reversible, so that a single grammar specification can be used for both parsing and unparsing/pretty-printing. that means i have to define the details myself anyway. about the only thing that spoils this nice setup is error handling. i've done some of the things that parsec does myself, such as labeling productions, keeping positions and unexpected input, and merging of error info from branches, but it just doesn't seem to fit easily: what starts out as an elegant reuse of Monad/MonadPlus/StateT soon looks rather involved (compare also the implementation description in the parsec paper). parsec is a bit more systematic about these things, so it is easier to see where it is headed: a three-valued logic. if one has successful parses, successful errors, and failure to produce either as the third outcome, then one can try to merge the success and failure continuations into the single continuation provided by the monadic (=). still not very natural/simple, as one always has to deal with both continuations at once, the same way, but perhaps workable. Negation pretty much just works. please keep in mind that i was asking for general monadic negation. if one introduces a bias towards the first successful parse (as parsec does, apart from longest-match), one can model negation as failure: not m = (m return False) `mplus` return True this only uses Monad and MonadPlus, but it only works as expected for some MonadPlus (those which commit locally to the first success, instead of collecting multiple successes, such as lists, or searching for global success, such as amb, or longest-match parsers). alternatively, one could require an overloaded 'first' method, selecting the first successful branch in an ordered collection of solutions: not' m = first $ (m return False) `mplus` return True but that wouldn't work for unordered collection monads. in other words, one can define monadic negation for some specific monads, but not for all monads. but coding implementation knowledge about any specific monad into the source makes the code less general than it could be. so i was wondering whether there should be a class such as MonadChoice (committed choice instead of collections; every MonadChoice gives a MonadPlus, but not vice-versa), or MonadFirst (giving access to the first success), or MonadNegate (providing monadic not by whatever means). then code depending on monadic negation could still be reasonably general (not working with arbitrary monads, but also not restricted to a specific one). btw, in an approach with two continuations, negation is as simple as switching the success and failure continuations. but the merging of success and failure branches is perhaps no less involved than what one gets when implementing the two-kinds-of-success approach. i was just hoping that someone had come up with something more elegant, and i was wondering whether there were other issues that people have to work around again and again. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: Re: [Haskell-cafe] avoiding command window with wxHaskell on Windows?
On 6/30/07, Duncan Coutts [EMAIL PROTECTED] wrote: On Fri, 2007-06-29 at 23:22 -0400, Dean Herington wrote: Date: Mon, 25 Jun 2007 20:19:50 -0400 With gtk2hs, using -optl-mwindows as a command line option for GHC lets me get rid of this window. Perhaps it will do the same for wxHaskell? Yes, that did the trick! Thanks a lot! But now I've discovered that using -optl-mwindows creates a program that doesn't work when invoked from a command line. Is there any way to create a program that can work when invoked either from a command line or through double-clicking? You'll have to be a bit more specific about what you mean. Perhaps you mean that when launched from the command line you cannot interact with the program via that command line interface. That is indeed standard windows behaviour. You can create new terminals at runtime using Win32 functions, but I'm not sure if you can figure out if the program was launched from a terminal and associate with that terminal. But perhaps you meant something else. Assuming it's not something else. As far as I know, the console/non-console application is marked in exe-header, and you can, in principle, have two entrypoints to a program, one for console and one without. Unfortunately that's not supported by most tools (and probably none outside Microsoft toolchains.) So, in practice, either you make console applications, or non-console application. And as Duncan says, you can open new console if you don't have one, but that will have different window than parent process had. Opening new console might also require some interfacing with haskell runtime system if you want to use default putStrLn and friends. I think I saw a library to help with that, but I can't find it right now. Best regards, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Parsers are monadic?
Gregory Propf gregorypropf at yahoo.com writes: First post. I'm a newbie, been using Haskell for about a week and love it. Anyway, this is something I don't understand. Parsers are monadic. I can see this if the parser is reading from an input stream but if there's just a block of text can't you just have the parser call itself recursively feeding the unparsed text down the recursion and tacking nodes onto the tree as the recursions return, finally returning the whole tree to the top level caller. Seems this meets the criteria for pure functionality, same result every time with same args. myParser :: [Char] - ParseTree Looks as if others may be answering questions you didn't ask. It seems to me as if your definition of monadic is a little off. You're right: parsers (for a well-behaved grammar) *are* purely functional. Same input always gives the same output. And you're right in your understanding that calculations that aren't purely functional are handled in Haskell by a monad, specifically the IO monad. However--there are lots of monads in Haskell other than the IO monad and many of them are purely functional. Take Maybe: using the Maybe monad is just syntactic sugar for what you'd get explicitly writing out a chain of and if this fails return Nothing for the whole calculation, but if it succeeds, then Monadic just means a calculation using a mathematical structure called a monad. All impure calculations in Haskell are monadic, but not all monadic calculations are impure. Does this answer your question? --Eric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] avoiding command window with wxHaskell on Windows?
At 8:13 PM +0300 6/30/07, Esa Ilari Vuokko wrote: On 6/30/07, Duncan Coutts [EMAIL PROTECTED] wrote: On Fri, 2007-06-29 at 23:22 -0400, Dean Herington wrote: Date: Mon, 25 Jun 2007 20:19:50 -0400 With gtk2hs, using -optl-mwindows as a command line option for GHC lets me get rid of this window. Perhaps it will do the same for wxHaskell? Yes, that did the trick! Thanks a lot! But now I've discovered that using -optl-mwindows creates a program that doesn't work when invoked from a command line. Is there any way to create a program that can work when invoked either from a command line or through double-clicking? You'll have to be a bit more specific about what you mean. Perhaps you mean that when launched from the command line you cannot interact with the program via that command line interface. That is indeed standard windows behaviour. You can create new terminals at runtime using Win32 functions, but I'm not sure if you can figure out if the program was launched from a terminal and associate with that terminal. But perhaps you meant something else. Assuming it's not something else. As far as I know, the console/non-console application is marked in exe-header, and you can, in principle, have two entrypoints to a program, one for console and one without. Unfortunately that's not supported by most tools (and probably none outside Microsoft toolchains.) So, in practice, either you make console applications, or non-console application. It turns out I was confused (due I think to terribly slow network response). I have experimented more and believe I understand: -optl-mwindows creates a program that is suitable for launching (by either double-clicking or via a command line). The program so launched does not have a console or any direct way to communicate to the launcher. In particular, the launcher continues on its way immediately and cannot obtain the launchee's termination status. For the application I'm building, besides being able to launch it as above, I want also to be able to invoke it (normally from a command line). A program so invoked can interact with its invoker, and the invoker awaits the program's completion and gets its termination status. From what Esa said, it appears unlikely that a single .exe can be built easily using Haskell and wxHaskell that can be both launched and invoked. (In which case being able to produce a shared library containing the common code for the two .exe files would be nice!) Thanks for all the replies. Dean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] avoiding command window with wxHaskell on Windows?
For the application I'm building, besides being able to launch it as above, I want also to be able to invoke it (normally from a command line). A program so invoked can interact with its invoker, and the invoker awaits the program's completion and gets its termination status. From what Esa said, it appears unlikely that a single .exe can be built easily using Haskell and wxHaskell that can be both launched and invoked. as a partial workaround, you could create a shortcut for the .exe, and set the shortcut properties to start in a minimized window.. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Parsers are monadic?
Eric devnull1999 at yahoo.com writes: Looks as if others may be answering questions you didn't ask. I should read more carefully before posting: Big Chris did answer your question, though phrased differently than I did. --Eric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Read-only functions in State Monad
I'd like to have a state monad with the feature that I can somehow annotate using the type system that some functions are only going to read the state and not modify it. Such read-only functions are only permitted to call other read-only functions, whereas state-modifying functions can call both read-only and other state-modifying functions. How can I do this? It does not seem to be straightforwardly doable with Control.Monad.State. --ken ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Parsers are monadic?
Thanks, that was helpful. I didn't realize that there were pure functional monads. -- Monadic just means a calculation using a mathematical structure called a monad. All impure calculations in Haskell are monadic, but not all monadic calculations are impure. Does this answer your question? --Eric ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out. http://answers.yahoo.com/dir/?link=listsid=396545469___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Read-only functions in State Monad
Ken Takusagawa wrote: I'd like to have a state monad with the feature that I can somehow annotate using the type system that some functions are only going to read the state and not modify it. Such read-only functions are only permitted to call other read-only functions, whereas state-modifying functions can call both read-only and other state-modifying functions. How can I do this? It does not seem to be straightforwardly doable with Control.Monad.State. How about something like readonly :: Reader a - State a readonly = gets . runReader Implicit conversion is probably not possible with Control.Monad.State, you will have to make your own monad, maybe newtype State2 w s a = State2 (State s a) data Write The phantom type w can be used to encode whether writing is needed (State2 Write) or not (forall w. State2 w) get :: State2 w s s put :: s - State2 Write s s Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] sha1 implementation thats only 12 times slower then C
So I tried implementing a more efficient sha1 in haskell, and i got to about 12 times slower as C. The darcs implementation is also around 10 to 12 times slower, and the crypto one is about 450 times slower. I haven't yet unrolled the loop like the darcs implementation does, so I can still get some improvement from that, but I want that to be the last thing i do. I think I've been getting speed improvements when minimizing unnecessary allocations. I went from 40 times slower to 12 times slower by converting a foldM to a mapM that modifies a mutable array. Anyone have any pointers on how to get hashElem and updateElem to run faster, or any insight on what exactly they are allocating. To me it seems that those functions should be able to do everything they need to without a malloc. This is the profiling statistics generated from my implementation COST CENTREMODULE %time %alloc hashElem SHA1 42.9 66.2 updateElem SHA1 12.7 16.7 unboxW SHA1 10.60.0 hashA80SHA1 5.20.3 temp SHA1 4.60.0 sRotateL SHA1 4.60.0 ffkk SHA1 3.32.6 hashA16IntoA80 SHA1 3.10.1 sXor SHA1 2.90.0 do60 SHA1 2.92.6 sAdd SHA1 2.30.0 do20 SHA1 1.32.6 splitByN SHA1 1.22.3 do80 SHA1 0.82.6 do40 SHA1 0.42.6 Thanks, Anatoly module SHA1 where import GHC.Exts import Data.Array.IO import Foreign.C.String import Control.Monad import Foreign.ForeignPtr import Foreign.Ptr import Data.List import Data.Bits import Control.Exception import Data.Word import Data.Array.Storable import Array import Data.Array.Base import qualified Data.ByteString as BS import qualified Data.ByteString.Base as BS(unsafeUseAsCStringLen) data Word160 = Word160 !Word# !Word# !Word# !Word# !Word# deriving Show unboxW::Word - Word# unboxW !(W# w) = w boxW::Word# - Word boxW !w = W# w unboxI::Int - Int# unboxI !(I# w) = w sXor !a !b = a `xor#`b sAnd !a !b = a `and#` b sOr !a !b = a `or#` b sComp !a = (not# a) sAdd !a !b = a `plusWord#` b sRotateL::Word# - Int# - Word# sRotateL !a !b = (uncheckedShiftL# a b) `sOr` (uncheckedShiftRL# a ((unboxI 32) -# b)) add5 (Word160 x0 x1 x2 x3 x4) (Word160 y0 y1 y2 y3 y4) = Word160 (x0 `sAdd` y0) (x1 `sAdd` y1) (x2 `sAdd` y2) (x3 `sAdd` y3) (x4 `sAdd` y4) word64ToWord8s::Word64 - [Word8] word64ToWord8s ww = map (mkWord8 ww) $ reverse [0..7] where mkWord8::Word64 - Int - Word8 mkWord8 ww ii = fromIntegral $ (shiftR ww $ ii * 8) .. 0xff mkTailStr::Int - BS.ByteString mkTailStr len = BS.concat [BS.pack oneAndZeros, BS.pack (word64ToWord8s $ fromIntegral ln)] where ln = 8 * len oneAndZeros::[Word8] = (0x80::Word8):(replicate ((needzeros - 7) `div` 8) (0x00::Word8)) needzeros = if(bits 0) then bits + 512 else bits where bits = 447 - ((8 * ln) `mod` 512) splitByN::Int - BS.ByteString - [BS.ByteString] splitByN nn ll = st : (if (BS.null en) then [] else (splitByN nn en)) where (st,en) = BS.splitAt nn ll updateElem::(StorableArray Int Word) - Int - IO () updateElem a80 ii = do x3 - unsafeRead a80 (ii - 3) x8 - unsafeRead a80 (ii - 8) x14 - unsafeRead a80 (ii - 14) x16 - unsafeRead a80 (ii - 16) let ux3 = unboxW x3 let ux8 = unboxW x8 let ux14 = unboxW x14 let ux16 = unboxW x16 unsafeWrite a80 ii (boxW (sRotateL (ux3 `sXor` ux8 `sXor` ux14 `sXor` ux16) (unboxI 1))) data FFKK = FFKK !Word# !Word# ffkk::Int - Word# - Word# - Word# - FFKK ffkk !ii !bb !cc !dd | ii 20 = do20 bb cc dd | ii 40 = do40 bb cc dd | ii 60 = do60 bb cc dd | otherwise = do80 bb cc dd do20 !bb !cc !dd = FFKK ff kk where ff = (bb `sAnd` cc) `sOr` ((sComp bb) `sAnd` dd) kk = unboxW 0x5A827999 do40 !bb !cc !dd = FFKK ff kk where ff = bb `sXor` cc `sXor` dd kk = unboxW 0x6ED9EBA1 do60 !bb !cc !dd = FFKK ff kk where ff = (bb `sAnd` cc) `sOr` (bb `sAnd` dd) `sOr` (cc `sAnd` dd) kk = unboxW 0x8F1BBCDC do80 !bb !cc !dd = FFKK ff kk where ff = bb `sXor` cc `sXor` dd kk = unboxW 0xCA62C1D6 temp ww (FFKK ff kk) aa ee = (sRotateL aa (unboxI 5)) `sAdd` ff `sAdd` ee `sAdd` kk `sAdd` ww hashElem::(StorableArray Int Word) - (StorableArray Int Word) - Int - IO () hashElem a5 a80 ii = do aa - unsafeRead a5 0 bb - unsafeRead a5 1 cc - unsafeRead a5 2 dd - unsafeRead a5 3
Re: [Haskell-cafe] Read-only functions in State Monad
Hi Ken, 2007/7/1, Ken Takusagawa [EMAIL PROTECTED]: I'd like to have a state monad with the feature that I can somehow annotate using the type system that some functions are only going to read the state and not modify it. I would suggest declaring a MonadReader instance for State, and writing your read-only functions as f :: MonadReader s m = Param - m Result Would that solve your problem? Best, - Benja ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Name Decoration and Undefined References
Bulat Ziganshin-2 wrote: Hello SevenThunders, Saturday, June 30, 2007, 7:45:57 AM, you wrote: My own code is half Haskell and half C. My build process is rather complex i have the same. initially C code was compiled by gcc but finally i switched to ghc-only compilation. it's also important to use the same gcc for compiling both Haskell and C code (and using GHC as driver solves this problem, of course). i use make to control compilation of C code. you can download my program as http://www.haskell.org/bz/FreeArc-sources.tar.gz -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Yes, I'm in the process of migrating to ghc wherever possible. For my little problem, I solved it by copying both the object code (.o files) and the interface files (.hi files) to the source directory from the object file directory created by cabal specifically for building one of my libraries. That object code in turn was linked by gcc into another library (foo) with some external C code. Then to link against foo in Haskell I make sure it's compiled with all the .hi files that had been moved to the source directory. Thus you have to control the files for a given build context and keep them all together, prior to actually using any libraries or object files built with that code. You can't just bring in a different object file during a previous or different link using ghc. Unfortunately it's easy enough to forget where your .hi files came from. -- View this message in context: http://www.nabble.com/Name-Decoration-and-Undefined-References-tf4003458.html#a11378399 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] sha1 implementation thats only 12 times slower then C
aeyakovenko: So I tried implementing a more efficient sha1 in haskell, and i got to about 12 times slower as C. The darcs implementation is also around 10 to 12 times slower, and the crypto one is about 450 times slower. I haven't yet unrolled the loop like the darcs implementation does, so I can still get some improvement from that, but I want that to be the last thing i do. I think I've been getting speed improvements when minimizing unnecessary allocations. I went from 40 times slower to 12 times slower by converting a foldM to a mapM that modifies a mutable array. Anyone have any pointers on how to get hashElem and updateElem to run faster, or any insight on what exactly they are allocating. To me it seems that those functions should be able to do everything they need to without a malloc. Try inlining key small functions, and check the core. -O2 -ddump-simpl | less -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
