Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704A-Liber) Newsgroups: comp.lang.misc Subject: Discussions of languages (Was: Re: Modern langauges) Message-ID: <3315@ihlpf.ATT.COM> Date: 9 Jan 88 02:56:11 GMT References: <1520@ogcvax.UUCP> <1522@ogcvax.UUCP> <2582@enea.se> Reply-To: nevin1@ihlpf.UUCP (00704A-Liber,N.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 129 In article <2582@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes: > >On type conversions: (Explicit or not?) > The key word here for me is data abstraction. Even integer to integer >may be wrong. >(Using Pascal here) > SIA_range : (some interval); (* Index in the IA *) > DIL_range : (some interval); (* Index in a block *) >Assignment from type to the other does seem like a error. Logically, it is an error. C does not provide data abstraction on this level; if you want it, use a language like C++. Looking at Pascal (the other extreme :-)), if I define two arrays of two different sizes I must use two different routines to manipulate them. This makes things like string processing nearly impossible (most uses of strings are with variable length). >It is these kinds of logical mistakes I talk about. Not the risk >of losing some accuracy. (But allowing reals to integer without >explicit conversion was something I thought only Fortran did. >C does also?) C does do type conversion automatically but in a well-defined way. (See K&R section 2.7) > >Array-index checking: > >If you write checks yourself, that seems like a source of error to me. > >Another comments on range checking in loops: It's only safe to leave >them out if the index can't be altered while in the loop. Don't >know about C, but this is certainly possible in Pascal. Ada, on other >regards the loop index as a constant. In C, there is no real concept of a loop index; 'for' statements are much more general in C than in Pascal. (I will not describe the mechanism here; look at K&R section 1.3) Also, arrays in C are not necessarily indexed; pointers may be used insted (abstractly, these are equivalent, however). >Generally, a good compiler should give you the possiblity to surpress >checking, either for the entire program, or just a part of it. So you >can always the remove the checks on delivery. The quetsion is just: Dare >you? The hostile user's may provide data you've never dreamt of. What actually happens when a program gets an out of range error? Usually, the program just dies. If you don't dare remove the checks, you shouldn't be programming! I would rather put the checks in myself so that I may be able to perform a more graceful handling of possible bugs. These types of runtime checks do not in any way insure that my code is more correct; they only provide a way of stopping badly written programs. The only thing that these checks might do is help someone find an error in their code (although as an experienced C programmer this information would not usually help me). In an earlier article you mentioned that we should all buy faster hardware to compensate for run-time checks. I'm sorry, but when I am sorting 100,000 + records I do NOT want the execution time to be tripled just to perform checks on each operation. Faster hardware should NOT be an excuse for badly-written software! >Yes. But he should get as much support as possible from the language. Thus, >the compiler should suspect any input. Most compilers I know of do this on a syntactic level. You are proposing that this should be done on a semantic level. Very few languages are this well-defined. Pascal, for example, at the end of a FOR loop, the index is undefined. Are you stopped from using it again before assigning it a value? I think not. Should I be stopped from using it, or should the value of an index be defined at the end of a FOR loop? I prefer the latter, but that's just my opinion. >> A programmer is simply a >>person who translates concepts from one language (that of the application) to >>concepts in another language (that of the programming model). It is very >>similar to natural language interpreters. If I were to hire a Russian >>to interpret for me, I would want one who understood both Russian and English. > >Not really. Your Russian interpreter doesn't need to have a full notion >of what you are talking of as long as he gets the words right. This just isn't true. If it were, why isn't there a computer program available that will do this? David Letterman tried this type of language translation once. He took the Beatle's song "A Hard Day's Night", had it translated into six different languages (English -> Russian, Russian -> French, ...) and back into English. Funny, the meaning wasn't quite the same as the original song. >What have this to with C? Well, a powerful language with good possibilities >abstracting the data is a help here to see: "What is to be done?". >Does C have the good devices for this? I doubt. Strong type checking is >a must here, I believe. First of all, if you want C to become Pascal why don't you use Pascal instead? Strong type checking only helps you find more errors at compile time, that's all. The function of English is not to stop me from expressing myself badly, so why should the function of C be to stop me from programming badly? USE THE RIGHT LANGUAGE FOR THE RIGHT PURPOSE!! If I need strong type checking, I would pick a language like C++. Can we discuss modern languages now? I'm tired of the 'which language is best' argument. My favorite language is Icon :-) :-); this language is VERY loosely typed. My problems usually don't come about because of type differences (Note: since it is an interpretive language it does provide the equivalent of runtime checks). This language helps me find my logic bugs (I don't have to worry about silly little things like stacks and lists; they are built into the language. One of the philosophies of Icon is that every function should either return a useful value or fail (i.e., x < y returns y if true; otherwise fails). Another thing is that functions can return more than one value (generators; i.e., find(s1,s2) returns all the positions of s1 in s2, and fails when it can't find any more). I love these concepts; what do others' think? BTW, Icon is relatively modern (it was created in the late '70s), and is the successor to SNOBOL4 and SL5. What I would like to know are interesting concepts people have found in other languages, and from these discussions try to decide what we think would belong in (to coin a phrase from the Icon Newsletter) 'the Perfect Programming Language'. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_