Re: newbie can't get exceptions to work!

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Fri, 6 Apr 2001, Robert A Duff wrote:
> Brian Rogoff <bpr@shell5.ba.best.com> writes:
> 
> > On Fri, 6 Apr 2001, Robert A Duff wrote:
> > > "Marc A. Criley" <mcqada@earthlink.net> writes:
> > > > I was very pleased with the addition of "use type" to Ada 95, despite
> > > > the opinion of a some that it's an ugly addition that was included
> > > > merely to avoid having to write "renames" clauses for operators.  
> > 
> > Hmmm. I think it's ugly because it was included merely to avoid having to
> > write use clauses. If you're a no-use fanatic, you should be content with
> > not using use clauses, but no, use-phobes thinks it's OK as long as the 
> > infix syntax is used. So the language is butchered to handle this special
> > case. 
> 
> It has nothing to do with "writing".  It has to do with reading.
> 
> I'm neither use-phobe nor use-phile.  I think it depends on the package,
> whether you should say "use" of it.  I take it you're a use-phile, and
> don't really care if the use-phobes have to write unreadable code.

Actually, I'm a use-phobe who believes that absolute rules *never* make 
sense :-). What that means in practice is that I like to write code in a 
use-phobe style, except that there are just always cases where use is
clearer, and when it is, I'd like to use it. And typically, when I do use
it, I heed J.P. Rosen's advice about restricting it's scope. In other
words, be careful using use (and goto, and exceptions, and overloading,
and dynamic dispatch, and ...) because if you aren't careful your code
will become unreadable. 

I don't think use-philes really exist (OK, maybe somewhere there are a
few), but use-phobia is quite a real phenomena. 

What I hate are statements to the effect of "don't think, never use X!". 

>  If
> so, then I suppose you think "use" should be banished, and everything
> should be use-visible by default?

No. I've adopted a style that's very use-phobe phriendly. 
 
> > Why, what's so special about operators?
> 
> Operators are used when the programmer thinks the concise notation of
> operator syntax makes the code more readable than identifier-named
> functions.  Eg, we think that:
> 
>     A + B*C
> 
> is more readable than:
> 
>     Add(A, Multiply(B, C))
> 
> If that's true, it makes no sense at all to ever say:
> 
>     "+"(A, "*"(B, C))
> 
> or:
> 
>     Some_Package."+"(A, Some_Package."*"(B, C))
> 
> Given that the whole point of operators is to use a concise symbol
> instead of an English word, I think one should always use operator
> notation for calls to operator functions.  If you always "use"
> everything, then you can do that.  But I think it makes sense not to
> 'use' a particular package, so you have to say
> Some_Package.Some_Function, but still want to write calls to operators
> using operator notation (infix, etc).

OK, I was sort of being a pain with that question. However, since we're 
redesigning the language :-), the right solution IMO would be to have a 
more precise form of import and export clause than what Ada has, so that 
if you want to use a package you can choose precisely what gets seen.
This way, the use type folks are happy, I'm happy (well, I'm always happy:)
you're happy (yes?), and Niklaus Wirth is vindicated. For example,
something like 

from Some_Package use "+", "-", "*", Some_Function;

...
Some_Package.Some_Other_Function(Some_Function(A + B * C));
...

I think that would be an improvement. The only bummer is use-type folks
would have to specify which operators they want, but there is no danger 
of cut and paste rename issues.

> >... Well, OK, Ada makes them a bit
> > special by not allowing you to define new ones (an annoying restriction
> > IMO) but they are just functions, right?
> 
> I agree that it's an annoying restriction.  The reason, I guess, is that
> if you allowed someone to define an operator "$" or "&^%$$##", you would
> have to worry about the syntax.  What is the precedence of these
> operators?  I think Cecil has a nice solution to the problem.

What's the Cecil solution? The OCaml solution is to have precedence and
associativity inherited from the first character of the operator, so 
+. and +/ are like +. Unfortunately OCaml doesn't yet have overloading so 
it really needs this feature. You're probably not surprised to learn that 
in many language communities (Modula-3, ML, Eiffel?) overloading is viewed 
by many the same way that "use" is viewed by many in the Ada world. And I 
respond the same way, sure overloading can make a mess for the reader but 
used well it makes code more readable.

> > > You don't have to say "use" in order to
> > > write "X := Y"; 
> > 
> > ":=" is special. It's not a function, and you can't redefine it, except
> > for very special types. Yes, I know you know all this :-). 
> 
> Yes, I know it, and I know you know it, and I know you know I know it. ;-)

:-)

> I can still gripe about it.

That's the beauty of Usenet. 
 
> It's not just ":=", but also notations like "in", "and then", and "A(I)"
> (I would prefer "A[I]", by the way) 

Thank you, I completely agree. I find the choice of () for array access
makes code far less readable, since my eyes can't distinguish from
function calls. 

> and literal notation.  These are all
> "special" in that you don't need to say "use" to use these notations
> (and also in that you can't redefine them; sigh).  They look like
> operators to me, but Ada says otherwise.

I tell you what, design this next language, and I'm on board. I'm willing
to give up full closures as long as pattern matching and parametric
polymorphism are in the language. Take a look at the Cyclone project as 
an example of a decent looking futuristic systems programming language, 
unfortunately based on C. 

http://cvs.metaprl.org:12000/cvsweb/~checkout~/cyclone/doc/cyc_users_guide.htm

> > > why should you have to write "use" in order to write
> > > "if X = Y ..."?
> > 
> > "=" is also kind of special, right? 
> 
> Unfortunately true.

This is actually a deep problem. SML has it's eqtypes, OCaml has it's
polymorphic comparison primitives. Neither seem satisfactory to me. 

> > Are you proposing that assignment and equality are both special enough
> > that no use is necessary, or are you saying all operators should be exempt 
> > from being use (type)-ed? 
> 
> I meant that all operators should be exempt.  I wasn't speaking
> particularly about ":=" and "=" (and I realize that Ada defines "=" to
> be an operator, but not ":=" or "in", etc).

Well, I think the Wirthian solution is probably better, and has the nice 
property of not treating operators specially. Why didn't Ada have such a 
selective import? 

-- Brian