Path: utzoo!attcan!uunet!super!udel!princeton!njin!rutgers!psuvax1!psuvm.bitnet!
cunyvm.bitnet!l30cc
From: L3...@CUNYVM.CUNY.EDU
Newsgroups: comp.sys.amiga,comp.sys.amiga.tech
Subject: Need recommendation on Modula-2 compiler
Message-ID: <1801L30CC@CUNYVM>
Date: 16 Dec 88 03:35:19 GMT
Followup-To: comp.sys.amiga
Organization: The City University of New York - New York, NY
Lines: 14
DISCLAIMER: Author bears full responsibility for contents of this article
Hello all, can someone please recommend a good Modula-2 compiler for the
Amiga? I need it for an upcoming Pascal data structures class. Am I correct
in assuming that Modula-2 is a super-set of Pascal and that standard Pascal
source will compile under a Modula-2 compiler w/o any modifications?
- krb -
#! rnews
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!
bu-cs!purdue!decwrl!sun!pitstop!sundc!seismo!uunet!portal!cup.portal.com!dan-hankins
From: dan-hank...@cup.portal.com (Daniel B Hankins)
Newsgroups: comp.sys.amiga
Subject: Re: Need recommendation on Modula-2 compiler
Message-ID: <12749@cup.portal.com>
Date: 18 Dec 88 20:47:01 GMT
References: <1801L30CC@CUNYVM>
Organization: The Portal System (TM)
Lines: 38
In article <1801L30CC@CUNYVM> L3...@CUNYVM.CUNY.EDU (krb) writes:
>Hello all, can someone please recommend a good Modula-2 compiler for the
>Amiga?
There are three available. Which one you choose should depend on what you
like.
I have TDI Modula-2. I think it is fine, when combined with a
public-domain utility that gives simple error message formatting, instead
of forcing you to use TDI's integrated editor.
I like TDI because it is *NOT* an integrated package. It is more like a
component system. I am free to use whatever editor I like, and glue it
together with TDI M2 by means of ARexx (if I ever get around to getting
ARexx).
I can't really speak for the others, but there was a recent issue of
AmigaWorld that reviewed all three.
>Am I correct in assuming that Modula-2 is a super-set of Pascal and that
>standard Pascal source will compile under a Modula-2 compiler w/o any
>modifications?
'Fraid not. However, the conversion should not be difficult. A good book
with which to learn Modula-2 is "Modula-2 Wizard: A Programmer's Reference"
by Richard S. Wiener. It is published by John Wiley and Sons.
The syntax is somewhat different; more sensible. The standard libraries
have to be imported. They are not part of the language definition. Things
like Readln, Writeln, and so on have been moved into standard libraries
(with name changes). Also, the language is case-sensitive and all reserved
words must be in upper case.
So there are some differences.
Dan Hankins
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!
nth!loyd
From: l...@nth.UUCP (Loyd Blankenship)
Newsgroups: comp.sys.amiga
Subject: Re: Need recommendation on Modula-2 compiler
Summary: !tdi
Message-ID: <403@nth.UUCP>
Date: 24 Dec 88 23:11:41 GMT
References: <2058@van-bc.UUCP>
Organization: Nth Graphics, Ltd., Austin, TX
Lines: 38
I spent 6 months trying to do something useful with TDI's compiler, and I
will unequivicobly give it my Worst-Product-Of-All-Time award.
1) The editor eats 50K of RAM every time it is invoked. The only way to
recover the RAM is rebooting.
2) The editor sometimes finds errors, and sometimes doesn't. Completely
random in functionality.
3) The example code given (the BOX code specifically) does not compile. De-
bugging is left as an excercise to the purchaser.
4) In the definition files, several variables and types are defined wrong.
It's been long enough that I don't remember specific examples.
5) The documentation is the worst collection of vauge and misleading statements
it's ever been my misfortune to wade through.
6) The index is wrong about 25% of the time.
7) Customer support is non-existant. When you call on the phone (I tried both
the UK & the US phone #'s), the person who knows anything about it is
'not available', and not *once* in over 20 attempts did anyone ever
return my call.
I was using the expensive 'Professional' version of the thing, too!
I finally just bit the bullet, considered it $225 down the tube, and
bought the Lattice C Professional kit. I am so much happier with it I am
like a new man! I don't know anything about Benchmark Modula-2, and wasn't
willing to risk another couple hundred dollars on an unknown product. Lattice
is a fantastic product, they have good customer support, and if you aren't
dead set to work in Modula-2, I'd recommend you go with Lattice.
Loyd Blankenship cs.utexas.edu!nth!loyd (UUCP)
Nth Graphics Ltd. Austin, TX 78758 w: 512-832-1944
h: 512-441-2916
Disc: It's my opinion, not theirs...
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!
pasteur!agate!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!portal!cup.portal.com!
dan-hankins
From: dan-hank...@cup.portal.com (Daniel B Hankins)
Newsgroups: comp.sys.amiga
Subject: Re: Need recommendation on Modula-2 compiler
Message-ID: <13030@cup.portal.com>
Date: 29 Dec 88 06:38:23 GMT
References: <2058@van-bc.UUCP> <403@nth.UUCP>
Organization: The Portal System (TM)
Lines: 59
In article <4...@nth.UUCP> l...@nth.UUCP (Loyd Blankenship) writes a
scathing criticism of TDI's compiler.
Personally, I don't think that it's that bad. I've successfully
written a modestly sized program in it without too many problems. I'm now
in the process of writing an interpreter for an object-oriented language in
it (not a small project). Here's some answers to his points:
>1) The editor eats 50K of RAM every time it is invoked. The only way to
> recover the RAM is rebooting.
Their editor is lousy anyway. Don't use it. MG or DME or just about
any other editor is superior. MG in particular has the capability to be
customized to be syntax-sensitive.
>2) The editor sometimes finds errors, and sometimes doesn't. Completely
> random in functionality.
Again, don't use TDI's editor. Use the public domain program m2error
(available on Fish) which will invariably give the correct error code and
location.
>3) The example code given (the BOX code specifically) does not compile.
> Debugging is left as an excercise to the purchaser.
I won't argue with you here. I don't know, myself. In my book,
compiling example code is usually a waste of time, unless it does something
in particular that you need.
>4) In the definition files, several variables and types are defined wrong.
> It's been long enough that I don't remember specific examples.
Again, no argument. I haven't personally encountered any of these.
Is this in the documentation, or on the files actually provided on the
disks? I haven't yet encountered any errors in the files provided on the
disks. If the definition file is wrong, well then I would just use DecSym
to generate one from the .sym file. Haven't had a need to try that yet, so
it may not work.
>5) The documentation is the worst collection of vauge and misleading
> statements it's ever been my misfortune to wade through.
I must have backlevel documentation. Mine is fairly short, clear, and
concise.
>6) The index is wrong about 25% of the time.
You mean you don't grep the .def files on the distribution disks?
>7) Customer support is non-existant. When you call on the phone (I tried
> both the UK & the US phone #'s), the person who knows anything about it
> is 'not available', and not *once* in over 20 attempts did anyone ever
> return my call.
I haven't needed this yet, so I wouldn't know. I get most of my
support from other users, when necessary.
Dan Hankins
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cs.utexas.edu!
nth!loyd
From: l...@nth.UUCP (Loyd Blankenship)
Newsgroups: comp.sys.amiga
Subject: Re: Need recommendation on Modula-2 compiler
Summary: get real
Message-ID: <406@nth.UUCP>
Date: 27 Dec 88 00:12:25 GMT
References: <2058@van-bc.UUCP> <403@nth.UUCP> <13030@cup.portal.com>
Organization: Nth Graphics, Ltd., Austin, TX
Lines: 102
In article <13...@cup.portal.com>, dan-hank...@cup.portal.com (Daniel B Hankins)
writes:
>In article <4...@nth.UUCP> l...@nth.UUCP (Loyd Blankenship) writes a
>scathing criticism of TDI's compiler.
>
> Personally, I don't think that it's that bad. I've successfully
>written a modestly sized program in it without too many problems. I'm now
>in the process of writing an interpreter for an object-oriented language in
>it (not a small project). Here's some answers to his points:
>
>>1) The editor eats 50K of RAM every time it is invoked. The only way to
>> recover the RAM is rebooting.
>
> Their editor is lousy anyway. Don't use it. MG or DME or just about
>any other editor is superior. MG in particular has the capability to be
>customized to be syntax-sensitive.
>
>>2) The editor sometimes finds errors, and sometimes doesn't. Completely
>> random in functionality.
>
> Again, don't use TDI's editor. Use the public domain program m2error
>(available on Fish) which will invariably give the correct error code and
>location.
Hmmmmm. So if I buy a car and the engine doesn't work, your suggestion
to stop whining about the crappy engine that came with the car and put in
a *real* engine, right?
>>3) The example code given (the BOX code specifically) does not compile.
>> Debugging is left as an excercise to the purchaser.
>
> I won't argue with you here. I don't know, myself. In my book,
>compiling example code is usually a waste of time, unless it does something
>in particular that you need.
But Dan, if you provide someone with example code that won't compile,
that probably means that there's an error in it somewhere (or an error in the
compiler- 50/50 either way with TDI.) What's the bleedin' point of providing
non-working example code? "Here's some code that kinda might work, we aren't
sure, but take a look at it, and if you fix it up, let us know."
>>4) In the definition files, several variables and types are defined wrong.
>> It's been long enough that I don't remember specific examples.
>
> Again, no argument. I haven't personally encountered any of these.
>Is this in the documentation, or on the files actually provided on the
>disks? I haven't yet encountered any errors in the files provided on the
>disks. If the definition file is wrong, well then I would just use DecSym
>to generate one from the .sym file. Haven't had a need to try that yet, so
>it may not work.
The errors were in the documentation. The fact that I could recreate my
own version of the documentation in no way obviates TDI from putting correct
information in the original.
>>5) The documentation is the worst collection of vauge and misleading
>> statements it's ever been my misfortune to wade through.
>
> I must have backlevel documentation. Mine is fairly short, clear, and
>concise.
You must.
>>6) The index is wrong about 25% of the time.
>
> You mean you don't grep the .def files on the distribution disks?
No Dan, I don't. Y'see, I have this little quirk about using a manual to
look something up occasionally, so I expect the index to tell me where to
look. See #4 above.
>>7) Customer support is non-existent. When you call on the phone (I tried
>> both the UK & the US phone #'s), the person who knows anything about it
>> is 'not available', and not *once* in over 20 attempts did anyone ever
>> return my call.
>
> I haven't needed this yet, so I wouldn't know. I get most of my
>support from other users, when necessary.
>
>Dan Hankins
Oh good. How fortunate for the other users.
Dan, why are you making excuses for these weasels? I'm complaining about
an obviously inferior product, and you sit and give me ways to work around
TDI fuckups. The point is, I *SHOULDN'T* have to use another editor, and I
*SHOULDN'T* have to rebuild my own documentation because they were to {lazy|
careless|stupid} to do it correctly. And I certainly shouldn't have to rely
on other users to support a product!
With Lattice, I could actually *USE* the editor that came with the package,
and the documentation was correct and reflected the contents of the manuals!
Wow! What a concept! Plus every question I've ever had was cheerfully and
quickly answered by placing one phone call. And yes, Lattice does return
calls when they say they will.
Loyd Blankenship cs.utexas.edu!nth!loyd (UUCP)
Nth Graphics Ltd
Austin, TX 78758
Disclaimer: These Opinions are Mine. Mine, you hear me? Leave them alone!
Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!cwjcc!hal!
nic.MR.NET!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!portal!cup.portal.com!dan-hankins
From: dan-hank...@cup.portal.com (Daniel B Hankins)
Newsgroups: comp.sys.amiga
Subject: Re: Need recommendation on Modula-2 compiler
Message-ID: <13074@cup.portal.com>
Date: 31 Dec 88 02:19:23 GMT
References: <2058@van-bc.UUCP> <403@nth.UUCP> <13030@cup.portal.com> <406@nth.UUCP>
Organization: The Portal System (TM)
Lines: 75
In article <4...@nth.UUCP> l...@nth.UUCP (Loyd Blankenship) writes:
> Hmmmmm. So if I buy a car and the engine doesn't work, your
>suggestion (is) to stop whining about the crappy engine that came with the
>car and put in a *real* engine, right?
1. I would hardly call the editor the engine of the compiler package. More
like the stereo, if you're going to use the car analogy. Many compiler
packages don't come with an editor at all.
2. If you don't like the crappy car stereo that came with the car, why then
yes you *do* pull it out and replace it with a Blaupunkt or Alpine.
> But Dan, if you provide someone with example code that won't compile,
>that probably means that there's an error in it somewhere (or an error in
>the compiler- 50/50 either way with TDI).
The compiler isn't quite that bad. You were using a bit of hyperbole,
I assume.
> What's the bleedin' point of providing non-working example code?
>"Here's some code that kinda might work, we aren't sure, but take a look
>at it, and if you fix it up, let us know."
What's the point of providing example code at all? I don't see a need
for it.
> The errors were in the documentation. The fact that I could recreate
>my own version of the documentation in no way obviates TDI from putting
>correct information in the original.
Of course not. I'm simply saying that it's not an impassable barrier.
Your comments earlier about giving up gave the impression that it was.
Were it an impassable barrier, I wouldn't have been able to write code with
the package.
>> You mean you don't grep the .def files on the distribution disks?
> No Dan, I don't. Y'see, I have this little quirk about using a manual
>to look something up occasionally, so I expect the index to tell me where
>to look. See #4 above.
Yes, I understand that your standards are higher than mine. I suppose
that after a few years of dealing with IBM's software and documentation
thereof, *anything* looks good.
> Dan, why are you making excuses for these weasels? I'm complaining
>about an obviously inferior product, and you sit and give me ways to work
>around TDI f***ups.
I'm not making excuses for TDI. I'm making constructive suggestions
about how you can make effective use of the package instead of just whining
about it. You have a problem. TDI can't or won't fix it. I will, to the
best of my ability.
I'm not defending them; I'm just attacking you. :-)
I'll be the first to admit that TDI's product is imperfect; hell,
it's pretty lousy. In fact, I just rediscovered my major gripe with it:
the compiler itself won't work on files in RAM:.
But it isn't unusable. I'd rather create a few work arounds than
spend $400 or whatever to go back to a language I really dislike (C, that
is). Or even to spend $200 to move to a different Modula-2 compiler.
>The point is, I *SHOULDN'T* have to use another editor, and I *SHOULDN'T*
>have to rebuild my own documentation because they were too {lazy|
>careless|stupid} to do it correctly. And I certainly shouldn't have to
>rely on other users to support a product!
No, of course you shouldn't. TDI's product certainly leaves something
to be desired in areas that seem to matter to you and to some other people.
But since you paid $200 for it, you might as well get *some* use out of it.
If I can, you can.
There are lots of things in life that one shouldn't have to do, yet
you do have to anyway. Like lock your house to keep things from being
stolen.
Dan Hankins