Lotta stuff. It seemed worth breaking out into a separate thread. But
forgive me the Subject line pun!

>	It might; I haven't decided how interested I am in doing it. It's just
>so depressing, after all the talk from Squeak Central about how they didn't
>particularly care about adhering to standards.

Uh...to be fair, that's not a full understanding of their position. Dan
Ingalls wrote, on Mon, 21 Sep 1998:

--------Start quote---------
>[I've written the following in the first person, but I think my thoughts
>on this issue are pretty much shared by the whole Squeak team...]

[snip]

>THE BIGGER ISSUE
>As you (may) know ANSI compatibility is of no importance to me, *except*
>that I know it affects the synergy of this community with the larger
>>Smalltalk community, and that *is* important to me.
>
>A possible process for moving forward here would be for "a few good
>Squeakers" to step forward and work together to propose some reasonable
>set >of changes that would maximize ANSI compatibility, while minimizing
>any
>detriment to Squeak's current direction.  What I have in mind is a sort of
>"10 most wanted" changes rather than a massive overhaul.  In the context of
>such a reasoned process, I would probably not stand in the way of changing
>the treatment of nil in literal arrays (though I might still roll my eyes
>;-).
>
>This is probably a good time for such an undertaking.  It is likely that we
>will make a significant blue-plane departure 6 months or a year down the
>road, but so far we have been able to accomplish most of our goals working
>within the system and not changing the language a great deal.  I am hoping
>that faster execution, and better access to native code (more about this
?later) will soon be a part of Squeak, and it would be nice to somehow reach
>a point of maximum value as a "workhorse Smalltalk" before we blast off
>into some more incompatible realm of "Principia Mathematica meets
>>Multimedia."
--------End quote-----------

> I was shocked to see them
>attach so much importance to the ANSI standard, which goes beyond
>specifying interfaces into specifying implementation. (My
>exception-handling framework had ANSI support, by the way). So much for
>experimentation.

Now, if I understand all the issues involved, your exceptions framework
supports much of, if not all of, the ANSI protocals, but the ANSI spec
demands certain implementation details which your system (rightly or
wrongly, I have no idea) eschews (sorry, personal moment of triumph as I've
wanted to use 'eschews' in a email message for a *very* long time). Given
Dan's statement above, and these facts (if correct), it doesn't seem
contradictory that SC went with a straight ANSI exception system over
yours. (I take it that your "ANSI support" falls short, by necessity, of
full compilance. Not that I know how much that *matters*.)

I'm sorry you feel brusied over exceptions. I'd like to point to the bright
side: the current system is, in part, as you've said, based on your work.
It fulfills a different need (strict ANSI compatibility) and is, I hope,
NOT the last word ;) (After all, I'm on record as detesting exceptions and
how we have to deal with them, but I don't see your system (directly)
answering my complaints (since my complaints are as much a UI issue as
anything else), nor, of course, was it intended to. I would be interested,
nevertheless, to know how your system handles the classic control flow
understanding, stack tracing, etc. whatever-they-are problems :),
especially as compared to ANSI.)

I dearly hope that ANSI exceptions don't become the norm for Squeak code.
In my porting experiments, excpetions typically just got in the way of my
understanding what's going on.

Indeed, one thing I'm growing to like about Kent Beck's testing framework
is it's separation from the actual application classes. In his paper, he
even suggests only loading them when your working on a particular system.
Yes! I *like* that modularity. It would be great if exceptions worked
similarly so that just as I have my Class and my TestCases/Suite, I would
have my Class and my Exceptions. (But I don't want to scatter references
and calls through my class' methods! That's the difference.)

Bah. Someone's going to tell me about "aspects" again :)

Exceptions should probably grow out of testing and debugging. A class of
error that you can't elimnate, can't prevent, and want to handle
gracefully. Something like that. Bah. I don't know!

Maybe Third Voice(TM) style annotations would do the job. Little marks that
pop out into little sticky note type panes. That would be neat for type
annotation.

Cheers,
Bijan Parsia.