Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
When I said "I stare at a particular section of the code for a while", I
meant it as an idiom for deeply studying that particular code alone. It's
just me and the code and whatever debugging tools I have readily
available.
Are you familiar with the difficulty in maintaining legacy platforms
written by a team which no longer exists? In some cases, it might be
required to completely rewrite the entire platform in another code base
(like Haskell) while maintaining the original behavior (including any and
all bugs or undocumented features) of the legacy software. In those cases,
"staring at the code" may be one of the better option because the code will
tell you most of what you need to know to recreate that software in another
platform.
Going back to the original thought, my curiosity has more to do about
Backus (he is cited quite a lot) and how much of his theory made it into
Haskell and other commonly used functional languages.
On Thu, Mar 21, 2013 at 12:36 AM, Albert Y. C. Lai wrote:
> On 13-03-20 06:54 PM, OWP wrote:
>
>> For me personally, one thing I enjoy about a typical procedural program
>> is that it allows me to "Brute Force Learn".
>>
> [...]
>
> 1. I believe that you can also stare at functional programs and figure out
> as much as what you can with procedural programs.
>
> It only requires knowing the language and the libraries. And you can no
> longer argue that functional languages are more declarative or higher level
> than procedural languages. Once upon a time, it was true, with
> parametricity, algebraic data types, higher-order functions, and list
> comprehensions; now procedural languages have them too or competitive
> alternatives.
>
> 2. I doubt how much you can learn from staring, be it functional programs
> or procedural programs.
>
> I posit that at most you're just reading aloud in your native tongue how
> to execute the program. But then you're just competing with a computer at
> its job. You barely know what requirement the program satisfies, much less
> why the program satisfies that requirement.
>
> (With the exception that the program contains no iteration or recursion,
> or contains just boring iteration or recursion such as walking over an
> array.)
>
> I do not mean that you lack jargons like "gradient" and "matrix", no. You
> can explain in your own words, if you know the right idea but just not the
> jargon. I am positing this: apart from telling me how to execute the
> program, you cannot explain the purpose of the program, not even in your
> own words, because you do not know.
>
> Here is an example I learned recently. It is ingenious.
>
> Let A, B be arrays of the same length N. Their elements are numbers. They
> use 0-based indexing. They are the input.
>
> int h=0, i=0, j=0;
> bool answer;
>
> while (h int Aih = A[(i+h) % N], Bjh = B[(j+h) % N];
>
> if (Aih == Bjh) {
> h = h + 1;
> } else if (Aih > Bjh) {
> i = i + h + 1;
> h = 0;
> } else { /* Aih < Bjh */
> j = j + h + 1;
> h = 0;
> }
> }
> answer = (h >= N);
>
> answer is the output. What does answer say about the input?
>
> The algorithm is no different in Haskell (it makes me use lowercase a, b,
> n):
>
> answer = go 0 0 0
> go h i j =
> if h case compare (a!((i+h) `mod` n)) (b!((j+h) `mod` n)) of
> EQ -> go (h+1) i j
> GT -> go 0 (i+h+1) j
> LT -> go 0 i (j+h+1)
> else h>=n
>
> 3. I completely refuse to believe that you literally do not know what
> you're doing before you start.
>
> If it were true, it must be like this: You throw dice 500 times to
> generate a 500-character file. If the compiler doesn't like it, you throw
> dice more times to decide what to mutate in that file. Eventually the
> compiler surrenders. Now, and only now, you stare at the file for a few
> minutes, and discover: it implements doubly linked list! It will be useful
> when you write your own web browser later, it can help provide the "back"
> button and the "forward" button...
>
> No, it has to be the other way round. You have to decide to attempt a web
> browser project or whatever in the first place. You are vague about
> details, what not to include, what to include, how to do them... but you
> know vaguely it's a web browser. After some time, you have to decide which
> part, however small, you start to code up. Maybe you decide to code up a
> doubly linked list first. Now you type up something. You type up something
> knowing that the short term goal is doubly linked list, and the long term
> goal is some kind of web browser or whatever project it is. This much you
> know. And while you type, every key you type you strive to get closer to a
> doubly linked list in good faith. Maybe sometimes you're creative, maybe
> sometimes you make mistakes, maybe you write clever code and I can't
> understand it, but it is not random typing, you know the purpose, you have
> reasons, you understand, and you don't just stare.
>
[Haskell-cafe] ANN: text-printer - abstract interface for text builders/printers
Hello, I was writing a library for working with IP addresses when I found myself puzzled with the number of contexts in which the textual representation of an address could be used: plain strings, bytestring builders (ASCII/UTF8), text builders, pretty printers, etc. I could've just written an `addressToString :: Address -> String` function, but that would be suboptimal: (a) namespace pollution (that's a lot of *ToString's if you count IPv4/6, network addresses, socket addresses, etc) and (b) some contexts can take advantage of the fact that textual representations are ASCII (e.g. UTF8 bytestring builder). And so the text-printer[1] was born. It is mainly two type classes. One for injecting text into a monoid, with special methods for ASCII and UTF-8 characters/strings. The other provides the default injection for values of a type (think of the `Pretty` type class in pretty printing libraries), the textual representation is supposed to be simple (single-line). Plus some convenient combinators and number formatters. [1] http://hackage.haskell.org/package/text-printer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: A Thought: Backus, FP, and Brute Force Learning
-- Forwarded message -- From: Eli Frey Date: Wed, Mar 20, 2013 at 4:56 PM Subject: Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning To: OWP I have not read Bacchus' paper, so i might be off the mark here. Functional code is just as simple (if not more so) to puzzle apart and understand as imperative code. You might find that instead of "stepping through the process" of code, you end up "walking the call graph" more often. FPers tend to break their problem into ever smaller parts before re-assembling them back together, often building their own vocabulary as they go. Not to say this is not done in imperative languages, but it is not so heavily encouraged and embraced. One result of this is that you can easily understand a piece of code in isolation, without considering it's place in some "process". It sounds as though you are not yet comfortable with this yet. So yes, you might have to learn more vocabulary to understand a piece of functional code. This is not because the inner workings are obfuscated, but because there are so many more nodes in the call graph that are given names. You can still go and scrutinize each of those new pieces of vocabulary by themselves and understand them without asking for the author to come down from on high with his explanation. Let's take iteration for example. In some imperative languages, people spend an awful lot of time writing iteration in terms of language primitives. You see a for loop. "What is this for loop doing?" you say to yourself. So you step through the loop imagining how it behaves as it goes and you say "Oh, this guy is walking through the array until he finds an element that matches this predicate." In a functional style, you would reuse some iterating function and give it functions to use as it is iterating. The method of iteration is still there, it has just nested into the call graph and if you've never seen that function name before you've got to go look at it. Again I don't mean to suggest that this isn't happening in an imperative language, just not to the same degree. As well there is a bit of a learning curve in seeing what a function "does" when there is no state or "doing" to observe in it. Once you get used to it, I believe you will find it quite nice though. You have probably heard FPers extolling the virtues of "declarative" code. When there is no state or "process" to describe, you end up describing what a thing is. I for one think this greatly increases readability. Good Luck! Eli On Wed, Mar 20, 2013 at 3:59 PM, OWP wrote: > I made an error. I meant FP to stand for Functional Programming, the > concept not the language. > > On Wed, Mar 20, 2013 at 6:54 PM, OWP wrote: > >> This thought isn't really related to Haskell specifically but it's more >> towards FP ideal in general. >> >> I'm new to the FP world and to get me started, I began reading a few >> papers. One paper is by John Backus called "Can Programming Be Liberated >> from the von Neumann Style? A Functional Style and It's Algebra of >> Programs". >> >> While I like the premise which notes the limitation of the von Neumann >> Architecture, his solution to this problem makes me feel queasy when I read >> it. >> >> For me personally, one thing I enjoy about a typical procedural program >> is that it allows me to "Brute Force Learn". This means I stare at a >> particular section of the code for a while until I figure out what it >> does. I may not know the reasoning behind it but I can have a pretty >> decent idea of what it does. If I'm lucky, later on someone may tell me >> "oh, that just did a gradient of such and such matrix". In a way, I feel >> happy I learned something highly complex without knowing I learned >> something highly complex. >> >> Backus seems to throw that out the window. He introduces major new terms >> which require me to break out the math book which then requires me to break >> out a few other books to figure out which bases things using archaic >> symbols which then requires me to break out the pen and paper to mentally >> expand what in the world that does. It makes me feel CISCish except >> without a definition book nearby. It's nice if I already knew what a >> "gradient of such and such matrix" is but what happens if I don't? >> >> For the most part, I like the idea that I have the option of Brute Force >> Learning my way towards something. I also like the declarative aspect of >> languages such as SQL which let's me asks the computer of things once I >> know the meaning of what I'm asking. I like the ability to play and learn >> but I also like the ability to declare this or that once I do learn. From >> Backus paper, if his world comes to a reality, it seems like I should know >> what I'm doing before I even start. The ability to learn while coding >> seems to have disappeared. In a way, if the von Neumann bottleneck wasn't >> there, I'm not sure programming would be as popula
[Haskell-cafe] Fwd: A Thought: Backus, FP, and Brute Force Learning
I always forget to reply-all :( -- Forwarded message -- From: Eli Frey Date: Thu, Mar 21, 2013 at 5:04 PM Subject: Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning To: OWP Ah, ye old "point free programming" [1]. Yes when you first see this stile it's a bit alarming. I think it's valid to say you shouldn't take this too far, but IMHO it is a good thing. If it is any more enlightening, it is good to think of this style like building shell pipelines. Depending on your disposition, that might make you more dismayed though :). Personally I like this style because it allows me to very rapidly prototype my ideas. When I am fleshing some solution out I will write it nearly entirely in this style. As I am throwing code around and refactoring, I will reevaluate things and name my pipes and their inputs and outputs where it makes sense to increase legibility. I am sure that Bacchus is serious about this, but have no fear. Just because you can do this does not mean you have to. You are still free to name your inputs and outputs as much as you please. However, no-one is forcing you to. There is a parallel in languages that have syntactic support for OOP. obj.dothis.dothat.andthis.andthat.andanotherthing There is just as much debate about how far to go with method chaining, and when to name intermediate values. [1] https://en.wikipedia.org/wiki/Tacit_programming On Thu, Mar 21, 2013 at 4:21 PM, OWP wrote: > Thank you for this reply. This thought is more about Backus (he is cited > quite a lot) and how much of his theory made it into Haskell and other > commonly used functional programming. > > In Backhu's paper ( > http://www.thocp.net/biographies/papers/backus_turingaward_lecture.pdf), > is his comparison between FP and Impertive as seen in 5.1 & 5.2 of > "Programs for Inner Product". > > When I start seeing that program described as: > > "Def Innerproduct = (Insert +) o (ApplyToAll x) o Transpose" > > I start getting queasy. When he later describes functional programming > main purpose is to expand on that, I get worried. When he later explains > how I don't need to use variables and just need to use "elementary > substitution rule" for everything, I'm wondering if he's really serious > about this. > > From what you say, it doesn't sound as bad and I hope it isn't as I learn > more. > > Thanks for the reply. > > On Wed, Mar 20, 2013 at 7:56 PM, Eli Frey wrote: > >> I have not read Bacchus' paper, so i might be off the mark here. >> >> Functional code is just as simple (if not more so) to puzzle apart and >> understand as imperative code. You might find that instead of "stepping >> through the process" of code, you end up "walking the call graph" more >> often. FPers tend to break their problem into ever smaller parts before >> re-assembling them back together, often building their own vocabulary as >> they go. Not to say this is not done in imperative languages, but it is >> not so heavily encouraged and embraced. One result of this is that you can >> easily understand a piece of code in isolation, without considering it's >> place in some "process". It sounds as though you are not yet comfortable >> with this yet. >> >> So yes, you might have to learn more vocabulary to understand a piece of >> functional code. This is not because the inner workings are obfuscated, >> but because there are so many more nodes in the call graph that are given >> names. You can still go and scrutinize each of those new pieces of >> vocabulary by themselves and understand them without asking for the author >> to come down from on high with his explanation. >> >> Let's take iteration for example. In some imperative languages, people >> spend an awful lot of time writing iteration in terms of language >> primitives. You see a for loop. "What is this for loop doing?" you say to >> yourself. So you step through the loop imagining how it behaves as it goes >> and you say "Oh, this guy is walking through the array until he finds an >> element that matches this predicate." In a functional style, you would >> reuse some iterating function and give it functions to use as it is >> iterating. The method of iteration is still there, it has just nested into >> the call graph and if you've never seen that function name before you've >> got to go look at it. Again I don't mean to suggest that this isn't >> happening in an imperative language, just not to the same degree. >> >> As well there is a bit of a learning curve in seeing what a function >> "does" when there is no state or "doing" to observe in it. Once you get >> used to it, I believe you will find it quite nice though. You have >> probably heard FPers extolling the virtues of "declarative" code. When >> there is no state or "process" to describe, you end up describing what a >> thing is. I for one think this greatly increases readability. >> >> Good Luck! >> Eli >> >> >> On Wed, Mar 20, 2013 at 3:59 PM, OWP wrot
Re: [Haskell-cafe] To seq or not to seq, that is the question
On Fri, Mar 08, 2013 at 08:53:15PM -0800, Edward Z. Yang wrote: > Are these equivalent? If not, under what circumstances are they not > equivalent? When should you use each? > > evaluate a >> return b > a `seq` return b > return (a `seq` b) > > Furthermore, consider: [...] > - Does the underlying monad (e.g. if it is IO) make a difference? [...] Here's a monad transformer DelayT which adds an "evaluate" operation to any monad. Perhaps it will help in understanding the situation. (NB it only has the desired behaviour for monads which must force x to at least WHNF before they can perform the action associated with x >>= f, so Identity won't do, for example). % cat evaluate.hs && ghc -fforce-recomp evaluate.hs && ./evaluate import Control.Monad.Trans.Class (lift, MonadTrans) data DelayT m a = DelayT (m a) deriving Show unlift :: DelayT m a -> m a unlift (DelayT x) = x instance Monad m => Monad (DelayT m) where return = lift . return x >>= f = lift $ unlift x >>= unlift . f instance MonadTrans DelayT where lift = DelayT evaluate :: Monad m => a -> DelayT m a evaluate = lift . (return $!) type M = Maybe should_succeed :: Bool should_succeed = x `seq` () == () where x :: DelayT M () x = evaluate undefined should_fail :: DelayT M () should_fail = evaluate undefined >> return () main = do putStrLn "Should succeed" print should_succeed putStrLn "Should fail" print should_fail [1 of 1] Compiling Main ( evaluate.hs, evaluate.o ) Linking evaluate ... Should succeed True Should fail evaluate: Prelude.undefined ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
The only safe way is acceptnig keys from people you know don't view pdf using adobe reader, who don't browse the web (neither use flash) etc. And then still you also have to know that their email account password is reasonable strong .. So whatever this thread is about - its only about making it harder to intentionally inject bad code. Also "signed by two people" - how to verify that two accounts/email addresses really belong to different people? - You understand the problem. Anyway - having signed packages is good, because attackers will be slower, they have to build up trust first .. So it will improve the situation a lot. I also would appreciate being able to get hash sums from the 00-index.tar. Then automatic packaging is much easier. Oh - and don't forgett the huge amount of code hackage has today. It may not be feasable to trust - check all code - but having the most used code checked by multiple parties alreday is a great improvement. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Tutorials at Commercial Users of Functional Programming 2013
There's still time to submit a tutorial proposal for Commercial Users of Functional Programming in Boston … http://cufp.org/cufp2013-call-tutorials Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thomp...@kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some advice around lazy IO
Hi folks, I've run into more issues with my report generation tool I'd really appreciate some help. I've created a repro project on github to demonstrate the problem. git://github.com/ckkashyap/haskell-perf-repro.git There is a template xml file that needs to be replicated several times (3000 or so) under the data directory and then "driver" needs to be run. The memory used by driver keeps growing until it runs out of memory. Also, I'd appreciate some tips on how to go about debugging this situation. I am on the windows platform. Regards, Kashyap On Tue, Mar 19, 2013 at 1:11 PM, Kim-Ee Yeoh wrote: > On Tue, Mar 19, 2013 at 2:01 PM, Konstantin Litvinenko > wrote: > > Yes. You (and Dan) are totally right. 'Let' just bind expression, not > > evaluating it. Dan's evaluate trick force rnf to run before hClose. As I > > said - it's tricky part especially for newbie like me :) > > To place this in perspective, one only needs to descend one or two > more layers before the semantics starts confusing even experts. > > Whereas the difference between seq and evaluate shouldn't be too hard > to grasp, that between evaluate and (return $!) is considerably more > subtle, as Edward Yang notified us 10 days ago. See the thread titled > To seq or not to seq. > > -- Kim-Ee > > ___ > 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] Announcement - HGamer3D - 0.2.1 - featuring FRP based GUI and more
Hi Johan, you are right all libraries could be compiled at least on Linux (maybe even Mac OS) and the bindings could be too. I simply have no time currently to mainain another platform. I started on Windows, because I like it and I thought its the platform with the most gamers. I got in troubles with the linux toolchain on Windows (gcc with Mingw) for Ogre and switched to the MSVC based Ogre libraries, not considering that possibly the Ogre Linux libraries directly on Linux might work well. If there is time or sombody volunteers a Linux version can be built, I'm quite sure. regards Peter Johan Holmquist schrieb: Looks nice! I am curious as to why this is Windows only. Of the listed libraries (Ogre, CEGUI, SFML, enet, BulletPhysics, Vect, netwire) none seem to be platform specific. Regards /Johan 2013/3/20 Ivan Perez : This is very cool. I've been keeping an eye on this library for a few months. Keep it on! On 19 March 2013 15:18, Heinrich Apfelmus wrote: Peter Althainz wrote: Dear All, I'm happy to announce release 0.2.1 of HGamer3D, the game engine with Haskell API, featuring FRP based API and FRP based GUI. The new FRP API is based on the netwire package. Currently only available on Windows: http://www.hgamer3d.org. Nice work! Of course, I have to ask: what influenced your choice of FRP library in favor of netwire instead of reactive-banana ? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - featuring FRP based GUI and more
Peter Althainz wrote: > you are right all libraries could be compiled at least on Linux > (maybe even Mac OS) and the bindings could be too. I simply have no > time currently to mainain another platform. I started on Windows, > because I like it and I thought its the platform with the most > gamers. I got in troubles with the linux toolchain on Windows (gcc > with Mingw) for Ogre and switched to the MSVC based Ogre libraries, > not considering that possibly the Ogre Linux libraries directly on > Linux might work well. If there is time or sombody volunteers a Linux > version can be built, I'm quite sure. Haskell is very good at writing portable code, but there are some things to keep in mind: * Use System.FilePath instead of string operations, * use a portable media library like SDL, * when using System.IO or Control.Concurrent modules, pay attention to the Haddock documentation. That should make your library portable enabling you to reach a much larger portion of the Haskell community. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announcement - HGamer3D - 0.2.1 - why netwire
Peter Althainz wrote: Dear All, I'm happy to announce release 0.2.1 of HGamer3D, the game engine with Haskell API, featuring FRP based API and FRP based GUI. The new FRP API is based on the netwire package. Currently only available on Windows: http://www.hgamer3d.org. Nice work! Of course, I have to ask: what influenced your choice of FRP library in favor of netwire instead of reactive-banana ? Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com Hi Heinrich good question, actually I need to thank you for your excellent tutorials on FRP and GUI on the WEB. I tried the version of reactive-banana without switches as the first FRP framework to have contact with and I liked its simplicity and the cool introduction around Excel cells you gave on the Web. HGamer3D is my personal way to get more insight into FP and Haskell especially and from the beginning I wanted to have a FRP API to try it with game examples. So your intro on FRP and the examples were very helpful with that. After reading a lot on the web it became clear, that currently reactive-banana and netwire are good candidates to start with. So why in the end I decided to use netwire for the binding? It's some personal things and I do not claim to have done a proper evaluation or comparison. I also cannot judge on performance or other relevant topics. Having said that, I can give you some points why I choosed netwire: - The cool simplicity of reactive-banana API seems to have suffered a little bit after the introduction of the switch functionality. - After getting around Monads and Applicative by great help of "Learning a Haskell for great good" I was shocked to see, there is even more to learn, when I detected Arrows. So I started to look at it and discovered some nice tutorials for Arrows. - What struck me was introduction of netwire author Ertugrul Söylemez on Arrows and the explanations of local state, which can be kept into an arrow. Since I was also curious on OOP and FP and game state handling, actually this raised some interest. So I think this "Arrows keep local state" argument was the killer feature. But also behaviours keep local state and maybe I got misguided here. - I then did some trials with netwire and I felt it's a quite comprehensive and nice API, so I got started with that. regards Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - why netwire
Peter Althainz wrote: > - What struck me was introduction of netwire author Ertugrul Söylemez > on Arrows and the explanations of local state, which can be kept into > an arrow. Since I was also curious on OOP and FP and game state > handling, actually this raised some interest. So I think this "Arrows > keep local state" argument was the killer feature. But also behaviours > keep local state and maybe I got misguided here. It's not arrows that keep local state, but it's specifically the automaton arrows, in particular Auto and Wire. Both are automaton arrows. One way to express Auto is the following: data Auto a b = forall s. Auto s ((a, s) -> (b, s)) Similarly Wire can be expressed like that (simplified): data Wire a b = forall s. Wire s ((a, s) -> (Maybe b, s)) Both contain a local state value and a transition function. That's why they are called automaton arrows. > - I then did some trials with netwire and I felt it's a quite > comprehensive and nice API, so I got started with that. Thanks. =) Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Compiled code
Suppose I compiled some module and kept it's .hi and .o files. Is it possible to use this module in my program if the source code was deleted for some reason? Seems like the answer is "yes" — by creating a fake .hs file (with no real content) and touch-in .hi and .o files I tricked ghc so that it didn't attempt to recompile the module, so the information in .hi and .o files is sufficient. But ghc insists on having the .hs file around, and I didn't find a way to turn it off. Is there any? Or there is a specific reason not to allow this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiled code
Sorry, I think that's not the right list for this question. Отправлено с iPhone 23.03.2013, в 2:04, MigMit написал(а): > Suppose I compiled some module and kept it's .hi and .o files. Is it possible > to use this module in my program if the source code was deleted for some > reason? > > Seems like the answer is "yes" — by creating a fake .hs file (with no real > content) and touch-in .hi and .o files I tricked ghc so that it didn't > attempt to recompile the module, so the information in .hi and .o files is > sufficient. But ghc insists on having the .hs file around, and I didn't find > a way to turn it off. Is there any? Or there is a specific reason not to > allow this? > ___ > 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] Compiled code
MigMit wrote: > Suppose I compiled some module and kept it's .hi and .o files. Is it > possible to use this module in my program if the source code was deleted for > some reason? > > Seems like the answer is "yes" The answer is yes as long as the compiler version and the versions of all libraries your orignal .hs file used remain the same. As soon as any of these versions change, you need the full original .hs file. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiled code
Erik de Castro Lopo wrote: > MigMit wrote: > > > Suppose I compiled some module and kept it's .hi and .o files. Is it > > possible to use this module in my program if the source code was deleted > > for some reason? > > > > Seems like the answer is "yes" > > The answer is yes as long as the compiler version and the versions of > all libraries your orignal .hs file used remain the same. As soon as > any of these versions change, you need the full original .hs file. If you change the compiler flags (eg optimisation levels) you will also need the full original .hs file. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] question about PutM patterns
Hello, cafe.
I have a big problem using builders, so currently I'm using own
builder based on Nettle one [1].
It uses Strict bytestring to build into and unchecked writes, thus
it's very unsafe, plus other
builders/PutM, developed rapidly so I like to switch to another one.
However I use some patterns that seems not implemented in other
builders, so I'd like to hear
advices how to implement it there or how I can write code without using them.
All of the patterns is done in order to have more performance and
gives a way to build complex
data without additional allocations.
1). Delayed input:
This unsafe pattern can be implemented in any PutM monad for any
constant sized value,
the idea is that we write a plaseholder and returns a funtion that
will write correct value to the
address when applied. This pattern is needed when we need to update
length or CRC sum after
content is written:
> test1 put = delayedWord16be >>= \ph -> someOtherStuff >> undelay ph
> calculateCRC
2). LookAhead:
Sometimes I need to know the length of the content to be written,
possibly I can write content
to ByteString, and calculate length and write it, however if resulting
type is not LBS it leads to
additional allocations and memory move. For PutM a special wrapper can
be written
withLength :: a {- length type -} -> PutM () -> PutM ().
Or special data structure and delayed input can be used, special data
structure is Marker, it
marks a place in datastructure allowing to calculate distances, it
works very efficiently with
ByteString, but I have no idea how to implement it with LBS:
> test1 put = delayedWord32be >>= \ph -> marker -> \m -> put >> distance m >>=
> undelay . fromIntegral
3). LookBehind
Returning back to crc calculation I had to use additional pattern,
it's a lookback: I need to inspect
unfinished data, that I've already have written, I have not done
correct wrappers so I've used markers
and fromForeignPtr from ByteString.Internal:
> test3 = do
>m <- marker
>somestuff
>d <- distance marker
>let crc = (unsafePerformIO $ BS.unsafePackAddressLen hlen' (toAddr m))
--
Alexander
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some advice around lazy IO
I got some profiling done and got this pdf generated. I see unhealthy growths in my XML parser. On Fri, Mar 22, 2013 at 8:12 PM, C K Kashyap wrote: > Hi folks, > > I've run into more issues with my report generation tool I'd really > appreciate some help. > > I've created a repro project on github to demonstrate the problem. > git://github.com/ckkashyap/haskell-perf-repro.git > > There is a template xml file that needs to be replicated several times > (3000 or so) under the data directory and then "driver" needs to be run. > The memory used by driver keeps growing until it runs out of memory. > > Also, I'd appreciate some tips on how to go about debugging this > situation. I am on the windows platform. > > > Regards, > Kashyap > > > On Tue, Mar 19, 2013 at 1:11 PM, Kim-Ee Yeoh wrote: > >> On Tue, Mar 19, 2013 at 2:01 PM, Konstantin Litvinenko >> wrote: >> > Yes. You (and Dan) are totally right. 'Let' just bind expression, not >> > evaluating it. Dan's evaluate trick force rnf to run before hClose. As I >> > said - it's tricky part especially for newbie like me :) >> >> To place this in perspective, one only needs to descend one or two >> more layers before the semantics starts confusing even experts. >> >> Whereas the difference between seq and evaluate shouldn't be too hard >> to grasp, that between evaluate and (return $!) is considerably more >> subtle, as Edward Yang notified us 10 days ago. See the thread titled >> To seq or not to seq. >> >> -- Kim-Ee >> >> ___ >> 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] Need some advice around lazy IO
Oops...I sent out the earlier message accidentally. I got some profiling done and got this pdf generated. I see unhealthy growths in my XML parser. https://github.com/ckkashyap/haskell-perf-repro/blob/master/RSXP.hs I must be not using parsec efficiently. Regards, Kashyap On Sat, Mar 23, 2013 at 11:07 AM, C K Kashyap wrote: > I got some profiling done and got this pdf generated. I see unhealthy > growths in my XML parser. > > > > On Fri, Mar 22, 2013 at 8:12 PM, C K Kashyap wrote: > >> Hi folks, >> >> I've run into more issues with my report generation tool I'd really >> appreciate some help. >> >> I've created a repro project on github to demonstrate the problem. >> git://github.com/ckkashyap/haskell-perf-repro.git >> >> There is a template xml file that needs to be replicated several times >> (3000 or so) under the data directory and then "driver" needs to be run. >> The memory used by driver keeps growing until it runs out of memory. >> >> Also, I'd appreciate some tips on how to go about debugging this >> situation. I am on the windows platform. >> >> >> Regards, >> Kashyap >> >> >> On Tue, Mar 19, 2013 at 1:11 PM, Kim-Ee Yeoh wrote: >> >>> On Tue, Mar 19, 2013 at 2:01 PM, Konstantin Litvinenko >>> wrote: >>> > Yes. You (and Dan) are totally right. 'Let' just bind expression, not >>> > evaluating it. Dan's evaluate trick force rnf to run before hClose. As >>> I >>> > said - it's tricky part especially for newbie like me :) >>> >>> To place this in perspective, one only needs to descend one or two >>> more layers before the semantics starts confusing even experts. >>> >>> Whereas the difference between seq and evaluate shouldn't be too hard >>> to grasp, that between evaluate and (return $!) is considerably more >>> subtle, as Edward Yang notified us 10 days ago. See the thread titled >>> To seq or not to seq. >>> >>> -- Kim-Ee >>> >>> ___ >>> Haskell-Cafe mailing list >>> Haskell-Cafe@haskell.org >>> http://www.haskell.org/mailman/listinfo/haskell-cafe >>> >> >> > driver.pdf Description: Adobe PDF document ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some advice around lazy IO
Hi Kashyap I am not sure if this solution to your problem but try using Bytestring rather than String in parseXML' :: String -> XMLAST parseXML' str = f ast where ast = parse (spaces >> xmlParser) "" str f (Right x) = x f (Left x) = CouldNotParse Also see this post[1] My Space is Leaking.. Regards, Mukesh Tiwari [1] http://www.mega-nerd.com/erikd/Blog/ On Sat, Mar 23, 2013 at 11:11 AM, C K Kashyap wrote: > Oops...I sent out the earlier message accidentally. > > I got some profiling done and got this pdf generated. I see unhealthy > growths in my XML parser. > https://github.com/ckkashyap/haskell-perf-repro/blob/master/RSXP.hs > I must be not using parsec efficiently. > > Regards, > Kashyap > > > > > On Sat, Mar 23, 2013 at 11:07 AM, C K Kashyap wrote: > >> I got some profiling done and got this pdf generated. I see unhealthy >> growths in my XML parser. >> >> >> >> On Fri, Mar 22, 2013 at 8:12 PM, C K Kashyap wrote: >> >>> Hi folks, >>> >>> I've run into more issues with my report generation tool I'd really >>> appreciate some help. >>> >>> I've created a repro project on github to demonstrate the problem. >>> git://github.com/ckkashyap/haskell-perf-repro.git >>> >>> There is a template xml file that needs to be replicated several times >>> (3000 or so) under the data directory and then "driver" needs to be run. >>> The memory used by driver keeps growing until it runs out of memory. >>> >>> Also, I'd appreciate some tips on how to go about debugging this >>> situation. I am on the windows platform. >>> >>> >>> Regards, >>> Kashyap >>> >>> >>> On Tue, Mar 19, 2013 at 1:11 PM, Kim-Ee Yeoh wrote: >>> On Tue, Mar 19, 2013 at 2:01 PM, Konstantin Litvinenko wrote: > Yes. You (and Dan) are totally right. 'Let' just bind expression, not > evaluating it. Dan's evaluate trick force rnf to run before hClose. As I > said - it's tricky part especially for newbie like me :) To place this in perspective, one only needs to descend one or two more layers before the semantics starts confusing even experts. Whereas the difference between seq and evaluate shouldn't be too hard to grasp, that between evaluate and (return $!) is considerably more subtle, as Edward Yang notified us 10 days ago. See the thread titled To seq or not to seq. -- Kim-Ee ___ 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
