I'm working on modifying the handling of "lazy" values.
The main change is that I'm adding "implicit forcing",
as allowed by R5RS (and the R7RS draft).
The classes that implement (delay EXP) and (future EXP) are modified
to implement a new gnu.mapping.Lazy interface:
public interface Lazy<T>
{
public T force() throws Throwable;
}
I plan to add a new type descriptor to indicate lazy values:
lazy[T]
will be equivalent to the Java type gnu.mapping.Lazy<T>.
(See the previous message about parameterized types.)
Given a type T which is neither Object, nor a lazy type, then
Kawa will support bi-directional conversion between type T and
lazy[T].
In a context that requires T, if we have a lazy value, Kawa will
automatically call force. This includes arithmetic operations.
Accessing a truth value (as in the condition of an 'if') also does a
force.
(This will cause a slight performance hit if the type of the
condition expression is unknown, since in that case the compiler has
to add a
run-time check for lazy values, rather than just comparing against
#f.)
I'm suggesting that a lazy value would not be an instance of a non-
lazy type.
I.e.
(instance? 3 integer) ==> #t
(instance? (delay 3) integer) ==> #f
OTOH, perhaps:
(instance? 3 lazy[integer]) ==> #t
(instance? (delay 3) lazy[integer]) ==> #f
One reason is to try to keep laziness as a feature you only pay for
only when you use it (at least as much as possible). Also I think
it makes
sense to consider type T as being "more specific" than lazy[T].
Converting a value v to lazy[T] where v is compatible with T is
trivial: Just create a pre-evaluated Promise object whose value is v.
The display function will automatically call force - but write will
not.
Note the Kawa's REPL by default displays the result.
One use case is to support lazy and parallel arrays, though
that will also be a work-in-progress. The plan is that a command
window
will include "more"-style functionality (such as I implemented for
Emacs's
term-mode), so if the REPL evaluates to a lazy infinite sequence only
as much will be evaluated and printed as requested by the user.
Comments? Obviously this is going to be somewhat experimental!