trouble with saw_c

[dsp1986]

while following the guides, to get to know the environment I came accross the need of a saw_c unit generator. I couldn't find it anywhere, so I took it as an exercise to write my own. I came up with:

(bind-func saw_c
  (lambda (phase)
    (lambda (amp freq:SAMPLE)
      (let ((incr (/ freq 44100.0)))
    (set! phase (% (+ phase incr) 1.0))
    (* amp (- (* 2 phase) 1))))))

however, on compilation I get a type error:

Type Error conflicting i64 with float in (+ phase incr)

I don't understand why extempore thinks phase should be an i64? Up to this point all examples in philosphy and the guide have worked.

Any ideas?

[digego]

In xtlang integer literals are typed as i64 by default, so in this instance 'phase' is typed as i64 because of (* 2 phase). This then conflicts with 'incr' which is typed SAMPLE. If you change your 2 to 2.0 and the 1 to 1.0 you should be good ;)

On Wed, Nov 14, 2018 at 10:50 PM dsp1986 notifications@github.com wrote:

while following the guides, to get to know the environment I came accross the need of a saw_c unit generator. I couldn't find it anywhere, so I took it as an exercise to write my own. I came up with:

(bind-func saw_c (lambda (phase) (lambda (amp freq:SAMPLE) (let ((incr (/ freq 44100.0))) (set! phase (% (+ phase incr) 1.0)) ( amp (- ( 2 phase) 1))))))

however, on compilation I get a type error:

Type Error conflicting i64 with float in (+ phase incr)

I don't understand why extempore thinks phase should be an i64? Up to this point all examples in philosphy and the guide have worked.

Any ideas?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/extemporelang/extemporelang.github.io/issues/17, or mute the thread https://github.com/notifications/unsubscribe-auth/AAh3qWMO69MSoqheaejHPeH7U_cHnyaNks5uvBGXgaJpZM4YdrWY .

[dsp1986]

that did the trick. Thank you! weird though, that the compiler complained about a bit of code that was perfectly fine, while the actual error was somewhere else...

[digego]

the 'bit of code' was not perfectly fine because the compiler was trying to (+ phase:i64 incr:SAMPLE) -- so the error was correct and pointed to the 'bad' code. The line ( 2 phase) is* perfectly fine, but causes the compiler to type phase as i64. This then has the (unintended in your case) consequence of forcing phase to i64.

You might reasonably question why (+ phase incr) doesn't force the phase to SAMPLE, and the answer to that is that it would except that a literal 2 (2:i64) takes precedence when resolving the type so (* 2 phase) takes precedence for type resolution over (+ phase incr).

Now, all that said, I 100% agree that we would like better error messages from the xtlang compiler - onwards and upwards :)

What you should try to keep in mind from this example though is that literals have a high precedence when resolving types.

On Sun, Nov 18, 2018 at 10:54 AM dsp1986 notifications@github.com wrote:

that did the trick. Thank you! weird though, that the compiler complained about a bit of code that was perfectly fine, while the actual error was somewhere else...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/extemporelang/extemporelang.github.io/issues/17#issuecomment-439658983, or mute the thread https://github.com/notifications/unsubscribe-auth/AAh3qT7To0YrukJreahiNHwE4qk7i0t-ks5uwK-xgaJpZM4YdrWY .