I've been intrigued with applications like the one from Noteheads (the
music scoring system, named Igor something or other). I think it's
really cool how you can download patches and update the system in
realtime, but apparently this is a common feature of Lisp apps.
How does the functional model of Lisp get along with event-driven
applications?
From: Zach Beane
Subject: Re: How does Lisp's functional model gel with event-driven GUI apps?
Date:
Message-ID: <m37jj8kxtj.fsf@unnamed.xach.com>
"jonathon" <···········@bigfoot.com> writes:
> How does the functional model of Lisp get along with event-driven
> applications?
Mark Jason Dominus recently had an interview[1] where I was pleased to
see this exchange:
TPR: Readers learn a lot about functional programming from Higher
Order Perl. Do you think programmers should still learn Lisp or
some other functional language?
MJD: First I need to put in a disclaimer that I don't think Lisp is
a good example of a functional language and I don't think most Lisp
programmers would consider it one. "Functional language" suggests a
firm philosophical stance against side effects. You can see this
stance in true functional languages, like Haskell, where all side
effects must be quarantined in a special kind of data structure
called a "monad". I think most of the Lisp world doesn't care about
that stance.
I'm hoping that's what he meant when he said Lisp has a "dysfunctional
user community" earlier in the interview. :)
Zach
[1] http://www.theperlreview.com/Interviews/mjd-hop-20050407.html
From: Kent M Pitman
Subject: Re: How does Lisp's functional model gel with event-driven GUI apps?
Date:
Message-ID: <umzs3o273.fsf@nhplace.com>
"jonathon" <···········@bigfoot.com> writes:
> I've been intrigued with applications like the one from Noteheads (the
> music scoring system, named Igor something or other). I think it's
> really cool how you can download patches and update the system in
> realtime, but apparently this is a common feature of Lisp apps.
>
> How does the functional model of Lisp get along with event-driven
> applications?
It seems to work fine. Both LispWorks CAPI and Franz Allegro's
windowing system [can't recall its name--common graphics, or some
such] fit in with it very naturally.
The LispWorks system is cheaper to acquire, but doesn't [so far as I
know--I haven't seen their latest release] come with a GUI for creating
stuff, you have to define it programmatically. The Allegro stuff is
a bit pricier, but truly highly easy to use -- much more fun than
the Java gui builders I've seen.
But I think something in your question is implying that you think Lisp
is "only" functional. It has functions available, but it's not like
it's side-effect free. Some teachers use Lisp to teach
side-effect-free programming, but most serious engineers don't program
that way. It's like programming with your hands tied. Normally you
use all the available tools.
Is there some reason you'd imagine that there was a conceptual problem?
Where would you expect that problem to be?
Kent M Pitman wrote:
> The LispWorks system is cheaper to acquire, but doesn't [so far as I
> know--I haven't seen their latest release] come with a GUI for creating
> stuff, you have to define it programmatically.
The LispWorks has an interface builder (except for the Mac version). I
have not used it very much but it seems interesting. The code is
generated as you build the interface. You can also make changes in the
code view to update the graphical representation of the interface.
John DeSoi, Ph.D.
http://pgedit.com/
Power Tools for PostgreSQL
> The LispWorks system is cheaper to acquire, but doesn't [so far as I
> know--I haven't seen their latest release] come with a GUI for
creating
> stuff, you have to define it programmatically. The Allegro stuff is
> a bit pricier, but truly highly easy to use -- much more fun than
Since I'm still learning Lisp and only plan to use it for experimental
personal projects, buying it doesn't make sense for me at this time.
> But I think something in your question is implying that you think
Lisp
> is "only" functional. It has functions available, but it's not like
> it's side-effect free. Some teachers use Lisp to teach
> side-effect-free programming, but most serious engineers don't
program
> that way. It's like programming with your hands tied. Normally you
> use all the available tools.
>
> Is there some reason you'd imagine that there was a conceptual
problem?
> Where would you expect that problem to be?
Well, I was thinking in callbacks and event handlers, the GUI
event-processing loop, and so on.
I guess the event handlers would *have* to use side effects, since
their usual return values would probably be GUI rather than app
related, right?
jonathon wrote:
> How does the functional model of Lisp get along with event-driven
> applications?
SLIK (Small Lisp Interface Kit) is an event-driven GUI-in-Lisp
programming sytem that runs on top of X windows.
It has been used to build a real system, the Prism radiation therapy
treatment planning program.
This report describes how it works and has some programming examples
http://www.radonc.washington.edu/medinfo/prism/slik-v21.ps.gz
The code is available too
http://www.radonc.washington.edu/medinfo/prism/slik.tgz
Jon Jacky
From: Greg Menke
Subject: Re: How does Lisp's functional model gel with event-driven GUI apps?
Date:
Message-ID: <m3vf6ke7up.fsf@athena.pienet>
"jonathon" <···········@bigfoot.com> writes:
> I've been intrigued with applications like the one from Noteheads (the
> music scoring system, named Igor something or other). I think it's
> really cool how you can download patches and update the system in
> realtime, but apparently this is a common feature of Lisp apps.
>
> How does the functional model of Lisp get along with event-driven
> applications?
It works fine. Kind of like callbacks, but nicer since you can supply a
lambda as the callback, not just a function pointer. That lets you
choose how you service the call right where you set it up. Its a lot
easier in Lisp and C. Lisp can be used in a purely functional sense if
you want to but you're in no way bound to do so.
Gregm