Re: Comparing Lisp conditions to Java Exceptions

First of all, let me say a few things in general. It may be that my original
post came across very critical of Common Lisp (that is, the Common Lisp
standard). This was not my intent. While I did use the abscence of
certain error conditions in CL as an example, this is not the focal point
of my "frustration". I was reflecting over the situation in general with
most API:s that deal with external circumstances (and thus are expected
to fail). My original "complaint", if you will, was not specific to Lisp,
but is a general issue I have experience with a number of libraries/API:s
for several different languages. My reasons for using Common Lisp as an
example are simply that (1) this is comp.lang.lisp and (2) Common Lisp
is what I want to use for the projects I have in mind.

> Nothing could be farther from the truth. It was simply a HUGE project
> to be explicit on this and there was no money to do that project.
> We all wished for it, but none of us had access to the US Treasury's
> machine for printing money.

I won't debate the facts you are pointing out. But I will say that I did
not indend to critisize the CL standardisation effort. Even disregarding
any monetary or time based constraints, I can certainly understand the
lack of certain things in the CL spec; things that have become much more
important in "modern" times. In particular, I do understand that you
consider my comparison with Java unfair; but it was truly not meant to
critize Lisp as compared to Java. I used Java as an example because it
happens to be very representative of what I am after when it comes to
*this specific (and very narrow) issue*.

[ snipped some very interesting few paragraphs on the CL standardization process
that I loved reading, but do not have much to say aboue since I really was
never trying to argue against any of it ]

>> I am only interested in being able to handle *expected* conditions.
>
> I agree it's more work, but is there some reason "implementation-dependent"
> or even "implementation-defined" does not work?

No; it does work. My frustation was primarily based on the difficulty I have
experienced in finding *out* those implementation dependent details. I was
interested in what people *do* in practice, as I have not run / looked at a
lot (actually, pretty much none) Common Lisp applications intended for
end-users, where showing a debugger with available restarts is not acceptible.

I probably put too much emphasis on the portability issue, which I suppose
contributed to my entire post sounding very critical of CL.

[ vendors and their financing ]

> This is the part I'm struggling to understand--why you think that's not
> relevant.

Because I was not making a complaint against anybody in particular, nor
against library/API authors in general (even if I may have given that
impression). I was (and still am) truly more interested in how these issues
are solved, in general, in real-world Lisp applications.

But then, I don't really know of any such applications. Particularly none
that use the libraries/API:s that I have been looking at. Perhaps they
just don't exist.

> And, btw, when you use "corporation" do you mean to say you missed all those
> places where I noted that by vendor I always mean to include a maker
> of free software? (There needs to be some generic term for "supplier of
> an implementation", and I use the term "vendor" for that, usually trying to
> explicitly remark on my non-stnadard use of this term. Are you, likewise,
> using "corporation" in that non-standard way or are you reading past my
> parenthetical remarks about meaning to be thus inclusive and erroneously
> thinking thatI am talking only of commercial Lisps when I make these remarks?)

Sorry - that was my misstake. I was commenting under the impression that you
where "implying" (by saying I should talk to my vendor) that I should buy
a commercially supported Lisp or stop complaining.

>> Even assuming I am willing to pay for a commercial Lisp (which is no
>> great assumption I assure you, though at the moment I cannot afford
>> the fee required for the CL I was looking at possibly buying), there
>> is still the issue that any non-free CL is going to be restrictive
>> in terms of portability. That has nothing to do with money.
>
> The reason I'm assuming it does is that you're apparently concluding
> that you're not yourself part of the community. you're standing on
> the outside and not thinking that you yourself can change things.
> when you don't see something in the formal standard written and
> published over 10 years ago, you project the assumption (rightly or
> wrongly) that the community doesn't care and that nothing has
> happened since. take the bull by the horns. contact your vendor
> and ask. tell them what you would pay. get your friends to pony up
> money, too. i'm not saying pay for the whole thing UNLESS you find
> you're the only one asking. what I'm saying is that your fair share
> of the cost is
> x/y
> where
> x = cost of doing what you want
> y = number of people who want it enough to pay for it

It is really not about making somebody ("they") just magically fix it because
I want it. I was interested in current common practice.

As I have indicated I would have no trouble "fixing" whatever I feel needs
fixing, assuming I have the time and knowledge required. However since I am
still fairly new to CL, I would probably do a very lousy job of creating that
hypothetical "CLCL" I mentioned. In terms of learning CL, I am looking at
writing some useful applications *first*.

Taking what is already there and applying it to something I want is easier
than making a high-quality re-usable library. And the usefulness of said
application is not as much reduced by my (what I assume will be) suboptimal
code quality, as in the case of a useful library (because the latter by
definition requires a certain quality in order to be useful, while the
former is mostly dependent on the final end-user visible result).

> OR, if it's open source as you say, WRITE THE DOC yourself and give it to
> the vendor and say "Is this your intent for now and furture releases? If it
> is, maybe you could thus document it." and then go to the vendor you think
> that disagrees (causing non-portability) and tell them you care about
> portability and ask if they could compromise.

I could; but again I was probably do a lousy job for now given my lack of
CL experience.

(The best I can see myself doing until I have more CL experience is put together
some kind of informal list of "tips" for people in my position.)

> I don't have trouble with your claim that this needs to be done. I have
> trouble with your claim that no one cares. People DO care.

Again I would like to apologies if I gave this impression; it was not my intent.

> for having succeeded. People already know it, what they seek is a workable
> solution. Make one. Document something. Make your hobby-horse be getting
> everyone to adopt it, NOTWITHSTANDING the absence of a very cumbersome
> standards process to bless it. We don't need the blessing. We just need
> the accidental fact.

No reason why I won't try to do so in the future.

> No, i wasn't trying to make that point. I was trying to make the point that
> ERROR _is_ a documentation of every single condition that might arise.
>
> I'd prefer it if there were more fine grained names sometimes for the
> conditions that might get signaled, sure. But I diagree with the
> technical claim that we don't document what might get signaled. ERROR
> might get signaled. It might be called FILE-NOT-FOUND or
> NETWORK-INTERFACE-MISSING, but it's still ERROR. I'm not saying the
> problem you're having doesn't exist. I'm just saying that your
> on-and-off characterization of the error as "the error is not
> documented" is the wrong phrasing and is not helping your case, it's
> just confusing me into side-tracks of having to correct terminology.
>
>
> Writing
>
> (ERROR 'FILE-NOT-FOUND :NAME #P"/foo/bar")
>
> _is_ an implementation of "an error of type ERROR will be signaled."

But it's *mostly* useless implementation as compared to using a documented
more specific exception.

The problem is that most robust applications are not going to want to catch
*ALL* errors - other than to do some kind of emergency cleanup and logging the
occurrance as a likely software bug. Catching *ALL* errors because you know
the file creation or file reference might fail is not a good solution,
because any other errors that might get signalled as a result of bugs in
your own code (or code you call) will suddenly be treated as "file not
found". At best, this is confusing and difficult to debug after the fact. At
worst, it's disastrous.

> You might wish it said something more refined, but the problem is not
> not that the error isn't documented, it's that the error that is documented
> is not of an adequately specific type for you to allow you to distinguish
> it from other kinds of errors that you don't want to handle. This is a
> legitimate thing to want. It just needs to be spoken about properly as
> you ask for it.

This was exactly the point I was trying to make, and exemplify by the Java
comparison. Thank you for providing the short and disambiguous explanation
I should have used to begin with :)

> Your failure to use good error and type terminology makes it hard for
> me to answer you on-topic. And when I reply correcting your
> terminology, you think I'm saying I disagree with your cause, which I
> don't. I just can't talk about causes with incorrect terminology--it
> makes it appear I'm agreeing with false premises. [Sort of like the
> "have you stoppped beating your wife?" problem. You might or might
> not beat your wife, but if you don't, it's hard to have a discussion
> on the subject that begins with a false premise.]

Fair enough, and I certainly won't refuse admit that my phrasing and choice
of words is far from perfect.

>> I would be very interesting in doing so. Which site is that?
>
> http://www.nhplace.com/kent/Papers/
>
> look for the 1990 and 2001 papers on conditions.

Thanks; I will have a look!

> IO-ERROR is there, I think. It's spelled STREAM-ERROR, though.
> I don't think that's your problem in the specific. That doesn't mean
> there aren't missing specific condition classes, I just don't think
> this is the one. And in some cases maybe it doesn't say to use STREAM-ERROR
> though I bet a lot of times you can.

I will look into STREAM-ERROR; I was not aware of it.

>> Come on. I am merely talking about documentation of the most obvious
>> error condition;
>
> No, you're assuming that these are obvious.

I fully accept that some of the stuff I would want now would not be at all so
obvious a number of years ago when this stuff was being hashed out.

> Keep in mind there was very little experience with conditions at the time.
> A lot of people rejected the condition system we have completely and I
> had to do a HUGE sale to the community that we should have ANYTHING. The
> condition system itself may seem obvious now but it was not then.

I'm curious; what was the propsed alternative (if any)? (Given that checking for
error return code is pretty much out if you are to maintain any kind of
Lispish style)

> The only implementation that more than just ERROR, that had any condition
> classes at all, was the Lisp Machine, and people kept saying it required
> special purpose implementations. I had to write a portable implementation
> and give it away to convince people. And even then they didn't believe it.
> I kept saying "JUST LOAD THE CODE. REALLY. IT WORKS." It took years of
> lobbying to get them to just load it and little by little they would trickle
> in with phone calls saying "Uh, I finally loaded your code. You're right,
> it doesn't take special hardware. Can we, uh, actually use that code?"
> And I'd say "of course". [See the original proposal and original
> implementation--actually, revision 18 of that, just to give you some idea
> of how many iterations it went through before adoption, at my web site.]
>
> And even then, when accepted into the standard, CLOS was also new. So
> no one was sure that [and this was a HUGE sticking point] that multiple
> inheritance was there for the long run. So the committee INSISTED that
> no pre-defined error condition could rely on multiple inheritance. All
> error classes we defined had to be ones that made sense in a single-inheritance
> system. So we couldn't install the "obvious" things like many file conditions
> because the only extant, working, tested implementation was Symbolics Genera,
> and it relied heavily on multiple inheritance and did not want the standard
> to break it, while other vendors didn't want to commit to multiple
> inheritance. "file not found", just to take a point, can happen when a
> network is down, as a temporary error. Or it can happen when the network
> is up becasue of a permanent error of the file just not being there. Both
> result in a file not being visible. It can also happen due to a directory
> not being present. And some of these make assumptions about host file
> systems, which implies agreeing on more details about pathnames than we may
> have specified. Signaling that a host is down was something some people
> wanted to do by specifying a host, which gets into whether a host is
> a representable object or just a string--some wanted one, some another. And
> that's another way to bog down a proposal. So there were legit points of
> disagreement. But don't call this a lack of caring. Call it a legitimate
> reason that there is not a standard.

This was a very interesting read; thank you. I think the above paragraphs
covered more about the origins of Common Lisp as a standard as it appears
today, than pretty much all material on CL that I have read.

Obviously I cannot disagree with or argue any of it.

> Propose a standard now and maybe people will adopt it WHETHER OR NOT
> you do it formally. Adoption won't come on comp.lang.lisp. It will come
> by your one-by-one convincing vendors to care. comp.lang.lisp may put you
> in touch with people who can help, but since "me, too" posts are discouraged
> here, mostly you'll find dissent, not support in this venue.

Point taken.

> Most people don't write portable programs. They write semi-portable.
> They write to one implementation. When they port, they add some #+/#-
> conditionals. They try to isolate this into macros. e.g.,
>
> (defmacro handling-sql-errors (&body forms)
> #+LispWorks ...
> #+Franz ....)
>
> Each time they port, they elaborate these a bit.
>
> It seems to me that MANY people when they encounter a porting issue
> will write to comp.lang.lisp saying "how do i...". That seems
> normal. Your post seemed, by contrast, to have been leading with a
> broad allegation/conclusion of "lack of caring", which seemed to me
> way off base. Which is why I reacted strongly. I think you just don't
> understand the issue of "obviousd".

Again - my apologies for coming off like that.

> Nor did any of us, by the way. In 1984, Steele published CLTL.
> In 1986, we all (the people who worked on CLTL) got together in Monterrey,
> California (a beautiful venue, btw) and had a meeting about whether there
> was anything that needed fixing. We found we had no way to "vote" because
> there were many new people there and no way to consolidate opinions. In the
> end, this is how we came to ANSI. But in the process, Steele had a page or
> two document labeled "obvious" or "non-controversial" or some such. Something
> on the order of magnitude of about 50 things, each a one-liner like
> "Add a function XOR which is like AND and OR but does the obvious thing."
> He was _sure_ that no one would object to these. Nearly every one was objected
> to by someone. And from this, we all learned a lot about how much we had
> in common.
>
> Note well again: This didn't mean no one cared about these issues. Most
> they did. But they wanted to address each in different ways.
>
> It's the issue of non-caring that I snagged on in your posts. The language
> cares a lot. The people care a lot. But consensus is hard to achieve in
> a diverse community where people's care has led to use, and where change,
> even change for the better, can break things.

Point also taken.

(This post is turning out to be pretty light on content, with me just agreeing...)

>> I abhore [sic] binary-only distributions and the problems
>> they create (practical problems, not some abstract ideological issue).
>
> I personally prefer not to look at source, even when it's there.
> I prefer to look at doc.

Even if I don't have any intention of looking at the source, typical
open source solutions tends to be more portable and less susceptible to
the "oh we (the platform people) changed the version of library X and
thus application Y (the binary distributino) was broken on this
platform for 5 months because it happened at a poor time in the
application's release cycle" syndrome.

(E.g., the mess that was some of Sun's releases of the JDK for Linux,
inspite of the resources Sun has at its disposal.)
> In your world, where people give you stuff for free, I thought you
> were supposed to contribute the doc that was missing, as your
> contribution to the whole sharing thing. Or you contract a freeware
> maintainer to add the doc that will then be free for others. Maybe I
> misunderstand the social contract of freeware, but I thought that was
> how it worked.

In the broadest of sense, sure. But for a specific situation there are
any number of reasons why a certain person X cannot contribyte Y to Z
even though said person would like to see Y in Z.\

> By the way, again to help you with the history, CL was standardized
> before the only operating systems in the world were linux, windows and
> pc. We planned for about two dozen operating systems, all with
> radically different file systems. This made it hard to get agreement
> too. Maybe some agreement would be easier now.

Absolutely. My comment about portability between OS:es above was mostly
in response to the pay-the-vendor-or-stop-complaining argument that I
*thought* you were making, but now realize you were not.

[ again, a lot snipped that probably deserve insightful answers,
but unfortunately I'm not up to the task ]

--
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@xxxxxxxxxxxx>'
Key retrieval: Send an E-Mail to getpgpkey@xxxxxxxxx
E-Mail: peter.schuller@xxxxxxxxxxxx Web: http://www.scode.org

.

Relevant Pages

  • Re: Understanding # and function variables
    ... That's the reason for my statement that I don't care whether a ... >>change is standard compliant or not. ... >>substantial revision of ANSI Common Lisp and would provide equally ... I will find out about an already existing language that is strictly ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... in the Common Lisp community. ... libraries that work across implementations that provide de facto ... This is one of the very few instances of behavior outside the standard ... to the language at all. ...
    (comp.lang.lisp)
  • Re: Qi Seems Great
    ... Common Lisp will simply trounce anything else in the long ... but having third party libraries to support the new ... ideas come along doesn't mean that the language itself will grow. ... Having in mind that the CL standard is rather old, ...
    (comp.lang.lisp)
  • Re: Running Standalone Lisp Programs
    ... On platforms without a command line ... into the ANSI Common Lisp standard is a very problematic venture. ... > for not including file system operations in the CL standard. ...
    (comp.lang.lisp)
  • Re: scheme seems neater
    ... people are not interested in extending Common Lisp? ... ANSI CL standard is, for example, a system definition facility. ... the fact that a hygienic macro system doesn't exist for Common ... implementations of syntax-rules bug-free? ...
    (comp.lang.lisp)