On Wed, Apr 20, 2005 at 09:29:17PM +0300, Gaal Yahas wrote: : (FWIW, this is called "signalProcess" in Haskell.)
Also in the FWIW department, I mislike mixed-case identifiers for anything in the "core". That sort of things screams "user-defined" to me. To a lesser extent, I also tend to avoid underscores in the core unless I'm trying to be obnoxious: DONT_EVER_USE_THIS_FEATURE(1). : We also want repeat events; I can think of two ways to do it. Either : require everything to be explicit with adverbs, or have the closure's : return value determine whether to keep calling back or to quit. GLib : does the latter, and there's a cleanliness in how the closure itself can : control when to stop, but the former means you can schedule arbitrary : code without changing it. I think the conceptual default for callbacks should be single call, with the return value reserved for returning actual data to whatever context calls it. It's easy enough to have a special call that says something like call_me_again(). Er, callmeagain()... :-) You also have the ability to schedule repeated calls externally to the closure, presumably. In general, I think that's even cleaner than usurping the return value. I'm presuming we also give the closure some way to get at its scheduler handle so it can remove itself from repeats, or otherwise give it some kind of dont_call_me_again(). Er... All that being said, it doesn't actually make a lot of sense to return user data to the scheduler. Unless, that is, the scheduler is also managing some kind of pipeline and will feed that return value to some other code. But then, timed generators are nice for lots of simulation applications. (But then you start getting into discrete event simulations where you want to simulate the flow of time as well, where delay() isn't really a real delay, but just waits till virtual time gets far enough. Well, that's enough brain strain for now.) Larry
