[net.micro.atari] Modula-2 for the 520 ST

mccamy@lymph.DEC (02/01/86)

From: "...decvax!decwrl!rhea!Squirt!McCamy"


I just picked up Modula-2 by TDI and I'm very excited about
it from my first impression!  I got it at Instant Software
in the Nashua Mall here in New Hampshire for $69.95.

It's about time somebody (namely Dr. Niklaus Wirth) put 
together a program development language that makes good
sense!  This language is what I've only dreamed about
in the past.  It's structured programming at it's finest.

Unfortunately for me, I don't have the development package
from Atari, and therfore will be fumbling for a while until
I can understand the AES and VDI interfaces.

Is anyone aware of documentation that exists or may come
out soon on the AES and VDI interfaces?

I highly recommend Modula-2 for anyone who really wants fast
executable code and wants to harness the power of the 68000.

It's a GEM of a product, and well WIRTH the price!

bammi@cwruecmp.UUCP (Jwahar R. Bammi) (02/02/86)

> 
> From: "...decvax!decwrl!rhea!Squirt!McCamy"
......

> It's a GEM of a product, and well WIRTH the price!

I agree with the above article, it is a GEM of a product and well
WIRTH the price etc. However I have the following concerns:

1) The user interface of the compiler SUCKS (please excuse my french -
or is it american -:). Why? Firstly you cannot call up the compiler
from a command line, you have to use the desk top (this is probably
due to gem and not the compiler, but they could have provided two fron
ends). Secondly, your default drive has to be the one containing the
compiler which has some overlay files. In addition all the .SYM files
required by the program have to be on the default disk, you cannot
specify a path for them. You can run the compiler, and it will let you
answer dialogues so that it finds them somewhere else, but it takes
all day to answer the dialog and compile. If your source file is not
there in the default directory, you have to do a lot of work just to
specify the file name to the file dialog (again a problem with gem ,
but the compiler fron end could prompt for a simple file name, sort
of like ttp). Third, compiler options have to be given as comments in
the source code, which means that if you want to change some options
you have to go re-edit your program (the options provided are pretty
useless in any case for majority of the programs). It all boils down
to how they have used the Gem interface. The interface is getting in
the way of using the otherwise excellent product. A .TTP kind of
interface would have been mich nicer for the way they have used it. It
would have been much nicer, if they would have used the gem interface
in the following manner - the files menu would let you specify which
file(s) you want to compile, giving you a dialog to enter the file
names. The file menu has a selection for compile, quit etc, which
allows you the flexibility to compile another file. The option menu
lets you select compiler options and so on. This would of course mean
a lot of shuffling between the mouse and keyboard, so i would prefer
just a simple command line interface, which can be also invoked from
the desktop in a .TTP fashion if you so prefer.

2) Errors: The compiler generates an error file, which contains a
bunch of numbers, which only the editor supplied can understand. This
is fine if you want to use their editor (that lets you go to the next
error), but what if you do not want to use their editor? Why could it
not generate a human readable error file too (or may be a compiler
option). ?

3) Editor: really slow, very simple minded, has lots of useless menu
selections (like under the move menu, it has a selections for line
up/down. There are alternate key binding for these functions, so it is
not too bad, but this spce could be used much for effectively  to
privide functions that make sence to have in a menu. It looks like
they put up menus just for the sake of having them, and did not
consider their utility at all).

4) Linker: The biggest short coming in the whole system is that the
compiler produces its own format (.LNK) object files. The linker will
only understand .LNK files. This means that implementation modules
HAVE to be written in modula. To my mind this is totally RIDICULAS
(sp?), modula is not the ideal language for all the things you want to
do at the implementation level, though it is great for specifying the
interface and dealing with say the object at the higher levels.
Again like the compiler it is really painful, when your .LNK file is
not in the current directory to specify another one.

5) Library: Xbios and Bios interfaces are missing. There are no
routines for LONGINT LONGCARD i/o.

	Note that i am mainly complaining about the interface, and not
the compiler itself. How do others feel about the interface. The only
serious complaint about the compiler is not being able to write
implementation modules in other languages, which kind of ailienates
modula from rest of the languages and useful libraries in the system.

	As far as I am concerned PASCAL is DEAD (finally, good
riddance..)






-- 
					Jwahar R. Bammi
			       Usenet:  .....!decvax!cwruecmp!bammi
			        CSnet:  bammi@case
				 Arpa:  bammi%case@csnet-relay
			   CompuServe:  71515,155