Announcing Semaphors : CLIM Killer? Garnet redux?...
Kenny Tilton
going to break down and share with the world what I call Semaphors
and/or DefModel (it is traditional I gather to name stuff after a key
macro, anyway...) something I developed originally under MCL and am now
using under ACL in support of a major new application under development
at CliniSys:
http://franz.com/careers/jobs/outside/tekwood.00.8.4.php3
I'll try a twenty-five words or less on Semaphors below, but first...the
reason for sharing Semaphors now is precisely to locate folks who might
want to get involved with the CliniSys project. I intended to go public
with Semaphors eventually, but I am doing so now and taking time from
development because we are looking to grow the development team.
But recruiting aside, if you miss Garnet or need a better GUI or if you
like constraints (a word I hate especially since it is wrong for the
simpler, linear 'dataflow' functionality of Semaphors) or if you are
interested in an overall better way to program <gasp>...I think you'll
enjoy Semaphors.
My next post will start the substantive description of Semaphors, this
post is just preliminary drum-beating. The substantive bit will be
replete with code samples and listener output so anyone can follow
along, but if you want to dabble you will need a copy of ACL for Windows
from Franz, and sadly the free download will not suffice (can't load
FASLs). Send me eMail and i will eMail you a zipped FASL...in a classic
case of the cobbler's children I have no Web site from which to FTP.
Semaphors are not Open Software (yet? Maybe someday...) but if I ever
get some proper legal stuff taken care of I will be able to share the
source, enabling more people to play along. Or maybe a better idea: if I
am inundated with requests for an implementation in a given environment
(but the CL compiler needs good MOP support ala ACL) I will likely hook
up with someone strong in said environment (CMUCL?) and get a FASL cut
for that.
One last thing: while I developed Semaphors in blissful ignorance of
similar work elsewhere, there is loads of prior art. Constraint
programming is the more ambitious superset in which Semaphors would
fall, and lots of info on constraints can be found over at UNH:
http://www.cs.unh.edu/ccc/archive/constraints/links/pubs.html
That will include references for Garnet, which I looked at briefly but
never used. Some of the syntactic similarities were delightful, btw.
More recent similar work was presented at LUGM '99 in San Francisco, but
I have lost every shred of info I had on that conference...if anyone
attended and can give me a lead on the presenter (the paper title
mentioned "constraints" I think) i would be grateful.
OK, one more last thing: I am just a simple programmer, and everything i
have done has been in support of application development, so don't ask
me anything deep. But i do tend to chew the scenery with grandiose
claims, just ignore those or refute them, i don't mind.
In twenty-five words or less, and glossing over some complexity,
Semaphors let you define selected slots of (CLOS) ModelObject instances
as if they were cells in a spreadsheet. (The LUGM '99 presenter uses the
same spreadsheet metaphor, btw.)
As with spreadsheet cells, a semaphoric slot (semaphor, for short) can
have bound to it a literal value or a formula. The formula is any Lisp
form which, when wrapped in a suitable macro, enjoys access to anaphoric
variables 'self (the CLOS instance of the slot) and 'value (the most
recent value calculated by the formula).
Literals or formulas can be offered via :initform, :default-initarg or
make-instance (not sure my metaclass code is strong enough in the
reinitalization area to handle 'change-class or reinitting for a changed
class, but if necessary that will be made to work). I like to think of
this as instance-oritented programming, since different instance of the
same class can get different rules.
If the formula references another semaphor at runtime, a dependency is
automatically recorded. Semaphors are automatically recalculated when
their dependencies change. Sadly this compromises GC, so when you want
to lose something from the model you have to snuff it explicitly. (tech
note: I looked at weak hash tables at one point, forget what
happened...but see below)
Semaphors can reference semaphors of the same or any other instance.
Every ModelObject has an 'mdName slot. Included in the package I will
send is a Family model with a semaphoric slot for 'kids (I like short
names) and a host of routines that let you manage a namespace of
ModelObject instances. 'kids being semaphoric is huge; it means the
model itself changes shape dynamically in response to other change in
the model.
It is possible to define what I call 'echo' functions which are
dispatched when a sempahor changes value. Thus if a semaphoric slot
'myColor changes from red to blue, an echo function can trigger screen
redraw. (My experience has been that it is a Bad Thing to have side
effects inside semaphor formulas.) The echo function is passed the
instance and the old and new values of the slot.
getting back to GC, I always manage model instance in a Family-based
namespace, and the 'echo function for the kids slot explicitly snuffs
lost kids, so there was no pressing need for the weak-hash table trick.
that could be revisited if necessary, along with lots of other design
decisions. Semaphors have been through a lot and are definitely
mature...they never give me trouble any more (almost)...but one thing I
see is that it is fertile ground and lots of fun remains to be had.
There are several kinds of semaphors besides the standard kind.
Ephemeral semaphors revert to nil after propagating news of any new
state to dependents, good for events. Deferred semaphors do not evaluate
(or echo) until asked (read at runtime). This is an efficiency thing,
and actually an awful lot about Semaphors derives from making them
faster.
Another kind is what I call a Drifter...unlike other formulaic (ruled)
semaphors, you can 'setf their value; the formula for a drifter is
understood to return a delta to be applied to the current value. I might
use this to define a clock whose hands would normally move along with a
semaphoric feed from the system clock, but which could be reset at will,
resuming their ruled motion once reset.
Others are Delta (when a numeric Delta "changes" from 3 to 0, it is
considered "unchanged", ie, the value is understood to be a change, and
we are saying "if the change is 0 I do not need to be recalculated") and
Stream, currently under development in support of a report writer...set
a Stream semaphoric slot to a list and when any dependendent formula is
triggered to recalculate, the formula will see not the list but each
element in turn.
..and no reason we cannot have more. As I tackle different projects
(some for fun just to explore Semaphors before starting on the CliniSys
project) I always come up with one or more extensions.
Aside from the different kinds of Semaphors, more control can be had by
placing filters on any given dependency within a formula. I call these
Synapses for fun, though I think it a misnomer. A good example is a
"sensitivity" synapse, which says "don't tell me you have changed until
you have changed by this amount"...btw, that is another case of
efficiency driving the engineering. Synapses are fully user-programmable
(whereas the engine itself needs to be taught about new kinds of
Semaphors.) One new synapse let's a formula "watch" another semaphoric
list and not be triggered unless a particular kind of thing appears in
that list. really, a lot of room for fun here, especially since...
Synapses also modulate the value returned to the formula. Synapses sit
between the using and used semaphors, mediating both the decision to
trigger and the result returned. An example of the latter is a "delta"
synapse, subtly but crucially different from a delta semaphor. Imagine
one semaphor indicates speed, and I am building an accelerometer widget.
I want a value that tells me the change in speed. Or maybe I want to
trigger an airbag if the speed drops, what, 5%? between two settings.
Semaphor formulas out of the box just see the current state of the
universe, to make a determination like that would require a lexical
closure in which the formula could preserve state across
invocations...synapses make that a little easier. And only a synapse can
avoid the triggering of the formula in the first place where that is
desired.
I do not really find frequent need for synapses at all, but sometimes
they help out.
A final note: semaphors optimize themselves out of existence if after
evaluation they discover that all semaphors accessed contained constant
literals. That needs some explaining. In support of this optimization I
require the programmer to decide at instance-initialization time if a
semaphoric slot /not/ being assigned a formula will be constant or not.
If I place a button at (make-position 25 25) it stays there. If I
specify the same value as being a semaphoric variable (SMVariabl), by
coding: (smv (make-position 25 25)), then it later can be moved.
Basically by omitting the 'smv macro (like I said, I like short names
for stuff I use a zillion times) I am guaranteeing to the model that it
need not record a dependency on that slot. Other metaclass internals
then reject any change to that slot (as they do any atempt to setf a
ruled semaphor other than Drifters).
OK, that's more than I thought i was going to write. I'll save the
rah-rah I wanted to finish with for a follow-up post. Send email if you
want the ACL fasl. Since this is also a recruiting exercise, resumes
welcome as well, and all communications will be treated confidentially.
Kenny
PS AStore fans will be amused to learn I managed to create a joint
metaclass of 'persistent-standard-class and ModelClass, so persistent
objects can have semaphoric slots, stored procedures if you will.
Fernando Rodríguez
>My next post will start the substantive description of Semaphors, this
>post is just preliminary drum-beating. The substantive bit will be
>replete with code samples and listener output so anyone can follow
>along, but if you want to dabble you will need a copy of ACL for Windows
>from Franz, and sadly the free download will not suffice (can't load
>FASLs).
It won't work with any other implementation of cl? O:-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Barry Margolin
Fernando Rodríguez <spa...@must.die> wrote:
>On Fri, 13 Oct 2000 21:00:12 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:
>
>
>>post is just preliminary drum-beating. The substantive bit will be
>>replete with code samples and listener output so anyone can follow
>>along, but if you want to dabble you will need a copy of ACL for Windows
>>from Franz, and sadly the free download will not suffice (can't load
>>FASLs).
>
It sounds like it contains quite a bit of graphics code, which isn't
standardized by CL, and he hasn't yet written the modules that interface
with other implementations.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Rainer Joswig
<kti...@nyc.rr.com> wrote:
> OK, that's more than I thought i was going to write. I'll save the
> rah-rah I wanted to finish with for a follow-up post. Send email if you
> want the ACL fasl. Since this is also a recruiting exercise, resumes
> welcome as well, and all communications will be treated confidentially.
Have you ever looked at Frame Representation languages?
KEE (Knowledge Engineering Environment, no longer developed,
still supported - I think) from Intellicorp provides something
like that. They also have large UI system (Units + Common Windows ->
KeePictures -> ActiveImages) built on top.
From what you describe, I think some stuff of KEE sounds very
similar (though KEE is pre-CLOS). KEE is a bit like Lisp + IDE,
on steroids. Lot's of steroids.
Btw., "Common Windows" was once supposed to be the standard
for windowing in Lisp.
--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Paolo Amoroso
> More recent similar work was presented at LUGM '99 in San Francisco, but
> I have lost every shred of info I had on that conference...if anyone
> attended and can give me a lead on the presenter (the paper title
> mentioned "constraints" I think) i would be grateful.
I didn't attend the conference, but I have the proceedings. Maybe you refer
to:
"COSI: Adding Constraints to the object-oriented paradigm"
Gary Curtis, Mark Giuliano (Space Telescope Science Institute)
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Fernando Rodríguez
>On Fri, 13 Oct 2000 21:00:12 GMT, Kenny Tilton <kti...@nyc.rr.com> wrote:
>
>> More recent similar work was presented at LUGM '99 in San Francisco, but
>> I have lost every shred of info I had on that conference...if anyone
>> attended and can give me a lead on the presenter (the paper title
>> mentioned "constraints" I think) i would be grateful.
>
>I didn't attend the conference, but I have the proceedings. Maybe you refer
>to:
>
> "COSI: Adding Constraints to the object-oriented paradigm"
> Gary Curtis, Mark Giuliano (Space Telescope Science Institute)
Found it: http://www.stsci.edu/apsb/doc/papers-and-meetings/99-LUGM/lug-99.pdf
David J. Cooper Jr.
>
> More recent similar work was presented at LUGM '99 in San Francisco, but
> I have lost every shred of info I had on that conference...if anyone
> attended and can give me a lead on the presenter (the paper title
> mentioned "constraints" I think) i would be grateful.
>
I also presented on GWL at LUGM '99, which is based on GDL or
ICAD/IDL, which I believe address some similar issues to what you
describe.
GDL and GWL are covered in chapters 4 and 5 of
http://www.franz.com/resources/educational_resources/cooper.book.pdf
GWL is also covered in a bit more detail in the conference paper, for
which I am preparing an updated version and will post shortly.
-dave
--
David J. Cooper Jr, Chief Engineer Genworks International
dco...@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com
David J. Cooper Jr.
Kenny Tilton <kti...@nyc.rr.com> writes:
>
> More recent similar work was presented at LUGM '99 in San Francisco,
> but I have lost every shred of info I had on that conference...if
> anyone attended and can give me a lead on the presenter (the paper
> title mentioned "constraints" I think) i would be grateful.
>
Kenny,
If you have documentation on Semaphores and a fasl for ACL Linux or
Solaris, I or some people I know might be interested in having a look.
I also presented on GWL (Generative Web Language) at LUGM 1999, which
is based on GDL (General-purpose Declarative Language), which may
address some similar issues to what you describe in Semaphores. It
basically boils down to cached methods with the associated required
dependency tracking.
GDL and GWL are covered briefly in chapters 4 and 5, respectively, of
http://www.franz.com/resources/educational_resources/cooper.book.pdf
GWL is also covered in a bit more detail in the conference paper, for
which i am preparing an updated version and will post shortly.
Kenny Tilton
> > Gary Curtis, Mark Giuliano (Space Telescope Science Institute)
>
> Found it: http://www.stsci.edu/apsb/doc/papers-and-meetings/99-LUGM/lug-99.pdf
> :-)
Thx Paulo & Fernando, that's the one...I believe Mark Giuliano was the presenter.
Good paper.
Btw, in mentioning prior art, I usually mention that programmers are always
coming up with tricks to see to it that state change reliably gets propagated
though an application state space.
A bottleneck setter function (used assiduously) is one such trick, the problem
being that any new reference to the state set requires that someone update the
setter function.
The Think Class Library on the Mac had a subscribe/notify mechanism, and an
Observer pattern was described in Gamma et al's "Design Patterns". Those are fine,
but the ones I know about require hand-wiring of dependencies.
And, again, a spreadsheet application itself certainly offers the benefit of
guaranteeing model state remains internally consistent. I hear Excel lets you
attach VBA to spreadsheet cells...sounds like we are tunneling towards each other.
:)
I am just polishing up a couple of examples I thought should proceed the rah-rah
stuff I promised. RSN.
kenny
Kenny Tilton
screamingly fast, but apparently its NG server is, um, suboptimal...just
now dropped back to my old ISP (kept for just this eventuality) and
found some traffic. computers...
kenny
Kenny Tilton
>
> In article <rnveussidqcuht2gk...@4ax.com>,
> Fernando Rodríguez <spa...@must.die> wrote:
[snip]
> >It won't work with any other implementation of cl? O:-)
Fernando, you think they are all the same? :) Read on.
>
> It sounds like it contains quite a bit of graphics code
No, no graphics, tho my next upload (if interest develops) would indeed
be a package with a GUI Library built atop Semaphors. The Semaphor
package per se is just a dataflow implementation. The implementation is
via a metaclass, so right now MCL would not even be able to handle it,
IUC. Ironically, Semaphors began under MCL where I managed without a
metaclass. So if someone jumped up and down begging insanely for an MCL
version I would at least take a look at resurrecting it.
Also, as I worked thru converting to a metaclass-based implementation, I
discovered ACL's implementation differed from what I was reading in
AMOP. Plus I encountered bugs in ACL's stuff which I had to work around
because they failed to address them, even after I proved they existed.
(Sorry, Franz, whom I adore. <g>) So....no guarantee the source will
work out of the box even under some other CL that implements the AMOP.
Plus I am hoping to share Semaphors without sharing the source for now.
(Hey, would an ACL for Win FASL work in ACL for Linux? Look...I have a
FASL built in ACL for Win, you want it, you got it.) Getting back to a
source sharing, I do not say that will never happen, but until I get to
that point I am hoping to get by sharing Semaphors /functionally/...if
no one gives a rat's ass about that, I may as well just shut up.
I admit it does not exactly jump out at you, but I tried to address this
when I wrote:
> Semaphors are not Open Software (yet? Maybe someday...) but if I ever
> get some proper legal stuff taken care of I will be able to share the
> source, enabling more people to play along. Or maybe a better idea: if I
> am inundated with requests for an implementation in a given environment
> (but the CL compiler needs good MOP support ala ACL) I will likely hook
> up with someone strong in said environment (CMUCL?) and get a FASL cut
> for that.
kenny
Kenny Tilton
Yes, I had seen that a while ago, but just looked again at some sample
KEE code, f*cking terrifying. :) Yes, fer sher we are in the same rough
domain, but Semaphors are something vastly more approachable. I'll say
again, if you want to understand what Semaphoric programming is like,
and you have ever used a spreadsheet, there ya go. Same thing.
Only diff is, in Semaphors a rule is bound to a slot of an instance...in
a spreadsheet you just have cells, no identifiable "instance" grouping
of cells.
Not sure if KEE works this way, but one thing I want to make clear is
that, just as with a spreadsheet, Semaphors are absolutely not about
supplying partial information and having the system effectively search
for a solution which satisfies one or more partial requirements. This is
not Prolog or Constraint Logic Programming, where you sit there
scratching your head trying to figure out why the result you got was not
the one intended. I do not mean to deprecate those, they are indeed more
ambitious by far than Semaphors, but I think I have discovered that the
less ambitious one-way, linear, dataflow model with which I was content
is enough for a large set of applications.
Again, this is easy, think spreadsheet. The engine just evaluates a form
to come up with a value. One of my Prime Directives has been that
Semaphors will not be of any value if a programmer has to /learn/ them.
The only thing you have to do with semaphors is /accept/ that they work
(it took a while for me to accept it, and I was implementing them).
But one key point: this is not just functional programming made
efficient via smart caching of computations. In another post I will talk
about how Semaphors change programming by letting us think in terms of
dataflow and modeling as opposed to what I call procedural
hand-animation.
kenny
Kenny Tilton
"David J. Cooper Jr." wrote:
>
> I also presented on GWL at LUGM '99, which is based on GDL or
> ICAD/IDL, which I believe address some similar issues to what you
> describe.
>
> GDL and GWL are covered in chapters 4 and 5 of
>
Hey, David. I looked at Chapter 4, and yes, I see a lot of similarities
between Semaphors and GDL. I am a poor reader, but it looks as if in GDL
you specify some "slots" as inputs, some as "attributes", and ne'er the
twain shall meet. So when you call make-part you cannot supply a rule
for an input or a value or different rule for an attribute. If I am
correct, GDL is closer to COSI than semaphors. COSI allows you to define
a constraint for a /class/, whereas with Semaphors, well...
Funny, I forgot about this. One reason I believe Semaphors work so well
is that they are not a new language (or library or embedded language as
Lisp does so well), they are a new datatype. In Lisp I do have to create
a metaclass to make that datatype work (and I do offer as an option that
slots of ModelObjects can be standard slots for whatever efficiency that
might offer)...but I see Python allows new datatypes to de defined, so I
think it would be fun to implement Semaphors over there...anyway, my
point is, with Semaphors you simply add the :semaphor initarg to a slot
declaration and you are then free to assign an instance (via any
standard CLOS mechanism--initform, def-initarg, intarg) a constant
literal, a literal which can be changed later, or a rule...and any rule.
There is less syntax to be learned, and greater reuse of classes,
perhaps one of the biggest benefits of Semaphors: they let OO deliver on
the undelivered promise of reuse.
Another huge difference I see is that apparently (like I say, I am a bad
reader) in both GDL and COSI, attributes do not get recalculated /until
accessed/ should the values on which they depend change (get "bashed"
<g>). This is a night-and-day contrast with Semaphors. In my next
"experience" piece I will get into how I found that Sempahors led to a
modelling or animation paradigm of programming. I have not settled on
the right word, but at bottom this is all about adding causation to the
semantics of a programming language.
I distinguish between models and working models. The latter, once any
cause enters the system, works by itself. Non-working models are like
someone desk-checking an algorithm, meticulously maintaining on paper
the states of all the variables. We programmers without some form of
dataflow programming hack are effectively hand-animating our models.
"Oh, they selected Cut from the menu, now I have to go pull the selected
text into a buffer and update the screen and rememebr to disable Cut and
set up the Undo and, oh sh*t, update the scroll bar and, omigod, enable
Save and..."
With Semaphors we do not wait until some other code accesses a value
whose dependencies have been bashed before we recalculate it, because
then you have no dataflow. Suppose I have a rule that decides the color
of a rectangle, and the values on which it depends change. That
rectangle should change color ASAP, but no one is asking, so no update.
Or maybe we have a two step dependency, A depends on B, B depends on C.
If C changes we have to reevaluate B to decide if A changes, because
maybe A has to be manifested somehow. What if A is a value indicating
whether some real world valve should be open or closed, or more
prosaically, whether a scroll bar should appear or not?
OK, I am off on a nice rant here and maybe I missed something, but my
rough guess is that GDL and COSI applications are largely procedural in
spirit with just a small taste of declarative programming. The twin
mechanisms in Semaphors of 'smv (where you can designate any slot of any
ModelObject as an input from the outside world) and echo functions, via
which one can guarantee values are manifested outside the application
model, if only to the screen...these mechanisms allow programmers to
build working models enjoying both internal causation and the ability to
causally interact with the rest of the world.
kenny
dco...@genworks.com
Kenny Tilton <ti...@liii.com> writes:
>
> Hey, David. I looked at Chapter 4, and yes, I see a lot of similarities
> between Semaphors and GDL. I am a poor reader, but it looks as if in GDL
> you specify some "slots" as inputs, some as "attributes", and ne'er the
> twain shall meet. So when you call make-part you cannot supply a rule
> for an input or a value or different rule for an attribute.
>
:optional-inputs are hybrids of :attributes and :inputs - you can
pass in a value or allow the default expression to compute it.
Usually you do not call make-part explicitly, anyway (you only do this
for the root-level instance). All other instances are specified
declaratively using :parts, and get instantiated (and cached)
on-demand like everything else. And the :inputs specified to a :part
generally come from :attributes in the parent part. So in effect, this
is supplying a rule for an input (normal :inputs as well as
:optional-inputs).
>
> Another huge difference I see is that apparently (like I say, I am a bad
> reader) in both GDL and COSI, attributes do not get recalculated /until
> accessed/ should the values on which they depend change (get "bashed"
> <g>).
>
Correct. Everything is calculated on-demand. This is a main difference
from a spreadsheet, which does not have this kind of fine-grained
dependency-tracking (another main difference from a spreadsheet is a
spreadsheet's lack of distinction between class definitions and
instances). On-demand computation is a key concept of a KB language,
since in a large model hundreds or thousands of computations can
depend on the bashing of a single value. Some of those computations
may never be needed, so it would be wasteful (and in some cases
computationally intractible) to "forward-chain" and compute all these
values at "bash-time."
>
> With Semaphors we do not wait until some other code accesses a value
> whose dependencies have been bashed before we recalculate it, because
> then you have no dataflow. Suppose I have a rule that decides the color
> of a rectangle, and the values on which it depends change. That
> rectangle should change color ASAP, but no one is asking, so no update.
>
Why should it change color ASAP? What if no one _ever_ asks to see
that rectagle? What does it mean for it to "change color" if no one is
displaying the rectangle or requesting its color?
Think of the code which does the UI display as "some other code
accessing a value whose dependencies have been bashed."
> Or maybe we have a two step dependency, A depends on B, B depends on C.
> If C changes we have to reevaluate B to decide if A changes, because
> maybe A has to be manifested somehow. What if A is a value indicating
> whether some real world valve should be open or closed, or more
> prosaically, whether a scroll bar should appear or not?
>
When that valve's open/closed status is demanded, it will be computed
(and possibly cached). If the valve's status never ends up being
demanded, that computation will never happen (as well it shouldn't).
>
> OK, I am off on a nice rant here and maybe I missed something, but
> my rough guess is that GDL and COSI applications are largely
> procedural in spirit with just a small taste of declarative
> programming.
>
Is this a statement or a question?
Reini Urban
>As with spreadsheet cells, a semaphoric slot (semaphor, for short) can
>have bound to it a literal value or a formula. The formula is any Lisp
>form which, when wrapped in a suitable macro, enjoys access to anaphoric
>variables 'self (the CLOS instance of the slot) and 'value (the most
>recent value calculated by the formula).
Looks like garnet for CLOS instead of KR. CLOS has some overhead, but is
on the other side better extendable than KR objects and its delegation
mechanism.
>If the formula references another semaphor at runtime, a dependency is
>automatically recorded. Semaphors are automatically recalculated when
>their dependencies change. Sadly this compromises GC, so when you want
>to lose something from the model you have to snuff it explicitly. (tech
>note: I looked at weak hash tables at one point, forget what
>happened...but see below)
KR has an extensive caching algorithm on such changes. see the sources.
>(My experience has been that it is a Bad Thing to have side
>effects inside semaphor formulas.)
hmm. precalculation of objects being affected by side effects would be
nice to store.
(kr stores links, most clos objects pre-calculate it parents)
how would you improve arbitrary events then?
resolving side-effected objects at compile-time would be a good thing to
have, e.g. to warn about cycles and illegal constraints, cache links,
..
>There are several kinds of semaphors besides the standard kind.
>Ephemeral semaphors revert to nil after propagating news of any new
>state to dependents, good for events. Deferred semaphors do not evaluate
>(or echo) until asked (read at runtime). This is an efficiency thing,
>and actually an awful lot about Semaphors derives from making them
>faster.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
Barry Margolin
>Barry Margolin wrote:
>> It sounds like it contains quite a bit of graphics code
>
>No, no graphics, tho my next upload (if interest develops) would indeed
>be a package with a GUI Library built atop Semaphors. The Semaphor
>package per se is just a dataflow implementation.
Then why did you call it a "CLIM Killer"? CLIM is a user interface
management system, with lots of graphical features.
And your descriptions of the automatic things that you can make happen when
a value changes seemed oriented towards graphics. For instance, you
mentioned that you can cause an action to take place when you change a
color attribute -- naturally, I assumed that a likely action would be to
change the color of some graphic on the screen.
Kenny Tilton
This is odd, you quoted me saying that my /next/ upload would be the GUI
I am building atop Semaphors, then you asked why I am talking about a
GUI. :) Anyway...
I am doing a phased introduction, introducing first the semantics of
Semaphors, which can be appreciated just by seeing output to the
listener. This is part an attempt at good pedagogy, part a desire to
make clear that Semaphors are not just another GUI framework.
That said, I have long believed that it is pointless to share just
Semaphors since most folks who might be interested would want to begin
by building an app with a GUI. I also see from time to time on this NG
people expressing interest in having something other than CLIM, hence my
attention-grabbing headline.
BTW, you were not wrong...if enough interest develops for me to continue
the effort to share Semaphors, the MDGraphics package would work only
with ACL's win: package loaded, I think.
kenny
Barry Margolin wrote:
>
> In article <39EBDF42...@liii.com>, Kenny Tilton <ti...@liii.com> wrote:
> >Barry Margolin wrote:
> >> It sounds like it contains quite a bit of graphics code
> >
> >No, no graphics, tho my next upload (if interest develops) would indeed
> >be a package with a GUI Library built atop Semaphors. The Semaphor
> >package per se is just a dataflow implementation.
>
Tom Breton
> I admit it does not exactly jump out at you, but I tried to address this
> when I wrote:
>
> > Semaphors are not Open Software (yet? Maybe someday...) but if I ever
> > get some proper legal stuff taken care of I will be able to share the
> > source, enabling more people to play along.
Well, I hope you get those legal difficulties taken care of.
Semaphors sound very interesting, but without source, there's little
chance I would use them, unfortunately.
--
Tom Breton, http://world.std.com/~tob
Not using "gh" 1997-2000. http://world.std.com/~tob/ugh-free.html
Some vocal people in cll make frequent, hasty personal attacks, but if
you killfile them cll becomes usable.
Barry Margolin
>Barry,
>
>This is odd, you quoted me saying that my /next/ upload would be the GUI
>I am building atop Semaphors, then you asked why I am talking about a
>GUI. :) Anyway...
But you mentioned CLIM in the subject line of the thread. So I assumed
that the GUI was an initial feature of Semaphors, not something you would
add on later.
Robert Monfera
> Correct. Everything is calculated on-demand. This is a main difference
> from a spreadsheet, which does not have this kind of fine-grained
> dependency-tracking (another main difference from a spreadsheet is a
> spreadsheet's lack of distinction between class definitions and
> instances). On-demand computation is a key concept of a KB language,
> since in a large model hundreds or thousands of computations can
> depend on the bashing of a single value. Some of those computations
> may never be needed, so it would be wasteful (and in some cases
> computationally intractible) to "forward-chain" and compute all these
> values at "bash-time."
Aren't on-demand calculation and eager calculation reconcilable? For
example, part of the spreadsheet model is the window on the
spreadsheet, demanding constant updates. Update the few visible cells
(as demanded by the user's mental model) and don't worry about the rest.
1. Calculated cells (essentially cached values) get invalidated (set to
a secret value) based on dependencies
2. Invalidated cells that are visible on the screen are recalculated
Robert
Kenny Tilton
Robert Monfera wrote:
>
> dco...@genworks.com wrote:
>
> > Correct. Everything is calculated on-demand. This is a main difference
> > from a spreadsheet, which does not have this kind of fine-grained
> > dependency-tracking (another main difference from a spreadsheet is a
> > spreadsheet's lack of distinction between class definitions and
> > instances). On-demand computation is a key concept of a KB language,
> > since in a large model hundreds or thousands of computations can
> > depend on the bashing of a single value. Some of those computations
> > may never be needed, so it would be wasteful (and in some cases
> > computationally intractible) to "forward-chain" and compute all these
> > values at "bash-time."
>
You know, I am just going to go out and slit my wrists. Two different
fucking ISPs are incapable of operating NGs!!!! <g> Aside from this
quotation, I have no clue what Mr. Cooper offered. But...
OK, bravely trying to read between the lines: I say again, if one is
calculating on-demand, then one is still procedural. One has not
achieved causation. The programmer is still deciding when values should
be sampled, and while you might have a good programmer, you do a lot
better with a paradigm that just plain works, good programmer or
indifferent. There lies the Grail.
I totally reject the performance objection. I have solved that time and
again thru engineering, not by compromising the paradigm of causation. I
call these "speed weeks", where once the app starts to drag I hunker
down and work out why (some dependency causing loads of expensive
recalculatins) and invariably I am able to look at the problem and say,
shucks, there is no reason to recalculate the whole thing each time, i
just need to surgically recalulate a couple of things. I am able then to
effect that with Semaphors as they stand....and in the early days I
would extend Semaphors in some way (such as by introducing the whole
idea of synaptic mediators between two semaphors) such that I could
maintain peak performance.
Don't forget, the small expenditure of CPU power required to track
semaphors /begins/ by improving on the procedural paradigm. I believe
the COSI folks made the same point: we lose a few ticks tracking the
dependencies, and get repaid immediately by knowing precisely what needs
to be recalculated.
To say it would be wasteful to bring a model into conformity with a
state change proves one is not committed to the modelling paradigm...one
is hoping one can get by by procedurally deciding when to bring which
state into conformity. And that sounds like GOTOs to me... :)
kenny
Kenny Tilton
to post anything after having kamikazes poured down my throat in a
sports bar...go Yanks...
Worst thing is I was wrong, performance of course is an issue. Semaphors
are structs which must be allocated and GCed, and the metaclass
implementation certainly slows things down a little. I always say I
would not try to use semaphors for Deep Blue's search mechanism.
On the other hand, as I said in my unfortunate previous post, I have
encountered performance problems several times and have always managed
to solve them without abandoning the declarative paradigm semaphors
support. For example, just for fun I created a double-acrostic
interface, in which it turned out my original approach had some four or
five hundred little boxes for letters all watching each
keystroke...sloooowwww. So I took a little trouble and created a mixin
for a FocusTracker class and mixed that in selectively at a couple of
places in the control hierarchy, so that only five or so letters watched
any given FocusTracker, the lowest level of tracker watched a higher
level of trackers, the top actually watch a semaphor corresponding to
the keyboard.
But getting back to problems such as Deep Blue or many other
comutationally intensive jobs, right, I would not use semaphoric slots
to model those, just as I would not even allocate a CLOS instance for
every pixel in an 18mb image I was transforming.
kenny