`indexed-signal` fails inside `network` macro

[pdikmann]

the network macro does not play nice with indexed-signal:

(define test/not-ok
  (network ()
           [out2 (indexed-signal (lambda (f) 0))]))

(define test/ok
  (let ([what (indexed-signal (lambda (f) 0))])
    (network ()
             [out2 (what)])))

play-signal of test/not-ok results in a contract violation for *:

*: contract violation
  expected: number?
  given: #<network/s>
  argument position: 2nd
  other arguments...:
   32767.0

[jbclements]

The short version is that this is a bad error message. The issue here is that the "network" macro implicitly lifts the RHS to a lazy application... unless it looks like a constant, in which case it just gets evaluated. In this case, it's going to lift the application of indexed-signal, which isn't what you want at all. I'm torn between more cleverness--in this case, the macro could see that the arguments aren't other names appearing as LHSes--or less cleverness; making the not-lifted nature explicit.

[pdikmann]

For what it's worth, I think it's reasonable that only specific commands would work inside a network clause. In hindsight, the documentation is already pretty explicit about it.

a right-hand-side must be a constant, or an application, either of a primitive function or of a network.

In that light, this is the way it's supposed to (and does) work:

(define test/ok2
  (network ()
           [out2 ((indexed-signal (lambda (f) 0)))]))

So, uhm, pardon my dust? :P