From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.ada Subject: Re: If not Ada, what else... Date: Thu, 30 Jul 2015 11:26:04 -0700 Organization: A noiseless patient Spider Message-ID: <87bnetmrib.fsf@jester.gateway.sonic.net> References: <87mvz36fen.fsf@jester.gateway.sonic.net> <2215b44f-8a89-47c6-a4c4-52b74d2dac45@googlegroups.com> <9e492c82-868d-43d3-a18a-38274400e337@googlegroups.com> <40184feb-4053-4ac3-8eaa-c3bd9cd8a77c@googlegroups.com> <10272577-945f-4682-85bc-8ad47f3653ae@googlegroups.com> <87si8i81k2.fsf@atmarama.net> <8076cbd0-2655-4c98-b70e-cb5f0c32e4ba@googlegroups.com> <5e6cb30b-5f8c-4fed-969e-3941315ecba0@googlegroups.com> <87si87nf8k.fsf@jester.gateway.sonic.net> <87oaiumdfy.fsf@jester.gateway.sonic.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="d4217d68945dedf510265c644f2a7daa"; logging-data="27280"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+/eaNl6R+PhlNe9t7qxhND" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:mnAQfquo3VMg8X3eAFhUziZWFPQ= sha1:JN6lLed9qYPsX5iNkcY/ZaXwMig= Xref: news.eternal-september.org comp.lang.ada:27231 Date: 2015-07-30T11:26:04-07:00 List-Id: Georg Bauhaus writes: > Aren't these features (tail recursion, strict, ...) among the reasons > why Haskell got lazy strategies in the first place? Tail recursion is a standard FP thing and you have to do it in Scheme and ML as well. Haskell's lazy evaluation was an interesting experiment that has its good and bad points. The interesting next-generation FP languages like Idris seem to have gone back to strict evaluation, though there's stuff happening in the theory community that might show up in languages further down the road, that might allow strict/lazy combinations whose behavior is tracked by type systems better than has been done in the past. >> p2 xs m = sum . map head . takeWhile (not . null) . iterate (drop m) $ xs > (Nitpick: This loops when m<=0, try "p2 [1] 0". (*)). Yeah, it was supposed to only be illustrative of how to compute the sum without all that explicit recursion. To handle the non-positve case, add p2 _ m | m <= 0 = 0 > {-# LANGUAGE BangPatterns #-}, news to me, thanks!), I waited minutes after > intense disk swapping for > *Main> p2 [1 .. 123456789] 6 OK, yeah, as predicted, the problem is that ghci isn't noticing it can optimize sum as strict. ghc -O would probably do it. Try writing: import Data.List (foldl1') p2 :: [Int] -> Int -> Int p2 _ m | m <= 0 = 0 p2 xs m = foldl1' (+) . map head . takeWhile (not . null) . iterate (drop m) $ xs (Mostly the same thing, except for the formatting). > Seems another feature of prototyping is apparent: can't use larger data sets. > I guess I have also missed some way or other of controlling the prototyping > interpreter (GHCi) that would make it produce more efficient code, ways that > would be "obvious" to ... of course ;-) I usually run ghci in an emacs window so I can kill the window (which also kills the ghci process) if it goes berserk. Also run "w" in another window so you can see the memory consumption climbing in the case of a space leak. You can usually ctrl-c out of it if you do it before the system is pushed into swapping. Or you could use ulimit to bound the memory footprint, or run in a VM, or whatever.