John D. Ramsdell wrote:
All I know is it was dog slow without
any annotations, and spaying them on the suspect data structures cured that
problem.
Ah ok, that makes sense :) although it's a bit unsatisfactory to be
forced to do that blindly.
Regards,
apfelmus
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
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
ChrisK wrote:
The data dependency is circular.
Yes and no. The input and outputs pairs are dependent on each other, but
the integer doesn't depend on the string. Thus, I'm pretty sure that
(Int, String) - (Int, String)
can be refactored into
Int - (Int, String - String)
This is
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
John D. Ramsdell wrote:
On Nov 17, 2007 3:04 PM, apfelmus [EMAIL PROTECTED]
mailto:[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,
John D. Ramsdell wrote:
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
The data dependency is circular. The case e of Str and Brk are not-circular:
layout examines the input parameters to determine column'. Then column'
is used to compute columnOut and s'. Then the current data is
prepended to s'. The Blo case is the circular one. Pushing the circular
Brent Yorgey wrote:
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 ?
Ah, that looks
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
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
John D. Ramsdell wrote:
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
John D. Ramsdell wrote:
This is another Haskell style question.
I had some trouble with the pretty printer that comes with GHC, so I
translated one written in Standard ML. I have already translated the
program into C, so rewriting it in Haskell was quick and easy for me.
Concerning the
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
14 matches
Mail list logo
