[Haskell-cafe] Master's thesis topic sought

[Shelby Moore]

Throttling at the thunk+GC interaction as I suggested, thus transparent to
the semantics of Haskell language, is an experimental concept that
potentially convolves with the system-at-large.  Perhaps I would also
pursue an orthogonal strategy at the semantics layer, which is less global
in scope.  Perhaps it is possible to categorize and generalize many of the
types of structures that cause space leaks, then handle them at the
semantic layer (but afaics this can not be argued to most optimal in all
respects).  The latter is successful every time you generalize a case and
are able to identify it automatically with an analyzer.


> Generally, a form of lenient evaluation + lazy data structures can
> provide the benefits of Haskell non-strict evaluation without the
> drawbacks. A "reimagining" of Haskell cast in this mold might make for
> a very practical thesis.
>
> Regards,
>
> John A. De Goes
> N-Brain, Inc.
> The Evolution of Collaboration
>
> http://www.n-brain.net    |    877-376-2724 x 101
>
> On Nov 4, 2009, at 7:29 PM, Shelby Moore wrote:
>
>>> Hello, -Cafe,
>>>
>>> I'm looking for an interesting topic to hack on in my thesis.
>>>
>>> The thesis should be rather "theoretical"/abstract (writing a mail
>>> client in Haskell is not, for example), dealing with FP or related
>>> fields.
>>
>> The theoretical concept of how to make lazy evaluation less
>> discontinuously correlated to allocation space determinism:
>>
>> http://www.haskell.org/pipermail/haskell-cafe/2009-November/
>> 068436.html
>> http://www.haskell.org/pipermail/cvs-ghc/2009-October/050928.html
>> http://www.haskell.org/pipermail/cvs-ghc/2009-November/050946.html
>> http://www.haskell.org/pipermail/cvs-ghc/2009-November/050949.html
>> (should have written "stochastic" instead of "statistical")
>>
>> I think this would make you a hero also if you succeed, as I see this
>> problem as the main problem stopping its adoption as a mainstream
>> language.
>>
>> The problem as I see it (Google "space leak Haskell" for examples), is
>> that even a very small change in the code can cause a huge space
>> leak that
>> slows the program to molasses due to paging (faults) load.  And these
>> effects are not predictable or easy to reason about.  When these
>> discontinuous effects occur, we have to stop our development, do
>> profiling, and try to isolate the obscure cause, then restructure
>> code in
>> bizzarre ways to try to get some determinism in space allocation.
>>
>> My abstract idea is that it should be possible to stochastically
>> throttle
>> these effects, by throtting whether (and whic) thunks get cached to
>> (WH)NF
>> or re-valuated on each use.
>>
>> I do think it is possible to teach people how to program in FP
>> succinctly
>> and without making their head hurt:
>>
>> http://www.haskell.org/pipermail/haskell-cafe/2009-November/
>> 068564.html
>>
>> You may not find many people here openly expressing their interest in
>> these topics, but I think there are millions of people out there who
>> would
>> benefit.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>