Last year, as part of a collection from Springer entitled "Advances in
Exception Handling Techniques" (edited by A.Romanovsky, C.Dony,
J.L.Knudsen, and A.Tripathi), I wrote another paper on condition handling
entitled "Condition Handling in the Lisp Language Family".
As a courtesy to those producing the collection, I voluntarily
withheld web publication of the paper for the first year of the book's
publication in order not to interfere with the book's sales, but by
now I figure those who are going to rush out and get the book have
done so, and I'd like to make the paper available to the web community
at large. Fortunately, I was careful to retain my copyright and am
able to choose to do this. All I got personally for the couple of
weeks time (and lost salary) it took me to put this together was the
[somewhat obscure] glory of having my name in the book... no money, in
other words. (And while it's good for Lisp to get some visibility in
this arena, that doesn't help me recover my personal costs.) All this
to say that, while it was an honor to be included in the selections,
it doesn't put bread on my table (and actually removes my chance to
put some there by other means), so if they're unhappy with me webbing
it, they can cut me in on the royalties next time... Putting it on
the web won't get me paid either, but at least it will make me feel
like it got to a larger audience. I really have no idea if anyone
ever reads these obscure academic texts, or whether those who do ever
read the parts on languages other than those they are personally
familiar with.
The new paper is:
http://world.std.com/~pitman/Papers/Condition-Handling-2001.html
It's got some conceptual overlap with my prior paper
http://world.std.com/~pitman/Papers/Exceptional-Situations-1990.html
but I think it's enough new that people interested in this topic won't find
it a bore to read. Feel free to send me feedback in private email or to
post thoughts about it here if you think they're of general interest to the
community.
For those who don't know, my full list of technical publications is in
http://world.std.com/~pitman/Papers/index.html
(At some point in the near future, I think this whole repository is going
to have to move to another site, because world.std.com is becoming
unbearably painful to use. But it's there for a little longer anyway.
I'm sure when it moves, Google will manage to find it ...)
Thanks !
I'm a newbie and trying to digest as much lisp related material as I can.
and appreciate you (and other many other people) put these valuable work
online.
thanks again,
Raymond
··········@hotmail.com (Raymond Tam) writes:
> Thanks !
>
> I'm a newbie and trying to digest as much lisp related material as I can.
> and appreciate you (and other many other people) put these valuable work
> online.
I'm glad you're interested enough to have a look. I'm especially
interested, by the way, in the readability issues of this paper, both
text and examples, to people who aren't very familiar with Lisp, so if
it raises confusion or leaves lingering questions, do ask. (Feel free
to follow up on this in private email if you don't think your comments
are of general interest to the group here. But in most cases other than
simple typos, I'll be that if one person has a question, so will someone
else and the newsgroup is fine.)
Btw, I'm also interested in readability feedback for people who _are_
already Lispers, of course, I just don't expect it to be as big a deal
there. As always with my writings for people from our community, my
chief concern is keeping the audience entertained, since I know I
repeat myself a lot and I imagine people would otherwise (and perhaps
still do) get quite bored with me.
At MIT, I used to go to lots of talks by the various AI researchers,
and I felt like people were saying the same things over and over and
over in slightly altered form in order to keep their funding coming
in. In the cases of some speakers, it got quite boring, and I tried
to learn from those whose talks were not boring and develop my own
strategies for not boring my audience. The problem is that talks and
papers need to make the assumption the reader doesn't know the topic
-- but often that's painfully not so, and they don't want to be
tedious as they revisit the obvious for those who've seen it a million
times. I don't know how others resolve the dilemma about how to
simultaneously reach both audiences, but my personal solution is to
try to always to offer both instruction for beginners AND subtle humor
or obscure trivia for the experienced folks.... I've noticed all the
best television cartoons seem to have reached pretty much the same
conclusion. I guess their problem is really not dissimilar...
Kent M Pitman <······@world.std.com> writes:
> I'm glad you're interested enough to have a look. I'm especially
> interested, by the way, in the readability issues of this paper, both
> text and examples
I haven't read it yet, but my first reaction was: YUCK those colours
are GROSS (8 bit colour depth) . Let's hope they'll grow on me, or
maybe not. I guess I'll turn off page-determined colours and use my
own.
P.S: I'm not famous for my aesthetic sense.
--
H�kon Alstadheim, hjemmepappa.
Kent M Pitman <······@world.std.com> writes:
> Btw, I'm also interested in readability feedback for people who _are_
> already Lispers, of course, I just don't expect it to be as big a deal
> there. As always with my writings for people from our community, my
> chief concern is keeping the audience entertained, since I know I
> repeat myself a lot and I imagine people would otherwise (and perhaps
> still do) get quite bored with me.
I think it's a succesful presentation of it's chosen topic and found
it quite readable. The decision to present condition handling as
primarily a protocol matter is key, and I believe that it will allow
people new to CL or without much condition subsystem experience to
better grasp it's capabilities and how to succesfully use it.
I am loathe to start a CL vs. Scheme war, but I still feel compelled
to remark that the CL's inclusion of the Condition system, conceived
of as a protocol, versus Scheme's inclusion of call/cc and subsequent
exclusion of any such protocol for condition handling is indicative of
a major difference between the communities behind those languages.
Perhaps if we had beers in our hands, and a few in our tummies, I
would go so far to say that it is indicative of the difference between
computer scientists and programmers.
> simultaneously reach both audiences, but my personal solution is to
> try to always to offer both instruction for beginners AND subtle
> humor or obscure trivia for the experienced folks.... I've noticed
> all the best television cartoons seem to have reached pretty much
> the same conclusion. I guess their problem is really not
> dissimilar...
The cultural contribution of cartoons has always been
under-appreciated 8)
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!
Kent,
I'm reading your 'Condition Handling'. The following two examples
(except some minor typos marked ; *) need some explanations or
corrections. At least *break-on-signals* should be set or SIGNAL
changed to ERROR. Isn't it? I had began to learn you article (writing
down my questions) but stuck on this.
(defvar *line-number* 0)
(defvar *page-height* 3)
(define-condition end-of-page (condition) ()) ; *
(defun show-lines (lines)
(dolist (line lines)
(incf *line-number*)
(when (and *page-height*
(zerop (mod *line-number* *page-height*)))
(restart-case (signal 'end-of-page)
(continue ())))))
(show-lines (loop for n from 1 to 10 collect (format nil "Line-~D" n)))
----------------------------------------------------------------
(defvar *line-length* 4)
(define-condition end-of-line (condition) ()) ;*
(defun show-line (line)
(let ((eol (or *line-length* -1)) (hpos 0))
(loop for pos below (length line)
for ch = (char line pos) ;*
do (write-char ch) ; *
when (= hpos eol)
do (restart-case (signal 'end-of-line)
(wrap ()
(write-char #\Newline)
(setq hpos 0))
(truncate ()
(return))
(continue ()
;; Just allow to continue.
))
else do (incf hpos))))
(show-line (coerce (loop for i from 0 below 72 collect (code-char (+ i (char-code #\0)))) 'string))
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> I hope I've understand what could be added to make it more plain
> (for me of course not very experienced in such matter):
>
> > (defvar *line-number* 0)
> > (defvar *page-height* 3)
> > (define-condition end-of-page (condition) ()) ; *
> >
> > (defun show-lines (lines)
> > (dolist (line lines)
> > (incf *line-number*)
> > (when (and *page-height*
> > (zerop (mod *line-number* *page-height*)))
> > (restart-case (signal 'end-of-page)
> > (continue ())))))
> >
> > (show-lines (loop for n from 1 to 10 collect (format nil "Line-~D" n)))
>
> (handler-bind ((end-of-page #'(lambda (condition)
> (read-line)
> (invoke-restart (find-restart
> 'continue)))))
> (show-lines (loop for n from 1 to 10
> collect (format nil "Line-~D" n))))
I'm not looking at the paper as I reply, so I may be confused as to
what part is there and what part you are suggesting. I'll go back and
look at the presentation again later when I have more time.
But that's the thing about protocols: You only write half of them and you
expect someone else to write the other half. If I wrote it like you show
it, with everything in one expression, people would ask why I don't just
do the query inline. Having it in halves is important, but maybe I botched
the explanation. So if I re-did it, it wouldn't be as one expression.
Still, that doesn't mean I couldn't have explained it more clearly.
(In my partial defense I was under severe length limitation. I
finally couldn't squeeze it down more and they had to extend the paper
length limit to accomodate the paper "as is".)
The whole point is to have some function
(defun show-those-lines (interactive-stream)
...show lines with no end-of-page handling...)
and then to be able to add:
(defun call-handling-end-of-page (function interactive-stream)
(handler-bind ((end-of-page #'(lambda (c)
(let ((r (find-restart 'continue c)))
(when r
(read-line interactive-stream)
(invoke-restart r))))))
(funcall function)))
(defmacro handling-end-of-page ((interactive-stream) &body forms)
`(call-handling-end-of-page #'(lambda () ,@forms) ,interactive-stream))
so that you can do
(handling-end-of-page *query-io*
(show-those-lines))
or whatever.
> > ----------------------------------------------------------------
> > (defvar *line-length* 4)
> > (define-condition end-of-line (condition) ()) ;*
> > (defun show-line (line)
> > (let ((eol (or *line-length* -1)) (hpos 0))
> > (loop for pos below (length line)
> > for ch = (char line pos) ;*
> > do (write-char ch) ; *
> > when (= hpos eol)
> > do (restart-case (signal 'end-of-line)
> > (wrap ()
> > (write-char #\Newline)
> > (setq hpos 0))
> > (truncate ()
> > (return))
> > (continue ()
> > ;; Just allow to continue.
> > ))
> > else do (incf hpos))))
> >
> > (show-line (coerce (loop for i from 0 below 72 collect (code-char (+ i (char-code #\0)))) 'string))
>
> (handler-bind ((end-of-line #'(lambda (condition)
> (invoke-restart (find-restart
> 'truncate)))))
> (show-line
> (coerce
> (loop for i from 0 below 72
> collect (code-char (+ i (char-code #\0)))) 'string)))
>
> Right ? Now I understand better your sayings about 'protocol' under
> 'Condition Handling is Primarily a Protocol Matter'.
I think you have the underlying idea, yes, even if I'm not sure what the
right way to fix the presentation is.
Kent M Pitman <······@world.std.com> writes:
> But that's the thing about protocols: You only write half of them and you
> expect someone else to write the other half. If I wrote it like you show
> it, with everything in one expression, people would ask why I don't just
> do the query inline.
The neat thing about the Condition System is that sometimes you only
write a third of the protocol. With the separation of restarts and
handlers, there are three pieces of code involved in the code path
through any exceptional situation: the signaller, the handler and the
restart (or catch or whatever).
This is particularly useful in the debugger, as you can select from
the restarts, including ones that were not specifically addressed to
the error that actually occurred, say, "reload the file". This
something a combined handler/restart could not offer, since it would
be presumptous to assume that some error would always be handled like
this.
--
Pekka P. Pirinen
If you don't succeed at first, try again. Then quit. No use of being a
damn fool about it. - W. C. Fields
Please note I'm going to talk _only_ of my own impressions. Because I
can't be called 'experienced' Lisper in any case they could be wrong
or 'common place' (e.g well known to all), sorry in that case.
Condition Handling Is Primarily a Protocol Matter
Emphasizing that condition system 'is primarily about protocol' was
new and significant to me.
Influence of Symbolics Zetalisp on Common Lisp
After reading this I hope I've understand restarts some better. At
least this section changed remarkably my seeing them. Also this throw
some light on the condition system as a whole.
Terminological Influences
The 'it is sufficient to see a continuation as an actual or
conceptual function that represents, in essence, one of possibly
several "future worlds", any of which can be entered by election to
call its associated continuations.' seems to me rather abstract (of
course I can't account historical reasons for that).
Separating Signaling and Handling
'The handler will transfer control (by GO, RETURN or THROW) if it
chooses to handle the problem described by its argument.' This I
didn't understand, probably because I've never seen such things in
code. Probably corresponding example some after would be useful. To be
sure, INVOKE-RESTART would be more plain to me.
Non-serious conditions
Some minor typos in code. Please note I don't say these are typos,
just I suspect so:
Should be:
(define-condition end-of-page (condition) ())
(define-condition end-of-line (condition) ())
for ch = (char line pos)
do (write-char ch)
I think the section will be more plain it something like
(handler-bind ((end-of-page #'(lambda (condition)
(read-line)
(invoke-restart (find-restart
'continue)))))
(show-lines (loop for n from 1 to 10
collect (format nil "Line-~D" n))))
(handler-bind ((end-of-line #'(lambda (condition)
(invoke-restart (find-restart
'truncate)))))
(show-line
(coerce
(loop for i from 0 below 72
collect (code-char (+ i (char-code #\0)))) 'string)))
added.
Independent, Reflective Specification of Restarts
I think word 'reflective' used here to emphasize some capabilities of
restarts in Common Lisp, especially FIND-RESTART and their expressive
freedom. If so I should say it took some time to understand this. But
my insufficient knowledge of English may be the cause.
MY-SYMBOL-VALUE example interesting and illustrative though I think
some comments when interactive function is invoked and when not will
be helpful to simplify understanding.
Handling in the Context of the Signaler
Very valuable indeed and uncovers important concept. In a concise form
it says about very important matter. I've stuck with consequences of
my poor understanding of this subject several time. The last one was
yesterday when I lost more than two hours finding the bug before I
realized that HANDLER-BIND handlers were run in dynamic context of
signaler.
About examples with "Outer" and "Inner foo". I think some
visualization could be useful. I mean one who could try this code
could see which restart actually chosen.
Default Handling
Quote from the last paragraph: 'If, on the other hand, some outer
handler does handle the condition, the default handling code will
never be reached and so will not run.' Shouldn't it be '.. some inner
handler does handle...' ,should it ?
Unifying "Signals" and "Exceptions"
Concerning mp:interrupt-process. I mean
(progn (funcall interrupt-function) (exp))
Does such possibility assume that Lisp knows the point where it could
interrupt. I mean it might quest all interruptions' requests and
reaching one such point could execute one of the requests. I hardly
can imagine that arbitrary form could be interrupted at any point.
Restarts vs Handlers
I think this section could be more detail especially about
RESTART-CASE, RESTART-BIND. Is this true that they relates to each
other the same way as HANDLER-CASE, HANDLER-BIND ? I mean in which
context unwounded or not corresponding restarts are executed.
The "Conditional Firewall"
From my point of view the idea needs some more explanation. Especially
'a given handler should be executed in an environment that does not
"see" intervening handlers that might have been established since its
established'. Is this applicable only to HANDLER-CASE ? Probably
so. What about HANDLER-BIND then (it is used in examples). Also I
understand vaguely your mentioning of 'infinite recursion'. Where is
it possible (paragraph 'It is interesting to note...').
To conclude: Very valuable material indeed. Reading it I've learn more
than after months seeking here and there. Thank you Kent.
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> writes:
Some of your comments (such as typos) should have gone in private email as
they are not of general interest. Replying here to the elements of your post
that may perhaps be of general interest.
> Terminological Influences
>
> The 'it is sufficient to see a continuation as an actual or
> conceptual function that represents, in essence, one of possibly
> several "future worlds", any of which can be entered by election to
> call its associated continuations.' seems to me rather abstract (of
> course I can't account historical reasons for that).
The paper seeks to offer a variety of readers a place to grasp onto in
order to find something they can relate to. This particular remark is
aimed at those with a strong background in Scheme who are wandering
around saying "I know continuation are in here somewhere. Where are
they?" If you are a Scheme person and you didn't get it, then this
text failed in that regard; if you're not a Scheme person, it's not
surprising it went by you. Continuations are a "term of art" in the
Scheme language and the related Functional Programming community.
> Separating Signaling and Handling
>
> 'The handler will transfer control (by GO, RETURN or THROW) if it
> chooses to handle the problem described by its argument.' This I
> didn't understand, probably because I've never seen such things in
> code.
They are almost always subprimitive. I didn't necessarily mean literally
those. Just that those are the control mechanisms which underly the more
abstract things like INVOKE-RESTART. If you go into CLHS and you look up
things like HANDLER-BIND and RESTART-BIND, you'll see in the notes about
implementation some macro expansions that may be instructive.
You can also look in the sample implementation in
http://world.std.com/~pitman/CL/Revision-18.lisp.txt
which is a historical document and not correct to every detail of the ANSI CL
spec, but will give you the general shape.
> Probably corresponding example some after would be useful. To be
> sure, INVOKE-RESTART would be more plain to me.
I'll think about adding an explanatory note here now that I'm not subject to
the hard length limitation that this paper labored under. I wasted a good
deal of time in the production of this paper making it smaller. I'm sure
somewhere in there it merely became more concise, but I think in some cases
I really lost a little and certainly it's the case that I had no option to
expand anything in response to reviewer comments.
> Independent, Reflective Specification of Restarts
>
> I think word 'reflective' used here to emphasize some capabilities of
> restarts in Common Lisp, especially FIND-RESTART and their expressive
> freedom. If so I should say it took some time to understand this. But
> my insufficient knowledge of English may be the cause.
Yeah, it's a term that occurs in The Literature that I wanted to
connect in. Especially because the initial placement of this paper
was an audience of people who might come from varied backgrounds.
Some other venues use the term "introspective" which might be easier.
I don't think the use of "reflective" is something that would sit well
with a mainstream English speaker either, btw. It's a specific term
that's been used by a certain body of literature to address a specific
kind of programming. I did make a literature cite on first use of the
term, though it's an obscure document that is probably hard to get to.
Not sure how to address that part. If everyone were doing their part
to web their past, otherwise-inaccessible documents, as I'm trying to
do for mine, the problem would be easier.
> Handling in the Context of the Signaler
>
> Very valuable indeed and uncovers important concept. In a concise form
> it says about very important matter. I've stuck with consequences of
> my poor understanding of this subject several time. The last one was
> yesterday when I lost more than two hours finding the bug before I
> realized that HANDLER-BIND handlers were run in dynamic context of
> signaler.
>
> About examples with "Outer" and "Inner foo". I think some
> visualization could be useful. I mean one who could try this code
> could see which restart actually chosen.
I bet I will probably not have time to make a graphic for this, but if
you or someone makes me one that looks like it will help, I'll consider
linking it in (with appropriate attribution).
> Default Handling
>
> Quote from the last paragraph: 'If, on the other hand, some outer
> handler does handle the condition, the default handling code will
> never be reached and so will not run.' Shouldn't it be '.. some inner
> handler does handle...' ,should it ?
No. You're missing the issue with default handling. A default handler
is a regular handler of the form
(lambda (c)
(signal c)
...default code...)
It's always the case that an inner handler can preclude a handler from
running. What's special about a default handler is that it gives an
outer handler a chance to run, and if such a handler exists and transfers
control, the default code does not get reached (and therefore does not run).
> Unifying "Signals" and "Exceptions"
>
> Concerning mp:interrupt-process. I mean
>
> (progn (funcall interrupt-function) (exp))
>
> Does such possibility assume that Lisp knows the point where it could
> interrupt. I mean it might quest all interruptions' requests and
> reaching one such point could execute one of the requests. I hardly
> can imagine that arbitrary form could be interrupted at any point.
In a multi-tasking Lisp, you should generally expect that any form can
be interrupted anywhere (only because the best posture, absent other
knowledge, is utter paranoia), but that's really up to the implementation
and you should consult vendor doc. If you have something that doesn't
want to be interrupted, you'll want to investigate the collection of tools
for synchronization, such as macros like without-interrupts (usually too
heavyweight, but usually present anyway), without-preemption, without-aborts,
with-lock, and so on.
> Restarts vs Handlers
>
> I think this section could be more detail especially about
> RESTART-CASE, RESTART-BIND. Is this true that they relates to each
> other the same way as HANDLER-CASE, HANDLER-BIND ? I mean in which
> context unwounded or not corresponding restarts are executed.
No. There is no "restart firewall", if that's what you mean.
> The "Conditional Firewall"
>
> From my point of view the idea needs some more explanation. Especially
> 'a given handler should be executed in an environment that does not
> "see" intervening handlers that might have been established since its
> established'. Is this applicable only to HANDLER-CASE ?
> Probably so.
NO. It's not even RELEVANT to HANDLER-CASE, which throws first and executes
a weak kind of handling second. It's only meaningful for HANDLER-BIND, which
does not otherwise disturb the stack context in which signalling is going on.
> What about HANDLER-BIND then (it is used in examples).
Because it is the only thing to which this issue applies.
> Also I
> understand vaguely your mentioning of 'infinite recursion'. Where is
> it possible (paragraph 'It is interesting to note...').
If you do
(handler-bind ((error #'(lambda () oops2)))
oops1)
you will get infinite recursion trying to handle an unbound variable OOPS2
if you don't have a condition firewall, because each time the handler runs,
it will try to handle its own error.
I've added some simple examples to illustrate (I hope) some points.
1. Default handling.
My misunderstanding of 'Default Handling' was caused mainly by
CONDITION-BIND-DEFAULT. After reading about it I were inclined to
expect establishing default handling on some 'outer' level. Hence I
concluded (wrongly) that form
(handler-bind ((error
#'(lambda (c)
(signal (c) ;resignal
;;...default handling...
))))
;;..body in which handler is in effect...
)
should have appeared at some 'outer' level of establishing handlers.
Here is the simple example that makes it more clear (at least to me):
(define-condition my-condition (condition) ())
(tagbody
(handler-bind ((my-condition #'(lambda (c)
(print "Outer handler")
#|(go outer)|#)))
(handler-bind ((my-condition #'(lambda (c)
(signal c)
;; Default handling
(go default))))
;;..body in which default handler is in effect...
(signal 'my-condition)))
outer
(print "Outer")
(go done)
default
(print "Default")
done)
2. Understanding "Conditional Firewall"
The following example illustrates that handler for MY-CONDITION
doesn't see both handlers for ERROR (marked as "Inner" and "Inner
Inner". In this example outer handler will be selected.
(handler-case
(handler-bind ((error #'(lambda (c) (print "Inner")))
(my-condition #'(lambda (c) my-unbound-variable)))
(handler-bind ((error #'(lambda (c) (print "Inner Inner"))))
(signal 'my-condition)))
(error (c) "Outer"))
Also I've realized that handlers established with HANDLER-BIND,
HANDLER-CASE differ in following respect. If former wish to handle
condition it should explicitly transfer control (INVOKE-RESTART, GO,
THROW etc). Unless it done that process of handling would
continue. This is not the case for latter (established with
HANDLER-CASE). Being selected such one stops signaling from going
further by implicit.
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> Also I've realized that handlers established with HANDLER-BIND,
> HANDLER-CASE differ in following respect. If former wish to handle
> condition it should explicitly transfer control (INVOKE-RESTART, GO,
> THROW etc). Unless it done that process of handling would
> continue. This is not the case for latter (established with
> HANDLER-CASE). Being selected such one stops signaling from going
> further by implicit.
Yes, I've said this many times but somehow people miss it a lot.
HANDLER-CASE is a sort of "packaged application" of HANDLER-BIND that
loses most of its power but makes you write less for certainly highly
primitive and klunky kinds of error handling. People seem to gravitate
toward it because it is most like things they see in other languages,
and strangely, even latter day languages like Java that seem to have
learned from CL in some regards provide only this and not HANDLER-BIND.
HANDLER-BIND is the only one that interacts materially with restarts at
a time when it could matter. Without HANDLER-BIND, or its equivalent,
detailed restarts are nearly meaningless. And since calculated use of
restarts are what really distinguish the CL condition system, HANDLER-BIND
is utterly central and should be your first choice to use.
By contrast, and probably confusingly, RESTART-BIND is almost never useful,
thought it has a few very notable exceptions. Consider it subprimitive, and
don't go looking for it unless you really get stuck in (pardon the pun) a
bind. RESTART-CASE is almost always what you will want.
From: Brian P Templeton
Subject: Re: pitman's 2001 condition handling paper
Date:
Message-ID: <87n0xni84y.fsf@tunes.org>
Kent M Pitman <······@world.std.com> writes:
> Vladimir Zolotykh <······@eurocom.od.ua> writes:
>
[...]
>> Independent, Reflective Specification of Restarts
>>
>> I think word 'reflective' used here to emphasize some capabilities of
>> restarts in Common Lisp, especially FIND-RESTART and their expressive
>> freedom. If so I should say it took some time to understand this. But
>> my insufficient knowledge of English may be the cause.
>
> Yeah, it's a term that occurs in The Literature that I wanted to
> connect in. Especially because the initial placement of this paper
> was an audience of people who might come from varied backgrounds.
>
> Some other venues use the term "introspective" which might be easier.
>
> I don't think the use of "reflective" is something that would sit well
> with a mainstream English speaker either, btw. It's a specific term
> that's been used by a certain body of literature to address a specific
> kind of programming. I did make a literature cite on first use of the
> term, though it's an obscure document that is probably hard to get to.
> Not sure how to address that part. If everyone were doing their part
> to web their past, otherwise-inaccessible documents, as I'm trying to
> do for mine, the problem would be easier.
>
I think the term `reflexive' is sometimes used as a synonym for
`reflective', but that's probably just as bad. Brian Rice says that he
prefers to use category-theoretic terms instead. (This is mentioned in
the message with the subject ``RE: collaboration'' from him, sent 14
November 2001 to the TUNES mailing list (you can find archives at
lists.tunes.org).) I'm not aware of any other good alternatives (that
are better than `reflection').
[...]
Regards,
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
From: Michael Hudson
Subject: Re: pitman's 2001 condition handling paper
Date:
Message-ID: <ur8my3q83.fsf@python.net>
Brian P Templeton <···@tunes.org> writes:
> I think the term `reflexive' is sometimes used as a synonym for
> `reflective', but that's probably just as bad. Brian Rice says that he
> prefers to use category-theoretic terms instead.
I may not have a clue what is being talked about, but "reflective"
*is* a category-theoretic notion (a subcategory is reflective if the
inclusion functor has a left adjoint, e.g. sheafs on a space included
in presheafs on the space, the adjoint being "sheafification").
Which category theoretic terms did you mean? Not that one, I guess.
Cheers,
M.
--
I believe C++ instills fear in programmers, fear that the
interaction of some details causes unpredictable results.
-- Erik Naggum, comp.lang.lisp