hi guys,
may i know how to use recursive in a function. for example i have a function lets call it old which accept [[Bool]]->[(Int),(Int)]->(Int,Int) and return [(Int),(Int)]
and now i have another function lets say its called new, which calls the previous function and new will recursively check
>
> hi guys,
> may i know how to use recursive in a function. for example i have a function lets
> call it old which accept [[Bool]]->[(Int),(Int)]->(Int,Int) and return
> [(Int),(Int)]
> and now i have another function lets say its called new, which calls the previous
> function and new will r
On Thursday, 2003-08-21, 13:32, CEST, Keith Wansbrough wrote:
> [...]
> BTW: please post in plain ASCII, not HTML - this should be an option in
> Hotmail somewhere. It makes it easier for people to read your messages and
> reply to them.
Or post both, plain text and HTML, in combination. Users o
On 2003-08-23 at 20:14+0200 Wolfgang Jeltsch wrote:
> On Thursday, 2003-08-21, 13:32, CEST, Keith Wansbrough wrote:
> > [...]
>
> > BTW: please post in plain ASCII, not HTML [...]
>
> Or post both, plain text and HTML, in combination. Users
> of HTML-capable mail clients will be able to read your
Does the following code increase the level of recursion
once for each input line or is the recursive construct
converted to an iteration?
Thanks,
Dave Feustel
main :: IO ()
main = do
line <- getLine
processIt line
main
processIt :: String -> IO ()
processIt s = do
print (le
Is the call to "go" in the following code considered as tail recursion?
data DList a = DLNode (DList a) a (DList a)
mkDList :: [a] -> DList a
mkDList [] = error
<http://haskell.org/ghc/docs/latest/html/libraries/base/Prelude.html#v:error>
"must have at least one element&
functions...
The idea, I thought, is tail recursion, so perhaps I just have a big bug in my
code, caused by the fact, that it needs even for 5000 approximately 100MB
memory:
--
import Data.Array
main :: IO ()
main = putStr $! unlines $! map show $! filter snd
$! zip [1..] $! elems $! calc
On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Does the following code increase the level of recursion
once for each input line or is the recursive construct
converted to an iteration?
Thanks,
Dave Feustel
main :: IO ()
main = do
line <- getLine
processIt line
main
) you will get an
iteration instead of a recursion, but consider instead this:
main = do
input = readFile stdin
let r = map processit (lines input)
putStrLn (unlines s)
For more details, see:
http://blogs.nubgames.com/code/?p=22
On Tuesday 06 March 2007 11:52, Bryan Burgers
On 3/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Does the following code increase the level of recursion
once for each input line or is the recursive construct
converted to an iteration?
As was pointed out, tail recursion in Haskell isn't straightforward.
The answer may als
hiya
I was wondering how I would get the second function do recursively do the
function for poolNews xs tried that and it fails.
Ryan
--Give wins, draws a rating.
poolNews :: Result -> PoolNews -> PoolNews
poolNews (a,b,c,d,e) (home,away,goaless,scoredraw)
| c > d = (h
Hi,
Haskell compilers optimize tail recursive functions as cycles, which
improves both memory and CPU complexity. However, it's easy to make a
mistake and break the conditions under which a function can be tail
recursive and thus optimized. Is there a way to tell a Haskell
compiler that a functi
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 m
Daryoush Mehrtash wrote:
Is the call to "go" in the following code considered as tail recursion?
data DList a = DLNode (DList a) a (DList a)
mkDList :: [a] -> DList a
mkDList [] = error "must have at least one element"
mkDList xs = let (first,last) = go last xs first
A conversation on #haskell just showed that it's quite hard to explain
(at least it is for me) to people attached to tail recursion why that is
a red herring in Haskell.
I had a poke around the wiki and couldn't see a page which explains it
clearly. In fact
http://www.haskell.org/h
H. <[EMAIL PROTECTED]> writes:
> Hello @ all,
>
> Sometimes one has an imperative algorithm, and wants to write a program in
> Haskell which do has the same effect...
>
> So the question is - how a construct as the following can efficiently be
> written?
>
> --
> Pseudo code:
> n[1..1]
Jon Fairbairn cl.cam.ac.uk> writes:
> The idea in Haskell is not to think of stepping through the
> array. Look at accumArray and ixmap.
Thanks for your answer.
But I can't really see how the calc-function can be written more efficiently
with accumArray or ixmap, perhaps you can write it as an
H. <[EMAIL PROTECTED]> writes:
> Jon Fairbairn cl.cam.ac.uk> writes:
> > The idea in Haskell is not to think of stepping through the
> > array. Look at accumArray and ixmap.
>
> Thanks for your answer.
>
> But I can't really see how the calc-function can be written more efficiently
> with acc
"Simon Brenner" <[EMAIL PROTECTED]> writes:
> The key is letting haskell be lazy and produce the output one item at
> a time.
True.
> This solution goes up to 100k in 25M of heap and up to 400k in 200M of
> heap. While working better, the space requirement seems to be (at
> least almost) quadrati
Simon Brenner student.liu.se> writes:
> > listOfIndices' ubound = concat [ [i,(2*i) .. ubound] | i <- [1..ubound] ]
> > calc ubound = accumArray (const.not) False (1,ubound) $
> > [(x,False) | x <- listOfIndices ubound]
Thanks a lot!
Your solution works fine as long as there are not to much
I won't speak for anyone else, but I remember when recursion first
"clicked". It was in a 400-level data structures and algorithms class.
I had already done a fair amount of chess programming (which of course
does a massive amount of recursion), but it still seemed a bit magical
Hi
I understand the basic principle of recursion but have difficulty
with the following:
-- a recursive function
-- for calculating the length of lists
myLen [] = 0
myLen (x:xs) = 1 + myLen xs
What's happening here?
Top marks for a comprehensive jargon-free explanation.
Thanks in advance
Looks to me like you want:
poolNewsB = foldr poolNews (0,0,0,0)
On Nov 10, 2007 11:54 AM, Ryan Bloor <[EMAIL PROTECTED]> wrote:
>
> hiya
>
> I was wondering how I would get the second function do recursively do the
> function for poolNews xs tried that and it fails.
>
> Ryan
>
>
>
>
> --Give
On Nov 10, 2007 11:54 AM, Ryan Bloor <[EMAIL PROTECTED]> wrote:
> hiya
>
> I was wondering how I would get the second function do recursively do the
> function for poolNews xs tried that and it fails.
>
> Ryan
>
>
>
> --Give wins, draws a rating.
>
>
>
> poolNews :: Result
> *->* PoolNews *->*
I was wondering why Parsec's buildExpressionParser doesn't allow
prefix expressions to be handled recursively, e.g. given a prefix "!"
operation, it seems that "!!a" could parse without requiring
parentheses ("!(!a)"). Is there an easy way to extend it? (I have a
rich expression grammar I'd
Am Samstag, 23. August 2003 22:42 schrieb Jon Fairbairn:
> On 2003-08-23 at 20:14+0200 Wolfgang Jeltsch wrote:
> > On Thursday, 2003-08-21, 13:32, CEST, Keith Wansbrough wrote:
> > > [...]
> > >
> > > BTW: please post in plain ASCII, not HTML [...]
> >
> > Or post both, plain text and HTML, in com
ive... for instance, one of foldr/foldl is and the other
isn't.)
5. Are there any examples/patterns anywhere that illustrate standard
tail-recursion practice in Haskell?
Thanks!
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.hask
> intermediate thunk has already been built. You need a separate "strict
> foldl" function, usually called foldl', which was unaccountably
> omitted from the prelude.
There is one in Data.List.
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.
I'm missing something, a functional idiom, whatever. I know there's
"length" to count the elements in a list and it works fine, but the
function below stack overflows on a large list.
countLines [] = 0
countLines (_:ls) = 1 + countLines ls
I would have thought that this was tail recursive a
* Martin Drautzburg [2013-02-20 08:13:16+0100]
> 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?
The trick in this case is that ghci doesn't use a recursive descent
parser — it uses
nswered.
>
> 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,
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
* Tillmann Rendel [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
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
* Tillmann Rendel [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
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
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 wrote:
> Did you see ex
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
Sweden, May
24-30, 1995, Tutorial Text},
editor = {Johan Jeuring and Erik Meijer},
volume = {925},
series = {Lecture Notes in Computer Science},
publisher = {Springer},
isbn = {3-540-59451-5},
}
Most left recursion stems from the fact that conventional CFG notation is
sufficient, but
On Wednesday, 20. February 2013 09:59:47 Tillmann Rendel wrote:
>
> 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
Hi Martin,
Martin Drautzburg wrote:
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.
Just a silly quick question: why isn't right-recursion a si
* Martin Drautzburg [2013-02-24 12:31:37+0100]
> > > 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 con
On Sun, Feb 24, 2013 at 7:09 PM, Roman Cheplyaka wrote:
> Thus, your
> recursion is well-founded — you enter the recursion with the input
> strictly smaller than you had in the beginning.
>
Perhaps you meant /productive/ corecursion? Because the definition "A ::= B
A&qu
* Kim-Ee Yeoh [2013-02-24 19:22:33+0700]
> On Sun, Feb 24, 2013 at 7:09 PM, Roman Cheplyaka wrote:
>
> > Thus, your
> > recursion is well-founded — you enter the recursion with the input
> > strictly smaller than you had in the beginning.
> >
>
> Perhap
* Kim-Ee Yeoh [2013-02-24 19:22:33+0700]
> On Sun, Feb 24, 2013 at 7:09 PM, Roman Cheplyaka wrote:
>
> > Thus, your
> > recursion is well-founded — you enter the recursion with the input
> > strictly smaller than you had in the beginning.
> >
>
> Perhap
ictly smaller" input. I don't see any of this.
That's when I remembered that well-founded recursion (a desirable) is
sometimes confused with productive corecursion (another desirable).
-- Kim-Ee
___
Haskell-Cafe mailing list
Haskell-Caf
cent
parsers (as recursive functions) which parse a left-recursive and a
non-left-recursive grammars, and see in which case the recursion is
well-founded and why.
Roman
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On Sun, Feb 24, 2013 at 8:03 PM, Roman Cheplyaka wrote:
> It may become more obvious if you try to write two recursive descent
> parsers (as recursive functions) which parse a left-recursive and a
> non-left-recursive grammars, and see in which case the recursion is
> well-fou
On Sun, Feb 24, 2013 at 6:31 AM, Martin Drautzburg wrote:
> Just a silly quick question: why isn't right-recursion a similar problem?
>
Very roughly:
Left recursion is: let foo n = n + foo n in ...
Right recursion is: let foo 1 = 1; foo n = n + foo (n - 1) in ...
In short, m
Just n1 -> case parseA (drop n1 text) of
Nothing -> Nothing
Just n2 -> Just (n1 + n2)
Note that parseA is recursive. The recursion is well-founded if (drop n1
text) is smaller then text. So we have two cases, as Roman wrote:
If the language defined by B contains t
On Sun, Feb 24, 2013 at 10:04 PM, Tillmann Rendel <
ren...@informatik.uni-marburg.de> wrote:
> The recursion is well-founded if (drop n1 text) is smaller then text. So
> we have two cases, as Roman wrote:
>
> If the language defined by B contains the empty string, then n1
peaking, this is the same as magically knowing when to use
the inductive hypothesis vs when to bottom out at a base case. Using this
grammar as-is, the recursive descent parser always decides to use the
inductive hypothesis. Hence, infinite loop.
It should be apparent that this isn't an issue with left
On Sunday, 24. February 2013 16:04:11 Tillmann Rendel wrote:
> Both approaches are essentially equivalent, of course: Before
> considering the very same nonterminal again, we should have consumed at
> least one token.
I see. Thanks
So for the laymen:
expr ::= expr "+" expr
is a problem, becaus
2013/2/26 Martin Drautzburg :
> I wonder if I can enforce the nonNr property somehow, i.e. enforce the rule
> "will not consider the same nonterminal again without having consumed any
> input".
You might be interested in this paper:
Danielsson, Nils Anders. "Total parser combinators." ACM Sigpl
Hi
Another alternative is this Haskell library: https://github.com/paulcc/xsaiga
This is a combinator library which is suitable for mid-scale NLP work,
so handles left recursion and (high amounts of) ambiguity to produce a
packed result (which can be decoded to a list of results if required).
It
tor library which is suitable for mid-scale NLP work,
> so handles left recursion and (high amounts of) ambiguity to produce a
> packed result (which can be decoded to a list of results if required).
> It uses a technique similar to Danielsson's for termination.
>
> The technic
This page [1] has useful info on it. Having done a lot of lisp/ocaml
before coming to Haskell I was also very attached to tail recursion;
it took a long time to realise this was wrong. This topic definitely
needs more prominence on the wiki.
- Joe
[1] http://www.haskell.org/haskellwiki
On Fri, 18 May 2007 01:52:11 -0700, Jules Bean <[EMAIL PROTECTED]>
wrote:
A conversation on #haskell just showed that it's quite hard to explain
(at least it is for me) to people attached to tail recursion why that is
a red herring in Haskell.
If someone has the energy and the
Jules Bean wrote:
A conversation on #haskell just showed that it's quite hard to explain
(at least it is for me) to people attached to tail recursion why that is
a red herring in Haskell.
What is tail recursion?
Suppose
(1)x = f y x
A participant of the said conversation class
g for
the function '(:)', which when given two arguments, the first of which
is 1, will evaluate to its second. I don't really see these as being
the same expression.
Define
(2)cs = 'c' : cs
Is (2) a tail recursion?
No, for the same reason discussed above: you
+ xs
> | |
> z x
>
> foldr f z (x:xs) = f x (foldr f z xs)
>
> f-+--+
> | |
> x foldr-+--+--+
>| | |
>f z xs
>
> Tail recursion, then, expresses the idea that a function appears at
> the top of its call stack, or at
Ilya Tsindlekht <[EMAIL PROTECTED]> writes:
> On Sat, May 19, 2007 at 04:10:29PM +0100, Jon Fairbairn wrote:
> [...]
> >
> > > foldl f z l = case l of
> > (x:xs) -> foldl f (f z x) xs
> > [] -> z
> >
> > which reveals that foldl in the RHS isn't really the
> > lef
Ilya Tsindlekht <[EMAIL PROTECTED]> writes:
> On Sat, May 19, 2007 at 09:16:46PM +0100, Jon Fairbairn wrote:
> > Ilya Tsindlekht <[EMAIL PROTECTED]> writes:
> > > By definition, tail recursive function is recursive function in which
> > > the value returned from a recursive call is immediately ret
The key is letting haskell be lazy and produce the output one item at
a time. My solution below generates a list of all indices to be
inversed (with indices being duplicated as appropriate), then for each
index in that list inverses the corresponding element in the array.
The list can be written c
Hi Andrew,
You wrote:
combine :: [Int] -> [Int] -> [[Int]]
combine [] _ = []
combine (x:xs) ys = (take x ys) : (combine xs (drop x ys))
...A much more experienced haskeller told me he
preferred to write it like this:
combine' :: [Int] -> [Int] -> [[Int]]
combine' xs ys = snd $ mapAccumL aux ys
On 31/01/07, Andrew Wagner <[EMAIL PROTECTED]> wrote:
Like I said, I'm familiar with map, foldr, etc. But this is the
first time it's dawned on me that I need to think in more general
recursive patterns like this instead of simple, raw recursion. That
map and foldr aren'
kinga and Patterson's "Functional Programming with Bananas,
Lenses and Barbed Wire," which makes the comparison between arbitrary
recursion and goto early on, and develops four replacement operators
(cata-, ana-, hylo-, and paramorphisms). At the time, I was involved
in teaching
On Feb 17, 2007, at 21:32 , P. R. Stanley wrote:
Hi
I understand the basic principle of recursion but have difficulty
with the following:
-- a recursive function
-- for calculating the length of lists
myLen [] = 0
myLen (x:xs) = 1 + myLen xs
What's happening here?
This definition
prstanley:
> Hi
> I understand the basic principle of recursion but have difficulty
> with the following:
> -- a recursive function
> -- for calculating the length of lists
> myLen [] = 0
> myLen (x:xs) = 1 + myLen xs
So this is a definition for the 'length' fu
on.
I think the trick here is to see that "[1]" is exactly the same as "1:
[]". Once you grasp this, the rest will probably easy.
Good luck!
-chris
On 17 Feb, 2007, at 19:32 , P. R. Stanley wrote:
Hi
I understand the basic principle of recursion but have difficulty
wit
erminology, stipulates that the
recursion ends with an empty list and returns 0. Simple though one
question - why does mylen require the parentheses even when it is
evaluating the length of [...]? I can understand the need for them
when dealing with x:... because of the list construction function
On Feb 18, 2007, at 21:26 , P. R. Stanley wrote:
mylen (x:y) = 1 + mylen y
The base case, if that is the right terminology, stipulates that
the recursion ends with an empty list and returns 0. Simple though
one question - why does mylen require the parentheses even when it
is evaluating
if that is the right terminology, stipulates that the
recursion ends with an empty list and returns 0. Simple though one
question - why does mylen require the parentheses even when it is
evaluating the length of [...]? I can understand the need for them when
dealing with x:... because o
On Feb 18, 2007, at 21:44 , Michael Vanier wrote:
I think what you're asking here is why you need the parens around
(x:y) in the second case. Function application doesn't use
parentheses
Function application never applies to pattern matching.
The usual answer to this is "category theory"
Brandon S. Allbery KF8NH wrote:
On Feb 18, 2007, at 21:44 , Michael Vanier wrote:
I think what you're asking here is why you need the parens around
(x:y) in the second case. Function application doesn't use parentheses
Function application never applies to pattern matching.
You're right
Chaps,
is there another general pattern for mylen, head or tail?
mylen [] = 0
mylen (x:xs) = 1 + mylen (xs)
head [] = error "what head?"
head (x:xs) = x
tail [] = error "no tail"
tail (x:xs)= xs
This pattern matching reminds me of a module on formal spec I studied
at college.
What are the pre
functional style of programming (which is what you really
should be working on at this point), the book _Structure and Interpretation of
Computer Programs_ by Abelson and Sussman (which uses Scheme, not Haskell) is
very valuable. For learning about recursion, the book _The Little Schem
On Feb 18, 2007, at 22:22 , P. R. Stanley wrote:
is there another general pattern for mylen, head or tail?
Those are basically it, aside from optionally replacing the unused
variables with _.
What are the pre-requisites for Lambda calculus?
Lambda calculus isn't related to what's norma
now.
For absorbing the functional style of programming (which is what you
really should be working on at this point), the book _Structure and
Interpretation of Computer Programs_ by Abelson and Sussman (which uses
Scheme, not Haskell) is very valuable. For learning about recursion,
the book
>
> For absorbing the functional style of programming (which is what you really
> should be working on at this point),
For functional style and the reasoning attitude associated with lazy
functional programming, the following book is a good introduction:
@Book{Bird-2000,
author = {Richard
of course stylistic variations possible, e.g. you can use case
instead of pattern bindings:
mylen list = case list of
[] -> 0
(x:xs) -> 1 + mylen (xs)
As you see, this moves pattern matching from the lhs to the rhs of the
equation. Another very common 'pattern' is to fa
gt; Another very common 'pattern' is to factor the recursion into a
> generic higher order function
>
> fold op z [] = z
> fold op z (x:xs) = x `op` (fold op z xs)
> -- parentheses not strictly necessary here, added for readability
>
> and define mylen in terms of f
On Sat, 23 Aug 2003 23:21:26 +0200
Ralf Hinze <[EMAIL PROTECTED]> wrote:
> Am Samstag, 23. August 2003 22:42 schrieb Jon Fairbairn:
>
> > On 2003-08-23 at 20:14+0200 Wolfgang Jeltsch wrote:
> > > On Thursday, 2003-08-21, 13:32, CEST, Keith Wansbrough wrote:
> > > > [...]
> > > >
> > > > BTW: plea
functions have
time/space properties like their sources in the Haskell report,
but I'm not sure if there are exceptions.
But as I said, non-tail recursion is not necessarily a problem. Most
functions are suitable for large lists even if they are not tail
recursive; when they use O(N) memory, it&#x
tterns anywhere that illustrate standard
tail-recursion practice in Haskell?
i'd imagine these would be much the same as in o'caml.
a common functional programming pattern when you get tail recursion is
to rewrite a function using an accumulator (i.e. a bit of local state)
hat is the proper way to solve this little problem then?
Would foldl suffer from the same issue?
> >5. Are there any examples/patterns anywhere that illustrate standard
> >tail-recursion practice in Haskell?
>
> i'd imagine these would be much the same as in o'caml.
> a
r a
particular recursive function is tail-recursive?
As far as I know it is crucial for loop optimisation since without tail recursion there is theoretically no way of transforming the code to an iteration. (without a stack of any kind).
4. Is a reference available documenting which Prelude/standar
John Goerzen <[EMAIL PROTECTED]> writes:
> If I instead wrote:
>
> sum [] = 0
> sum (x:xs) = x + sum(xs)
>
> then I have the same problem.
>
> What is the proper way to solve this little problem then?
sum n [] = n
sum n (x:xs) = (sum $! n + x) xs
It's unfortunate that it requires $! or seq,
On Tuesday 28 Sep 2004 8:17 pm, John Goerzen wrote:
> On Tuesday 28 September 2004 01:54 am, Iavor S. Diatchki wrote:
> > OTOH there are a few classical cases in haskell where you run out of
> > space even if you have a tail
> > recursive function: e.g.
> > sum n [] = n
> > sum n (y:ys) = sum (n +
> > 1. Do Haskell interpreters/compilers perform [tail call optimization]?
Georg Martius wrote:
> ghc does it with one of -O -O1 -O2 switches.
> hugs doesn't seam to do it since [2] says that
> foldl (\n _ -> n + 1) 0 [1..10]
> causes a stack overflow.
All Haskell compilers (including Hugs)
On 28-Sep-2004, John Goerzen <[EMAIL PROTECTED]> wrote:
> As I'm investigating Haskell, it's occured to me that most of the
> Haskell tutorials out there have omitted something that was quite
> prominent in the OCaml material I had read: making functions properly
> tail-recursive.
>
> The OCaml co
Fergus Henderson <[EMAIL PROTECTED]> held forth:
> On 28-Sep-2004, John Goerzen <[EMAIL PROTECTED]> wrote:
> > As I'm investigating Haskell, it's occured to me that most of the
> > Haskell tutorials out there have omitted something that was quite
> > prominent in the OCaml material I had read: maki
On 04-Oct-2004, Jon Cast <[EMAIL PROTECTED]> wrote:
> Fergus Henderson <[EMAIL PROTECTED]> held forth:
> > If analyzing the performance and space usage of your programs is
> > important, then Haskell may not be the best choice of language.
>
> I disagree. If performance and space usage are suffic
n on http://haskell.org/hawiki/CommonHaskellIdioms ?
> -Original Message-
> From: GoldPython [mailto:[EMAIL PROTECTED]
> Sent: 10 December 2004 15:07
> To: [EMAIL PROTECTED]
> Subject: [Haskell-cafe] Flattening tail recursion?
>
> I'm missing something, a functional idiom
countLines [] = 0
countLines (_:ls) = 1 + countLines ls
I would have thought that this was tail recursive and would be
flattened into iteration by the compiler. Can anyone explain why?
This function isn't tail recursive, because you do additional operations
to the result of the function cal
On 10 Dec 2004, at 15:34, Robert Dockins wrote:
So it should get "flattened," but it still doesn't run in constant
space because the "x" parmeter isn't strict, so it will accumulate a
bunch of closures like (((0)+1)+1)+1)+1)+1) To make it strict,
do something like this:
Isn't this what
Jules Bean wrote:
On 10 Dec 2004, at 15:34, Robert Dockins wrote:
So it should get "flattened," but it still doesn't run in constant
space because the "x" parmeter isn't strict, so it will accumulate a
bunch of closures like (((0)+1)+1)+1)+1)+1) To make it strict,
do something like this:
GoldPython wrote:
I know there's
"length" to count the elements in a list and it works fine, but the
function below stack overflows on a large list.
countLines [] = 0
countLines (_:ls) = 1 + countLines ls
I would have thought that this was tail recursive and would be
flattened into iteration by
Jules Bean wrote:
On 10 Dec 2004, at 15:34, Robert Dockins wrote:
So it should get "flattened," but it still doesn't run in constant
space because the "x" parmeter isn't strict, so it will accumulate a
bunch of closures like (((0)+1)+1)+1)+1)+1) To make it
strict, do something like this:
On 10 Dec 2004, at 16:35, Ben Rudiak-Gould wrote:
Jules Bean wrote:
On 10 Dec 2004, at 15:34, Robert Dockins wrote:
So it should get "flattened," but it still doesn't run in constant
space because the "x" parmeter isn't strict, so it will accumulate a
bunch of closures like (((0)+1)+1)+1)+1)+
1 - 100 of 249 matches
Mail list logo
