Path: utzoo!mnetor!uunet!husc6!uwvax!dogie!uwmcsd1!csd4.milw.wisc.edu!zdenko From: zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) Newsgroups: comp.lang.fortran Subject: Re: [long]Re: modules in f8x Message-ID: <5208@uwmcsd1.UUCP> Date: 13 Mar 88 00:28:12 GMT References: <9872@steinmetz.steinmetz.UUCP> <1178@ut-emx.UUCP> <1456@pasteur.Berkeley.Edu> Sender: daemon@uwmcsd1.UUCP Reply-To: zdenko@csd4.milw.wisc.edu (Zdenko Tomasic) Organization: University of Wisconsin-Milwaukee Lines: 101 Keywords: fortran,f8x,typing Summary:there is a need for user-defined data structures/operations In article <1456@pasteur.Berkeley.Edu> hshankar@sim.Berkeley.EDU.UUCP (RAMACHANDRAN HARISHANKAR) writes: >I must disagree that the strong typing available in pascal and c and ada is >sufficient for fortran users. > >First, I have never found the >need for structures in my numerical programming. The data structures are ^^^^^^^^^^^^^^^^^^^ >simply not that complex. So adding that feature simply complicates life >for insufficient reason. This depends a lot on what you are doing and how. If you are used to basic data structures, you may already be conditioned to consider them exclusively and not even consider anything else (why bother learning new stuff when a quick hack along old lines seems to suffice or does it?). Thus, you may subconsciously limit yourself and potentially miss a data structure that might be more convenient or efficient. It seems to me that in your tensor example below a new data structure (user defined?) is what you really need. Object oriented programming should probably be considered also, but I do not know enough about it to be specific. Someone will doubtlessly pick up on that. > >Second the kind of strong >typing available in pascal does not handle tensors and units. In the example >given if we defined variables with appropriate >types, pascal would still not allow us to check for that error. In one of >my programs I had a large number of multidimensional arrays, with nearly >all dimensions that same , but with very specific physical >meaning. So it was alright to contract the 2nd row of A with the 3rd column >of B, but not with the 4th column, even though the dimensions agreed. The >resulting mess took me months to work out, and I finally did so by the >use of a precompiler that enforced my strong typing for me. So fortran >DOES need strong typing, and it needs a version of it that is quite different >from pascal and c. > >A more general example is the need to distinguish covarient and contravarient >indices in a tensor. Both are indices going from 1 to 4. But never should >we allow covarient to contract with covarient and vv. I do not know of an >algorithm that will allow fortran to enforce this, but I do know that pascal >does not. [I learnt the language for that purpose and found it unsuitable] > The above just proves the need for the user defined data structures and operations. No compiler (or compiler writer, language designer) can predict all the needs of the world, just the most common ones. However one should be careful with customized definitions, else the eventually data structure extensible languages may end up being a big mess rather than help. Make a new structure only if you really need it and it cannot be easily achieved through the common ones. >Third, pascal and c compilers lack the complex >type, and most of my programming is in the complex plane. > This just indicates that they are not best tools for nontrivial numerical analysis or math programming. However, that by itself does not mean they cannot be improved or extended for purposes other than what they have been designed (pascal-teaching novice programming, c-systems programming). >Fourth, invisible coddling by a language is VERY beneficial to those of >us who are not master programmers. When I program I use all sorts of horrible >constructs, knowing that if it is wrong the compiler will catch me out. I >don't make a career of programming. It is just a tool to use in doing research. >So I expect to find safeguards to protect me from myself. I believe that >a very large number of scientists are in the same boat. > This is a dangerous attitude if you believe that compiler is responsible for catching all your errors so you will not have to think about it. There are definite limits on compiler error checking and they can mostly be limited to syntactical check and partly semantics. No compiler can read your mind and know what you actually want. Those which try to do that can mislead you and confuse more than you ever thought possible. After all, compilers do not have intelligence, just compiler writers(?) :-) and they are all too human too. >In short, I don't care about structured constants and typedefs and things >like that, but DO care to have the ability to associate units with dimensions. >That is a very important and useful capability. Many mathematical aids >now a days have this ability, and it is there because physicists think >better in terms of conceptual formulae than in terms of computerese. > > > >hari ramachandran. In short, even if you do not intend to be professional programmer, you must know your tool and know it well. There is no substitute for clear thinking, YOUR thinking. Zdenko Tomasic UWM, Chem. Dept. Milwaukee,WI,53201 __________________________________________________________ UUCP: ihnp4!uwmcsd1!csd4.milw.wisc.edu!zdenko ARPA: zdenko@csd4.milw.wisc.edu __________________________________________________________