Re: newbie can't get exceptions to work!

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

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

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

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

My answer applies equally to SML, Erlang, Haskell, Clean, ...

Do you know SML? 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,...)

module RedBlackSet (Element : ORDERED)
  : (SET with type elem = Element.t) =
struct
  type elem = Element.t

  type color = R | B
  type tree  = E | T of color * tree * elem * tree
  type set   = tree

  let empty = E

  let rec member x s = match x, s with
    | _, E -> false
    | _, T (_, a, y, b) ->
        if Element.lt x y then member x a
        else if Element.lt y x then member x b
        else true

  let balance = function
    | B,T (R,T (R,a,x,b),y,c),z,d -> T (R,T (B,a,x,b),y,T (B,c,z,d))
    | B,T (R,a,x,T (R,b,y,c)),z,d -> T (R,T (B,a,x,b),y,T (B,c,z,d))
    | B,a,x,T (R,T (R,b,y,c),z,d) -> T (R,T (B,a,x,b),y,T (B,c,z,d))
    | B,a,x,T (R,b,y,T (R,c,z,d)) -> T (R,T (B,a,x,b),y,T (B,c,z,d))
    | a,b,c,d                     -> T (a,b,c,d)

  let insert x s =
    let rec ins = function
      | E -> T (R, E, x, E)
      | T (color, a, y, b) as s ->
          if Element.lt x y then balance (color, ins a, y, b)
          else if Element.lt y x then balance (color, a, y, ins b)
          else s in
    match ins s with  (* guaranteed to be non-empty *)
      | T (_, a, y, b) -> T (B, a, y, b)
      | _              -> impossible_pat "insert"
end

If you understand the balancing operations, which are decidedly
non-trivial, you'll find that the pattern match is a direct transcription. 

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

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. 

> >...Why didn't Ada have such a
> > selective import? 
> 
> I don't know the history of that.

Now that is something I'd like to find out. Jean Ichbiah did an amazing
job with Ada in the late seventies. I don't even know if Wirth had come up
with these features then. Too bad RBKD has vanished, since he usually
knows the answer to these questions...

-- Brian