possible errors in TSPL4

[symingz]

Hi, not sure if this is the right place for reporting errors in TSPL4, I apologize in advance if the answer is no. Here are some possible errors that I spotted:

In Exercise 12.11.2 of TSPL4 (bottom of https://www.scheme.com/tspl4/examples.html#./examples:h11),

(let ([value (proc)] [ticks (stop-timer)])
  (do-complete value ticks))

should be

(let ([value (proc)] [ticks (stop-timer)])
  (do-complete ticks value))

Similarly in Exercise 12.11.3,

(let ([value (proc)])
  (do-complete value (stop-timer)))

should be

(let ([value (proc)])
  (do-complete (stop-timer) value))

Also, contrary to what Exercise 12.11.3 suggests, I think there is actually nothing wrong with replacing

(let ([value (proc)])
  (let ([ticks (stop-timer)])
    (do-complete ticks value)))

with

(let ([value (proc)])
  (do-complete (stop-timer) value))

[dybvig]

Thank you for the corrections. I have fixed the argument order in the two calls and posted errata.

With regards to what's wrong with the 12.11.3 replacement code, consider what sort of problem might occur with the following version:

(let ([value (proc)])
  (let ([f do-complete])
    (f (stop-timer) value)))

Kent

[symingz]

(let ([value (proc)])
  (let ([f do-complete])
    (f (stop-timer) value)))

is problematic if do-complete is an identifier macro which expands into an application. But in the particular case in the book do-complete is a plain variable, so I don't think there is a problem.

My other a bit of a stretch theory is that there exists engine implementations in which even variable look up can consume ticks, so (stop-timer) should be done before looking up do-complete. But then again, this is not relevant to the particular case in the book.

[burgerrg]

@symingz, does the value of the do-complete variable change? If so, could that cause problems?

[symingz]

@burgerrg do-complete in general changes, but not during (do-complete (stop-timer) value) or (let ([f do-complete]) (f (stop-timer) value)), so there shouldn't be a problem.

[burgerrg]

What happens if there is a timer interrupt after f is bound but before (stop-timer) is evaluated?

[symingz]

That's not possible in this particular implementation of engines.

[burgerrg]

The call to stop-timer will use one unit of fuel, so it could cause a software interrupt upon entry.

[symingz]

No, the call to stop-timer does not use any fuel, because only timed-lambda uses fuel, and stop-timer does not use timed-lambda.

[symingz]

I'm curious to get to the bottom of Exercise 12.11.3, @dybvig @burgerrg any further comments will be appreciated, thanks!

[burgerrg]

The evaluation order of do-complete and (stop-timer) is unspecified. As you pointed out, the evaluation of these two expressions does not consume fuel, so the expression ought to work as expected.

[symingz]

Sorry @burgerrg, I haven't checked this for a while. So just to confirm, you agree that Exercise 12.11.3 should be removed or changed, right?

[burgerrg]

Sorry @burgerrg, I haven't checked this for a while. So just to confirm, you agree that Exercise 12.11.3 should be removed or changed, right?

Chez Scheme implements timer interrupts on entry to procedures, so the example in question isn't safe with it. That may be what @dybvig had in mind. I'd wait to hear back from him.

[jgarte]

Hi,

There is a broken link here:

https://cs.indiana.edu/chezscheme/debug/

https://cisco.github.io/ChezScheme/csug9.6/debug.html#./debug:h0

Would someone be able to reinstate that link or point to the correct page?

[jltaylor-us]

Hi,

There is a broken link here:

https://cs.indiana.edu/chezscheme/debug/

https://cisco.github.io/ChezScheme/csug9.6/debug.html#./debug:h0

Would someone be able to reinstate that link or point to the correct page?

Adding a comment to an unrelated issue where the discussion is a year old is not a great way to get answers to your questions. But, having said that, #467 #363