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=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!watmath!clyde!att!rutgers!sri-unix!trent From: trent@unix.SRI.COM (Ray Trent) Newsgroups: comp.lang.ada Subject: Re: Collective response to := messages Message-ID: <24922@sri-unix.SRI.COM> Date: 1 Dec 88 18:31:44 GMT References: <10906@ulysses.homer.nj.att.com> Reply-To: trent@unix.sri.com (Ray Trent) Organization: SRI, Menlo Park, CA. List-Id: In an article dsr@hector.UUCP (David S. Rosenblum) writes: >domains and algebras. However, assignment is a concept that is peculiar to >programming languages, so in a sense you're comparing apples and oranges. Untrue. "Let S = foo" is an idea from mathematics. But this is an aside. >And most "sensible" definitions of assignment that I know of describe >assignment simply in terms of placing a value in a variable or memory Except C's definition, of course, which is that = is an operator that returns a value and has a domain and range. >meaning, but you are not able to override Ada's type checking. Thus, >allowing overloading of assignment (or any basic operation) would seriously >weaken Ada's strong typing features. I'm afraid unchecked programming already does that. If the language designers were sooooo concerned about strong typing, why was unchecked programming included at all? Was it perhaps because programmers know that strong typing is a crock? I'd rather have nastiness like non-strong typing out in the open, rather than hidden away in places where it can't necessarily be found. (like package bodies, for example) >Ada's constraint language (such as LCD-ness). So why stop with assignment? >Wouldn't you need overloading of all the basic operations? Suppose Of course you would. (and do) > type EVEN is new INTEGER; >which I want to constrain in a way that would require all variables of >the type to have even values. In order to enforce this constraint [several other basic operations overloaded] >For example, type conversions, qualifications, attribute evaluations and >membership tests never propagate exceptions. Yet what would be the effect And why not? They often should. >perform I/O on EVEN values. How do I get the instantiation to enforce my >evenness constraint? First I would need another language change that requires You shouldn't have to in a language that purports to have strong typing. Simply using a value outside of the constraints of the ADT should raise a constraint error. I don't actually propose we change the language to allow assignment overloading. It would cause too many problems at this late date. I'm just saying it wasn't designed right the first time. I would argue that if assignment cannot be overloaded in any situation then "=" should not be overloadable in any situation. In fact, I think it's inconsistant to allow overloading of any kind if you don't allow overloading of all kinds. After all, it's just as easy to type "FooReal(X)" and "FooInt(X)" as it is to type just "Foo(X)", right? hurm. And more understandable, right? Might even be more readable, neh? Not allowing ":=" to be overloaded because it's "special" is a kludge. -- "Our little lives get complicated It's a simple thing Simple as a flower And that's a complicated thing" ../ray\..