From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,79bbf7e359159d0d X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-04-09 19:14:01 PST Path: supernews.google.com!sn-xit-03!supernews.com!logbridge.uoregon.edu!newsfeed.mesh.ad.jp!sjc-peer.news.verio.net!news.verio.net!sea-read.news.verio.net.POSTED!not-for-mail Newsgroups: comp.lang.ada From: Brian Rogoff Subject: Re: newbie can't get exceptions to work! In-Reply-To: Message-ID: References: <25%y6.2364$jz.201607@www.newsranger.com> <3ACDB29E.45B91316@earthlink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Date: Tue, 10 Apr 2001 02:11:56 GMT NNTP-Posting-Host: 206.184.139.136 X-Complaints-To: abuse@verio.net X-Trace: sea-read.news.verio.net 986868716 206.184.139.136 (Tue, 10 Apr 2001 02:11:56 GMT) NNTP-Posting-Date: Tue, 10 Apr 2001 02:11:56 GMT Organization: Verio Xref: supernews.google.com comp.lang.ada:6689 Date: 2001-04-10T02:11:56+00:00 List-Id: On Tue, 10 Apr 2001, Robert A Duff wrote: > Brian Rogoff 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