preston@ariel.rice.edu (Preston Briggs) (02/16/91)
>pmontgom@euphemia.math.ucla.edu (Peter Montgomery): >> The requested operation returns q and/or r, where >> >> a*b + c = q*n + r and 0 <= r < n jlg@lanl.gov (Jim Giles) writes: >You will, unfortunately, recieve little sympathy for this kind of >request. The UNIX community, in particular, will accuse you of >requesting a 'swiss army knife' compiler. He has my sympathy; it's free. However, I won't spend much time inventing special syntax or optimizations for specific problems. There are however, many people working on many ways of expressing and implementing extensible languages. "They" don't belong to a special club; everyone is free to join. It's very simple and fairly popular: while (dissatisfied) { Design a language (perhaps an extension of another language) Implement your language (perhaps hacking an existing compiler or building an iterpreter). Write many programs in your language to gain experience with its limitations. Try and get others to use it. } Some people repeat the process many times (e.g., Wirth). Other people have problems they want solved and don't wish to get pulled into an infinite loop. They can keep complaining; but I don't expect to see any results. Language designers aren't satisfied with existing languages (or they'd be out of the loop); they're busy - designing, implementing, testing. They've got their own agenda. You might be able to sneak your pet idea on someone's agenda, but it's probably expensive. If you want it done right, ...
hrubin@pop.stat.purdue.edu (Herman Rubin) (02/16/91)
In article <1991Feb15.192653.9846@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes: > >pmontgom@euphemia.math.ucla.edu (Peter Montgomery): > >> The requested operation returns q and/or r, where > >> > >> a*b + c = q*n + r and 0 <= r < n > > jlg@lanl.gov (Jim Giles) writes: > >You will, unfortunately, recieve little sympathy for this kind of > >request. The UNIX community, in particular, will accuse you of > >requesting a 'swiss army knife' compiler. > > He has my sympathy; it's free. > However, I won't spend much time inventing special syntax > or optimizations for specific problems. There are however, > many people working on many ways of expressing and implementing > extensible languages. "They" don't belong to a special club; > everyone is free to join. It's very simple and fairly popular: > > while (dissatisfied) { > Design a language (perhaps an extension of another language) > > Implement your language (perhaps hacking an existing compiler > or building an iterpreter). > > Write many programs in your language to gain experience > with its limitations. Try and get others to use it. > } This assumes that the one who needs the operations, or the improved performance, has the resources and time to do this. Montgomery and Silverman are number theorists, I am a professor of Statistics and Mathematics. We are expected to do other things. Mathematicians are used to the idea of an extensible language for communicating to reasonably intelligent beings. A computer is not an electronic "brain"; it is an extremely fast sub- imbecile. Someone remarked elsewhere on the complexity of the code in Fortran to handle x**y; there is necessarily separate code for each combination of types of x and y, and even code taking into account particular values of x and y. Producing translators of this magnitude is a major project, and there are not adequate macro translators even available. I believe that such a macro translator could be produced, and with that it would be easy to use machine language, rather than the overly restrictive assembler languages designed essentially so as to be easy for the machine to read. What is needed in addition is a language which allows the introduction of operator syntax according to the user's desires. The above production > >> a*b + c = q*n + r and 0 <= r < n is understood by essentially any mathematician, and it should not be necessary to do more than provide a template to convert this into code. Of course, that does nothing to get the operation into hardware. The RS/6000 has a*b+c in floating point, using double double arithmetic internally but not reusably. One of the reasons behind putting this into hardware is that it is relatively easy, and it would be even easier for integer arithmetic. From an architecture standpoint, to a mathematician there is not that much difference between integer and floating point, floating point being the more complicated. > Some people repeat the process many times (e.g., Wirth). > Other people have problems they want solved and don't > wish to get pulled into an infinite loop. They can keep > complaining; but I don't expect to see any results. > Language designers aren't satisfied with existing languages > (or they'd be out of the loop); they're busy - designing, > implementing, testing. They've got their own agenda. You > might be able to sneak your pet idea on someone's agenda, > but it's probably expensive. > > If you want it done right, ... Wirth is being employed to design and develop languages and related things. In addition, he has available for this development somewhere between a squad and a platoon of assistants. This is extermely important; it is difficult to catch one's own minor errrors, even in something as flexible as English, designed to be read by an intelligent being. Communicating to a machine is much harder. There is also the need for people to do the routine work. For Montgomery or Silverman or me to produce the language would be more than asking an individual automotive designer to do everything from idea to prototype without any assistance whatever. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
preston@ariel.rice.edu (Preston Briggs) (02/17/91)
hrubin@pop.stat.purdue.edu (Herman Rubin) writes: >What is needed in addition is a language which allows >the introduction of operator syntax according to the >user's desires. This is a hard thing. People have been fooling with it for years and haven't gotten very useful results. The Lisp community (especially the Schemers) are probably the most advanced, but many people seem unwilling to accept the parentheses and other overhead. >Wirth is being employed to design and develop languages and >related things. This doesn't seem quite right. He's a professor, and certainly tenured. I expect he works on what he likes. >For Montgomery or Silverman or me to produce the language would be >more than asking an individual automotive designer to do everything >from idea to prototype without any assistance whatever. But individuals have designed and implemented languages (also cars). However, I agree that it's pretty hard and very time consuming. My point was supposed to be something like: There is no exclusive club. Language designers are doing it because they want to. No one is paid to design languages (Ada and COBOL are probably counterexamples) A person designing a language is has a problem he's trying to solve. He doen't care about anyone else; he's got too many problems as is. Actually, I'd be concerned about someone designing a language to another's specifications: If he's such a good language designer, why isn't he working on his own language?
hrubin@pop.stat.purdue.edu (Herman Rubin) (02/18/91)
In article <27BDC456.20D6@tct.uucp>, chip@tct.uucp (Chip Salzenberg) writes: > [ Followups to comp.misc ] > > According to hrubin@pop.stat.purdue.edu (Herman Rubin): > >Montgomery and Silverman are number theorists, I am a professor > >of Statistics and Mathematics. We are expected to do other > >things. > > I'm a programmer, but that doesn't mean I've got all the time I want > to do projects for J. Random Person. I'm expected to do other things, > too. > > >I believe that such a macro translator could be produced ... > > A spec, Herman. Surely you can squeeze a few hours our of your busy > schedule to produce a spec. Or is your desired language a mystery > even to you? I am not saying that every programmer should drop what he is doing to produce the appropriate tools. But the problems faced are problems which can be handled, and even anticipated, by including flexible tools. They are not going to be even treated by moving in the direction of more and more rigid structures, hardware, software, and OS. In the next few weeks I will produce something which I believe will indicate what should be done. It will definitely not be in the direction which programmers and language desingners are moving now; the great introduction of variables by Diophantus made it possible to communicate algebraically without confusion. Unfortunately, we seem to refuse to consider this simple idea, and instead concentrate on manipulations. The same is true in the current approach to computing. Instead of setting up tools so that the person expressing ideas in a notational language can have this automatically, as far as is possible, translated into what the sub-imbeciles known as computers can understand, we state that this processor can only use these idea. How efficiently a computer can handle things depends both on the hardware and software, and I suggest that the first step should be to make a preliminary translation of what the user wants to write, in the user's notation, into "computerese." THEN worry about how to do things efficiently. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)
hrubin@pop.stat.purdue.edu (Herman Rubin) (02/24/91)
In article <3381.27c548c3@iccgcc.decnet.ab.com>, herrickd@iccgcc.decnet.ab.com (daniel lance herrick) writes: > In article <6049@mentor.cc.purdue.edu>, hrubin@pop.stat.purdue.edu (Herman Rubin) writes: > > In article <1991Feb15.192653.9846@rice.edu>, preston@ariel.rice.edu (Preston Briggs) writes: > [i may have edited away all of preston's contributions to this line] > >> jlg@lanl.gov (Jim Giles) writes: > >> many people working on many ways of expressing and implementing > >> extensible languages. "They" don't belong to a special club; > >> everyone is free to join. It's very simple and fairly popular: ....................... > > This assumes that the one who needs the operations, or the > > improved performance, has the resources and time to do this. > > Montgomery and Silverman are number theorists, I am a professor > > of Statistics and Mathematics. We are expected to do other > > things. > [much more edited away, this is only to remind of what went before] > You are faculty at one of the two schools with the oldest departments > of Computer Science in the country. Go to your colleagues in CS and > tell them you have a design problem that seems to be about the right > size for a PhD. You are almost right about its size; something of this complexity needs at least two people working on it to avoid first class goofs. But it is not appropriate for a PhD thesis. It is a contribution, but not particularly research, which is the criterion for a thesis and for tenure. The current pressure for students in academia is to avoid what is not either required or directly needed for their thesis research and overconcentrate. The project can be done by a faculty member whose academic reputation is essentially assured with the help of a graduate student or two. Someone like Wirth can get the funding and the students. Someone like me has a small chance to get the funding, and real difficulty in getting the students. > If you can get them to cobble it together on gcc (or g++) you can > then profit from any improvements made later in the gnu code generator. > (And also portability to future computers.) > > What has frosted me about the languages is that the arithmetic > operators are all single valued. I usually want the quotient > and remainder from a division. I have to tell the compiler to > give me the quotient and then tell it to give me the remainder. > It might be smart enough to notice that it gets both of them in > one machine operation, but if it is, it is only undoing bad language > design. This WAS obvious when languages were first started. Fortran had a limited purpose, but not Algol. It is syntactically more difficult, but a purpose of a language is to make it easier for the user to use the hardware, and the hardware could do this on the great bulk of machines then. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)