haitex@pnet01.cts.com (Wade Bickel) (03/01/88)
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > Please enable your SMILEY_FACE bit while reading this posting. > >In article <405@csvax.liv.ac.uk> sqrkl@csvax.liv.ac.uk writes: >>Has anyone seen a GOOD Pascal compiler for the Amiga yet ? >> > There is no such thing as a GOOD Pascal compiler. This is largely >because, while C compilers are designed to generate code, Pascal compilers >are designed to generate error messages. > > ............. > > Because all the Real Programmers are on the Amiga, and Real >Programmers use C or assembly. Strong typing is for people with weak >memories, you know... - - - - - - - - - - - - - - - - - - - - - - Leo, have you tried Benchmark Modula-2? You could ingore the type checking if you like. I find it and the robust error reporting quite useful. I use Benchmark Modula-2. It has advantages and disadvantages over C. Listing the assets/liabilities of each C: + Established high level (supposedly :^)) language for the Amiga. Most source is currently in C. + Generates intermediate assembly file (MANX). + Pre-initialization of data. + Register specification. + Symbolic Debugger exists (MANX). + Manx is a "large" (relatively speaking) company. I assume Lattice is as well. - C compilers are buggy. When I first got Manx (v3.20a) it was buggy and Manx was unresponsive to the problem. It was over a month before any help was provided, and the patches supplied were incomplete. As far as I know there are still problems. I see Manx and Lattice bug reports regularly. There are hundreds of Benchmark user's, ever seen a Benchmark bug report? - Both C compilers are significantly more expensive than their Modula-2 counterparts. - Available C compilers are slow. M2: (Benchmark) + Integrated Development Environment. This makes using Benchmark extremely easy. From the editor (modified gnu-EMACs) just hit F2 to compile the current buffer, F3 to link, and F4 to execute the file (directly from the editor). If after compiling a buffer errors were found, F1 can be used to step through them, and the system descibes the errors. Every aspect of the Dev. Environment is good (though of course there is always room for improvement). + Compilation Speed. Benchmark is (as best I can compare) 8 times faster than MANX C. My test was compilation of the program "ShowILBM" under both, as this was a direct translation from C to M2. (I don't have Lattice). + Seperate compilation is a feature of M2 at the language level. Effectively, this combine with the above features means the wait between edit and run can usually be held to under 20 seconds. Also, M2 will not allow corrupt linkages to occure (important if you use seperate compilation). + Excellent Documentation. Benchmark was implemented entirely by Leon Frenkel. It is not a port (as I believe are both Cs). The documentation was written by the compiler author, and it shows. It is very complete and uniform. + Nested comments are allowed in M2. I find this very useful. + M2 includes a statement called "WITH" which supports record (structure) access. As far as I can tell no equivalent to this statement exists in C (as avail- able on the Amiga). This statement leads to both more readable (in terms of context) source, and more efficeint code. + No Bugs. In the last 6 months Benchmark has never Guru'd on me. As far as I (or anyone I've spoken with) can tell, this seems to be true. + Strong Types. M2 uses strong type checking. This makes the language easier to learn and debug. + Readablility. M2 is much more readable than C. This is of value to the novices and group efforts. + Benchmark includes a large number of examples. + Benchmark is considerably less expensive than either Manx or Lattice C. - Problems between Oxxi and Leon Frenkel. At one time Leon had planned to publish Benchmark through Oxxi. In the Fall there was a falling out between them. Since that time Oxxi has been selling Benchmark without Leon's consent (the Beta-test version with a draft manual). Leon is now releasing the "release" version (this month) and OXXI claims to have an update too. Benchmark seems to put out code that is at least as good as Manx-C. I would like to see good comparison. Hopefully we'll see a Benchmark symbolic debugger by Summer? Several new "add-ons" are soon to be released. In my opinion Leo, it is not so much the language as the implementation that makes the difference. Benchmark is the best piece of software I've seen for the Amiga. As far as I can tell there is nothing you can do in C you can't do in M2 (except assign a "register variable"). Use C if you wish, but Benchmark is worth looking into :^). Thanks, Wade. PS: I am a beta-tester for Benchmark, which means I got my copy for free, I was to evaluate it for my work (Southern Technologies). I also got my copy of Manx-C for free through Southern, along with TDI M2 (which I would not use). I have no financial association with Benchmark at all. PPS: Any Benchmark user's interested in forming a users' group please contact me via E-Mail (see my .sig). UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
duncanj@umd5.umd.edu (James Duncan) (03/02/88)
What about those people FORCED to use Pascal for academic reasons. Say your in a class and are permitted to use any computer but MUST program in Pascal! Gee sorry Prof., but real programmers use C. Sorry no-name generic student but real students program in Pascal or they don't get a real grade in my all too real class. Pascal is the de facto academic language. With the emphasis on personal computers these days often students are allowed to use any PC, but due to grading standardization the students are required to program in Pascal. Jim Duncan
peter@nuchat.UUCP (Peter da Silva) (03/06/88)
In article <2605@crash.cts.com>, haitex@pnet01.cts.com (Wade Bickel) writes: > ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > > Please enable your SMILEY_FACE bit while reading this posting. Hmmm. Someone didn't... > >In article <405@csvax.liv.ac.uk> sqrkl@csvax.liv.ac.uk writes: > >>Has anyone seen a GOOD Pascal compiler for the Amiga yet ? > > There is no such thing as a GOOD Pascal compiler. This is largely > >because, while C compilers are designed to generate code, Pascal compilers > >are designed to generate error messages. Cute. > I use Benchmark Modula-2. It has advantages and disadvantages > over C. Listing the assets/liabilities of each > C: + Established high level (supposedly :^)) language > for the Amiga. Most source is currently in C. Compared to the other languages that people do systems programming in, C is practically dictatorial about types. Have you looked into BCPL (:-<), PL/M, Bliss, or Assembly (:-/) lately? > + Pre-initialization of data. This is one hell of a biggee. I've seen the gross things people have had to do in Modula to emulate that (like turning off entry code and stuffing the data into a procedure, and then typecasting a procedure to whatever data type they want. > + Register specification. This is mainly due to the low level of most compilers of any kind on micros. The register specification is more of a hint than anything else on big machines these days. + Huge library of decent-quality public domain 'C' source exists, thanks to comp.sources.*. + A good standard library exists that makes porting well behaved and reasonably efficient programs between wildly differing computer architectures commonplace. > - C compilers are buggy. When I first got Manx (v3.20a) > it was buggy and Manx was unresponsive to the problem. > It was over a month before any help was provided, and > the patches supplied were incomplete. As far as I know > there are still problems. I see Manx and Lattice bug > reports regularly. There are hundreds of Benchmark > user's, ever seen a Benchmark bug report? I don't know about Benchmark, but the first modula I was exposed to, on the PC, was a horrible integrated environment that crashed if you tried to import code into their syntax-dependent editor. Also, there are thousands of C users. People also tend to be more critical of 'C' compilers on the net, since they're exposed to so many good ones on their UNIX boxes. > M2: (Benchmark) > > + Integrated Development Environment. This makes using > Benchmark extremely easy. From the editor (modified > gnu-EMACs) just hit F2 to compile the current buffer, > F3 to link, and F4 to execute the file (directly from > the editor). If after compiling a buffer errors were > found, F1 can be used to step through them, and the > system descibes the errors. Every aspect of the Dev. > Environment is good (though of course there is always > room for improvement). I'd put this as a minus for Benchmark, though M2Amiga seems to make good use of the integrated environment the Amiga comes. Neither a plus nor a minus for Modula as a whole. > + Nested comments are allowed in M2. I find this very > useful. Syntactic sugar. Some 'C' compiler allow this, others have a compile-time switch for it. I tend to use preprocessor directives for compilation control, myself. Speaking of compilation control, what does Modula provide? > + M2 includes a statement called "WITH" which supports > record (structure) access. As far as I can tell > no equivalent to this statement exists in C (as avail- > able on the Amiga). This statement leads to both > more readable (in terms of context) source, and more > efficeint code. Now we're getting down to religious differences. Myself, I like: register weird_structure *ptr; ptr = complex expression; ptr->... to WITH complex expression DO END; Mainly because of the semantic confusion that can occur if you're using two different syntaxes for accessing the same data. schooner.masts = 3; and masts = 3; > + Readablility. M2 is much more readable than C. This > is of value to the novices and group efforts. That's a matter of opinion. I find 'C' more readable myself, since I don't have to parse control flow words out of the language. Can't put this one on either side of the balance. > + Benchmark includes a large number of examples. More than comp.sources or even the RKM? Wow, and one minus that's a reference to political problems rather than the languages themselves. Glad to see you're so even handed. There are things I don't like about 'C' myself. I've got M2Amiga sitting here looking very attractive. One day I'll get the time to play with it. > In my opinion Leo, it is not so much the language as the > implementation that makes the difference. Nope, it's the language. > Benchmark is the best piece of software I've seen for the Amiga. I kind of like Intuition myself. > As far as I can tell > there is nothing you can do in C you can't do in M2 (except assign > a "register variable"). C is the only high-level language that provides more than minimal support for large compile-time initialised data structures. There are other advantages, but I'm not interested in debating religious issues (geeze, what a hypocrite) (shut up, Peter)... -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
cs178abu@sdcc8.ucsd.EDU (John Schultz) (03/07/88)
Seems like first impressions have lasting consequences on programmers... Peter, I'm curious, how would one implement a nested WITH in C? Oh, and another thing, let's say , for the sake of argument, that C in it's present state, is superior to all other languages (including M2), as a language definition. Enter Joe Blow, who can produce 10000 lines of code in TS 27 (Taco Sauce 27, a fictitious language), the worst language definition. Joe's friends persuaded him to try C. It took him twice as long to produce the same code, which doesn't run any faster. Now, should we force Joe to use C anyway? The point is, it's pointerless to try to typecast a hardcore C programmer into M2 or any other language. So use what works best for you own personal brain (of course, you will!). Is *anyone* going to be persuaded to switch languages? John
haitex@pnet01.cts.com (Wade Bickel) (03/07/88)
duncanj@umd5.umd.edu (James Duncan) writes: > >What about those people FORCED to use Pascal for academic reasons. >Say your in a class and are permitted to use any computer but MUST >program in Pascal! Gee sorry Prof., but real programmers use C. >Sorry no-name generic student but real students program in Pascal or >they don't get a real grade in my all too real class. > >Pascal is the de facto academic language. With the emphasis on personal >computers these days often students are allowed to use any PC, but due to >grading standardization the students are required to program in Pascal. > > > Jim Duncan > You should see if your Prof. will allow you to use Modula-2. Modula-2 is the successor language to PASCAL. Both were created by Niklaus Wirth. M2 is the derivative of Modual{-1} and PASCAL. Modula was a systems programming language. The result is a language which gives you all the niceities of PASCAL (well, most of them :^>), and the low level access PASCAL denied (which forced us to go to C, or assembly). M2 is *VERY* similar to PASCAL, so for grading purposes it should not be a burdon to the graders. I can't see any reason a Prof. in his right mind would not encourage using M2, as it is a vibrant language, whereas PASCAL is a dead one :^>. Good Luck, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
daveh@cbmvax.UUCP (Dave Haynie) (03/08/88)
in article <2605@crash.cts.com>, haitex@pnet01.cts.com (Wade Bickel) says: > I use Benchmark Modula-2. It has advantages and disadvantages > over C. Listing the assets/liabilities of each > C: ... > + Symbolic Debugger exists (MANX). Well, yes, but more than that. Manx ships with a symbolic debugger and now offers a very nice Source Level debugger as an option. Lattice doesn't include a symbolic debugger yet, but since they use the standard Amiga object format, any standard Amiga symbolic debugger (like MetaScope) will work just fine with Lattice. More + Manx C allows in-line assembly code + Manx C can produce native 68020 code and in-line 68881 code. > - C compilers are buggy. C compilers WERE much buggier than they are now. Not only that, but both Manx and Lattice offer BBSs that you can call. Lattice is also on BIX. I'm using both Manx 3.6 and Lattice 4.0 now, haven't run into any bugs myself yet. > There are hundreds of Benchmark user's, ever seen a > Benchmark bug report? No. Then again, I don't find this surprising, considering the relative number and level (eg most commerical developers use C) of C users over Modula2 > M2: (Benchmark) > > + Integrated Development Environment. This makes using > Benchmark extremely easy. From the editor (modified > gnu-EMACs) ^^^^ Smile when you say that. It's MG, not Gnu. A real GNU emacs wouldn't need modification, you could write all those extensions in M-LISP. Between running a background Emacs and using MAKE, I find little need for an integrated enviromnent. Certainly integrated environements are useful on single-tasking machines, but I'd rather build my own. For instance, what if I prefer a VI or EDT clone, or a better version of MG, over the BenchMark MG? > + Compilation Speed. Benchmark is (as best I can compare) > 8 times faster than MANX C. My test was compilation of > the program "ShowILBM" under both, as this was a direct > translation from C to M2. (I don't have Lattice). I'd expect the M2 compiler to be a bit faster; both BenchMark and M2Amiga are based on Wirth's latest M2 compiler, which is a single pass compiler. Both Amiga compilers are two pass compilers. Not only that, though, if Benchmark is truely integrated, it'll keep a copy of the compiler in memory, so your compile time doesn't reflect the loading of the compiler. On a real short program like ShowILBM, this makes a big difference. The best comparison would be to load the Manx or Lattice C compilers into RAM, then try compiling relatively large programs based on the same programs. > + Excellent Documentation. Benchmark was implemented > entirely by Leon Frenkel. Not true, this one, as M2Amiga, came from the Wirth compiler. But whether it's a port or not is meaningless, as long as the person porting it did a proper job of Amigaizing it. > + M2 includes a statement called "WITH" which supports > record (structure) access. As far as I can tell > no equivalent to this statement exists in C (as avail- > able on the Amiga). This statement leads to both > more readable (in terms of context) source, and more > efficeint code. I programmed in PASCAL for 4 years, and used WITH alot. It makes PROGRAMMING easier, since you don't have to include all the contexts for a reference. It makes support or translation a nightmare, since you may have no idea, in the case WITHs nested several levels deep, which individual structure elements belong to which structures. I ran into this in a port of a large CAD program from Pascal to C. > + No Bugs. In the last 6 months Benchmark has never > Guru'd on me. As far as I (or anyone I've spoken > with) can tell, this seems to be true. I've never had either compiler crash on me. No reason one should, a compiler is a pretty mild program in terms of what it does to the system. As for the output of that program crashing, there's always a tradeoff between the speed of your program and the errors you'd like the run-time environment to catch for you. This is compiler independent. > + Strong Types. M2 uses strong type checking. This makes > the language easier to learn and debug. Lattice has type checking as an option just about as good as any Modula2. Only it doesn't force it's ideas on you; type violations show up as warnings, not errors. I usually know from the warning if a real problem exists or not. > + Readablility. M2 is much more readable than C. This > is of value to the novices and group efforts. For novices, perhaps. M2 is also quite a bit less writable than C; it's very verbose. > Benchmark seems to put out code that is at least as good as Manx-C. Size-wise, maybe. If it's a typically M2 compiler, though, it'll put lots of bounds checking code in the run-time environment. So I'd expect it to execute slower than a C compiler that otherwise produces similar quality code. > I would like to see good comparison. Hopefully we'll see a Benchmark > symbolic debugger by Summer? Several new "add-ons" are soon to be > released. If that's true, I'd have to tell anyone interested in BenchMark to wait until that's out before even considering it. You can't do any serious development without a good debugger, at least a symbolic one. If they don't support standard Amiga object module symbol hunks (which would let you use any symbolic debugger), you'd have to use this without a debugger, and that's death. > In my opinion Leo, it is not so much the language as the > implementation that makes the difference. Benchmark is the best > piece of software I've seen for the Amiga. As far as I can tell > there is nothing you can do in C you can't do in M2 (except assign > a "register variable"). Use C if you wish, but Benchmark is worth > looking into :^). One question on that. Can you mix assembler with Benchmark's code? I know that M2 compilers require intelligent linkers, meaning that they don't use standard object code, and can't likely be hooked into code I produce with a standard assembler. If they can't be linked with assembler, is there any support in the Benchmark package for creating libraries and device drivers on the Amiga? Or in-line coding of things the compiler doesn't support, like 68020 instructions? Just curious; without these, you don't have a serious development system. -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!"
hcmutt@hpcllld.HP.COM (Harry Muttart) (03/09/88)
/ hpcllld:comp.sys.amiga / daveh@cbmvax.UUCP (Dave Haynie) / 12:23 pm Mar 7, 1988 / Dave Haynie (Thanks for Disksalv!) raises very interesting questions responding to statements made by Wade Bickel, earlier... >> + Compilation Speed. Benchmark is (as best I can compare) >> 8 times faster than MANX C. My test was compilation of >> the program "ShowILBM" under both, as this was a direct >> translation from C to M2. (I don't have Lattice). >>I'd expect the M2 compiler to be a bit faster; both BenchMark and > M2Amiga are based on Wirth's latest M2 compiler, which is a single > pass compiler. Both Amiga compilers are two pass compilers. Not > only that, though, if Benchmark is truely integrated, it'll keep a > copy of the compiler in memory, so your compile time doesn't > reflect the loading of the compiler. On a real short program like > ShowILBM, this makes a big difference. The best comparison would be > to load the Manx or Lattice C compilers into RAM, then try compiling > relatively large programs based on the same programs. You're quite right...the compiler can be made resident. It can also be unloaded (removed from memory). Having the compiler resident is very attractive after using TDI (chunk, chunk, whirrr... :^> ). > > I programmed in PASCAL for 4 years, and used WITH alot. It makes > PROGRAMMING easier, since you don't have to include all the contexts > for a reference. It makes support or translation a nightmare, since > you may have no idea, in the case WITHs nested several levels deep, > which individual structure elements belong to which structures. I > ran into this in a port of a large CAD program from Pascal to C. This is a feature which can be easily abused. Also, a compiler must make the effort to use the WITH information for more than context for locating an otherwise undefined variable or the code may be no better than fully specifying names of things. I have found that using a single level of WITH, surrounding ONLY references to the structure, means the positives outweigh the negatives. It also means that an "old man" like me can read his code three months later. >> I would like to see good comparison. Hopefully we'll see a Benchmark >> symbolic debugger by Summer? Several new "add-ons" are soon to be >> released. > > If that's true, I'd have to tell anyone interested in BenchMark to > wait until that's out before even considering it. You can't do > any serious development without a good debugger, at least a symbolic > one. If they don't support standard Amiga object module symbol > hunks (which would let you use any symbolic debugger), you'd have to > use this without a debugger, and that's death. Actually the object format used by Benchmark IS standard (according to the documentation and several reviewers). Metascope works as well with Benchmark as C, especially if you generate the symbol files (.RFM?). In addition, the package (old OXXI beta version) makes provision for adding image data to the compiled object (separate pass) so that only that hunk will need to be in chip memory. Not perfect, but much nicer than TDI (initialize phony PROCEDURE, alloc chip mem, copy PROCEDURE body to chip mem). >> In my opinion Leo, it is not so much the language as the >> implementation that makes the difference. Benchmark is the best >> piece of software I've seen for the Amiga. As far as I can tell >> there is nothing you can do in C you can't do in M2 (except assign >> a "register variable"). Use C if you wish, but Benchmark is worth >> looking into :^). > > One question on that. Can you mix assembler with Benchmark's code? > I know that M2 compilers require intelligent linkers, meaning that > they don't use standard object code, and can't likely be hooked into > code I produce with a standard assembler. If they can't be linked > with assembler, is there any support in the Benchmark package for > creating libraries and device drivers on the Amiga? Or in-line > coding of things the compiler doesn't support, like 68020 instructions? > Just curious; without these, you don't have a serious development > system. There is a tool for adding assembler hunks to your M2 object included in the package. Seems that an INTERFACE MODULE is compiled to describe the interfaces to procedures and data. There is also support for in-lining code (but only constant data, I think). This seems to cover 68010 and 68020 instructions. In a conversation with Leon, he indicated that there would be a means of initializing non-image data in official Avant Garde versions, as well (I do not know if that is what is shipping or if this is a RSN addition). All, and all, I am very hopeful regarding this version of Modula-2. While I have not gained Amiga hacker status, this product seems pretty nifty (and solid) and has met my needs, so far. Harry Muttart (just my opinions - my employer doesn't care about Ami's) ( ... hplabs!hpda!hcmutt ) -- Dave Haynie "The B2000 Guy" Commodore-Amiga "The Crew That Never Rests" {ihnp4|uunet|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy "I can't relax, 'cause I'm a Boinger!" ----------
peter@nuchat.UUCP (Peter da Silva) (03/10/88)
In article <813@sdcc8.ucsd.EDU>, cs178abu@sdcc8.ucsd.EDU (John Schultz) writes: > Seems like first impressions have lasting consequences on > programmers... I don't know why you'd say that. My first modern language was Pascal, and I spent months making a nuisance of myself at Berkeley telling all who tried to tell me that 'C' had any advantages that 'C' was a horrid kludge. > Peter, I'm curious, how would one implement a nested WITH in C? You mean: WITH shrimpboat DO WITH launchdate DO mm := 9; ... END (* with launchdate *); END (* with shrimpboat *); I'd do this: { register struct trawler *t = shrimpboat; { register struct date *d = t->launchdate; d->mm = 9; ... } } Or this: # define T shrimpboat # define D T.launchdate D.mm = 9; # undef D # undef T WITH is just a notational convenience. The implication in the reference I'm using is that the actual implementation is more likely to be like my first alternative ("Improved efficiency results from this rule, because the compiler need only evaluate the WITH variable once.") > Oh, and another thing, let's say , for the sake of argument, that C > in it's present state, is superior to all other languages I never said this, but go on. > (including M2), as a language definition. Enter Joe Blow, who can > produce 10000 lines of code in TS 27 (Taco Sauce 27, a fictitious > language), the worst language definition. So let him use it. I'm not suggesting that people change from Modula to C, or from Pascal to C. I'm just explaining why I like 'C'. > Joe's friends persuaded > him to try C. It took him twice as long to produce the same code, > which doesn't run any faster. That's two unjustified assumptions in one sentence. > Now, should we force Joe to use C anyway? Of course not. > The point is, it's > pointerless to try to typecast a hardcore C programmer into M2 or > any other language. So use what works best for you own personal > brain (of course, you will!). (*f+ (turn on flamethrower) *) I think you have quite a bit of gall to post a series of messages that look a lot like you're trying to convert me to Modula, and then act as if I'm the one doing the preaching. In fact, this whole discussion (if I recall correctly) started when I championed someone else's Modula compiler. Really the mark of a C bigot, eh? (*f-*) > Is *anyone* going to be persuaded to switch languages? Nor, it appears, compilers. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
haitex@pnet01.cts.com (Wade Bickel) (03/10/88)
[Just a line or three for hungry line eaters] >Dave Haynie writes: >in article <2605@crash.cts.com>, haitex@pnet01.cts.com (Wade Bickel) says: > >> I use Benchmark Modula-2. It has advantages and disadvantages >> over C. Listing the assets/liabilities of each > >> C: ... > >> + Symbolic Debugger exists (MANX). > > Well, yes, but more than that. Manx ships with a symbolic debugger > and now offers a very nice Source Level debugger as an option. > Lattice doesn't include a symbolic debugger yet, but since they use > the standard Amiga object format, any standard Amiga symbolic > debugger (like MetaScope) will work just fine with Lattice. > Oops! I meant Source Level Debugger. Also, Benchmark must conform to the object format, since it works fine with MetaScope. >More + Manx C allows in-line assembly code > + Manx C can produce native 68020 code and in-line 68881 > code. > >> - C compilers are buggy. > > C compilers WERE much buggier than they are now. Not only that, but > both Manx and Lattice offer BBSs that you can call. Lattice is also > on BIX. I'm using both Manx 3.6 and Lattice 4.0 now, haven't run into > any bugs myself yet. > My point exactly. Benchmark is a infant, whereas MANX and Lattice (like C) are middle aged. Yet Benchmark does not suffer from large numbers of bugs, as did MANX and Lattice. This is a testiment to Benchmarks' quality, which shows at many levels. Furthermore, while MANX and LATTICE are working on non-Amiga products, Avant-Gaurde and OXXI (seperatly) are working on Amiga products. At least 4 products are being developed, or are finished but not yet released. The point is that while MANX or LATTICE depend on bug reports to find bugs Benchmark does not (though of course bug reports are important). >> M2: (Benchmark) >> >> + Integrated Development Environment. This makes using >> Benchmark extremely easy. From the editor (modified >> gnu-EMACs) > > Between running a background Emacs and using MAKE, I find little need > for an integrated enviromnent. Certainly integrated environements > are useful on single-tasking machines, but I'd rather build my own. > For instance, what if I prefer a VI or EDT clone, or a better version > of MG, over the BenchMark MG? Benchmark can be used with any editor you wish. It can be called just like any other compiler so you can use VI if wish, but the EMACs editor is customized and *very* nice. Sure, you can create a multi-tasking solution if you want. By the time your hand is on the mouse I'm compiling! By the time you've typed in your compile commands I'm (probably) Linking! By the time you see your first compiler notice, my program is running! By the time you're done compiling I'm editing my program again! :^) > >> + Compilation Speed. Benchmark is (as best I can compare) >> 8 times faster than MANX C. My test was compilation of >> the program "ShowILBM" under both, as this was a direct >> translation from C to M2. (I don't have Lattice). > > I'd expect the M2 compiler to be a bit faster; both BenchMark and > M2Amiga are based on Wirth's latest M2 compiler, which is a single > pass compiler. Both Amiga compilers are two pass compilers. Not > only that, though, if Benchmark is truely integrated, it'll keep a > copy of the compiler in memory, so your compile time doesn't > reflect the loading of the compiler. On a real short program like > ShowILBM, this makes a big difference. The best comparison would be > to load the Manx or Lattice C compilers into RAM, then try compiling > relatively large programs based on the same programs. I'd call 8 times a bit more than a "bit" faster! Does it matter why? Not to me it doesn't! :^) Yes, Benchmark is "truely integerated". But your comparison comment is irrelavant, because M2 supports seperate compilation in a way that is easy to use and easy to modify. Because of this, ALL PROGRAMS ARE SHORT PROGRAMS! (Well, they compile as if they were, anyway :^>) Also, I put the C compiler in memory anyway, don't you? > >> + M2 includes a statement called "WITH" which supports >> record (structure) access. As far as I can tell >> no equivalent to this statement exists in C (as avail- >> able on the Amiga). This statement leads to both >> more readable (in terms of context) source, and more >> efficeint code. > > I programmed in PASCAL for 4 years, and used WITH alot. It makes > PROGRAMMING easier, since you don't have to include all the contexts > for a reference. It makes support or translation a nightmare, since > you may have no idea, in the case WITHs nested several levels deep, > which individual structure elements belong to which structures. I > ran into this in a port of a large CAD program from Pascal to C. > Bad code is bad code no matter what language it is in! Using nested WITH statements without carefull documentation is BAD coding. For that matter, using nested code of any kind without appropriate documentation is BAD coding. In general I don't nest WITHs in an ambiguous manner (in fact, almost not at all), and this is not hard to do. There just isn't much need to do so. Furthermore, using WITH will cause the refrence address to be placed in an address register, which minimise further address calculations in subsiquent accesses of the WITHed record. This also means that use of scope pointers does not add an address calculation to every access within that scope. [ A scope pointer (my own term) would be a pointer to a structure containing a very large block of data, usually mostly pointers. An example might be a data structure such as a tree, and all data related to that tree.] >> + No Bugs. In the last 6 months Benchmark has never >> Guru'd on me. As far as I (or anyone I've spoken >> with) can tell, this seems to be true. > > I've never had either compiler crash on me. No reason one should, a > compiler is a pretty mild program in terms of what it does to the > system. As for the output of that program crashing, there's always > a tradeoff between the speed of your program and the errors you'd like > the run-time environment to catch for you. This is compiler > independent. > And with Benchmark you can turn runtime error checking on or off as you wish. Also, when I was working with only 512K and one floppy with MANX, it bombed on me regularly. I assume MANX is better now, but v3.20a/b and v3.40a were awful. You probably work on an enhanced system (as I do now) and don't notice some types of problems that can be devastating to the new user working with a minminal system. By the way, I should also point out that Benchmark is much more useable on a minmimal system, compiling/linking 50+ times faster than I was able to coax out of MANX (and yes, I did follow Manx's instructions on how to set things up). >> + Strong Types. M2 uses strong type checking. This makes >> the language easier to learn and debug. > > Lattice has type checking as an option just about as good as any > Modula2. Only it doesn't force it's ideas on you; type violations > show up as warnings, not errors. I usually know from the warning > if a real problem exists or not. > Isn't it just wonderful to recieve a peice of source, compile it, and find a hundred or so "warnings" pop up? Did the author really "know" whether those warnings should be looked into or not? Do they affect my adaptation of the code? When I was in college we were graded down heavily for leaving those "warnings" in our code. Type violations can be gotten around easily enough in M2 >> + Readablility. M2 is much more readable than C. This >> is of value to the novices and group efforts. > > For novices, perhaps. M2 is also quite a bit less writable than C; > it's very verbose. What about group efforts? Readability is crucial here! As far as M2 being "very" verbose, NOT TRUE! In M2 there are a few added words. For instance you must follow the arg of an IF statment with "THEN" instead of "{" and you end the subsiquent statement list with "END" instead of "}". From your statements, I seriously doubt if you've used M2. Like so many, you think M2 is just like PASCAL. WRONG! PASCAL was never intended as a serious working language. > >> Benchmark seems to put out code that is at least as good as Manx-C. > > Size-wise, maybe. If it's a typically M2 compiler, though, it'll > put lots of bounds checking code in the run-time environment. So > I'd expect it to execute slower than a C compiler that otherwise > produces similar quality code. > No, M2 is NOT PASCAL. Your statement is wrong. The code seems to be as compact and as fast as MANX C, as long as you don't turn ON the range checking compiler option. >> I would like to see good comparison. Hopefully we'll see a Benchmark >> symbolic debugger by Summer? Several new "add-ons" are soon to be >> released. > > If that's true, I'd have to tell anyone interested in BenchMark to > wait until that's out before even considering it. You can't do > any serious development without a good debugger, at least a symbolic > one. If they don't support standard Amiga object module symbol > hunks (which would let you use any symbolic debugger), you'd have to > use this without a debugger, and that's death. > 'cuse me again, I meant "SOURCE LEVEL DEBUGGER". I know it already exists, so it's just a matter of time before it is released. As I stated above, Benchmark works great with MetaScope. Of course, most people won't need MetaScope with Benchmark. I've done fine without it. I've written some system level stuff, some copper-list stuff, and a dynamic nested list program, without need of MetaScope, though it is on my list of needed software. (Unless the Debugger is released soon). >> In my opinion Leo, it is not so much the language as the >> implementation that makes the difference. Benchmark is the best >> piece of software I've seen for the Amiga. As far as I can tell >> there is nothing you can do in C you can't do in M2 (except assign >> a "register variable"). Use C if you wish, but Benchmark is worth >> looking into :^). > > One question on that. Can you mix assembler with Benchmark's code? > I know that M2 compilers require intelligent linkers, meaning that > they don't use standard object code, and can't likely be hooked into > code I produce with a standard assembler. If they can't be linked FALSE! As far as I know, Benchmark does not utilize an "intellegent" linker of any type. In fact, I spoke to Leon about just such a mod. The intent would be to have the linker "realize" that a function was never called, and not include it in the code generated (with a compiler option to turn it off, or force inclusion of a module or a segement of a module, of course). Leon pointed out a number of significant difficulties in doing so. It is doable, but the returns are questionable, as well designed modules tend to contain routines which are used together. I suppose you could get the same result if you put only one function in each module, and allowed the compiler to handle "smart linking". > with assembler, is there any support in the Benchmark package for > creating libraries and device drivers on the Amiga? Or in-line > coding of things the compiler doesn't support, like 68020 instructions? > Just curious; without these, you don't have a serious development > system. > Benchmark supports (at least) two methods of assembly support. You can insert op-codes via the "INLINE" command or you can create a module of assembly routines, reference them, and call them. As I understand it OXXI will be adding an INLINE assembler soon. --------------------------------------------- I noticed you left out my references to Modula-2's seperate compilation facilities. This is feature C clearly cannot match. Seperate compiliation in C requires programmer attention to a tremendously higher degree than in Modula-2. ALL my programs use seperate compilation. It's almost as easy as useing #include. Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
cs178abu@sdcc8.ucsd.EDU (John Schultz) (03/11/88)
In article <765@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >In article <813@sdcc8.ucsd.EDU>, cs178abu@sdcc8.ucsd.EDU (John Schultz) writes: >> Seems like first impressions have lasting consequences on >> programmers... > >I don't know why you'd say that. My first modern language was Pascal, Well, Peter stated that he had a horrible time with M2 the first time he used it. (no insult intended) >(*f+ (turn on flamethrower) *) >I think you have quite a bit of gall to post a series of messages that >look a lot like you're trying to convert me to Modula, and then act as if >I'm the one doing the preaching. In fact, this whole discussion (if I recall >correctly) started when I championed someone else's Modula compiler. Really >the mark of a C bigot, eh? >(*f-*) This whole business of "flaming" is ludicrous. People, realize that in the "World of the Net" we cannot read a persons intentions as well as we could if we were face to face or even over the phone. Almost *every* "flame" posted is due to "a failure to communicate". Of course, some postings are outright stupid, and certain people feel it necessary to "flame" the poor uninformed poster of his or her mental deficiencies. We need a better protocol to deal with this problem. The solution is simple: Ban the "flame". Instead, try to find out what the other person really is trying to say. If they are outright obnoxious or irrational, don't waste your time "flaming" them. If they are simply wrong, tactfully point out the correct solution. But most importantly, don't get personal. It's simply not necessary. "Flame" induced message propagation greatly increases the noise on the net. Simply don't spread the "flame"... I use UseNet to give help and get information for the Amiga computer. I do not intentionally insult or "flame" anyone. My purpose here is to inform and learn. I believe that one resorts to "flaming" when her or she is no longer able to logically discuss the issues at hand and lets emotion take over. Lets work together for constuctive ends, not against each other with destructive results. A final word about Modula-2 and C: I'm not trying to convert anyone to anything, I'm just informing others of what many of us believe is the best knowledge available for tools on the Amiga. We simply state the facts, and if that leads some readers to believe that we are a bunch of "converters" (ie, "Computer Evangelists"), I hereby clarify the issue by stating that this is not our intentions. John
haitex@pnet01.cts.com (Wade Bickel) (03/11/88)
peter@nuchat.UUCP (Peter da Silva) writes: >In article <813@sdcc8.ucsd.EDU>, cs178abu@sdcc8.ucsd.EDU (John Schultz) writes: >> Seems like first impressions have lasting consequences on >> programmers... > >I don't know why you'd say that. My first modern language was Pascal, >and I spent months making a nuisance of myself at Berkeley telling all >who tried to tell me that 'C' had any advantages that 'C' was a horrid >kludge. > >> Peter, I'm curious, how would one implement a nested WITH in C? > >You mean: > WITH shrimpboat DO > WITH launchdate DO > mm := 9; > ... > END (* with launchdate *); > END (* with shrimpboat *); > >I'd do this: > { register struct trawler *t = shrimpboat; > { register struct date *d = t->launchdate; > d->mm = 9; > ... > } > } > >Or this: > ># define T shrimpboat ># define D T.launchdate > D.mm = 9; ># undef D ># undef T > >WITH is just a notational convenience. The implication in the reference I'm >using is that the actual implementation is more likely to be like my first >alternative ("Improved efficiency results from this rule, because the compiler >need only evaluate the WITH variable once.") > >> Oh, and another thing, let's say , for the sake of argument, that C >> in it's present state, is superior to all other languages > >I never said this, but go on. > >> (including M2), as a language definition. Enter Joe Blow, who can >> produce 10000 lines of code in TS 27 (Taco Sauce 27, a fictitious >> language), the worst language definition. > >So let him use it. I'm not suggesting that people change from Modula to >C, or from Pascal to C. I'm just explaining why I like 'C'. > >> Joe's friends persuaded >> him to try C. It took him twice as long to produce the same code, >> which doesn't run any faster. > >That's two unjustified assumptions in one sentence. > >> Now, should we force Joe to use C anyway? > >Of course not. > >> The point is, it's >> pointerless to try to typecast a hardcore C programmer into M2 or >> any other language. So use what works best for you own personal >> brain (of course, you will!). > >(*f+ (turn on flamethrower) *) >I think you have quite a bit of gall to post a series of messages that >look a lot like you're trying to convert me to Modula, and then act as if >I'm the one doing the preaching. In fact, this whole discussion (if I recall >correctly) started when I championed someone else's Modula compiler. Really >the mark of a C bigot, eh? >(*f-*) > >> Is *anyone* going to be persuaded to switch languages? > >Nor, it appears, compilers. >-- >-- a clone of Peter (have you hugged your wolf today) da Silva `-_-' >-- normally ...!hoptoad!academ!uhnix1!sugar!peter U >-- Disclaimer: These aren't mere opinions... these are *values*. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
papa@pollux.usc.edu (Marco Papa) (03/12/88)
In article <2652@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > I noticed you left out my references to Modula-2's seperate > compilation facilities. This is feature C clearly cannot match. > Seperate compiliation in C requires programmer attention to a > tremendously higher degree than in Modula-2. ALL my programs use ^^^^^^^^^^^^ > seperate compilation. It's almost as easy as useing #include. I would definitely have to disagree on this one. Separate compilation in C does NOT require a "tremendously high degree" of programmer attention. It just requires MAKE and LINT. MAKE is available in both public domain on the Fish Disks, and it is provided with both MANX and LATTICE. Amiga Lint has been available for over 2 years I believe, and MANX, for example, provides header files so that all of the Amiga and MANX libraries can be type-checked. A-Talk III consists of over 65 separately-compiled files, and 1 Makefile. Coming from an UNIX background, with both Lattice and MANX + Make + Lint, I had no problem in switching to doing "separate compilation" on the Amiga. I just did it the SAME way as under UNIX. And I believe I am not such a hot shot programmer :-) The makefile I have can create 3 different executables (A-TALK III, Digi-Weather and an "unnamed" Tek 4105 emulator) which share lots of files between them. I just have to say "make atalk", "make "digi", or "make tek". The same for lint. Setting up the makefile was just straightforward. In fact I NEVER read the MANX manual for their Make. I just set it up the way I knew it from UNIX. While not everybody has a UNIX background, rules for Makefiles don't seem to be such a "tremendous" problem to me. -- Marco
haitex@pnet01.cts.com (Wade Bickel) (03/13/88)
papa@pollux.usc.edu (Marco Papa) writes: >In article <2652@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >> I noticed you left out my references to Modula-2's seperate >> compilation facilities. This is feature C clearly cannot match. >> Seperate compiliation in C requires programmer attention to a >> tremendously higher degree than in Modula-2. ALL my programs use > ^^^^^^^^^^^^ >> seperate compilation. It's almost as easy as useing #include. > >I would definitely have to disagree on this one. Separate compilation in >C does NOT require a "tremendously high degree" of programmer attention. > >It just requires MAKE and LINT. MAKE is available in both public domain >on the Fish Disks, and it is provided with both MANX and LATTICE. Amiga >Lint has been available for over 2 years I believe, and MANX, for example, >provides header files so that all of the Amiga and MANX libraries can be >type-checked. ... >I just set it up the way I knew it from UNIX. While not everybody >has a UNIX background, rules for Makefiles don't seem to be such a >"tremendous" problem to me. > None-the-less that is tremendously more difficult than doing so in M2. All you do in M2 is cut the headers of the procedures you wish to have be public from your .mod modules into their corresponding .def modules, refrence them, and thats it. Same for data or types. When I first utilized this facility I had no documentation at all describing how to do it (I had no books on M2), only examples. It takes only a minute or two to figure out{{_xj6'C|fV$ut, with no background at all! Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
ross@swan.ulowell.edu (Ross Miller) (03/15/88)
In article <2652@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: ... lots of religious (my compiler is better than yours deleted ). > I noticed you left out my references to Modula-2's seperate > compilation facilities. This is feature C clearly cannot match. > Seperate compiliation in C requires programmer attention to a > tremendously higher degree than in Modula-2. ALL my programs use > seperate compilation. It's almost as easy as useing #include. I can't let this stand. I had the joy of taking a working 800 line C program and porting it to a Modula-II. Two weeks later, the C program took 2 days to write, and 1200 lines I had it working in Modula-II. Most of that time was spent with dealing with the seperate compilation facilities. In C you write your routine and link. In M-II you need definition and implementation modules. This takes time to write and is a pain. Not to mention if you get a garbage Modula compiler and it does things like truncates these module names to 12 characters, or enforces that module names match file names. Good compilers won't do this, but the problem does exist in some. Modula's seperate compilation facilities, or modules, rot. They are simple, but annoying and tedious. I don't need to waste my time on data protection for small projects that suit C well, and I will use Ada if forced into an Algol upgrade that requires packages or modules. Ross -- csnet: ross@swan.ulowell.edu uucp: ross@swan.ulowell.edu || ...harvard!ulowell!ross Trust the computer. The computer is your friend.
pds@quintus.UUCP (Peter Schachte) (03/15/88)
This modula-2 vs. C discussion is interesting. For those of us who see both sides and are deciding which compiler to use for our next project, it would be helpful to see a comparison of EXECUTION speed between benchmark and manx or lattice (or both). Particularly interesting would be modula implementations of drystone (sp?), seive, and the other tests lattice uses in their comparisons with manx. Has anybody done this? Would anybody who has benchmark be willing to do a few comparisons? Also, does benchmark modula-2 have some sort of macros? Either lexical macros like C has, or inline procedures? -- -Peter Schachte pds@quintus.uucp ...!sun!quintus!pds
haitex@pnet01.cts.com (Wade Bickel) (03/17/88)
ross@swan.ulowell.edu (Ross Miller) writes: >In article <2652@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: > >... lots of religious (my compiler is better than yours deleted ). >> I noticed you left out my references to Modula-2's seperate >> compilation facilities. This is feature C clearly cannot match. >> Seperate compiliation in C requires programmer attention to a >> tremendously higher degree than in Modula-2. ALL my programs use >> seperate compilation. It's almost as easy as useing #include. > >I can't let this stand. I had the joy of taking a working 800 line C >program and porting it to a Modula-II. Two weeks later, the C program >took 2 days to write, and 1200 lines I had it working in Modula-II. >Most of that time was spent with dealing with the seperate compilation >facilities. In C you write your routine and link. In M-II you need >definition and implementation modules. This takes time to write and >is a pain. Not to mention if you get a garbage Modula compiler and >it does things like truncates these module names to 12 characters, or >enforces that module names match file names. Good compilers won't do >this, but the problem does exist in some. > Modula's seperate compilation facilities, or modules, rot. They >are simple, but annoying and tedious. I don't need to waste my time >on data protection for small projects that suit C well, and I will >use Ada if forced into an Algol upgrade that requires packages or Don't blame me because your using a cheapy compiler and don't know what your doing. In Benchmark module names can be any length (or at least VERY big) you please. To create a definition module you just open a second editor window and cut and paste the needed Procedure headers and such to the second file. It couldn't be easier. Now consider the advantages. Once youve set up a .DEF module and compiled it and the rest of your program, you are free to change the code in the .MOD modules without having to recompile any others. If you have 20,000 lines of source, broken into 20 1000 line modules, in most situations you will be able to compile your program 20 times faster than using normal include file methodologies. An 800 line program is not a serious work, and using a weak complier to boot makes your opinion even less meaningfull. Why were you using definition modules at all? The are optional!; Get a copy of Benchmark, learn to use the editor, and READ a quaility text on M2, and you might change your opinion (though I doubt it). Thanks, Wade. UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex ARPA: crash!pnet01!haitex@nosc.mil INET: haitex@pnet01.CTS.COM
peter@nuchat.UUCP (Peter da Silva) (03/19/88)
In article <2688@crash.cts.com>, haitex@pnet01.cts.com (Wade Bickel) writes: > Now consider the advantages. Once youve set up a .DEF module and > compiled it and the rest of your program, you are free to change the code in > the .MOD modules without having to recompile any others. Sounds like ordinary seperate compilation to me. > If you have 20,000 > lines of source, broken into 20 1000 line modules, in most situations you will > be able to compile your program 20 times faster than using normal include file > methodologies. "Normal include file methodologies"? That doesn't make any sense. You have the same functionality in every 'C' compiler I've ever seen or heard of. Perhaps you're thinking of Pascal? Does the Benchmark compiler track changes to the .DEF module and recompile affected modules if you change it? -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
cs178abu@sdcc8.ucsd.EDU (John Schultz) (03/20/88)
In article <821@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: >Does the Benchmark compiler track changes to the .DEF module and recompile >affected modules if you change it? I haven't tried it yet, but I believe that a version key is is checked during compilation (import phase). If the versions don't match, an error message would be generated. That's what happened with TDI, and is part of the Modula-2 lang. def. When a def module is changed, all modules importing that def module must be recompiled, but when the mod module is changed (the actual code; this occurs more often), no recompilation is necessary for other modules. Basically, only variables, types, and procedure prototypes are in the def mods; they aren't changed very often. Looks like a make equivalent would be useful in that case... Do other M2 compilers have that feature? (wouldn't be too hard to do) Actually, the best method would be to recompile the offending modules as they are imported. The user would then need to save those newly modified modules (both defs & mods in some cases) to permanent storage. This could get kind of hairy... How would make handle it? John
peter@nuchat.UUCP (Peter da Silva) (03/23/88)
In article <823@sdcc8.ucsd.EDU>, cs178abu@sdcc8.ucsd.EDU (John Schultz) writes: > In article <821@nuchat.UUCP> peter@nuchat.UUCP (Peter da Silva) writes: > >Does the Benchmark compiler track changes to the .DEF module and recompile > >affected modules if you change it? > I haven't tried it yet, but I believe that a version key is > is checked during compilation (import phase). If the versions don't > match, an error message would be generated. That's what my experience has lead me to believe would be the case, too... > Basically, only variables, types, and procedure prototypes > are in the def mods; they aren't changed very often. Looks like a > make equivalent would be useful in that case... Do other M2 > compilers have that feature? (wouldn't be too hard to do) The .DEF modules are basically the equivalents of the .h files in 'C'. Make supports this: you just set up your makefile dependencies to reflect this. There are tools out there that build the makefile automatically. Suppose you have foo.c, foo.h, and bar.c. foo.h contains the defines for foo.c. The way I generally do this is like so: ---------- foo.h #ifndef GLOBAL #define GLOBAL extern #endif GLOBAL int var1, var2, var3; GLOBAL char *var4; GLOBAL int func1(); GLOBAL char *func2(); ---------- foo.c #include <stdio.h> #include <other.h> #define GLOBAL #include "foo.h" ... ---------- bar.c #include <stdio.h> #include <somthing.h> #include "foo.h" ... ---------- Makefile foo: foo.o bar.o ln -o foo foo.o bar.o foo.c: foo.h bar.c: foo.h ---------- This takes a bit more setup, but it does make sure everything's synched. And you only have to set this stuff up once. If I change foo.c, and I don't change foo.h, I'll get a type-clash or an undefined variable if the change to foo.c requires a change in foo.h. Most of the time nothing is needed: how often do you change your interfaces? If I change foo.h, then both foo.c and bar.c get recompiled automatically. I can forget about the dependencies once I have set them up. Most of the time the change is in a structure, and nothing needs to be done to bar.c except recompile to get the offsets right. > Actually, the best method would be to recompile the offending > modules as they are imported. The user would then need to save those > newly modified modules (both defs & mods in some cases) to permanent > storage. This could get kind of hairy... How would make handle it? See above. Since everythings in permanent storage most of the time there's no problem. You probably lose some speed that way, but you gain from not having to hold your compilers hand when you cross the street :->. I believe that Markus is working on something like this for M2Amiga. -- -- a clone of Peter (have you hugged your wolf today) da Silva `-_-' -- normally ...!hoptoad!academ!uhnix1!sugar!peter U -- Disclaimer: These aren't mere opinions... these are *values*.
ncreed@ndsuvax.UUCP (Walter Reed) (04/02/88)
In article <2642@crash.cts.com> haitex@pnet01.cts.com (Wade Bickel) writes: >duncanj@umd5.umd.edu (James Duncan) writes: >> >>What about those people FORCED to use Pascal for academic reasons. >>Say your in a class and are permitted to use any computer but MUST >>program in Pascal! Gee sorry Prof., but real programmers use C. >>Sorry no-name generic student but real students program in Pascal or >>they don't get a real grade in my all too real class. I had the same problem in some of my classes... >> >>Pascal is the de facto academic language. With the emphasis on personal >>computers these days often students are allowed to use any PC, but due to >>grading standardization the students are required to program in Pascal. >> >> Jim Duncan > > You should see if your Prof. will allow you to use Modula-2. > Modula-2 is the successor language to PASCAL. Both were created by >Niklaus Wirth. M2 is the derivative of Modual{-1} and PASCAL. Modula was a >systems programming language. The result is a language which gives you all >the niceities of PASCAL (well, most of them :^>), and the low level access >PASCAL denied (which forced us to go to C, or assembly). > M2 is *VERY* similar to PASCAL, so for grading purposes it should not > be a burdon to the graders. I can't see any reason a Prof. in his >right mind would not encourage using M2, as it is a vibrant language, whereas >PASCAL is a dead one :^>. > Wade. There are two major beefs I have with modula-2. 1. Modula does not allow a variable number of parameters in function calls. 2. Bitwise operators are not available (at least not standard.) Minor beef: Begin end's required even when only one statment used. Here is an example of why these things bother me. Pascal: If (x = True) Then WriteLn('Error #',e,' in line #',l,' detected.'); Modula-2: IF (x = TRUE) THEN WriteString("Error #"); WriteCard(e); WriteString(" in line #"); WriteCard(l); WriteString(" detected."); END; M2 is too verbose. Now, Modula 2 could be fixed, and should be fixed. Not having a variable number of parameters makes compiler writing simpler, but makes writing programs harder, and more time consuming. It may make debugging easier though. Now, modula-2 and pascal are both missing bit-wise manipulators. What is needed: BAND bitwise and BOR bitwise or BXOR bitwise xor BSHL function to shift bits left (returns the shifted number) BSHR function to shift bits right That helps alot. I had to write a microproccessor simulator in modula-2, and the lack of bitwise operators made my life a living hell (along with the problem of not having a variable number of parameters.) Fix these design flaws and allow single statements to be written easier and the language may even be usable. Hell, I may even use it! Borland could fix modula-2 like they fixed pascal. Modula-2 should never be forced upon students, it's inhumane. -- /* Walter Reed UUCP : uunet!ndsuvax!ncreed Internet : ncreed%NDSUVAX.BITNET@CUNYVM.CUNY.EDU Ph 701-235-0774 Bitnet : ncreed@ndsuvax OR NU105451@NDSUVM1 ------------------- */
hcmutt@hpcllld.HP.COM (Harry Muttart) (04/05/88)
Modula-2...no bitwise operators? Most implementations allow you to define
sets to be whatever word size you are working with. Then the set operations
can be used and correspond (pretty well) to the operators you seek.
I can see where you might miss WRITELN, tho'
Harry Muttart (* M2 hobbiest/programmer on Amiga (hah) *)
(* I tend to follow rules...M2 helps me *)