The local combinator is intended to act like an internal let operation, but doesn't seem to be handled correctly. In particular, if a stream bound via local is passed into an operator that uses Drop or Append, the resulting local variable will be referred to out of context. This is basically because code consuming core Stream definitions expects the stream recurrence expression not to have any free variables, but this is not guaranteed by reification. In contrast, an ordinary Haskell let has the desired behavior.
This can be seen in both the stream interpreter and in the code generator. Consider the following spec:
-- External temperature as a byte in degrees C
temp :: Stream Word8
temp = extern "temperature" (Just [1 .. 100])
-- width of the sliding window
window :: Int
window = 3
-- Compute a sum of the last 3 samples
sumTemp :: Stream Word32
sumTemp = local (cast temp) $ \t -> sum window (replicate 3 19 ++ t)
spec :: Spec
spec = do
trigger "heaton" (sumTemp < (18*fromIntegral window)) [arg sumTemp]
trigger "heatoff" (sumTemp > (21*fromIntegral window)) [arg sumTemp]
When interpreted, this yields:
Maybe.fromJust: Nothing
CallStack (from HasCallStack):
error, called at libraries/base/Data/Maybe.hs:148:21 in base:Data.Maybe
fromJust, called at src/Copilot/Core/Interpret/Eval.hs:156:41 in copilot-core-3.5-inplace:Copilot.Core.Interpret.Eval
When used for code generation, this yields code which, when compiled, causes:
heater.c:36:10: error: use of undeclared identifier 'local_0'
return local_0;
^
heater.c:40:10: error: use of undeclared identifier 'local_2'
return local_2;
^
heater.c:44:10: error: use of undeclared identifier 'local_4'
return local_4;
^
heater.c:48:10: error: use of undeclared identifier 'local_6'
return local_6;
The
localcombinator is intended to act like an internalletoperation, but doesn't seem to be handled correctly. In particular, if a stream bound vialocalis passed into an operator that usesDroporAppend, the resulting local variable will be referred to out of context. This is basically because code consuming coreStreamdefinitions expects the stream recurrence expression not to have any free variables, but this is not guaranteed by reification. In contrast, an ordinary Haskelllethas the desired behavior.This can be seen in both the stream interpreter and in the code generator. Consider the following spec:
When interpreted, this yields:
When used for code generation, this yields code which, when compiled, causes: