OK, I have my ducks in a row over here re my oft-threatened sharing of
Semaphors with the Outside World. But before undertaking the effort to
(1) read a book on software licensing and (2) write some nice
documentation, i thought I would see if anyone was actually interested.
So...
Here's an admittedly dopey Hello World:
(defmodel computer ()
((event :semaphor :ephemeral :initform (smv nil) :accessor event)
(response :semaphor t :initform nil :initarg :response :accessor
response)))
(def-sm-echo (response)(self newResponse oldResponse)
(when newResponse
(format t "~&Computer: ~a" newResponse)))
(def-sm-echo (event)()
(format t "~&World: ~a" newValue))
(defun hello-world ()
(let ((c (to-be (make-instance 'computer
:response (sm? (case (event self)
(:knock-knock "Who's there?")
(:world "Hello, world.")))))))
(setf (event c) :knock-knock)
(setf (event c) :world))
))
#| Output
World: KNOCK-KNOCK
Computer: Who's there?
World: WORLD
Computer: Hello, world.
|#
The main idea is that the RESPONSE slot is defined declaratively as a
function of the EVENT slot of the same instance, and changes to that
slot (which must also be semaphoric for this to work) are automatically
propagated to the RESPONSE slot. What I call echo functions are invoked
when a slot changes value so those changes can be manifested outside the
model. This incidentally is how screen updates get triggered
automatically; the programmer supplies an echo function to invalidate
the screen for any slot they know change the screen appearance.
That description leaves a unexplained a lot of what the code shows, and
the code shows just a little of what Semaphors are about, but that's the
big idea. And if there is interest, the code I will share also will
contain rudimentary GUI stuff which will then be extended in LGPL (or
similar) open source to include all standard GUI components and more.
(Once you get the idea it is trivial to whip up new widgets.)
For now the dataflow engine underlying Semaphors will be kept
proprietary and distributed only in FASL form. GPL or LGPL open source
is possible down the road. The distro will come with a transferrable
license for non-commercial use. If anyone falls in love with Semaphors
and wants to use it commercially, a royalty-free commercial license will
be worked out.
The initial release will be in ACL5 and ACL6 FASLs. The GUI code
includes enough proprietary ACL Common Graphics code that it will be a
bit of a pain to port to LW or CMUCL/Linux, but down the road if the
interest is there that will happen. The good news is that Franz does not
mind if you grab Trial ACL to check out Semaphors. (I asked.) So any
CMUCL or LW types can check out Semaphors that way and then if you like
them I will work out some way to get you FASLs for your chosen platform.
If you are interested you can respond here or send me e-mail and I'll
get to work on the doc (which will grow steadily), probably be able to
send you a distro in a week.
The rest of this article is something I posted last year which explains
pretty well why I like Semaphors.
kenny
clinisys
Semaphors began as a way to solve a tricky, dynamic GUI layout problem
which arose during work on an arithmetic tutorial, viz, allowing the
student to type easily things like long addition problems with addends
as big as they like and as many addends as they like. Also decimals
should align themselves automatically if entered.
Semaphors solved that almost trivially. Curious, we then applied
semaphors to a trivial problem to see if they were too much trouble for
simple problems. My thinking was, maybe semaphors would be worth the
trouble only for complex problem. The problem I chose was maintaining a
radio group, and semaphors not only solved the simple problem simply,
but when coding the solution i forgot about getting the radio group
initially set to a starting value--but the semaphoric approach happened
to take care of that...i took that as a Sign.
Since then semaphors have come to permeate my applications, and a
semaphor-based GUI framework is part of that. As I mentioned earlier, we
even managed to endow persistent instances with semaphors so views of
persistent data automatically get updated as that data becomes
associated with other persistent data.
The impression I get is that programming is much easier with semaphors:
more functionality gets built in less time with fewer bugs and more fun.
Indeed, the productivity improvement was so great I was led to meditate
on why exactly they were so beneficial. Lots of things have come to mind
over the five-six years I have lived with semaphors.
First, obviously a big win is knowing one's program state is guaranteed
to be self-consistent, and with semaphors this is done for you with near
transparency. Makes me wonder how many bugs could be categorized as
inconsistent-state errors. But this alone did not seem to be enough to
explain the benefit I was enjoying.
My next thought was that any application is a model. Without an
automatic state-propagation (dataflow) engine, the effort of making that
model work falls on the programmer. "OK, that selects some text, now I
have to enable the "Cut" menu item." With a dataflow engine, the model
works by itself. I think of semaphors as animating application models
which programmers generally have to animate by hand, if you will. This
is a grander take on the preceding observation in re self-consistent
state.
Another idea i had was that semaphors conquer the complexity of
applications by decomposing the total complexity into manageable pieces.
Again the spreadsheet is a good example. As a child (before even
calculators) I watched my father work paper spreadsheets by hand. Every
time he made a 'what-if" change he had to propagate that state from cell
to cell to cell. And because A depends on B depends on C, there is I
think some combinatorial explosion of application complexity as the
number of interesting state variables increase.
But even in the most complex spreadsheet, no one cell in a spreadsheet
has a formula tapping more than a few other cells. And semaphors give us
the same benefit in programming: semaphor rules generally access just a
few other semaphors. But in a sense this complexity i am talking about
is that of keeping program state internally consistent.
On our current project, I can see another benefit: semaphors help OO
deliver on reuse. Our classes are generic, low-level, all-purposes...we
get specific behavior by attaching different semaphors to different
instances of the same class, not by subclassing. This means we do not
get into situations where the only way to avoid or get some particular
behavior is to create yet another class...I can code any semaphor I want
for some special circumstance.
Finally, hey, semaphors make feasible a declarative, functional style of
programming, and those are well-understood improvements over other
paradigms.
Anyway, that's the best I can do to explain why it might be, but all I
know is, semaphors are great to program with.
On Fri, 30 Nov 2001 02:11:49 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>OK, I have my ducks in a row over here re my oft-threatened sharing of
>Semaphors with the Outside World. But before undertaking the effort to
>(1) read a book on software licensing and (2) write some nice
>documentation, i thought I would see if anyone was actually interested.
>So...
I am. :-)
--
Fernando Rodr�guez
frr at wanadoo dot es
--
OK, with your vote I have reached the threshold of "sufficient", and
anyway it had occurred to me that CliniSys developers would likely
appreciate some doc so that was going to get done anyway (and when it
looks decent I will let c.l.l. know for those of you who just want to
read the doc)...
Just had a laugh at myself. I was about to ask if you wanted me to send
it to ·······@must.die when I realized "frr at wanadoo dot es" is not a
Sanscrit chant. :)
re the doc, ouch, the TOC alone is four pages long. I will do as much as
i can in a week and ship a distro by next weekend. Then of course I can
answer any Qs and debug for you any efforts you might make, or even
suggest up front how to attack any given problem you might come up with.
I am even prepared to extend Semaphors as necessary to support new
twists, and it has occurred to me that with a little effort
Synapses...well, first:
:alarm (sm? (if (> (^pressure guage (fSensitivity 100)) 10000) :on
:off)
fSensitivity is a filter that keeps the alarm rule from being
re-evaluated for every little change in the pressure. another filter,
fDelta, here would return the /change/ in pressure (and that too takes a
sensitivity qualifier). anyway, I think filters are already
user-extensible and if not a small amount of work should make that
possible. Possibly also Semaphors themselves can be definable by the
user.
finally, I plan to develop mostly as a pedagogic exercise a new class
browser. my thinking is a real-world example will be better than some of
the goofier ideas I had for a seminar.
kenny
clinisys
"Fernando Rodr�guez" wrote:
>
> On Fri, 30 Nov 2001 02:11:49 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
> >OK, I have my ducks in a row over here re my oft-threatened sharing of
> >Semaphors with the Outside World. But before undertaking the effort to
> >(1) read a book on software licensing and (2) write some nice
> >documentation, i thought I would see if anyone was actually interested.
> >So...
>
> I am. :-)
>
> --
> Fernando Rodr�guez
> frr at wanadoo dot es
> --