seq as a class method

[Andy Gill]

On Mar 29, 2006, at 1:59 PM, Bulat Ziganshin wrote:

> Hello Andy,
>
> Thursday, March 30, 2006, 12:06:36 AM, you wrote:
>
>> Questions
>>   - Does anyone have any better suggestions of how to fix this real
>> issue?
>
> use mutable state, possible in the ST monad?
>

Thanks for you comments.

This would be fine if I was starting from scratch. For the sake of
argument, though, one of our clients gave us the basic
code, which, because it is written in a purely functional style,
they love its specification feel. We did not write it, so rewriting
is not an option (client will not pay for this). My job is to make our
wrapper round such that the state to state model works in reasonable
space. I can request small changes, a seq here, a prime there, but no
restructuring.

>> The problem(s) were things like
>
>>         regs ::  !Array Int RegVal
>
> use parallel or unboxed arrays here
>
>>          status :: ![Status]
>
> you need a strict list, smth like:
>
> type StrictList a = Cons !(StrictList a) !a | Nil
>
> it's the exact what i said some time ago, although for me main problem
> is not space leaks, but the huge time required to work with lazy data
> structures what are really never contain unevaluated data

Again, this is someone elses code. I've love a way of asking for a  
strict list,
or a strict array. Ideally a hyperstrict one. But using new datatypes  
in the
context of Haskell' is not a realistic option everywhere. I am  
talking about
what Galois is wanting from Haskell' .. a easier way of hammering  
space leaks.

Efficiency is not really a problem for us, thanks to the great work
of the Haskell community over the last few years! A deepSeq solution
would go a long way to help alleviate space leak, and helping track
them down. I've personally spend perhaps 4 weeks thumping space
leaks in various projects over the last 12 months (I do tend to get  
given
the space leaks to find) but would rather find better use of galois'  
time.

Once we find the problem, they tend to be a handful of lines, and  
deepSeq
is part of a methodology for systematically finding them.

I'm about to mail out a concrete proposal for deepSeq in Haskell'.

>> (Aside: What would be nice to have is "there should only be one
>> instance of this type,
>> tell me if that is not the case" evaluation mode. I'm not quite sure
>> how to express this,
>> though).
>
> my congratulations, you are discovered the "unique" types from Clean
> (these types is one of reasons why this lazy language sometimes are
> faster that haskell/ghc)

I'll look at unique times in Clean, then... thanks for the pointer.

> -- 
> Best regards,
>  Bulat                            mailto:Bulat.Ziganshin at gmail.com