klietz@ux1.cso.uiuc.edu (02/21/90)
> 1, 2, 3. No semicolons. End-of-line comments. Block structure indicated > by indentation. Here is a proposal for how to use indentation to scope statement and expression blocks. Semicolons are terminators. A newline is also a terminator if the following line is not indented with respect to the rightmost symbol on the current line that begins a new statement or expression block. e.g. while or =. Finally, a terminator within parenthesis has no effect outside the scope of the parenthesis. So, here is an example of a programs using these rules in a C-like language. i = 0 while (i < n) k = f + a[i] * lagrange(i, j) + a[i+1] * lagrange(i+1, j) + a[i+2] * lagrange(i+2, j) + if (f > 0) m = euler(f); gauss(m) else 0 i = i + 3 if (i > 0) f = f + 1; j = k; k = kolmogorov(k, j) h = ( do poisson(a[i+j]) g = f + ( alpha(x) + beta(x) + gamma(x) + delta(a) + epsilon(x) ) abel(a[i+j]) while (i == j); g; ) f = abs(h) Use of curly braces { } is not needed. It is obvious to the reader when he sees ;) that the trailing parenthesis terminates a statement and not an expression. -- Alan E. Klietz University of Illinois at Urbana-Champaign National Center for Supercomputing Applications 152 Computing Applications Building 605 E. Springfield Avenue Champaign, IL 61820 Ph: +1 217 244 8024 Internet: aklietz@ncsa.uiuc.edu
tneff@bfmny0.UU.NET (Tom Neff) (02/21/90)
Wouldn't depth-by-indentation make include files a nightmare?
rang@cs.wisc.edu (Anton Rang) (02/24/90)
In article <15190@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >Wouldn't depth-by-indentation make include files a nightmare? Yes. But I haven't yet found a use for include files which isn't handled better by some other mechanism (i.e. separate specification and body, or some other export/import system). There probably is some use, but I can't think of one offhand. Why don't all languages provide an export/import, ala Ada, Modula-2, or most (non-standard) Pascal implementations? Inertia? Anton, hoping for the perfect development environment within the next century :-) +---------------------------+------------------+-------------+ | Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | +---------------------------+------------------+-------------+
jlg@lambda.UUCP (Jim Giles) (02/24/90)
From article <RANG.90Feb23135101@derby.cs.wisc.edu>, by rang@cs.wisc.edu (Anton Rang): > [...] > Why don't all languages provide an export/import, ala Ada, Modula-2, > or most (non-standard) Pascal implementations? Inertia? Export/import is in Fortran 90. But you should have seen the public review complaints about it. Most people seem to want INCLUDE and most people seem to oppose export/import. I think this is programmer inertia, not language inertia. If people got used to export/import, I suspect they would lose interest in INCLUDE. J. Giles
kjj@varese.UUCP (Kevin Johnson) (02/24/90)
In article <15190@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >Wouldn't depth-by-indentation make include files a nightmare? In what way??? It's hard to imagine how this would be a problem. #include <standard_disclaimer> .-----------------------------------------------------------------------------. | Kevin Johnson ...!mcdphx!QIS1!kjj | | QIS System Administrator Motorola MCD kjj@phx.mcd.mot.com |
carroll@m.cs.uiuc.edu (02/24/90)
>/* Written 5:34 pm Feb 22, 1990 by jlg@lambda.UUCP in m.cs.uiuc.edu:comp.lang.misc */ >/* ---------- "Re: Anyone want to design a languag" ---------- */ >From article <18172@megaron.cs.arizona.edu>, by mike@cs.arizona.edu (Mike Coffin): >> [...] >> A correction for those readers not familiar with C: the above is not >> true. Arrays and pointers are different beasts. The confusion arises >> because array names are *converted* to pointers when passed as >> parameters and because the [] operator can be used on both. > >A correction for those readers not familiar with C: the above is not >true. Arrays are pretty useless unless you can pass them around as >procedure arguments. C converts all arrays to pointers when passing >them to procedures. AND: YOU _CAN'T_ CONVERT THEM BACK ONCE YOU'RE >THERE!!!!! They are not treated as arrays anywhere except the scope >in which they were declared - and CAN'T be treated as arrays anywhere >except their home scope. > >To make an analogy, it's as if, once an integer was converted to real, >it could _never_ be converted back! And normal usage of integers >_forces_ you to convert them to real on frequent occasions. So that, >in effect, you really _DON'T_ have integers. Fortunately, even C >doesn't really do this to integers. But is DOES do the corresponding >thing to arrays. > >J. Giles >/* End of text from m.cs.uiuc.edu:comp.lang.misc */ {Chris,Henry,Doug} correct me if I'm wrong, but I've always viewed array names simply as _constant_ pointers. IMHO, all of the differences between pointers and arrays can be understood by this model (and, of course, it does correspond to the underlying implementation). So, when you pass an array name to a function, it get converted to a pointer just like the constant 4 gets converted to an integer variable, and you can't ever convert it back to a constant. So, your analogy is flawed. It also fails because it relies on the underlying assumption of the reader that floats are slower than int's, and require different operators/declarations, when such things do not happen with the array/pointer "conversions". The only "conversion" is that the value of the array name is put into a variable. Alan M. Carroll "Like the north wind whistling down the sky, carroll@cs.uiuc.edu I've got a song, I've got a song. Conversation Builder: I carry it with me and I sing it loud + Tomorrow's Tools Today + If it gets me nowhere, I'll go there proud" Epoch Development Team CS Grad / U of Ill @ Urbana ...{ucbvax,pur-ee,convex}!cs.uiuc.edu!carroll
jlg@lambda.UUCP (Jim Giles) (02/26/90)
From article <5200044@m.cs.uiuc.edu>, by carroll@m.cs.uiuc.edu: > [...] > {Chris,Henry,Doug} correct me if I'm wrong, but I've always viewed array > names simply as _constant_ pointers. IMHO, all of the differences between > pointers and arrays can be understood by this model (and, of course, it > does correspond to the underlying implementation). [...] I'm not one of the people you specified, but I'll correct you anyway. An array is a constant pointer with the following additional properties: 1) It's usually _not_ aliased to any other arrays in a given context. In fact, arrays are so rarely aliased, the compilers should assume they aren't (and even check to make sure) unless you explicitly state otherwise. What's needed for this is a language statement which say, in effect, 'the following two items might be aliased: arg1,arg2.' 2) The pointer is to a _MULTIDIMENSIONAL_ structure with different bounds on each dimension. (C doesn't even get the degenerate case of one dimensional arrays right - it doesn't enforce the bound. Some Fortran implementations also do this wrong. But mostly, Fortran only ignores the bounds when you tell it to - with a '*' in the declaration, or when you turn off bounds checking entirely.) 3) Names of dynamically allocated arrays are not _constant_ pointers, they vary as the program proceeds. Such dynamic arrays still have the first two properties though. Finally, of course, any other object which is passed by reference is also implemented as a pointer. These other objects have different auxilliary properties than those for arrays. The auxilliary properties of these should also be inforced by the implementation - at least optionally - I don't absolutely oppose what C does, I just oppose the lack of an optional way to make it do anything else. In fact, the way C does things should be the option, and the default should apply the properties I mentioned above. J. Giles
dave@PRC.Unisys.COM (David Lee Matuszek) (02/27/90)
In article <15190@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >Wouldn't depth-by-indentation make include files a nightmare? Why? I would expect include files to come in at the depth of the include statement. Just think of indentation as relative, rather than absolute. -- Dave Matuszek (dave@prc.unisys.com) -- Unisys Corp. / Paoli Research Center / PO Box 517 / Paoli PA 19301 -- Any resemblance between my opinions and those of my employer is improbable. << Those who fail to learn from Unix are doomed to repeat it. >>
chris@inmos.COM (Chris Larsen) (02/27/90)
In article <15190@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >Wouldn't depth-by-indentation make include files a nightmare? Not neccesarily. occam, Inmos' language designed for parallel processing, uses include files and indentation is part of the language's syntax. "Unindenting" causes the end of scope for items declared at the previous level of indentation. Using include files can be quite a useful tool to simulate record structures in occam since occam doesn't have record structures. The way the mechanism is controlled is that the #INCLUDE statement in occam is indented to the level the programmer wishes the include file contents indented to. This means that generally speaking, there should be no indentation in the include file itself! Chris Larsen chris@isnet.inmos.COM Inmos US Central Apps./US Software Support