Re: newbie can't get exceptions to work!

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

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

> On Tue, 10 Apr 2001, Robert A Duff wrote:
> > 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.  ;-)
> 
> Well, I doubt that there will ever be a perfect programming language for
> *all* programming tasks. There are just too many conflicting requirements. 

There's also an awful lot of commonality.  Surely almost every
application area can benefit from a language that makes it easy to write
readable code!?

And if you look at the differences between current programming
languages, they're mostly arbitrary choices of the language designer,
rather than being particularly beneficial to some particular use.
For example, "end" vs "}", which we have been discussing:  I can
understand somebody liking one or the other, but I can't understand how
one could be better for, say, numerics, whereas the other is better for
business apps.  One or the other is simply better.

> Would you be happy with, say, 10 really good ones? :-)
> 
> > >... 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.
> 
> I disagree, at least a bit. I think the package designer can tell me he
> will allow me to see, but after that I (the client) may decide that I 
> don't want to see everything. 

Fine, but my point was that *if* you choose to see it, the package
designer is in a better position to choose the name by which you see it
(X vs Package_Name.X).

> > 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...)
> 
> That's fine. I'd force you to use some renaming then, or to import a
> prefix function as an operator. As long as the syntax is lightweight
> enough, I don't think that's a problem.

For operators, IMHO, the only syntax that is lightweight enough is none
at all.

> > > > 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.
> 
> But it still seems error prone.

I don't see why.  Please explain.

>... Another possibility is fixed precedence
> and associativity, and always force parenthesization. That's what Haskell 
> does with it's alphanumeric infixes, like 
> 
> 	11 `plus` 13
> 
> > >... 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.
> 
> I guess you didn't read ahead :-). No overloading in OCaml, that's a type
> error.

I did read ahead.  I guess I just didn't understand.  Can't I define
"+/" and "+" operators such that the above makes sense (i.e., type
checks)?  I suppose I should go and read the OCaml manual.

> > 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?
> 
> My answer applies equally to SML, Erlang, Haskell, Clean, ...
> 
> Do you know SML?

Yes.

>... Pattern matching is so much more wonderful than "if" or
> "case" because the same kind of construction that takes many lines of 
> code in such a language is far fewer lines in a language with pattern
> matching *and* very readable (IMO of course :). An example perhaps? 
> This is using short names (E for Empty, R for Red, B for Black, T for
> Tree,...)

OK, thanks.

But one advantage of Ada's case statement is the full coverage
checking.  This is a huge advantage, in my opinion.  I'd be happier
about pattern matching if it did full coverage checking.

> Well, assignment and equality are "special", so I'm relatively comfortable
> with a range of choices. I certainly wouldn't mind the Wirthian
> approach. In this case it seems like you could use it to get limited
> (in the Ada sense) views. But I certainly would prefer 
> 
> from Some_Package import "*";
> 
> to just letting infix operators be automatically used. Difference of
> opinion here I guess. 

Shrug.  I suppose I could live with that.

- Bob