Feb 86 Letters
Volume Number: 2
Issue Number: 2
Column Tag: Editorial & Letters
Standards Needed in Development Systems 
By Paul F. Snively, MacTutor Contributing Editor
TML Pascal Has The Right Approach
I had a nice long chat with Tom Leonard the other day. Tom, for those of you who
don't know his name yet, is the person behind TML Systems, Inc. who by the time you
read this should be quite famous for something that I have a copy of: The MacLanguage
Series Pascal compiler.
TML Pascal is a native code compiler that, in its release form, will support
compile to assembler source, compile to object code, or compile for syntax check
options. It will also support the easy construction of desk accessories, thanks in large
part to the efforts of MacTutor's own Alan Wootton.
TML Pascal includes licensed copies of the MDS Edit, Link, and RMaker utilities,
allowing easy combination of code generated by any language system that supports the
Consulair file formats. Tom is, as of this writing, negotiating to license Consulair's
new smart linker for distribution with his system. That would be a much appreciated
addition!
Tom has a copy of TMON, which I reviewed in the September issue of MacTutor. I
mentioned Darin Adler's user area to Tom and he was excited about TMON's obvious
power and expandability.
We discussed the possibility of Tom's writing his own user area for TMON, to be
distributed with TML Pascal, which would allow the displaying of the values of all
active local variables, as well as having the ability to refer to the object code by
function or procedure name as opposed to by address (TML Pascal and TMON will
support each other in this anyway; Tom has already, at my urging, implemented a code
labeling feature nearly identical to Lisa Pascal's, which is what TMON's label
recognition capability was intended to support).
There are a number of points to this. The first is that Tom Leonard is a straight
man with a good, solid product that is sorely needed, and he has it at a reasonable price
(the native code compiler, source/object generation, easy desk accessory generation,
real and potential debugger support, and Tom's listening ear all come for a mere
$99.95). The other is a bit more subtle, but at least as important.
Supporting Standards
Tom's product is a classic example of a third-party product that is relying
heavily on standards set by other people (in this case, Consulair). In order for his
system to be functional, let alone flexible, he has to rely on the shifting sands of "what
the developers are using.
Right at the moment, if you want code flexibility, you have to have compatibility
with Consulair's Linker, at least the MDS linker, if not the new smart linker. Now what
about Apple's new heirarchial file structure on the Hard Disk 20? Don't get me wrong
- the Hard Disk 20 and smart linker are both very good, very necessary things, but
they do tend to make life a bit unpredictable for people like Tom Leonard. Worse,
however, would be if no one else adhered to the standard means of generating Macintosh
code.
For non-native-code systems, the standards really don't matter. What Consulair
does with the linker doesn't make a bit of difference to MacFORTH users, for example.
For others, however, it is crucial.
Tom has made a supreme effort to provide a system that will enable you to write
Pascal programs quickly, compile, resource compile, link, and go, and if you want,
include code from other systems, such as MDS. At this point, it looks like he'll succeed,
and greatly.
Give Us Standard File Formats!
So here's the challenge to all of those people who are doing Macintosh native code
development systems: go with the flow, huh? It's nice to think that you have a radically
new, innovative system or what have you, but if you want to maintain flexibility and
portability, give us programmers using your system the ability to link our code with
code from other languages and compile resources that may have been created (at the
source level, anyway) by another system. In the end, we will all benefit.
And to the folks at Consulair: you guys have set a standard, for which you are to
be commended. Now, once you have the major wish lists taken care of - the smart
linker and so forth - how about not making any surprise changes of a drastic nature?
Too often compatibility is lost in this way, and in development tools this can be
disastrous. Please help to keep things on an even keel.
If all developers would just use these standard tools - compiler, assembler,
Consulair smart linker, RMaker (and/or ResEdit), and TMON with customized user
areas for your environment, Mac software development could reach the level of being a
science, which would greatly facilitate speedy Mac applications development.
So, for the moment, a good place to start is with TML Systems, Inc. Pascal
compiler and TMON. For $190.00 (more or less) you will have bought the only native
code Pascal compiler available for the Mac (it does require 512K, by the way) and
simply the best monitor/debugger available for the Mac, bar none. Add Darin Adler's
user area and call Tom Leonard and let him know that you support his efforts to
integrate TML Pascal with TMON's debugging capabilites and that you would be very
interested in a TML Pascal oriented user area.
Well, I'll get off of my soapbox now. Thanks for listening, and let's keep
development tools standard and, hopefully, working together, rather than working at
cross-purposes.
Enjoy,
Paul F. Snively
Apple, Are You Listening?
May I add that we wish Apple would also support what in reality is their own
creation; i.e., the ".REL" file format standard they helped to create! We encourage Apple
to make their new development system compatibile with the currently accepted object
code format, rather than once again force everyone to chose between the MDS/Consulair
format and whatever new format Apple is rumored to be coming up with. Macintosh
software has proven that well defined tools compatibile with each other are much more
flexibile and desirable than one giant integrated tool with many built-in functions, but
incompatibile with anyone. We simply want this fact to be accepted in the world of
development tools also. We encourage the support of a standard ".REL" file format so
that all development languages may be linked together under one linker. We look for the
day when this goal is achieved.
Blake Miller
Birmingham, AL
As with many of your readers, I too am terribly impressed by your publication. I
recently subscribed in October. It was not two weeks after I sent in the check that I got
my first issue! Many thanks. I am still waiting on the other publications, who received
checks at the same time as you.
I very much liked the October 1985's C workshop article on Networking. I am
interested in writing an AppleTalk-implementing game of some sort. Besides the
excellent in depth coverage, what caught my attention were the subtopic headings. The
very first one said "What Apple Doesn't tell you!" Myself, through experience, have
found it more aptly put "What Apple Won't Tell You!
As different compiler products are used for any given language, I would
appreciate it if your editorials would, at the beginning of each article, write which
company's compiler is being used for the current discussion. Case in point (no, I'm not
a lawyer): I was reading the FORTRAN articles and was not aware that Microsoft had
bought out Absoft. [Actually, they are only distributing the Absoft Product -Ed.] I was
confused for some time as to which FORTRAN development system was being addressed!
Moreover, include the version number, as significant changes can be
incorporated into later versions (ergo Consulair C). I think that this relevant
information would fit nicely into the article's main header.
I cast my vote for a standard ".REL" file format. I have recently read that Apple
plans to market a "new" development system which will incorporate Pascal, C, and
Assembler. In my case, they are a 'Day late and going to be dollars short', for I have
already purchased the Consulair Mac C 4.0 and the TML Systems Pascal to do just this
kind of development. While Apple may provide it all in one coherent package, I feel they
will be making a mistake if it does not conform to this "standard".
[We comletely agree, and thank you for the suggestions. We are looking into
them. -Ed]
One Year Anniversary!
David Tilley
Durham, NC
Thanks for a year full of news and essential technical info! Also congrats on your
1-year anniversary! I'm writing to renew my subscription (it dies soon, sniff.) Since
you guys don't have subscription-date-deaths printed on your labels, I hope everyone
remembers to re-subscribe! Anyhow, sign me up for another year!
[We don't use a subscription service. Instead, we use the Macintosh! We hope to
implement "death-date" stamping as soon as we convert our subscription lists from the
perfectly awful Mail Manager to the perfectly wonderful File Maker. We do send out a
renew notice however. -Ed]
What I Like
Bill Murray
Action, MA
You have a great publication. Keep up the good work. Keep up the assembler,
Pascal and Advanced Mac'ing. I'd like to see even more here. How about adding a
quickdraw section (tricks...). Oh, yes, I'd like to subscribe! [We are starting coverage
of Postscript, which has wonderful graphics capability far exceeding quickdraw. -Ed.]
Steve Brecher Fan
Denis Stanton
East Sussex, England
Your letters, Ask Prof Mac and in particular the Mousehole Report columns are a
vital source of news (and rumor) to me as Apple UK is very slow to announce anything
to users ehre. Steve Brecher's Preview of HFS was fascinating and very timely with
Apple at last joining in the hard disk market. I'm having an arguement with a friend
here about whether the Macintosh HD-20 is actually a MacBottom as was predicted
some time ago. Do you know? [Yes I know and no it is not! -Ed]
In the August Mousehole Don L advised how to get hold of a Journal driver from a
guided tour disk using ResEdit. Is this the same as REdit? [No, REdit 1.0 is the
European resource editor that made it out of Apple via their European Sales office.
ResEdit is the original resource editor that has remained in it's "engineering release
state while continuing to undergo slow development through various pre-release
versions. It is available on source code disk #6. -Ed.]
Still no sign of Chris Derossi in the Pascal column? Alan Wootton continues to
write about interesting things, but I've gotten a bit frustrated with keying them in only
to be greeted with "Sorry, out of memory". There are still some of us out here who
can't afford the 128K to 512K upgrade until the machine starts earning, and can't earn
until they upgrade! I envy you some of the prices I see. I hear Apple has cut the US price
of a LaserWriter from $6995 to $5995. Here in England it's recently been cut by
L1000 to L5995 ($8,812!)
[ I'm afraid very little will be possible on 128K Macs shortly, if not already.
Better bite the bullet and upgrade. We're already talking Mac+ upgrades over here to
1Meg! -Ed.]
Lisp and AI Please!
Bill Brayman
Bellevue, WA
Your mag is great. Keep it up. Particularly, keep the Lisp articles (I have Exper
Lisp). Even more on Lisp or other artificial Intelligence topics would be appreciated.
Also I'd like to see more expert opinion on the 1-2 meg memory upgrades; which
ones are good, Mac+ problems, and Apple warranty.
[Thank You. Andy Cohen will be greatly encouraged. On memory upgrades, I
personally use The MAX 1.5 Meg upgrade as a RAM disk and it works great. However,
there is a rumor that none of the odd size upgrades will work under HFS and the new
ROMS so I advise you not to purchase anything until the situation clears. -Ed]
Referenced by (2):