Re: newbie can't get exceptions to work!

[Robert A Duff <bobduff@world.std.com>]

Brian Rogoff <bpr@shell5.ba.best.com> writes:

> 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?),

Me?  Happy?  I'll be happy when I've designed the perfect programming
language (or somebody else beats me to it).  I.e., never.  ;-)

>... 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 this idea has some merit, but I tend to think that most of the
decisions should be on the other end.  That is, the person who chose the
names for Some_Function and Some_Other_Function is in a better position
to choose whether they should be used with "Some_Package." notation.

But for operators, I still insist that they should *never* be used with
dot notation, so if they're used at all, operator notation should be
used.  (Mike Yoder posted an obscure counter-example to my "never"
claim, some months ago.  Still...)

> > 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 problem with most languages that allow (more-or-less) arbitrary
operator symbols is that they view precedence as a relationship between
any pair of operators.  You get to define the precedence "level" of, say
$*&(^, and then it relates to the normal + and so forth as specified.
But that's error prone.

The cool thing about Cecil is that you define precedence among related
operators.  If two operators are unrelated, you have to parenthesize.
This seems much less error prone to me.

>... The OCaml solution is to have precedence and
> associativity inherited from the first character of the operator, so 
> +. and +/ are like +.

Sounds error prone.  If +/ is unrelated to +, then

    X +/ Y + Z

should require parentheses.

>... 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.

Agreed.  It's hard to get too hot and bothered about the dangers of
overloading, which is resolved at compile time, in a language like
Eiffel (or Ada), where a given name is dispatched at *run* time.
Yes, it's potentially confusing, but it's also potentially good.

> 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.

Please explain to me why pattern matching is so wonderful.  I know about
ML and the like, and pattern matching seems kind of nice, but why do ML
advocates seem to think it's so much more than just "nice".  Why is it
so much more wonderful than an 'if' statement?

And is your answer specific to OCaml, or does it apply equally to ML?

 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.

Indeed.  I don't know the right answer.

>... SML has it's eqtypes, OCaml has it's
> polymorphic comparison primitives. Neither seem satisfactory to me. 
> 
> > 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. 

I don't think that treating operators non-specially is a good thing.
Sure, it seems elegant (more uniform), but in practise, surely you want
operators to be visible with no fuss or bother.  Operator symbols *are*
special, because the programmer chose to use concise syntax over
wordiness ("*" vs "Multiply", for example).

Does it bother you that if we have:

    X: Some_Package.Some_Type;
    Y: Some_Package.Some_Type;

you can say (in Ada):

    X := Y;

Or would you prefer to require (the Wirthian?):

    from Some_Package import ":=";

first?

>...Why didn't Ada have such a
> selective import? 

I don't know the history of that.

- Bob