On Tue, Feb 17, 2009 at 04:27:40PM +0000, Alaric Snell-Pym wrote:
> 2) Yet it'd also be nice to automate some of this by establishing a
> group of states as a form of "lexical scope", declaring some state
> variables for that scope, and having the states within that scope,
> when they call each other, automatically passing any variables they
> don't explicitly pass.

...example elided...

> I don't know if this is a good idea or not - hidden state can be bad,
> and it requires keyword-style arguments to states, which may be more
> pain than it's worth.

Have you considered using SRFI-39 parameter objects?  I think those give
you precisely what you need - invisible parameters you don't need to
pass every time you call a procedure that might need it.  (can you tell
I'm a parameter fanboy? :) )

I don't think "parameterize" is tail-recursive (it uses dynamic-wind),
so if you expect procedure calls to be nested deeply, this might not be
an option.

> 2) How about reuse of portions of state machines? They should allow
> some kind of lexical scope, too. A complex set of states should be
> packagable into a black box with a set of defined entry states, and
> "dangling pointers" out to exit states that must be supplied when the
> package is used, in effect providing enough exit continuations with
> the correct signatures. It's not quite like a closure, since it might
> have several entry states. But perhaps that's not important and it
> should just be called a closure?

Or a module, perhaps?  I guess it depends on whether it has any runtime
state that it needs to keep.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

Attachment: pgp9ouvcuc7m4.pgp
Description: PGP signature

_______________________________________________
Chicken-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/chicken-users

Reply via email to