Re: [Haskell-cafe] Re: Knot tying vs monads
On Nov 19, 2007 11:42 AM, apfelmus <[EMAIL PROTECTED]> wrote: > Thanks. The interesting case of nested blocks still needs to be > specified, but with this description in mind and judging from the code, > I guess it behaves as follows: either a block fits entirely on the > remaining line (no line breaks inside), or it begins a new line. Yeah, breakdist does not look inside a block when computing the break distance. > On the strictness annotations, my reasons for them are the usual ones, > primarily to prevent memory leaks due to dragging, but a performance boost > is always welcome. At some point, I plan to profile the code with and > without the annotations, and find out where they are needed. That seems excessive. Can you really prove that this will prevent space > leaks? I doubt that. Ooh, I think I overstated my case. I meant to say that for my application, there are just a few data structures, such that if data traceable from them is strictly evaluated, I'm pretty sure I will have no space leaks. Currently it's just an intuition, but when the application is mature, I'll profile and validate this intuition. All I know is it was dog slow without any annotations, and spaying them on the suspect data structures cured that problem. Only careful profiling will tell which of those annotations can be removed. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Knot tying vs monads
Chris, You answer was quite a bit more than I expected for a simple style question. Thanks. On Nov 19, 2007 12:27 PM, ChrisK <[EMAIL PROTECTED]> wrote: > The data dependency is circular. Yes, thus the need for the knot. I gather your answer to my style question is you prefer knot tying over monads for this particular problem. By the way, it seems that the second line of your code was garbled, but it's easy to figure out what you meant. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Knot tying vs monads
On Nov 17, 2007 3:04 PM, apfelmus <[EMAIL PROTECTED]> wrote: > > Unfortunately, I don't have Paulson's book (or any other ML book :) at > home. I'm too lazy to figure out the specification from the source code, I guess the code is too opaque, as my colleague claimed. The layout the algorithm generates condensed indented blocks. Within a block, it inserts a newline when the distance to the next break point plus the current position is greater than the space remaining on the current line. Thus if S-Expression lists are rendered as blocks with indent two, and every element in a list is separated by a break point of length one, with the proper margin, you would see: (defthingy name-of-thingy (one thing) (two thing) (a-big-thing-made-bigger) (three thing) (four thing)) As an exercise, the book asks you to implement group indent, where if any break point in a group inserts a newline, they all do. So with that layout, one would get: (defthingy name-of-thingy (one thing) (two thing) (a-big-thing-made-bigger) (there thing) (four thing)) The C version I wrote supports this layout, but I didn't bother with that extension for the Haskell version. On the strictness annotations, my reasons for them are the usual ones, primarily to prevent memory leaks due to dragging, but a performance boost is always welcome. At some point, I plan to profile the code with and without the annotations, and find out where they are needed. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Knot tying vs monads
On Sat, 2007-11-17 at 13:30 -0500, John D. Ramsdell wrote: ... > It seems rather hard to avoid lazyness in the current version of > Haskell when it's not wanted. I hope one of the proposals for deep > strictness makes it into Haskell prime. In my application, there is > one datastructure, such that if every value tracable from an instance > of the datastructure is evaluated, I am quite sure my program will be > free from memory leaks due to dragging. I wish I could tell compilers > to make it so. Use strict constructors. Using strict data types is most probably the appropriate way to deal with many cases where you would want a deep seq. In particular, head strict lists would not be a bad addition. There is a library out there with several strict data types. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Knot tying vs monads
Thank you for your interesting reply. I found it enlightening. Compared to that, I'm missing the specification part for your pretty > printer. How's it supposed to lay out? The specification is in Paulson's book. The pretty printer is used with S-Expressions, and the block layout generates compact, indented output that is good when there is much data to be displayed. I played around with the Hughes pretty printer, but it wasn't obvious how to get the output I knew I could from the Paulson pretty printer. I confess I did not spend much time tinkering with the Hughes pretty printer. I failed to mention in my original note that the code was written so that the Haskell version lines up with the Standard ML version. The close connection between the Haskell and Standard ML versions is part of the reason I was able to quickly generate the code, and be confident in its correctness. It also explains why I did not use the sum function in the Prelude, or your map trick when writing the blo function. > What style do to you prefer, a knot-tying or a monad-based style? I > have enclosed the pretty printer. The printing function is the > subject of the controversy. ... a simple difference list ... will do. Hmm. Doesn't the output type (Int, String) -> (Int, String) show the implementation is using the essence of a difference list? Remember, the resulting function prepends something the string it is given in the second element of the pair, and returns that string. Introducing a difference list means to replace the output type > > (Int, String) -> (Int, String) > > of printing by > > Int -> (Int, String -> String) -- difference list > My first attempt at writing the printing function had a type similar to this one. I found myself composing difference lists of type ShowS. The performance was noticabily slow, specially as compared with the implementation displayed in my message. Perhaps the use of Data.DList would repair this performance problem. I don't mean to suggest that ShowS style difference lists cannot be used to make the function easier to understand--all I'm saying is my attempt to do so did not work out well. >> module Pretty(Pretty, pr, blo, str, brk) where > >> data Pretty >> = Str !String >> | Brk !Int -- Int is the number of breakable spaces >> | Blo ![Pretty] !Int !Int -- First int is the indent, second int >> -- is the number of chars and spaces for strings and breaks in block Drop those strictness annotations from !String and ![Pretty], they won't > do any good. The !Int are only useful if they will be unboxed, but I > wouldn't bother right now. I thought that the annotations ensure the first element of the list is evaluated. The Char and Pretty lists are generated with seqrev, so everything gets evaluated before constructor is applied to data. -- A reverse that evaluates the list elements. seqrev :: [a] -> [a] seqrev = foldl (\xs x -> x `seq` xs `seq` (x:xs)) [] The trouble is the constructors are not exported directly, but instead through str, brk, and blo, functions which are not strict. It's the best I could do, as near as I can tell. It seems rather hard to avoid lazyness in the current version of Haskell when it's not wanted. I hope one of the proposals for deep strictness makes it into Haskell prime. In my application, there is one datastructure, such that if every value tracable from an instance of the datastructure is evaluated, I am quite sure my program will be free from memory leaks due to dragging. I wish I could tell compilers to make it so. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Knot tying vs monads
> but isn't there a short text that describes in detail why foldl' is > different from foldl and why foldr is "better" in many cases? I thought > this faq would have been cached already :) > Perhaps you're thinking of http://haskell.org/haskellwiki/Stack_overflow ? -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
