Path: utzoo!attcan!uunet!decwrl!ucbvax!bloom-beacon!samalone
From: samalone@athena.mit.edu (Stuart A. Malone)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Think Pascal Wishes...?
Message-ID: <1990Sep25.152550.11504@athena.mit.edu>
Date: 25 Sep 90 15:25:50 GMT
References: <4251@husc6.harvard.edu>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: Massachusetts Institute of Technology
Lines: 94

Thank you for asking for our suggestions.  I'm not going to list every feature
I can imagine for THINK Pascal; I'd rather concentrate on the ones that I
believe are practical to implement and immediately useful.  Roughly in order of
increasing difficulty:


* Enable the "Save" command on untitled documents.  Sure, it will behave just
like "Save As...", but at least it will have a command-key equivalent.

* Wrap long lines in the editor.  Preferably, this would be done automatically
to fit the window.  Once this is done, you can eliminate the horizontal
scrollbar to make room for one more line of code.  (Oh, for a large screen!)
I realize that this wouldn't leave room for the stop sign at the bottom of the
window in "Stops In" mode, but I'd rather have the lines wrap than have a cute
icon, and perhaps your designers can come up with some other way to indicate
that the left column is special.

An inferior solution would be to allow the programmer to insert explicit
newlines.

* Make the option double-click trick work with more symbols.  Right now it only
works with procedure and function names, but it should also work with types and
constant names, and maybe even variables (though perhaps it's only practical
with global variables).  My wife was using Just Enough Pascal to refresh her
memory of Pascal and learn about the Macintosh, and was frustrated that most of
the time option double-click failed.

Along the same lines, if the symbol is defined in a library, it would be nice
to indicate which library contains the symbol by hilighting the library in the
Project window.

* Make the debugging environment more like the actual Macintosh environment.
Suspend, resume, and mouseMoved events should be passed through (or emulated)
to the application being debugged, and the mouseRegion and maxSleep arguments
to WaitNextEvent should be handled properly.  As things stand, there are
certain parts of my project that I can only check by building a standalone
application and guessing at the problem when something goes wrong.

* Provide a way (other than inline hexadecimal codes) to call ProcPtrs.  This
would eliminate nearly all the places where I use inline hexadecimal now.  I
think that the best way to accomplish this is to extend Pascal to allow the
programmer to declare procedure and function types, and pointers to these
types.  The procedure and function types would become a legal shorthand for
defining a procedure or function of that type, but could not be used as the
type of a variable or expression.  Types naming pointers to procedures and
functions could be used as variable and expression types, and could also be
used to coerce ProcPtrs to callable procedures.  Here's an example of what I
have in mind:

  TYPE
  { Note that the name "MyFilter" serves only as a placeholder. }
  { It's presence should be optional. }
    FilterProc = FUNCTION MyFilter(theDialog: DialogPtr;
      VAR theEvent: EventRecord; VAR itemHit: integer): boolean;
    FilterProcPtr = ^FilterProc;

  { Here we define a FilterProc function using the previous type declaration. }
  FilterProc FancyFilter;
  VAR
    i, j: integer;
  BEGIN
    i := itemHit;
    ...
  END;

  { Here we declare an argument of type FilterProcPtr, and proceed to call }
  { the function. }
  FUNCTION TestFilter(filter: FilterProcPtr):boolean;
  BEGIN
    ...
    TestFilter := filter^(dialog, event, item);
  END;


* Yes, I would also like to see a source-code control system built into THINK
Pascal.  I use one of these (RCS) on my UNIX machine at work, and it is a
tremendous programming aid.  As far as I can tell, Apple's Projector is only
available as part of MPW, which I use THINK Pascal to avoid.  Also, a built-in
system would undoubtedly be far more convenient to use than a separate
application, and ease-of-use is crucial to the success of a revision-control
system.  I would be satisfied even if it worked only on source files stored in
your proprietary format, which would probably make your job easier.  (After
solving the procedure-level segmentation problem so elegantly in THINK Pascal
3.0, I'm sure your engineers are up to the task of designing the interface to
the revision control system.  I really must praise your team for doing an
excellent job on such a tricky problem.)


I hope that these suggestions are helpful, and I hope they can be implemented.
I would certainly be willing to pay for an update containing these features.
If you have any questions, feel free to send me email.

				--Stuart A. Malone
				samalone@athena.mit.edu