Re: Clarification of \begin{code} ... \end{code} stuff

On Mon, Dec 10, 2001 at 04:03:27PM +, Ian Lynagh wrote: > > In the thread "Literate scripts not handled correctly" Simon Marlow > said: > > > Yes, it looks like GHC's unlit program removes whitespace when looking > > for \begin{code}, but not for \end{code}. The report isn't explicit > > ab

RE: Another question about sharing

> > You can't rely on adding dummy arguments to cause re-evaluation: > > full-laziness (enabled when optimisation is on in GHC) will do the > > opposite transformation. > > Well in this case, you may find it harder to claim that the full > laziness transformation constitutes an `optimisation'. M

Re: Another question about sharing

> You can't rely on adding dummy arguments to cause re-evaluation: > full-laziness (enabled when optimisation is on in GHC) will do the > opposite transformation. Well in this case, you may find it harder to claim that the full laziness transformation constitutes an `optimisation'. Maybe the GHC

RE: Another question about sharing

> Well, how about the following little circular program? > > paths :: () -> [Path] > paths () = let r = T : branch r in r > > As far as I can understand what you are looking for, I think > this meets > the bill. Every use of the expression `paths ()' will re-evaluate > the infini

Re: Another question about sharing

> > data Path = L Path | R Path | T > > paths = T : branch paths > > branch (p:ps) = L p : R p : branch ps > This code was originally written in Clean, and the Clean designers > addressed this problem by allowing the programmer to distinguish > between constants and functions with no

RE: Another question about sharing

> I'm curious, how does GHC determine that the CAF is no longer required > if it is referenced by code (somehow)? If code was also some kind of > heap allocated data structure I guess this would be possible, but I > thought this wasn't so with GHC. GHC actually tracks references to top-level ent

Re: Another question about sharing

On Monday 10 December 2001 11:18 am, Simon Marlow wrote: > > If I have.. > > data Path = L Path | R Path | T > > paths = T : branch paths > > branch (p:ps) = L p : R p : branch ps > > > > This will be a CAF which can never be garbage collected, but > > may grow indefinitely large as it

FME'2002, 2nd CFP

apologies if you receive multiple copies... FORMAL METHODS EUROPE FME 2002 "Formal Methods: Getting IT Right" International Symposium and Tutorials http://floc02.diku.dk/FME/

WAAAPL 2002, preliminary announcement

Apologies if you receive multiple copies... PRELIMINARY CALL FOR PAPERS [Deadline for submission: 3rd June 2002] WAAAPL 2002

Re: Another question about sharing

> If I have.. > data Path = L Path | R Path | T > paths = T : branch paths > branch (p:ps) = L p : R p : branch ps > > This will be a CAF which can never be garbage collected, but > may grow indefinitely large as it gets reduced. Correct? Any decent compiler will garbage collec

RE: Another question about sharing

> If I have.. > data Path = L Path | R Path | T > paths = T : branch paths > branch (p:ps) = L p : R p : branch ps > > This will be a CAF which can never be garbage collected, but > may grow indefinitely large as it gets reduced. Correct? GHC will collect the CAF when it can d

Another question about sharing

Hello, If I have.. data Path = L Path | R Path | T paths = T : branch paths branch (p:ps) = L p : R p : branch ps This will be a CAF which can never be garbage collected, but may grow indefinitely large as it gets reduced. Correct? Is it possible to avoid this problem so

CFP: WRS 2002 - 2nd WS on Reduction Strategies in Rewriting and Programming

[Apologies for multiple copies of this announcement] ** *** first call for papers and participation **