Re: [Haskell-cafe] Parser left recursion
Did you see expression parser in parsec packagehttp://hackage.haskell.org/packages/archive/parsec/3.1.3/doc/html/Text-Parsec-Expr.html? Is it not enough? 2013/2/20 Martin Drautzburg martin.drautzb...@web.de Hello all, this was previously asked on haskell-beginners, but only partially answered. As an exercise I am writing a parser roughly following the expamples in Graham Hutton's book. The language contains things like: data Exp = Lit Int -- literal integer | Plus Exp Exp My naive parser enters an infinite recursion, when I try to parse 1+2. I do understand why: hmm, this expression could be a plus, but then it must start with an expression, lets check. and it tries to parse expression again and again considers Plus. Twan van Laarhoven told me that: Left-recursion is always a problem for recursive-descend parsers. and suggested to do something like: parseExp = do lit - parseLit pluses - many (parsePlusToken * parseLit) return (combinePlusesWithLit lit pluses) combinePlusesWithLit = foldr Plus -- or foldl This indeed does the trick, but only when the first token is a Lit (literal integer). I then added the possibility to optionally put things in parentheses. But then I cannot parse (1+2)+3. The original code fails, because (1+2) is not a Lit and when I allow an expression as the first argument to + I get infinite recursion again. I am generally confused, that saying a plus expression is an integer followed by many plus somethings is not what the language says. So this requires a lot of paying attention to get right. I'd much rather say a plus expression is two expressions with a '+' in between. I do know for sure, that it is possible to parse (1+2)+3 (ghci does it just fine). But I seem to be missing a trick. Can anyone shed some light on this? -- Martin ___ 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] Parser left recursion
Hi, Martin Drautzburg wrote: As an exercise I am writing a parser roughly following the expamples in Graham Hutton's book. The language contains things like: data Exp = Lit Int -- literal integer | Plus Exp Exp So the grammar is: Exp ::= Int | Exp + Exp My naive parser enters an infinite recursion, when I try to parse 1+2. I do understand why: hmm, this expression could be a plus, but then it must start with an expression, lets check. and it tries to parse expression again and again considers Plus. Indeed. Twan van Laarhoven told me that: Left-recursion is always a problem for recursive-descend parsers. Note that the left recursion is already visible in the grammar above, no need to convert to parser combinators. The problem is that the nonterminal Exp occurs at the left of a rule for itself. One way to fix this problem is to refactor the grammar in order to avoid left recursion. So let's distinguish expressions that can start with expressions and expressions that cannot start with expressions: Exp-norec ::= Int Exp-rec ::= Exp-norec | Exp-norec + Exp-rec Note that Exp-rec describes a list of Exp-norec with + in-between, so you can implement it with the combinator many. Now if you want to add a rule like Exp ::= ( Exp ) you need to figure out whether to add it to Exp-norec or Exp-rec. Since the new rule is not left recursive, you can add it to Exp-norec: Exp-norec ::= Int | ( Exp-rec ) Exp-rec ::= Exp-norec | Exp-norec + Exp-rec If you implement this grammar with parser combinators, you should be able to parse (1+2)+3 just fine. Tillmann PS. Try adding multiplication to your grammar. You will need a similar trick to get the priorities right. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec without data declarations/AST
Thanks that is exactly what I was looking for, one further question I might ask is how I might allow for either a integer or a string to be parsed. As it is now I get a complaint if I try and parse either a String or an Integer without creating a data declaration for say Express containing: data Express = ID String | Num Integer is there a way around this without a need for a data declaration? As far as I know the parser will only accept (in this case) either Strings or Integers but not both, for example: expr8 = name | number name :: String number :: Integer will cause an error unless name and number are created using the value constructors ID and Num and are both the data type Express. Anybody have any thoughts on this ? Thanks in Advance, Seán On Tue, Feb 19, 2013 at 11:22 PM, Alexander Solla alex.so...@gmail.comwrote: Come to think of it, a parsec parser already wraps over Either, so if all you want to do is check if a result is valid, you can abuse the Either semantics so that your type is: Parser () -- the parser which returns nothing on success or an error on failure. On Tue, Feb 19, 2013 at 3:20 PM, Alexander Solla alex.so...@gmail.comwrote: If all you want to do is check that the code is valid (i.e., you aren't going to interpret the code), you can just return a Bool. If you want to interpret it, but don't want to have a Stmt type, you can return IO () actions. In that case, the parser's type will be Parser (IO ()) I think an algebraic AST (or even a functorial/monadic one) will help separate concerns, and will eventually help when it comes time to optimize your compiler. It really isn't as much boilerplate as it looks like (in fact, there's hardly any boilerplate if you target free monads and interpret those in IO), and you get the type safety for which Haskell is well-known. On Tue, Feb 19, 2013 at 3:02 PM, Sean Cormican seancormic...@gmail.comwrote: I have been trying to create a parser for a functional programming language, but there is no need to create an AST but merely check that the code is valid according to the grammar. In the following tutorial I have been trying to take some pointers from, data declarations are used to create an AST for the language, There is, as I understand a way to parse the language without an AST. http://www.haskell.org/haskellwiki/Parsing_a_simple_imperative_language My question is what should the type signatures for example parseFile function instead of Stmt accept as input if the parser is to accept Strings and numerical expressions alike ? Thanks for any help, Seán ___ 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] Parser left recursion
* Tillmann Rendel ren...@informatik.uni-marburg.de [2013-02-20 09:59:47+0100] One way to fix this problem is to refactor the grammar in order to avoid left recursion. So let's distinguish expressions that can start with expressions and expressions that cannot start with expressions: [...] PS. Try adding multiplication to your grammar. You will need a similar trick to get the priorities right. And then try adding subtraction ;-) Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parser left recursion
Hi, Roman Cheplyaka wrote: Another workaround is to use memoization of some sort — see e.g. GLL (Generalized LL) parsing. Is there a GLL parser combinator library for Haskell? I know about the gll-combinators for Scala, but havn't seen anything for Haskell. Bonus points for providing the graph-structured stack (for maximal sharing in the computation) and the shared packed parse forest (for maximal sharing in the results) as reusable components. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parser left recursion
* Tillmann Rendel ren...@informatik.uni-marburg.de [2013-02-20 12:39:35+0100] Hi, Roman Cheplyaka wrote: Another workaround is to use memoization of some sort — see e.g. GLL (Generalized LL) parsing. Is there a GLL parser combinator library for Haskell? I know about the gll-combinators for Scala, but havn't seen anything for Haskell. I am not aware of any. Dmitry Astapov and I played with this idea a long time ago, but we didn't succeed. Might be a good time for someone interested to have another go at it. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parser left recursion
All, Many (but not all) of the parsing algorithms that support left recursion cannot be implemented in Haskell using the standard representation of recursion in parser combinators. The problem can be avoided in Scala because it has imperative features like referential identity and/or mutable references. The most practical solution currently is probably to manually transform your grammars to a non-left-recursive form (as suggested above) and then use a standard parser combinator library with a top-down parsing algorithm (I suggest uu-parsinglib). That being said, there is active research into alternative functional representations of recursion in grammars/parsers that support a wider range of algorithms. If you want to read up on such research, I suggest the following papers to get an idea of some of the approaches: Baars, Arthur, S. Doaitse Swierstra, and Marcos Viera. Typed transformations of typed grammars: The left corner transform. Electronic Notes in Theoretical Computer Science 253.7 (2010): 51-64. Devriese, Dominique, et al. Fixing idioms: A recursion primitive for applicative dsls. Proceedings of the ACM SIGPLAN 2013 workshop on Partial evaluation and program manipulation. ACM, 2013. Oliveira, Bruno CdS, and William R. Cook. Functional programming with structured graphs. Proceedings of the 17th ACM SIGPLAN international conference on Functional programming. ACM, 2012. Oliveira, Bruno C. D. S., and Andres Löh. Abstract syntax graphs for domain specific languages. Proceedings of the ACM SIGPLAN 2013 workshop on Partial evaluation and program manipulation. ACM, 2013. DEVRIESE, DOMINIQUE, and FRANK PIESSENS. Finally tagless observable recursion for an abstract grammar model. Journal of Functional Programming 1.1: 1-40. For the last one, you can check out http://projects.haskell.org/grammar-combinators/ about the grammar-combinators library on Hackage. It has a packrat parser that can deal with left-recursion and a grammar transformation that transforms it away. There is a tutorial you can checkout. Dominique 2013/2/20 Tillmann Rendel ren...@informatik.uni-marburg.de: Hi, Roman Cheplyaka wrote: Another workaround is to use memoization of some sort — see e.g. GLL (Generalized LL) parsing. Is there a GLL parser combinator library for Haskell? I know about the gll-combinators for Scala, but havn't seen anything for Haskell. Bonus points for providing the graph-structured stack (for maximal sharing in the computation) and the shared packed parse forest (for maximal sharing in the results) as reusable components. Tillmann ___ 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] parser combinator for left-recursive grammars
It is indeed true that a grammar with left-recursion can be transformed to an equivalent grammar without left recursion -- equivalent in terms of the language recognized -- but _not_ in the parse trees. Linguists in particular care about parses. Therefore, it was linguists who developed the parser combinator library for general grammar with left recursion and eps-loops: Frost, Richard, Hafiz, Rahmatullah, and Callaghan, Paul. Parser Combinators for Ambiguous Left-Recursive Grammars. PADL2008. http://cs.uwindsor.ca/~richard/PUBLICATIONS/PADL_08.pdf I have tried dealing with left-recursive grammars and too wrote a parser combinator library: http://okmij.org/ftp/Haskell/LeftRecursion.hs It can handle eps-cycles, ambiguity and other pathology. Here is a sample bad grammar: S - S A C | C A - B | aCa B - B C - b | C A For more details, see December 2009 Haskell-Cafe thread Parsec-like parser combinator that handles left recursion? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On 20/02/13 08:13, Jan Stolarek wrote: Dnia wtorek, 19 lutego 2013, Gwern Branwen napisał: On Tue, Feb 19, 2013 at 5:36 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: - remove unlambda, brainfuck and show from the repo. They are on hackage, no need to keep them here - these packages aren't even used in the build process. Where will they go? These packages are already on hackage: http://hackage.haskell.org/package/brainfuck http://hackage.haskell.org/package/show http://hackage.haskell.org/package/unlambda No need to keep them in the lambdabot repo. They are in the lambdabot *repository*, but in separate hackage packages. Are you suggesting that the source code of these packages is moved out to their own darcs repositories? Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On Feb 19, 2013, at 9:54 PM, Jason Dagit dag...@gmail.com wrote: Random thought, feel free to ignore it: Would it make sense to split lambdabot up into core and contrib like is done with xmonad? Contrib could contain the sillier things like bf, unlambda, show, etc and would have a lower bar for contributors. Core would be the standard things and the essential things. Sounds like a good idea to me. I could probably do that this weekend if nobody else does sooner. Any opinion about whether it's better to put them in the same or separate actual repos? I've tried both with different collections of related packages and have no strong opinion, myself. It seems that people don't really contribute new plugins these days but it would be great if they did. For example, having a plugin for liquid types would be super spiffy. Also, any plugin that helps people to reason about other code (like vacuum). I suspect there are two big reasons for that. The biggest reason is probably that lambdabot has been getting long in the tooth, and the barrier to entry is sorting through a somewhat bit- rotted API with little to no documentation. That's why a lot of the work I did to clean it up for myself was API-related. The other is that there seemed to be, for a long time, no interest in maintaining it. Several years ago I did some work on fixing up some plugins, for example, but couldn't get a response from whoever was the current maintainer (I think it might have been dons, who was probably overextended at the time). Hopefully the API can be further simplified and documented; if it can be reduced to a few well-documented core modules and a few auxiliary utility/helper ones, that would probably make the educational barrier to entry quite a bit lower, and I'm happy to maintain the repo or willing to let others do so, so hopefully we can reduce the social barrier too. I don't currently have a lot of time to devote to hacking on it, but I try to be a responsive maintainer of all my projects. -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
Any opinion about whether it's better to put them in the same or separate actual repos? The general rule in git is that a repo should contain a single project. There are some projects that violate this rule - e.g. cabal stores both Cabal and cabal-install in the same repository - but with such a setup it is harder to manage commits in case some of them need to be reverted. I'd say that if we split lambdabot in such a way then core should be one repository and contrib should be another one (separate). Contrib repository should contain only one package (instead of bunch of smaller ones). couldn't get a response from whoever was the current maintainer Speaking of which, I think you could become the current maintainer since both Cale and Don agreed that the project should be maintained and you seem to have done a lot to improve it. Not saying that you should do all the development, but you could manage releases and uploads to Hackage. I don't have too much time to spend on this, but I will try to regularly spend 2-3 hours a week on lambdabot. Janek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] package show needs upper version bound for smallcheck?
Since smallcheck-1.0 contains API changes - Could the maintainers of show http://hackage.haskell.org/package/show-0.4.1.2 please add some version bound ( 1 or similar) for the smallcheck dependency? Thanks - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parser left recursion
More primitively, Parsec and its predecessor Hutton-Meijer provide the chainl/chainr combinators, these automatically remove left recursion within the parser - i.e. you don't have to rewrite the grammar. On 20 February 2013 08:19, Dmitry Olshansky olshansk...@gmail.com wrote: Did you see expression parser in parsec package? Is it not enough? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
Are you suggesting that the source code of these packages is moved out to their own darcs repositories? Exactly. This allows to use and develop these packages independently of lambdabot and I consider that a Good Thing. I'm also much in favor of using git, because github allows easy collaboration between community members. Janek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
I've catalogued a list of issues on github: https://github.com/mokus0/lambdabot/issues Let me know if you have objections against any of them. If no then I will try to fix them gradually. Right now a major problem for me are exceptions in Data.Binary, but I don't think I will be able to fix them. Janek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On Wed, Feb 20, 2013 at 12:59 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Exactly. This allows to use and develop these packages independently of lambdabot and I consider that a Good Thing. I'm also much in favor of using git, because github allows easy collaboration between community members. It may be a good thing, but speaking as the de facto maintainer of lambdabot for the past few years, it's a very small good thing and the goodness may be outweighed by the costs of switching: hardly anyone ever sends in patches for lambdabot proper, and even fewer for those add-on runtime dependencies. I am reminded of a recent incident on the XMonad mailing list: an enthusiastic young member proposed changing the entire infrastructure to Github because Github is the new hotness and it would surely promote easy collaboration between community members and so on and so forth. He put in a bunch of work in making copies and converting repos etc, and... nothing happened. His effort was wasted. Turns out the reason for people not submitting patches had more to do with things besides not being hosted on Github. -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
goodness may be outweighed by the costs of switching: Could you specify what are those cost of switching? Turns out the reason for people not submitting patches had more to do with things besides not being hosted on Github. Of course. I don't clain this is the reason for people not submitting patches. All I say is that I consider git+github to be a much easier platform for collaboration than darcs. I think many people would agree. Gwern, and what do you think about James' fork of lambdabot? It seems that there was a lot of work put into it and that this is indeed a good starting point to continue development. Janek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
My 2 cents: Switching to github: +0.1 Splitting into core contrib: +1 Okay I suppose that is more like 1.1 cents. I would love to help maintain lambdabot and help brush off the bitrot, but am personally quite overextended so I can't really promise any amount of dedication for at least the next few weeks. I can promise to occasionally throw my opinion around as if it mattered, though. ;) -- Dan Burton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On Wed, Feb 20, 2013 at 1:35 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Gwern, and what do you think about James' fork of lambdabot? It seems that there was a lot of work put into it and that this is indeed a good starting point to continue development. I haven't looked at the diffs; if as he says the security around the evaluation has been weakened, that's a deal-breaker until it's fixed. lambdabot can't be insecure since it will be run in a public IRC. -- gwern http://www.gwern.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Embedded haskell?
I've been working with open source rc aircraft transmitter software, and in looking at the shortcomings of one of them, started thinking about embedding a language. There are a number of options that can work here, like FORTH or a basic. But then I realized that Haskell - or similar functional language - could well be a good fit. The software is meant to let the end user express how the various inputs - joysticks, switches, trims, knobs - are mapped to values the radio sends on the various control channels. All the key values are immutable - you either read them from hardware once in the process of building a frame to transmit, or you fill them into a frame and transmit it, then start over for the next frame. You just need to let the end user express the functions to go from one to the other. The other restraint is that you need to be able to change the code in the field, with the only computer available being the embedded one. You might have a touch-screen, or you might just have cursor keys. Either way, actually inputting a program could be interesting. Similarly, the entire system: compiler, interpreter, whatever - needs to run on the embedded computer. A quick google turns up Hume, which seems to be designed for this kind of thing, though not with the in the field restrictions. Anyone have any other suggestions of software that might fit here? Experience with any of that software? Other suggestions? Thanks, mike ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parser left recursion
Thank you very much. To clarify: I am not in need of a parser, I just wanted to understand why left recursion is an issue (that was easy) and what techniques help to circumvent the problem. So your answer was spot-on (though I haven't implemented it yet) On Wednesday, 20. February 2013 09:59:47 Tillmann Rendel wrote: Hi, Martin Drautzburg wrote: As an exercise I am writing a parser roughly following the expamples in Graham Hutton's book. The language contains things like: data Exp = Lit Int -- literal integer | Plus Exp Exp So the grammar is: Exp ::= Int | Exp + Exp My naive parser enters an infinite recursion, when I try to parse 1+2. I do understand why: hmm, this expression could be a plus, but then it must start with an expression, lets check. and it tries to parse expression again and again considers Plus. Indeed. Twan van Laarhoven told me that: Left-recursion is always a problem for recursive-descend parsers. Note that the left recursion is already visible in the grammar above, no need to convert to parser combinators. The problem is that the nonterminal Exp occurs at the left of a rule for itself. One way to fix this problem is to refactor the grammar in order to avoid left recursion. So let's distinguish expressions that can start with expressions and expressions that cannot start with expressions: Exp-norec ::= Int Exp-rec ::= Exp-norec | Exp-norec + Exp-rec Note that Exp-rec describes a list of Exp-norec with + in-between, so you can implement it with the combinator many. Now if you want to add a rule like Exp ::= ( Exp ) you need to figure out whether to add it to Exp-norec or Exp-rec. Since the new rule is not left recursive, you can add it to Exp-norec: Exp-norec ::= Int | ( Exp-rec ) Exp-rec ::= Exp-norec | Exp-norec + Exp-rec If you implement this grammar with parser combinators, you should be able to parse (1+2)+3 just fine. Tillmann PS. Try adding multiplication to your grammar. You will need a similar trick to get the priorities right. -- Martin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Unused definitions across modules in a package
Hey! GHC warns me about unused definitions in a module. However, is it possible to warn me about unused definitions in a package? For example, suppose that module A exports function f and that module B uses A.f (everything on a single package). However, after some time B stops using A.f. Is there a way of receiving a warning saying that A exports f but no other module uses it.? (I know that this warning wouldn't be useful for libraries, since their whole point is to export things.) Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Embedded haskell?
Another option would be to use Atom. I have successfully used it to target the arduino platform before. Running the entire OS on the embedded system seems dubious. Assuming you are using something the 9x family of transmitters -- they are slow and have very little internal memory. Plus trying to programming using a 6 buttons would be a royal pain. If you really want in-field programming, then you might at least using a raspberry pi with a small bluetooth keyboard and have it upload to the transmitter. - jeremy On Wed, Feb 20, 2013 at 1:33 PM, Mike Meyer m...@mired.org wrote: I've been working with open source rc aircraft transmitter software, and in looking at the shortcomings of one of them, started thinking about embedding a language. There are a number of options that can work here, like FORTH or a basic. But then I realized that Haskell - or similar functional language - could well be a good fit. The software is meant to let the end user express how the various inputs - joysticks, switches, trims, knobs - are mapped to values the radio sends on the various control channels. All the key values are immutable - you either read them from hardware once in the process of building a frame to transmit, or you fill them into a frame and transmit it, then start over for the next frame. You just need to let the end user express the functions to go from one to the other. The other restraint is that you need to be able to change the code in the field, with the only computer available being the embedded one. You might have a touch-screen, or you might just have cursor keys. Either way, actually inputting a program could be interesting. Similarly, the entire system: compiler, interpreter, whatever - needs to run on the embedded computer. A quick google turns up Hume, which seems to be designed for this kind of thing, though not with the in the field restrictions. Anyone have any other suggestions of software that might fit here? Experience with any of that software? Other suggestions? Thanks, mike ___ 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] Embedded haskell?
On Wed, Feb 20, 2013 at 4:01 PM, Jeremy Shaw jer...@n-heptane.com wrote: Another option would be to use Atom. I have successfully used it to target the arduino platform before. Running the entire OS on the embedded system seems dubious. Assuming you are using something the 9x family of transmitters -- they are slow and have very little internal memory. Plus trying to programming using a 6 buttons would be a royal pain. If you really want in-field programming, then you might at least using a raspberry pi with a small bluetooth keyboard and have it upload to the transmitter. Atom does look interesting. Thanks for the pointer. The target transmitter is the Walkera Devo line. These have much more capable CPUs than the various 9x boards: 32 bit ARMs at 72MHz with comparable amounts of storage. Some have 9x-like screen/button combos, others have touch screens. The deviationTx software runs on all of them. Settings are stored in a FAT file system that can be accessed as a USB drive. I'm thinking that a traditional configuration interface on the transmitter, storing the config information as program text. The only actual programming would be done by replacing the virtual channel/switch feature with expressions or short programs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unused definitions across modules in a package
On 21 February 2013 08:56, Felipe Almeida Lessa felipe.le...@gmail.com wrote: Hey! GHC warns me about unused definitions in a module. However, is it possible to warn me about unused definitions in a package? For example, suppose that module A exports function f and that module B uses A.f (everything on a single package). However, after some time B stops using A.f. Is there a way of receiving a warning saying that A exports f but no other module uses it.? (I know that this warning wouldn't be useful for libraries, since their whole point is to export things.) My (getting-long-in-the-tooth-and-could-do-with-a-rewrite) SourceGraph package does identify these definitions. As for GHC warning about it, I wonder if maybe that's a better role for Cabal as it knows which modules are public vs private (and even libraries can have exported definitions that aren't used from non-exported modules). Cheers! -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Embedded haskell?
Ah, nice. Building Haskell applications on the Raspberry Pi which is a 32-bit 700 Mhz CPU with 512MB of RAM is still pretty painful. So, I think that running GHC on something even less powerful is probably not going to work well. But, handling a subset of Haskell for onsite programming could work. Using Haskell Source Extensions and the new Haskell Type Extensions should be enough to allow you to create an onboard mini-Haskell interpreter? It would actually be pretty neat to be able to extend all sorts of Haskell applications with a Haskell-subset scripting language.. I'd definitely be interested in exploring this more. I recently got into multirotors and I am also working on a semi-autonomous rover project -- plus I just want to see Haskell used more in educational robotics (http://www.haskell.org/haskellwiki/RoboticOverlords). - jeremy On Wed, Feb 20, 2013 at 4:28 PM, Mike Meyer m...@mired.org wrote: On Wed, Feb 20, 2013 at 4:01 PM, Jeremy Shaw jer...@n-heptane.com wrote: Another option would be to use Atom. I have successfully used it to target the arduino platform before. Running the entire OS on the embedded system seems dubious. Assuming you are using something the 9x family of transmitters -- they are slow and have very little internal memory. Plus trying to programming using a 6 buttons would be a royal pain. If you really want in-field programming, then you might at least using a raspberry pi with a small bluetooth keyboard and have it upload to the transmitter. Atom does look interesting. Thanks for the pointer. The target transmitter is the Walkera Devo line. These have much more capable CPUs than the various 9x boards: 32 bit ARMs at 72MHz with comparable amounts of storage. Some have 9x-like screen/button combos, others have touch screens. The deviationTx software runs on all of them. Settings are stored in a FAT file system that can be accessed as a USB drive. I'm thinking that a traditional configuration interface on the transmitter, storing the config information as program text. The only actual programming would be done by replacing the virtual channel/switch feature with expressions or short programs. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 259
Welcome to issue 259 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the week of February 10 to 16, 2013. Quotes of the Week * frerich: i thought endo is where the ewoks live * edwardk: on the other hand i also write excessively polymorphic code Top Reddit Stories * Comonads are objects Domain: haskellforall.com, Score: 105, Comments: 86 On Reddit: [1] http://goo.gl/ssFWD Original: [2] http://goo.gl/ADN3k * GHC HEAD now has OverloadedLists as an extension - allowing you to more easily specify literal Maps, Text, Vector, ByteString etc values. Domain: hackage.haskell.org, Score: 86, Comments: 66 On Reddit: [3] http://goo.gl/tVmBE Original: [4] http://goo.gl/m08GR * GHC HEAD: new parallel I/O manager merged Domain: haskell.org, Score: 67, Comments: 39 On Reddit: [5] http://goo.gl/HX04c Original: [6] http://goo.gl/j8AaN * The Algebra of Algebraic Data Types (Part I) Domain: chris-taylor.github.com, Score: 51, Comments: 23 On Reddit: [7] http://goo.gl/9WjrL Original: [8] http://goo.gl/Jyco0 * deprecation rage :: hpaste Domain: hpaste.org, Score: 49, Comments: 9 On Reddit: [9] http://goo.gl/ycHWD Original: [10] http://goo.gl/KAdsV * Github incorrectly recognizes haskell code as perl thus making language usage studies based on github useless. Domain: github.com, Score: 45, Comments: 45 On Reddit: [11] http://goo.gl/WQN38 Original: [12] http://goo.gl/jfpeH * StackOverflow [haskell] hits 10k questions! Domain: imgur.com, Score: 41, Comments: 31 On Reddit: [13] http://goo.gl/znqwX Original: [14] http://goo.gl/cdm3C * Don Stewart provides a great concise overview of the many areas of Haskell performance analysis Domain: stackoverflow.com, Score: 39, Comments: 1 On Reddit: [15] http://goo.gl/W9AOL Original: [16] http://goo.gl/nC6Mk * The Algebra of Algebraic Data Types, Part 2 Domain: chris-taylor.github.com, Score: 37, Comments: 9 On Reddit: [17] http://goo.gl/VHUjp Original: [18] http://goo.gl/mk95s * Upcoming conduit 1.0 comparison to pipes io-streams Domain: yesodweb.com, Score: 32, Comments: 11 On Reddit: [19] http://goo.gl/dbnpi Original: [20] http://goo.gl/8RHfb * Library: A collection of tools for processing PDF files in Haskell Domain: github.com, Score: 31, Comments: 38 On Reddit: [21] http://goo.gl/BtpFw Original: [22] http://goo.gl/loL4n * Introduction to Haskell, Lecture 5 is Live (Creating Data Types) Domain: shuklan.com, Score: 29, Comments: 2 On Reddit: [23] http://goo.gl/h2q3G Original: [24] http://goo.gl/ASx0B * FP Complete Hiring for Haskell evangelist / customer and community relations advocate Domain: haskellers.com, Score: 28, Comments: 0 On Reddit: [25] http://goo.gl/g2nic Original: [26] http://goo.gl/di728 * Quick and Easy DSLs with Writer Endo Domain: ocharles.org.uk, Score: 22, Comments: 17 On Reddit: [27] http://goo.gl/6p43B Original: [28] http://goo.gl/p8aX4 Top StackOverflow Questions * Least-strict (*) votes: 17, answers: 2 Read on SO: [29] http://goo.gl/tHzUf * Referential transparency with polymorphism in Haskell votes: 14, answers: 1 Read on SO: [30] http://goo.gl/PyBgK * Truncating to Word type votes: 11, answers: 1 Read on SO: [31] http://goo.gl/C4wwu * Is there a generalization of these Free-like constructions? votes: 11, answers: 0 Read on SO: [32] http://goo.gl/WLb7S * How fast is Data.Sequence.Seq compared to []? votes: 9, answers: 1 Read on SO: [33] http://goo.gl/d0x2d * Does FreeT keep the equational reasoning benefits of Free? votes: 9, answers: 1 Read on SO: [34] http://goo.gl/7vu37 * Understanding recursion in Haskell votes: 7, answers: 5 Read on SO: [35] http://goo.gl/I2SBM * What laws are the standard Haskell type classes expected to uphold? votes: 7, answers: 2 Read on SO: [36] http://goo.gl/FqQ5J * What does (== “ ”) mean, in Haskell? votes: 7, answers: 4 Read on SO: [37] http://goo.gl/EecMz * Linking separate projects in GHC votes: 7, answers: 1 Read on SO: [38] http://goo.gl/ZjVao * What are structures with “subtraction” but no inverse? votes: 7, answers: 1 Read on SO: [39] http://goo.gl/SaQ66 Until next time, +Daniel Santa Cruz References 1. http://www.haskellforall.com/2013/02/you-could-have-invented-comonads.html 2. http://www.reddit.com/r/haskell/comments/18isiu/comonads_are_objects/ 3. http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists 4. http://www.reddit.com/r/haskell/comments/18ncub/ghc_head_now_has_overloadedlists_as_an_extension/ 5. http://www.haskell.org/pipermail/ghc-devs/2013-February/000414.html 6.
Re: [Haskell-cafe] Embedded haskell?
in addition to atom http://hackage.haskell.org/package/atom/ theres also copilot http://hackage.haskell.org/package/copilot point being: theres lots of great tools you can use to target embedded systems that leverage haskell in cool ways! (eg: hArduino on the more hobbyist side, which I need to check out myself! ) enjoy your explorations! -Carter On Wed, Feb 20, 2013 at 10:51 PM, Jeremy Shaw jer...@n-heptane.com wrote: Ah, nice. Building Haskell applications on the Raspberry Pi which is a 32-bit 700 Mhz CPU with 512MB of RAM is still pretty painful. So, I think that running GHC on something even less powerful is probably not going to work well. But, handling a subset of Haskell for onsite programming could work. Using Haskell Source Extensions and the new Haskell Type Extensions should be enough to allow you to create an onboard mini-Haskell interpreter? It would actually be pretty neat to be able to extend all sorts of Haskell applications with a Haskell-subset scripting language.. I'd definitely be interested in exploring this more. I recently got into multirotors and I am also working on a semi-autonomous rover project -- plus I just want to see Haskell used more in educational robotics (http://www.haskell.org/haskellwiki/RoboticOverlords). - jeremy On Wed, Feb 20, 2013 at 4:28 PM, Mike Meyer m...@mired.org wrote: On Wed, Feb 20, 2013 at 4:01 PM, Jeremy Shaw jer...@n-heptane.com wrote: Another option would be to use Atom. I have successfully used it to target the arduino platform before. Running the entire OS on the embedded system seems dubious. Assuming you are using something the 9x family of transmitters -- they are slow and have very little internal memory. Plus trying to programming using a 6 buttons would be a royal pain. If you really want in-field programming, then you might at least using a raspberry pi with a small bluetooth keyboard and have it upload to the transmitter. Atom does look interesting. Thanks for the pointer. The target transmitter is the Walkera Devo line. These have much more capable CPUs than the various 9x boards: 32 bit ARMs at 72MHz with comparable amounts of storage. Some have 9x-like screen/button combos, others have touch screens. The deviationTx software runs on all of them. Settings are stored in a FAT file system that can be accessed as a USB drive. I'm thinking that a traditional configuration interface on the transmitter, storing the config information as program text. The only actual programming would be done by replacing the virtual channel/switch feature with expressions or short programs. ___ 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
