Date   : Wed, 18 Feb 1987 11:37:00 EST
From   : "John S. Fisher" <FISHER@rpicicge>
Subject: Response to Chris Gray's request for Draco feedback

In experience with Draco has been generally good--it has performed mostly
as described.  For the most part, it is a nice programming language.
I became interested in Draco because I have an application written in
FORTRAN that I want to release to the PD libraries.  It's a full screen
data entry/analysis type program that would be generally useful only if
terminal independent.  The Draco crt.lib looked promising.  In porting
that application, though, I have encountered a few shortcomings of
the package that I will share:
 
(1)  The compiler generates bad code for read(ptr*) if ptr is of type
     *ulong.  It adds an extra POP H / MOV M,E / INC H / MOV M,E that
     just doesn't belong there.  read(ulong), however, works fine.
 
(2)  In my application, most of the logic is decision table based.
     A GOTO would be damn convenient.  The While-loop and if-nests
     I'm forced to use now are quite overwhelming.
 
(3)  The lack of support for formatted input was a mistake.  Fixed
     format input does not belong in the stone ages; it is very
     appropriate for reading machine-generated data.
 
(4)  At one point I could have really used a floating type.  The
     compiler knows about float, but the run-time library does not.
     Can documentation be released about the internal representation
     of float and procedure linkage so we can develop our own float
     support?
 
(5)  BIGDRACO requires a 60K TPA, but does not check to see if it
     has it.  I have a 59K TPA (alas).
 
(6)  Is an open() to either a procedure or *char string cheap or
     expensive?  I need internal char -> number -> char conversion
     and wanted to avoid the overhead of repeated opens for each
     conversion.  The one-character-lookahead feature of read(),
     though, has been a problem.
 
(7)  Like most other support I've seen, the Draco crt library gets
     tailored of the particular terminal and this tailoring solves
     the problem of how to do output to the terminal.  Any thoughts
     on similar tailoring for input?  (E.g. choice of cursor keys,
     function keys, escape sequences....)  Any thoughts on special
     output rendering choices?  (E.g. "semi-graphic" type symbols
     to draw lines versus the typical - + and |.)
 
(8)  Given that Chris Gray has announced the very low probably of
     any continued support to the CPM version of Draco, would the
     author consider releasing the source?
 
 
(I have not, as yet, looked at any of the games, etc. so I have
no comments on them....)
 
 
JSFisher   FISHER@RPICICGE.BITNET