Re: incompatible types in assignment

[Roger M. Burkhart]

> > 2) Presumably the idea of flattening the 'inner loop' of fast agent step
> >    calls is used in order to save on 'merge' related overhead (i.e. with
> >    one schedule there should be no need to call the mechanisms which
> >    merge two schedules). Well, I'm wondering whether the overhead is being
> >    avoided by flattening the inner loop and furthermore I'm wondering
> >    whether that overhead is very large in the first place. Roger should
> >    post something about this trade-off (i.e. does his library 'notice' the
> >    case where no merging is necessary).
> 
> This is a good point.  Even presuming what I wrote above might work,
> there might be an issue with respect to comparing the two ways of
> doing things.

Merging adds a little bit of overhead compared to just bare schedules, but
not that much, and can actually reduce overhead if it results in not having
to dynamically add and remove actions from schedules.  I'd try the automatic
merge machinery before coding some implicit merge logic in a single flat
schedule.  The merge machinery overhead does currently go up linearly in the
number of schedules being merged, but the potential is there to reduce this
overhead to log N if the need for massive merging arises.  (Actually, the
current overhead is linear only the number of active schedules, those being
rescheduled frequently, with other schedules staying out of the way.)

In answer to Manor's question, the library does not currently notice when
there's only one schedule so that true merging is unnecessary, always
retaining a little overhead for the option, but this an opportunity for
further optimization that remains available.  There's a lot of internal
optimization potential, such as caching method lookup on actions, that
remains available, but we've still been concentrating entirely on the
functional model.  So if things seem slow or fast so far, they'll probably
only get more so!

Roger