Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!fluke!oophost!bobc
From: bobc@oophost.UUCP (Bob Campbell)
Newsgroups: comp.lang.modula2
Subject: Re: TML M2 system
Message-ID: <309@oophost.UUCP>
Date: 15 Dec 87 01:03:09 GMT
References: <2092@uvacs.CS.VIRGINIA.EDU> <273@dbase.UUCP> <307@oophost.UUCP> <275@dbase.UUCP>
Reply-To: bobc@oophost.UUCP (Bob Campbell)
Distribution: na
Organization: Carl Nelson & Associates Inc.
Lines: 150
Keywords: Modula-2, Macintosh

I should first say that I am the copyright owner of TML Modula-2, and
I have a strong interest in what people think about it.  I am
attempting to present a review of each of the items about my compiler
that have been presented.  I have looked at the code produced by both
TML Modula-2 and SemperSoft Modula-2, as well as the other features of
the langauges, and I feel that while my compiler could be improved
some (and it is being worked on), but it is still as good or better then
the SemperSoft compiler when all things are considered.

Dennis was one of TML Systems beta testers (and a very good one
at that, thank you Dennis).  Keith is was and always will be one
of my primary testers.  (I limit my beta testers because I can't
affort to be sending a lot of disks out.)  I have several other
testers in the seattle area and one in Vancouver BC (that's Canada).
It is up to TML systems to send copies to their beta testers.

I know what kind of code TML Modula-2 generates, and I also
know that the only glue code that exists is for MULTIPLY and
DIVIDE of 32 bit numbers, and a special routine called HALT, 
that is called sometimes for things like reaching the end of a
function with out returning anything.  In addition the JSR
instruction is used for handling case statements.  I don't
think that the "jumbs to glue routines at every turn" is a
valid statement.  There were a few extra MOVE instructions
used in type conversions but these will be taken care of in
the next release (1.3).

TML Modula-2 produces larger applications in many cases because
it uses the same libraies that Apple's C and Pascal compiler use.
The side effect of this is that it is painless to write a
simple application that uses the "InOut", and "Terminal"
modules and convert it into a MPW Tool by only changing the
File Type of the application from APPL to MPST.  Most of this
code is from the fact that TML Modula-2 always calls RTInit,
instead of just calling DataInit, and forcing the user to to
know when RTInit is needed instead.  (I may solve this in 1.3
which is currently in alpha test).

The conversion of TransSkel, was well done but limited in
scope to being a simple port.  I know of many things that can
be done to the sources (for TML Modula-2 at least) that will
make the program smaller and easier to read.

I will concide the point that SemperSoft's compiler is about
3-4% faster, then My compiler, and I don't expect this to last
forever.  The benchmarks that have been done indicate that his
compiler beats my by at most 12%, and my beats his at most by
20% (or more).  These bench marks are subjective and when
writing a macintosh application it is even harder to tell the
difference.

SemperSoft does not support lower case keywords, but it does
have a library of all the routines in lower case.  I
personally feel that case is sensitive, and that the
identifiers could be typed correctly.  For some people I
understand using the shift key is a problem not yet mastered,
and for those people Apple has nicly supplied the canon tool
that will convert the cases to be correct (very easy to use,
but don't used the default dictionary or LONGINT will look
like LongInt).  The rules for spelling names of routines is
very simple, just capitlize the first letter of each new
word (little if any memory work is required my fingers do it
automaticly).  And should I make a mistake I have a command
key to solve the problem:

AddMenu 'Modula' 'Lookup/=' \
	'Search /`cat "{Active}.O-6"`/ \
	{ModLib}MInterfaces.DEFs:O-X.MOD'
It is hard to do a MPW Script in Unix but "\" is really
option-d, "O-6" is option-6, and "O-X" is option-X.  There are
many other ways to do this, but this produces output that can
be selected and executed to open up the file in question and
let me see the actual declaration.

Pascal Strings, well SemperSoft does support pascal strings,
and while I personally don't like Pascal strings (they are far
too limiting for me), he has done a good job of supporting
them.  I would rather support Pascal Strings the way MPW C
supports them (using the \p escape inside of strings).  In
fact there is no real solution to this problem that will
make all factions happy.  In every case I tend towards making
the system as easy to use as possible, and I try to give
information so that more aware people can do things the harder
and faster way.  Also the vast majority of the ToolBox calls
do not need strings or characters as parameters.

The FileManager, well the FileManager is very limited in it's
usefulness.  If you do a Open, followed by a small number of reads
or writes using large buffers then the FileManager is ok,
otherwise it is very slow having the Trap over head for each
read and write.  The Streams module does a reasonable job of
buffering the I/O, and is very easy to use.  There is no reason that a
real macintosh application could not use Streams instead of the
FileManager (if the program uses a lot of File I/O it might run
faster.)

I will never support type-transfer functions other then the
VAL function.  I support Dr. Wirth's current design of the
language, type-transfer functions can cause problem, and
should be clearly marked.  It is not much harder to type
VAL(INTEGER,foo) and if you started doing it instead of just
complaining about it, it would be come just as easy.  I did
not like it at first, but I started using it and it really is
not that hard.  In addition there are a lot of places where
you have to use conversions in MacIntosh Pascal, that Modula-2
does not need.

PR time:  To answer the question "Which one does the best job
of creating real-life Macintosh applications and does it with
the minimum of fuss?"  I feel that TML Modula-2 is a better
choice for the following reasons:

[a]	The interface files for TML Modula-2 are orginized by
	Manager, this means that the interfaces are orginized
	the same way Inside Macintosh orginizes them, it is
	also the same way that MPW C orginizes them.  It is
	also as close as is reasonable to the way other
	Modula-2 compilers like TDI, MacLogicmo (spelling?)
	and MacMETH orginize them.

[b]	I have worked with professional programmers using my
	compiler to support a released product.  I spend a
	lot of time making sure then when I release something
	it will not cause them any problems, this means that I
	take a little bit more time per release, but I think
	that they are well worth the effort.

[c]	I feel (and most people agree) that I have the best
	documentation, and I believe that a product is only as
	good as the manual that you use it with.

[d]	TML Modula-2 supports commando, so you don't have to
	know how what all of the options work.

[e]	TML Modula-2 provides example worksheets that contain
	the instructions for building all of it's examples.
	You can open the file and select the commands and execute
	them with out opening the manual.

[f]	TML Modula-2 provides a set of menu commands that can
	be used from inside MPW for generating Modula-2
	statements like IF, REPEAT, WHILE, CASE, PROCEDURE...

In summary I feel that SemperSoft's compiler is a little better (at
the current time...), but based on my information it is not any easier
to use, it does not have any major features that TML Modula-2 does not
have.  TML Modula-2 does have a number of features that SemperSoft
does not have and I intend to keep it that way.  Mike from SemperSoft
is a good person, and I wish that I was not competing with him, but
since I am, I intend to do a first class job of it.