On 14/05/11 17:42, Jean-Philippe Bernardy wrote:
On Sat, May 14, 2011 at 7:06 AM, Reiner Pope<reiner.p...@gmail.com> wrote:
What should I do to ensure strictness of lazy datatypes like [a]? For
instance, the 'bufAccessList :: ![BufferRef]' field of 'Window' is marked
strict, but is a list. Is it the client's duty to ensure that this list is
fully evaluated?
I am not sure what you mean with "client" there. The bufAccessList is forced
only once in a while (when switching buffers), so it must be strict to avoid
accumulation of thunks. A-priori this list should not be huge, but
when I debugged
space leaks I had to iron them all out; it's hard to see the difference between
big leaks and small leaks on small examples.
Let me clarify what I mean by client. The Window type is publicly
exported, so there is nothing to stop someone (the "client") writing a
config file (i.e. ~/.yi/yi.hs) updating the 'bufAccessList' field
lazily. The strictness annotation on this field isn't enough to prevent
that, since it only forces the head and not the entire list.
So, what I mean is that strictness of the 'Window' type should (IMO) be
guaranteed by the 'Yi.Window' module, but at present anyone at all can
circumvent this.
Would there be any objections to using the 'deepseq' package to ensure
evaluation? The 'NFData' class is supported by Derive, so it might be
possible to generate many instances automatically.
You do not want to have an operation that will take O(n) time at every
keystroke,
where n = total size of buffers.
Also I believe that the Rope datastructure we use for buffers takes
advantage of laziness,
so it might be unwise to deepseq it.
Fair enough.
Cheers,
Reiner
--
Yi development mailing list
yi-devel@googlegroups.com
http://groups.google.com/group/yi-devel
