Re: [Guile-commits] GNU Guile branch, stable-2.0, updated. v2.0.7-291-g4a1cdc9

[Chris K. Jester-Young]

Hi Mark,

On Fri, Apr 05, 2013 at 02:48:29AM -0400, Mark H Weaver wrote:
> Thanks for working on this, but in the future, please post your proposed
> patches for review before pushing to stable-2.0 or master.

You're right, that was a lapse of judgement on my part. Sorry.

> > -(define %stream-null '(stream . null))
> > +(define %stream-null (cons 'stream 'null))
> 
> This change is not mentioned in the commit message.
> Ideally, it should have been a separate commit, IMO.

Fair enough. If you prefer, I can revert this last commit and then
make this a separate commit. That will make the git blame a bit
tidier, at the expense of having a revert commit in the log.

> The clarity of this code could greatly benefit from some helper
> procedures.  One possibility would be a procedure that takes a promise
> and two continuation arguments: one to call if the promise has already
> been computed, and another to call if it has not yet been.  Another
> possibility would be to simply have a predicate that tells whether a
> promise has already been computed.

I was actually mimicking the style used in the SRFI 45 reference
implementation of delay. If we change this here, we should also
correspondingly change delay. The two continuations thing is probably
worth trying.

> I'd like to hear opinions on how to print promises.  Here are mine:
> 
> * I don't like #<eager ...> and #<lazy #<procedure ...>>.
> 
> * Both forms should start with #<promise ...>, because from a user's
>   point of view that is the type.

Fair enough. I was recalling your comment about how we should make SRFI
45 promises print slightly differently to core promises, so that was the
most succinct way I could imagine.

> * We should avoid printing "#<procedure" in there.  Some kind of
>   location tag would be useful, but let's make it more compact.

Right, and if we fix that here, we should do the same for core promises
(which does indeed print "#<procedure").

> * I suspect 'eager' and 'lazy' are likely to confuse most users, because
>   they don't coincide with their own uses of 'lazy' and 'eager' as found
>   in the public API.

If we don't print "eager" or "lazy" in the display, do we still need a
way to unambiguously identify between the two states? Right now, with
core promises, you can never tell: if it shows a procedure, that could
be the delayed thunk, or the result of calling such.

Thanks for your feedback! I look forward to hearing about which approach
we should take to your concerns outlined above, and implementing them.

Cheers,
Chris.