<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
I welcome your questions - there hasn't been much discussion on this
library, and the attention of such a well versed contributor to the
subject is an immeasurable boon.<br>
<br>
The primary question is hard to answer, as I have to explain what
Heresy is <i>not</i> in comparison to a library that I don't
understand, where Heresy may be designed against different goals.<br>
<br>
It is complicated by the fact that I'm completing a revision with quite
a lot of internal code change (albeit preserving
the external interface) to better express these goals.<br>
<br>
I will address your questions from the standpoint of glancing at
cl-enumerations.<br>
<br>
Certainly, the presentation layer, how code interacts with the
lazy-lists was a significant part of what Heresy aimed to achieve.
This could be stereotyped as "looking like haskell" and "hiding the
underlying list type"; but the goals involve giving certain
fine-grained control over when evaluation of lazy elements occur, and
of certain caching/reference-retention issues.<br>
<br>
The Heresy API generally seeks to conceal the type of the underlying
container, which may not be a fixed container or have other
characteristics known. The idea of "reset to start" with a lazy-list
is antithetical to the goals of Heresy's lazy-lists.<br>
<br>
The classes that inherit from lazy-list have one thing in common - they
are completely redundant from a raw <i>functionality </i>standpoint.
They
exist only to facilitate certain performance optimizations in order to
ease some of the performance hits that come with having a per-element
function call in traversing a lazy container. (Performance of
lazy-lists is inherently much slower than using fixed containers and
loops). <i>They do not seek to map 1-1 with fixed containers such as
arrays or vectors</i> - those distinctions are captured elsewhere, and
generally concealed from the API's caller.<br>
<br>
Mechanically (in the version you are looking at), each pure lazy-list
is represented as a "call". The call returns 2 values - the value at
that position, and a call for use in obtaining the next pair, null if
the end has been struck. This (or something like it) was deemed
sufficient for the representation of both algorithmically generated and
fixed sequences. I suspect that, (<i>if </i>it works this way)
cl-enumeration's core could be used to replace the mechanics of what
I'm doing (although I'm uncertain if it is sufficient to deal with the
stack depth issue - mentioned below).<br>
<br>
The next revision will more clearly deal with thread-safety; but
thread-safety is almost an incidental feature.<br>
<br>
So what's the point of this? To support a certain way of expressing
solutions, certain control over proximity of execution and storage that
have revealed themselves in my other work.<br>
Examples (not exhaustive):<br>
- When the distinction between lazy and eager mode of nthcdr/ (one that
traverses immediately, one that defers) matters, as with the ability to
stereotype a section of code/form for treatment under either behavior.<br>
- Certain integrated caching issues.<br>
- The ability to chain up lazy effects without bloating the stack on
traversal. (This is addressed in the new revision I am currently
testing, and is structural and broad). With the current public
version, an example of this failure can be induced by calling (setf
my-list (append/ my-list)) a few thousand times then traversing (it's a
problem with concat, the trivial append/ check would only conceal this
variant).<br>
- Ability to distinguish between traversal with value extraction vs.
traversal with ignore value (in chained up effects, again with no stack
penalty) - where it may matter (this is better addressed in the next
revision).<br>
<br>
<br>
<br>
<br>
<br>
<br>
Marco Antoniotti wrote:
<blockquote cite="mid:F849F239-271A-4438-B00F-91CF1D8501DF@cs.nyu.edu"
type="cite"><br>
On Mar 28, 2008, at 18:06 , Matt Lamari wrote:
<br>
<blockquote type="cite"><br>
Well - the doc can be found here:
<a class="moz-txt-link-freetext" href="http://cl-heresy.sourceforge.net/Heresy.htm">http://cl-heresy.sourceforge.net/Heresy.htm</a>
<br>
<br>
Ultimately, there is the lazy-list class. The different sub-classes
exist to facilitate certain internal optimizations, e.g. getting the
CDR of a lazy-list that's just wrapping a lisp list.
<br>
<br>
All subclasses of lazy-list are lazy-lists containing a function that
yields a value and a "next" function. The extra data in each subclass
allows for optimizations in certain situations.
<br>
<br>
lazy-list-list-based <-- kind of self-evident
<br>
lazy-list-under-cdrs <-- keeps a CDR count such that successive CDRs
against same merely up the cdr-count. This one may be a candidate for
removal.
<br>
<br>
<br>
Let me know if I can be more specific in this or another direction.
<br>
</blockquote>
<br>
Well, I am a little confused by all the subclassing and by the
similarly named functions. In particular I have a doubt. While the
API is Lisp/Haskell and while there is welcome support for thread
safety, how is Heresy different in concept from the iterators in
CL-CONTAINERS or the enumerations (shameless plug) or CL-ENUMERATIONS?
<br>
<br>
In any case, could you explain a little more in detail the rationale
for all the subclasses and the sematincs of and the need for keeping a
separate value slot?
<br>
<br>
Cheers
<br>
--
<br>
Marco
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite"><br>
<br>
<br>
<br>
Marco Antoniotti wrote:
<br>
<blockquote type="cite">Hi
<br>
<br>
I am a bit puzzled by the innards of Heresy.
<br>
<br>
Could anybody shed a little light (and documentation :) ) on the actual
role of all the different delayed classes that are there?
<br>
<br>
Thanks
<br>
<br>
-- <br>
Marco
<br>
<br>
_______________________________________________
<br>
heresy-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:heresy-devel@common-lisp.net">heresy-devel@common-lisp.net</a>
<br>
<a class="moz-txt-link-freetext" href="http://common-lisp.net/cgi-bin/mailman/listinfo/heresy-devel">http://common-lisp.net/cgi-bin/mailman/listinfo/heresy-devel</a>
<br>
</blockquote>
<br>
</blockquote>
<br>
--
<br>
Marco Antoniotti
<br>
<br>
<br>
_______________________________________________
<br>
heresy-devel mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:heresy-devel@common-lisp.net">heresy-devel@common-lisp.net</a>
<br>
<a class="moz-txt-link-freetext" href="http://common-lisp.net/cgi-bin/mailman/listinfo/heresy-devel">http://common-lisp.net/cgi-bin/mailman/listinfo/heresy-devel</a>
<br>
</blockquote>
<br>
</body>
</html>