headers
Michael Sperber [Mr. Preprocessor] | 2 Apr 2003 12:39
Picon

Delay and dynamic extent


> Note that the lambda form does not close over the dynamic
> environment so why should it be different from delay?  Well if you
> did this the "dynamic environment" would in fact be the lexical
> environment so you would lose all the benefits of dynamic binding.
> When one writes a function with lambda there is an expectation that
> the dynamic environment is abstracted over.  However when using a
> DELAY the expectation is that only the evaluation time is changed,
> not the computation being performed (unless side-effects are
> performed that expose the evaluation order).

I'm afraid I can see problems with that characterization of delay. I'd
also like to show an example that seems to demonstrate why delay
should _not_ be closed over the dynamic environment.

It is sometimes convenient to invert an iteration "inside-out" --
turn an iteration over a collection into a lazy list of the traversed
elements. Generators in Icon, Ruby and now Python use a similar
trick. Here's a generic iteration inverter:

(define (foreach->lazy-list foreach-fn collection)
  (delay
    (call-with-current-continuation
      (lambda (k-main)
	(foreach-fn
	  (lambda (val)
	    (call-with-current-continuation
	      (lambda (k-reenter)
		(k-main (cons val
			  (delay
(Continue reading)

Permalink | Reply | 501 comments |
headers
Michael Sperber [Mr. Preprocessor] | 2 Apr 2003 12:42
Picon

Re: Delay and dynamic extent [previous message was by Oleg Kiselyov]


Sorry for the wrong From: header---my mistake.

--

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
Permalink | Reply | 501 comments |
headers
Alan Watson | 17 Apr 2003 08:47
Picon

Uniform names

This SRFI has a lot of good in it, but I'm glad the thread-specific
aspects are being treated separately.

A minor suggestion. One of the nice things about Scheme is it's
relatively uniform names. With this in mind, I'd propose:

   (make-parameter initial-value converter) => parameter
   (set-parameter! parameter value)

Then, as Olin Scrivers suggested, add the library procedure and derived
syntax:

   (with-parameter parameter value thunk)
   (let-parameter ((parameter value) ...) body)
   (let-parameter* ((parameter value) ...) body)

When you do deal with threads, please be careful when using the phrase
"mutable parameter", as different types of parameter can be "mutable"
with different semantics (for example, globally shared, shared between
parents and children, not shared). Please use a more specific term, like
thread-local, depending on the exactly what you mean.

Regards,

Alan
--

-- 
Dr Alan Watson
Instituto de Astronomía UNAM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthias Radestock | 18 Apr 2003 01:15

is it a new data type?

A few questions/comments:

1)
Are parameters a new data type? This srfi does not define any procedures 
on parameters, so in that sense they are not. However, implementations 
may want to define such procedures, in which case having a predicate 
|parameter?| would be essential. Note however that r5rs compliance would 
still require |procedure?| to return #t for parameters.

2)
What happens when the converter procedure returns more than once, e.g. 
when a continuation captured inside it is invoked?

3)
It would be useful for (<parameter> <value>) to return the existing 
value since a lot of uses of dynamic parameters are of the pattern:
  * get parameter value -> old_value
  * set parameter value
  * do something
  * set parameter value to old_value
Having a setter that returns the existing value allows elimination of 
the first step.

Matthias.
Permalink | Reply | 0 comments |

Gmane