[Gardeners] Shared State Concurrency specification.

[Matthew Astley]

On Mon, Jul 17, 2006 at 11:17:49AM -0700, Brad Beveridge wrote:

> 1) why is there THREAD.NAME, this looks like it isn't consistant
> with the rest of the function names.  The . is what I'm not liking.

I liked it - but I could get on fine with thread-name instead.

It tells me immediately that it's an accessor for the name slot of a
thread.  This is probably a C / Java prejudice on my part, but I
happen to find it useful in this context.

thread-name fits with the punctuation of most other symbols.  I guess
there is merit in that, and there's little ambiguity.

In a more complex example, if one had classes with methods

  object-handler.name		the name of an object-handler?
  object.handler-name		the handler-name of an object?

what would object-handler-name be?


Perhaps this marks me as insufficiently lispy, but in other languages
the method-name has its own namespace per class.  It seems unfortunate
to roll the combination of (class-name method-name) into one[1]
namespace *and* lose the gap between by not taking advantage of the
wide variety of punctuation available in a symbol name.  What's the
advantage I can't see?

I think this is a digression from SSC to CLOS.  I'm quite new to both.


> 2) would it be more flexible to pass keyword arguments to the thread
> function that is require in SPAWN-THREAD?

Are you referring to &allow-other-keys in

| spawn-thread function &key name &allow-other-keys [Function]

?  I'm guessing the other keys are to control the creation and
spawning of the thread, not for passing into the function.  If one
needed to pass args to `function',

 (spawn-thread (lambda () (my-func my-args)))

would do the trick.  There isn't much else to pass, and the thing that
calls the `function' has to avoid provoking an arg-count error.  No
args seems the simplest solution, for no loss of generality or coding
convenience.


I agreed with the rest of your mail.


Matthew  #8-)
-- 
[1] ok so the objects could live in different packages, and then you
have foo:object-handler-name and bar:object-handler-name to separate
the two.  But if you're using both packages heavily you'll :use both?
That's only one namespace, as seen by the user.