Does Lisp have means for event driven programming?
It's a neat feature in VB, I wish there was something similar in Lisp.
Thanks for any pointers.
Cheers
K�roly
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net
"K�roly Ladv�nszky" <··@bb.cc> writes:
> Does Lisp have means for event driven programming?
> It's a neat feature in VB,
It's also a completely limiting feature of VB. IMO there is nothing
"linguistic" about event-driven programming, and it is both appropriate that
CL doesn't offer this as part of the language and silly that VB, as a language,
does.
All there is to event-driven programming is a set of protocol bindings
between a particular user-interface model and a set of
otherwise-general-purpose functions. Since user-interface models are
constantly evolving, it's easy for such a model to become obsolete, making
obsolete any standard which makes the mistake of incorporating its bindings
at the language level.
CL is designed in a way that is intended to NOT become obsolete by NOT
binding to things that are likely to be more ephemeral than it...
Event-driven programming bindings WOULD be appropriate as a layered
standard that was clearly articulated as a separable layer, but at
present there is none such. The substitute is "ask your vendor". Which
is pretty much what you'd have to do even if there WAS such a standard
since each vendor could STILL opt to comply only with CL and not with every
layered standard, so you'd have to ask the vendor anyway.
Lisp certainly has the capability of writing functions which are associable
with events, but it's up to implementations to create the bindings between
them. LispWorks and Allegro both offer event-driven UI's, for example.
I won't be surprised if there are freeware UI's that work in an event-driven
> I wish there was something similar in Lisp.
Xanalys LispWorks has CAPI and Franz Allegro has something I'm not sure the
name of (maybe "Common Graphics"), both of which offer event-driven callbacks.
Neither has to modify the language in order to accomodate this. Probably
there are some freeware things that belong in this list, too, I just
don't know them. Btw, the CAPI is cool because it can work on both Linux
and Windows with a uniform interface; on the other hand, you have to work
from documentation. The Franz version has a drag-and-drop GUI builder, but
only works for Windows as far as I know. There may be other freeware things
I don't know about, but I'm sure someone will post followups with that
info.
> Thanks for any pointers.
Saying what implementation you're using often helps in queries of this kind.
Thanks for your answer.
What I have in my mind is not UI related. In VB, objects can raise events,
objects interested in the events will handle them. Thats a very simple
mechanism,
facilitates easy coding in many situations, even if its just a console
application with
no GUI at all.
Event methods and RaiseEvent in any class
"Kent M Pitman" <······@world.std.com> az al�bbiakat �rta a k�vetkez�
�zenetben: ····················@world.std.com...
> "K�roly Ladv�nszky" <··@bb.cc> writes:
>
> > Does Lisp have means for event driven programming?
> > It's a neat feature in VB,
>
> It's also a completely limiting feature of VB. IMO there is nothing
> "linguistic" about event-driven programming, and it is both appropriate
that
> CL doesn't offer this as part of the language and silly that VB, as a
language,
> does.
>
> All there is to event-driven programming is a set of protocol bindings
> between a particular user-interface model and a set of
> otherwise-general-purpose functions. Since user-interface models are
> constantly evolving, it's easy for such a model to become obsolete, making
> obsolete any standard which makes the mistake of incorporating its
bindings
> at the language level.
>
> CL is designed in a way that is intended to NOT become obsolete by NOT
> binding to things that are likely to be more ephemeral than it...
>
> Event-driven programming bindings WOULD be appropriate as a layered
> standard that was clearly articulated as a separable layer, but at
> present there is none such. The substitute is "ask your vendor". Which
> is pretty much what you'd have to do even if there WAS such a standard
> since each vendor could STILL opt to comply only with CL and not with
every
> layered standard, so you'd have to ask the vendor anyway.
>
> Lisp certainly has the capability of writing functions which are
associable
> with events, but it's up to implementations to create the bindings between
> them. LispWorks and Allegro both offer event-driven UI's, for example.
> I won't be surprised if there are freeware UI's that work in an
event-driven
>
> > I wish there was something similar in Lisp.
>
> Xanalys LispWorks has CAPI and Franz Allegro has something I'm not sure
the
> name of (maybe "Common Graphics"), both of which offer event-driven
callbacks.
> Neither has to modify the language in order to accomodate this. Probably
> there are some freeware things that belong in this list, too, I just
> don't know them. Btw, the CAPI is cool because it can work on both Linux
> and Windows with a uniform interface; on the other hand, you have to work
> from documentation. The Franz version has a drag-and-drop GUI builder,
but
> only works for Windows as far as I know. There may be other freeware
things
> I don't know about, but I'm sure someone will post followups with that
> info.
>
> > Thanks for any pointers.
>
> Saying what implementation you're using often helps in queries of this
kind.
>
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net
"K�roly Ladv�nszky" <··@bb.cc> writes:
> Thanks for your answer.
>
> What I have in my mind is not UI related. In VB, objects can raise events,
> objects interested in the events will handle them. Thats a very simple
> mechanism,
> facilitates easy coding in many situations, even if its just a console
> application with
> no GUI at all.
>
> Event methods and RaiseEvent in any class
What you might like to do (If I understand you correctly)
is create a table of objects interested in events of a particular
kind, and provide a mechanism for an object to register itself,
deregister itself, and for objects to raise events:
(raise-event :foo)
could then call all objects' functions that were registered as the
callback for that event. Obviously, there are possible issues with
order-dependent effects, etc., and possibly with dealing generic
functions, but at a basic level, very simple, I think.
Marcin Tustin <·····@benedict.i-did-not-set--mail-host-address--so-shoot-me> writes:
> "K�roly Ladv�nszky" <··@bb.cc> writes:
>
> > Thanks for your answer.
> >
> > What I have in my mind is not UI related. In VB, objects can raise events,
> > objects interested in the events will handle them. Thats a very simple
> > mechanism,
> > facilitates easy coding in many situations, even if its just a console
> > application with
> > no GUI at all.
> >
> > Event methods and RaiseEvent in any class
>
> What you might like to do (If I understand you correctly)
> is create a table of objects interested in events of a particular
> kind, and provide a mechanism for an object to register itself,
> deregister itself, and for objects to raise events:
>
> (raise-event :foo)
>
> could then call all objects' functions that were registered as the
> callback for that event. Obviously, there are possible issues with
> order-dependent effects, etc., and possibly with dealing generic
> functions, but at a basic level, very simple, I think.
Right. A lot of this is just simple and obvious use of the object system.
You have a system that is a game like Zork or MOO where objects might come and
go from rooms (containers), and those objects might also be containers,
and things need to tell each other about the event of entry, exit, etc.
So you define a generic function for each entry, exit, etc. that notices
such entry/exit. That's just a matter of advertising some set of generic
functions that objects in your application can/should/must implement.
You can, as Marcin suggests here, make a raise-event kind of thing that
doesn't take an argument of what to notify. That's pretty much a synonym
for "tell some dynamically chosen thing" of which there might be one or
many such things, depending on your application. e.g., in a MOO you
might write
(defun raise-event (event-name)
(with-simple-restart (event-handled "Dismiss event ~A." event-name)
;; Try possible handlers until someone does
;; (invoke-restart 'event-handled)
(loop for container in (object-and-its-containers *current-room*)
do (event-dispatch event-name *current-room*))))
Whether the method is managed by a static handler (a method on the object)
or a dynamic handler (a function that can be dynamically associated with
or deassociated from the handler) is a design choice.
Common Lisp lets you do all of these things, and requires remarkably little
work to do them. However, it does not (as VB does) force you into a corner
where you can do your control in only one standard way. That may seem
limiting if you're not looking to do a lot of thought, but since the thought
and the subsequent consequences lead to semantically different effects, it's
important to understand that tying you to only one way of doing things is
saying that the language knows better than the application designer what the
answer to a certain problem is, which is likely false in practice.
You might also look at the Common Lisp condition system, which is one
such worked mechanism for handling a particular kind of event (the
detection of a "condition"). The condition system is to allow quite
complicated combinations of advice from the surrounding dynamic
context about how to handle errors. This is good for some things, but
might be bad for others. Certain window system things, for example,
might prefer to do less search and more statically wired effects...
My guess, though, is that saying Common Lisp doesn't have this capability
already is more an admission that one hasn't done the basic work of reading
and understanding the object and condition systems, and has just assumed
that car and cdr are all Lisp has to offer.
Kent M Pitman wrote:
> Common Lisp lets you do all of these things, and requires remarkably
> little
> work to do them. However, it does not (as VB does) force you into a
> corner
> where you can do your control in only one standard way.
I did an implementation of this a while back in CLOS. It had two mixin
classes, master and dependent The protocol for master was as follows:
(add-dependent <master> <dependent>)
(release-dependent <master> <dependent>)
(dependents <master>)
(notify-dependents <master> <msg> &rest <parms>)
I did two implementations for this mixin. The first stored dependency
lists in a hash table hashed on the master and the second added a slot to
the master object.
The protocol for the dependent was a single function:
(acknowledge <dependent> <msg> &rest <parms>)
The implementation of notify-dependents simply mapped acknowledge over the
appropriate dependents collection.
Yes, I ripped it off from Smalltalk. It was, syntactically, a bit clunkier
because you didn't have a pseudo variable like self available in CLOS's
multi-method paradigm, so you had to pass the master around as a parameter.
But I was also able to use an EQL specializer on acknowledge's <msg>
parameter and so I didn't have a lot of odd dispatching logic o go through
either. In the end it performed the same function as Smalltalk's (or VB's)
event mechanism and worked quite nicely.
The important thing, though, was that it took about a dozen lines of code
to implement. It worked well enough for dependency lists holding less than
a a couple dozen objects. For more than that, I would have gone ahead and
built a real registry with dependents telling you what they were interested
in. That would have taken all of another dozen or so lines. The point is
that this type of event mechanism is SO easy to do in Lisp that you just go
ahead and code it. The user implementation fits so seamlessly and is so
little work that there's no real need to add it to the language itself.
faa
P.S. If this looks a lot like an "Observer" design pattern, it's because
the GoF ripped off (uh`, borrowed?) this dependency mechanism, too.
Johnson was (and still is) an avid Smalltalk fan. Observer just looks a
lot uglier by the time the whole model gets to C++ because you can't simply
design a generic update/acknowledge method and, instead, need an object
sitting around holding a bunch of crappy methods with different names.
Thank you Frank for your answer. It has been very helpful to me.
Cheers,
K�roly
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net
"K�roly Ladv�nszky" wrote:
> What I have in my mind is not UI related. In VB, objects can raise events,
> objects interested in the events will handle them. Thats a very simple
> mechanism,
This sounds like NeXT's NSNotification[Center] class from their
Foundation Framework. If you wish, go to the Apple website and read some
of the Foundation documentation (they may call it "Cocoa") to see how
they architected it. It's not necessarily the best way, even for the
ObjC language, let alone for lisp, but it has weathered well for 10
years now, so it might give you ideas.
Eric
--
US Supreme Court hearing 00-836
GEORGE W. BUSH, Petitioner, v. PALM BEACH COUNTY CANVASSING BOARD
Justice (Scalia?) to Mr. Klock (representing Katherine Harris):
20 and therefore, I guess, whether we win, whether your side,
21 the side you're supporting wins or loses, it doesn't
22 change that, and I guess that's moot, but my question is,
In article <············@corp-goliath.newsgroups.com>, K�roly Ladv�nszky wrote:
>Thanks for your answer.
>
>What I have in my mind is not UI related. In VB, objects can raise events,
>objects interested in the events will handle them. Thats a very simple
>mechanism,
>facilitates easy coding in many situations, even if its just a console
>application with
>no GUI at all.
Such a mechanism can be coded up in any reasonably powerful programming
language.
You just need to register the interested objects in some list or other
structure, and then walk the list and call handlers when events
are raised.
For example, in the Linux kernel, protocol modules can register for
specific packets coming from the network device driver layer; the IP
protocol wants only IP and ICMP packets, not, say, ARP or IPX packets.
This is done in C, although C has no specific built-in support for it.
>Event methods and RaiseEvent in any class
Lisp's object system doesn't assign methods to classes. You can create
a raise-event generic function, and then implement methods for relevant
parameter type combinations. In CLOS, you could handle events by type,
taking advantage of the type hierarchy to categorize events. This way,
an object wouldn't have to declare what events it wants at registration
time; the method combination system would figure out whether an object
can take the message, and which method(s).
In article <··········@corp-goliath.newsgroups.com>, K�roly Ladv�nszky wrote:
>Does Lisp have means for event driven programming?
Event driven programming simply means that the software obtains an input
from the real world, and then responds to it, without ever waiting for
any specific input type. The software typically has some loop which obtains
the event at the top, and then categorizes the event and dispatches the
appropriate handler.
Such an event-handling framework can be devised in any worthwhile
programming language.
"Kaz Kylheku" <···@ashi.footprints.net> az al�bbiakat �rta a k�vetkezo
�zenetben: ····························@news1.rdc1.bc.home.com...
> In article <··········@corp-goliath.newsgroups.com>, K�roly Ladv�nszky
wrote:
> >Does Lisp have means for event driven programming?
>
> Event driven programming simply means that the software obtains an input
> from the real world, and then responds to it, without ever waiting for
> any specific input type. The software typically has some loop which
obtains
> the event at the top, and then categorizes the event and dispatches the
> appropriate handler.
>
> Such an event-handling framework can be devised in any worthwhile
> programming language.
Yes, of course. That applies to several programming paradigms but in case it
is a built-in feature, it is not worth devising.
Thanks for the education.
Cheers,
K�roly
______________________________________________________________________________
Posted Via Binaries.net = SPEED+RETENTION+COMPLETION = http://www.binaries.net
"K?oly Ladv?szky" <··@bb.cc> wrote in message news:<··········@corp-goliath.newsgroups.com>...
> Does Lisp have means for event driven programming?
There is an example of a quite elaborate event-driven system
written in Common Lisp at
http://www.radonc.washington.edu/medinfo/prism/
There are papers, tech reports etc. as well as the code.
The Prism GUI is written using a library (in Common Lisp) called
SLIK, which in turn uses CLX (X windows). The report
ftp://ftp.radonc.washington.edu:/pub/slik/slik-v20.pdf (or .ps)
shows how the event-driven programming is done.
- Jon Jacky, ······@speakeasy.net