Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

L.S., On Thu, 11 Dec 2003 06:23:51 -0800, Iavor S. Diatchki <[EMAIL PROTECTED]> wrote: : : Henk-Jan van Tuyl wrote: 1) It takes no effort, once you are use to it, to code without n+k patterns; this does not seem like a good argument. there are many other features like that in haskell. for exam

Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

The n+k pattern issue inspired endless debates on the Haskell committee and this feature was considered for removal in nearly every iteration of the Haskell report. We all agreed that n+k is extremely ad-hoc but that certain programs can be expressed slightly more elegantly using them. Unfortunat

Re: bugs from n+k patterns (was: Re: Preventing/handling space leaks)

On Thu, 11 Dec 2003 06:23:51 -0800 "Iavor S. Diatchki" <[EMAIL PROTECTED]> wrote: ... > Henk-Jan van Tuyl wrote: ... > > 2) It is likely, that n+k patterns dissapear in the next Haskell > > standard. If you don't like to rewrite, test and debug all your > > software every few years, don't use an

bugs from n+k patterns (was: Re: Preventing/handling space leaks)

hi, first here is why i think n+k patterns are problematic; 1) they lead to some parsing awkwardness (e.g. when n+k pattern bindings are involved, but those don'treally make much sense anyways) 2) in haskell as it is, patterns are associated with algebraic datatypes, and n+k patterns may erronou

Re: Preventing/handling space leaks

L.S., On Wed, 10 Dec 2003 09:49:54 -0800, Iavor S. Diatchki <[EMAIL PROTECTED]> wrote: hello, Henk-Jan van Tuyl wrote: : : So far I have seen only one rule for Good Coding Practice in Haskell: Do Not Use n+k Patterns. I hope someone can give some directions, how to avoid known pitfalls (especia

Re: Preventing/handling space leaks

G'day all. Quoting Henk-Jan van Tuyl <[EMAIL PROTECTED]>: > So far I have seen only one rule for Good Coding Practice in Haskell: Do Not > Use n+k Patterns. I hope someone can give some directions, how to avoid known > pitfalls (especially Space Leaks). Here are a few rules of thumb: -

Re: Preventing/handling space leaks

hello, Henk-Jan van Tuyl wrote: I have spent most of the six years with my former employer coding in C and some time in Java (and other languages) and had never any trouble with space leaks; mainly because I strictly followed some rules for Good Coding Practice (never use gotos, only one retur

Re: Preventing/handling space leaks

L.S., On 07 Dec 2003 22:53:45 +0100, <[EMAIL PROTECTED]> wrote: "Henk-Jan.van.Tuyl" <[EMAIL PROTECTED]> writes: L.S., (Whom?) L.S. :: Abbreviation a => Latin a L.S. = "Lectoribus Salutem" -- Readers be greated Does anyone know about documentation (preferably on the Web) on how to prevent/find/r

Re: Preventing/handling space leaks

G'day all. Quoting Gabriel Dos Reis <[EMAIL PROTECTED]>: > I think it is fair to characterize auto_ptr as a curiously broken > class since its conception and design. I also think that's a fair characterisation. std::auto_ptr has always struck me as a fairly brittle abstraction. Learning that i

Re: Preventing/handling space leaks

Fergus Henderson <[EMAIL PROTECTED]> writes: | Even the C++ standard library itself, which has been | subject to review by the world's best C++ experts, suffers | from exception safety problems. A new exception safety | problem with std::auto_ptr was discovered just last Friday! See |

Re: Preventing/handling space leaks

On 08-Dec-2003, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > G'day all. > > Quoting Sven Panne <[EMAIL PROTECTED]>: > > > Granted, C++'s (copy) constructors, destructors and assignment operators > > make some things relatively easy compared to C, but the complexity of > > handling exceptions *c

Re: Preventing/handling space leaks

G'day all. Quoting Sven Panne <[EMAIL PROTECTED]>: > Granted, C++'s (copy) constructors, destructors and assignment operators make > some > things relatively easy compared to C, but the complexity of handling > exceptions > *correctly* makes things worse again: There is a famous article (I can't

Re: Preventing/handling space leaks

Sven Panne <[EMAIL PROTECTED]> writes: > [ Just one more mail and I promise to shut up on this topic... :-) ] Surely slamming C++ is on topic? :-) > Fergus Henderson wrote: >> [...] C does suffer from many of the same problems as C. But in C++, it is >> much easier to automate techniques like

Re: Preventing/handling space leaks

[ Just one more mail and I promise to shut up on this topic... :-) ] Fergus Henderson wrote: [...] C does suffer from many of the same problems as C. But in C++, it is much easier to automate techniques like reference counting, which can be done manually in C but are much more cumbersome and erro

Re: Preventing/handling space leaks

On 06-Dec-2003, Sven Panne <[EMAIL PROTECTED]> wrote: > Henk-Jan.van.Tuyl wrote: > >[...] it looks to me, that the problem of space leaks is a very good reason > >to not use Haskell for commercial applications. Java, for example, does > >not have this problem. > > I just can't resist when I read

Re: Preventing/handling space leaks

"Henk-Jan.van.Tuyl" <[EMAIL PROTECTED]> writes: > L.S., (Whom?) > Does anyone know about documentation (preferably on the Web) on how to > prevent/find/remove space leaks? Are there any differences between > Hugs and GHC or any other Haskell platform, regarding space leaks? I should probably i

Re: Preventing/handling space leaks

Henk-Jan.van.Tuyl wrote: [...] it looks to me, that the problem of space leaks is a very good reason to not use Haskell for commercial applications. Java, for example, does not have this problem. I just can't resist when I read PR statements like this (SUN's marketing department has *really* done

Preventing/handling space leaks

L.S., Does anyone know about documentation (preferably on the Web) on how to prevent/find/remove space leaks? Are there any differences between Hugs and GHC or any other Haskell platform, regarding space leaks? I read some discussions about why not everybody uses Haskell; it looks to me, that th