[comp.sys.hp] HP Pascal speaks! long

chip@hpclisp.HP.COM (Chip Chapin) (10/14/89)

*** Warning: Long Response Ahead ***

This message is a semi-formal response to the HP Pascal issues raised
by Richard Lloyd of the Liverpool University Computer Science
Department in his note entitled "HP9000 Pascal Buglist/Wishlist",
posted on comp.sys.hp October 3, 1989.  I say "semi-formal" because,
while I am the HP-PA Pascal project manager (s800 and s900), and while
both s300 and s800 project teams have been involved in preparing the
response, it is important to stress that, though we may (or may not)
appear knowledgeable, nothing in this note should be construed as a
commitment by the Hewlett Packard Company itself to any future product
enhancements.  These are our *individual* opinions about what ought or
ought not to be done.

When I first saw Mr. Lloyd's comments, I got the silly idea that a
coordinated [but still unofficial :-)] response from the s300 and s800
compiler groups would be useful.  Of course, the problem with that
plan is the time required to collect input from several people and
munge it into a single response.  As a result, this posting is a full
week later than it would have been if I had just let nature take its
course.  Oh well, I'll know better next time.  Fortunately, in the
meantime several knowledgeable individuals have responded to many of
Richard's concerns.

Besides my own remarks, most of the comments interspersed with the
original posting below are from Jim Bigelow of the s300 Pascal project
in Ft. Collins.  Thanks, Jim!  Several other people on the s800 Pascal
in Cupertino also contributed.  I'm afraid the whole thing is rather
long, but hopefully it will serve as both a satisfactory response and
a useful basis for further discussion.

Jim makes the following observation, with which I wholeheartedly agree...

  I find myself responding in one of two modes, defensively which causes
  much recourse to exact definitions, or as a sympathetic user where I
  agree with his wished for behavior.

    "You can please  some of the people some of the time,
     and most of the people, most of the time,but you can't
     please all the people, all the time." [1]

As the sympathetic user I could wish that the Pascal language were
more than it is.  As the hard-nosed implementor, however, I need to
maintain precise accordance with published standards, and avoid the
"Swiss Army Knife" approach to compiler implementation.

-- Chip Chapin

--------------------------------------------------------------------
Chip Chapin, Hewlett Packard Company, California Language Lab
           (HP/CBO/NSS/CSG/DLD/LMO/CLL)
uucp:      ... {allegra,decvax,ihnp4,ucbvax} !hplabs!hpda!chip
	or ... uunet!hp-sde!hpda!chip
Internet:  chip%hpda@hplabs.hp.com or chip%hpda@hp-sde.hp.com
HPDesk:    chip (hpda) /HPUNIX/UX
USMail:    MS47LZ; 19420 Homestead Ave; Cupertino, CA  95014; USA
Phone:     408/447-5735    Fax: 408/973-8455    HPTelnet: 1-447-5735
--------------------------------------------------------------------

> Richard K. Lloyd writes:
> We are currently running HP-UX 3.1 on an HP9000/850 and HP-UX 6.2 on various
> HP9000 Series 300 workstations. Since there has just been a very interesting
> posting on HP-UX 3.1 problems, I thought I'd weigh in with a similar document
> about HP Pascal.
> 
> Firstly, here's a list of currently strange 'features' (bugs to you and me) :
> 
> 1. Extremely large executable size (On Series 800 machines only)
>    -------------------------------
> 
>    Try compiling the following HP Pascal program on a Series 800 machine...
>    (WARNING: Make sure you have at LEAST 250 MBs of free disk space !)
> 
>    program bigexec ( input , output ) ;
> 
>    type str255 = string [ 255 ] ;
> 
>    var huge : array [ 1..1000 , 1..1000 ] of str255 ;
> 
>    begin
>       writeln ( 'If you get this far, then you have plenty of disk space !' )
>    end.
> 
>    Although this would normally be dismissed as a downright inefficient way of
>    building an s800 executable (what's wrong with a malloc at run-time ?), this
>    really does highlight the lack of disk quotaing (HP-UX 7.0 should cure this)
>    - any normal user can fill the disk in less than one minute. Compiling the
>    same program on Series 300 machines results in a less dramatic executable
>    size (69K).

Several people have already responded to this issue (Shankar Unni,
Dennis Handly, Marc Sabatella and Dave Decot (sort of :-)), and I
really have nothing to add.  We'd like to see this change.

> 2. Otherwise clause in a Case statement is compulsory at run-time
>    --------------------------------------------------------------
> 
>    If the case statement falls through all the selector values without
>    matching ANY of them at run-time, then the otherwise clause MUST be
>    present. I'm sure most Pascals just fall out of the case statement
>    without an error. The worst thing about this is that it is not
>    reported at compile-time - leading to programs that could be
>    potentially crashable when they really shouldn't be.

Here is good example of programming practice vs. language standards.
UCSD Pascal [incorrectly] allowed the program to fall through the case
statement, and some Pascals still follow that policy.  I may be wrong,
but I think even the Zurich P2 and P4 compilers would fall through.
In the days before the "otherwise" extension (or UCSD's CASE .. ELSE)
was made to the original J&W Pascal, this behavior made some sense,
even though it was "incorrect".  With the ability to use "otherwise",
however, in my humble opinion there really is no justification for
this sloppy practice.

John Flores (jjf@hpcllz2.hp.com) comments:

    The behaviour of our CASE statement is consistent with the
    ISO/ANSI standard.  The process should not just drop through the
    Case statement if the case-index does not match any of the
    constants:

    From the ISO standard:

        One of the case-constants shall be equal to the value of the
        case-index upon entry to the case-statement, otherwise it
        shall be an error.

    This is impossible to detect at compile time unless the case-index
    was a constant and in that case you wouldn't need a case
    statement.

And Jim Bigelow writes:
 
    As Marc Sabatella points out, ansi pascal does not allow for an
    otherwise clause. Wirth says in "pascal, User manual and report", 2nd
    Edition, 1978, P31.

      "The case statement selects for execution that statement
       whose label is equal to the current value of the
       selector; if no such label is listed, the effect is
       undefined." 

    As Mr Lloyd points out, in real practice, some provision must be
    supplied to account for the lack of an otherwise. S300 pascal will
    report, at run time, if the case selector assumes a value for which
    there is no label.

	program other(output);
	var
	    i :integer;
	begin
	    for i := 0  to 10 do
	      begin
	    	case i of
	    	  0:        writeln('0 case OK');
		end;
		writeln('statement after case');
	      end;
	end. {Program other.p}

    When the above is compiled and run the following run-time messages are
    seen: 

	$ pc other.p
	$ a.out
	0 case OK
	statement after case
	ERROR -9 IN LINE 0. Case value range error.

    Both the 68K and HP-PA Pascal compilers provide the keyword
    "otherwise". When the above program is modified to use otherwise,
    it becomes:

	program other(output);
	var
	    i :integer;
	begin
	    for i := 0  to 10 do
	      begin
	    	case i of
	    	  0:        writeln('0 case OK');
		  otherwise writeln('Hit otherwise clause');
		end;
		writeln('statement after case');
	      end;
	end. {Program other.p}

    This program compiles and runs successfully, and safely.


> 3. 'Accessed, but not initialised' compile-time warning
>    ----------------------------------------------------
> 
>    This appears on the Series 800 Pascal if you attempt to access a
>    variable before it has been initialised. I'd like to see this warning
>    on the Series 300 Pascal too - it's quite handy (and can be switched
>    off if it annoys you with $WARN OFF$).

It was added to the s800 Pascal as an easy by-product of the
optimizer's machinations.  We agree that it would be a useful
enhancement for the s300 Pascal, and Jim has said he would "add it to
the list of waiting enhancements".  If it's not easy to do, however, I
would personally not hold my breath.


> 4. close ( filevar ) doesn't have a sensible default behaviour (Series 300)
>    -----------------------------------------------------------
> 
>    When a file is opened for output with the rewrite statement, using the
>    close statement with only the file variable as a parameter not only closes
>    the file BUT DELETES IT. This is exactly the opposite behaviour of all other
>    Pascals I have come across. Yes, you can specify close ( filevar , 'SAVE' ),
>    but you shouldn't have to.

As you have noted, only the s300 compiler exhibits this behavior.
Even so, Richard should recognize that this is time-honored Pascal
trait, and not something that was just dreamed up in Ft. Collins.  For
example, I quote from the UCSD Pascal Users Manual, Version IV.0
(1981):

	"if [close( ..., ] OPTION is not present, the CLOSE simply
	sets the file state to closed.  If the file was opened using REWRITE
	and is a disk file, it is deleted from the directory".

If my memory serves me correctly, the file would be deleted even if
existed prior to the program run.  This even more extreme than the
s300 Pascal behavior, which deletes the file only if it was newly
created by the program.

Jim B. adds that "The 300 manual says that close accepts:

   'SAVE' -- save file and make permanent
   'NORMAL' or 'TEMP', or none  --If the file is already permanent, it
    remains in the directory.  If the file is temporary, it is removed.

    The behavior can be viewed as good, because it cleans up it own temp
    files, rather than cluttering up the file system. On the otherhand,
    existing files remain in place.  However, it's a gotcha for porting."

I think we're undecided about which behavior is "best".  If anything,
I personally lean toward the s300 style for the reasons Jim has given.
But I hear one customer voting for the s800 style.  Any others?  I
*would* like to see the compilers be consistent on this point.

> 5. The + operator for strings is fussy about its operands
>    ------------------------------------------------------
> 
>    Quiz time ! Which of the following is legal in HP Pascal (fred is a string) ?
> 
>    a)    fred := fred + '*' ;
>    b)    fred := fred + chr ( 42 ) ;
>    c)    bill := '*' ; fred := fred + bill ; { bill is a char }
> 
>    Answer:
> 
>    a) and b) both work on Series 300 machines.
>    Only a) works on Series 800 machines.
>    c) works on neither !
> 
>    This is incredibly inconsistent behaviour - my opinion is that all three
>    should be perfectly legal.

This is one of those things where we're torn between ease of use on
the one hand, and language rigor on the other.  Can you say "Strong
typing"?  I knew you could!  I'm afraid we don't have any plans to
make all of these legal, as Richard asks, and maybe the s300 will make
(b) illegal (as I guess it really should be).  On the other hand, as
programmers most of us would prefer all of them to be allowed.  Can
anybody list several popular Pascals that *do* allow all these
constructs?  If it became an issue for porting non-HP Pascal code,
we'd have an easier time rationalizing a change.

Jim Bigelow explains why it works the way it does...

   In keeping with the strict type checking of pascal, note that the
    concatenation operator is only defined for strings.

>   a)    fred := fred + '*' ;

    This works because string literals, '*' in this case, are

	"interpret[ed] as type PAC, string, or char depending 
         on context" [2]

>   b)    fred := fred + chr ( 42 ) ;
    
    Since char ( 42 ) is a char and not a string, this looks like a
    bug, or a bug that is a feature :-) [in the s300 Pascal].

>   c)    bill := '*' ; fred := fred + bill ; { bill is a char }

    Opps, can't fool the compiler here, bill is a char and not a string
    so type matching says this won't work.  And we get:

	Operand(s) are not proper type for this operation;


> The rest of these points are a wishlist for HP Pascal:
> 
> 1. Array slicing
>    -------------
> 
>    I really miss the ability to do:
> 
>    var fred : array [ 1..7 , 1..7 ] of integer ;
>    begin fred [ 1 , ] := fred [ 2 , ] end ; { OK, so it's uninitialised... }

As Shankar Unni pointed out in his response,
	fred[1] := fred[2];
works fine on both compilers.  Why would you want to do it the other way??


> 2. Constant assignment to arrays (and other types ?) in the var section
>    --------------------------------------------------------------------
> 
>    Again, I miss this lovely construct:
> 
>    var fred : array [ 1..2 , 1..2 ] of integer :=
>               ( ( 17 , 6 ) , ( 13 , -2 ) ) ;
> 
>    It saves having to put the data in a text file (or 100's of assignments).

Aside from using C-style comments in his example ("/*" instead of
"(*"), Shankar's example of using structured constants works fine in
both s300 and s800 Pascals:

    program p (input, output);
    type
	oneDarray = array[1..2] of integer;
	twoDarray = array[1..2] of oneDarray;
    var
	fred : twoDarray;
    const
	fred_init = twoDarray [ oneDarray [17, 6], oneDarray [13, -2] ];
    begin
	fred := fred_init;  (* initialize at one shot *)
    end.

Steve Taylor posted a similar example.  I agree with Shankar's remarks
that this seems ugly compared to the way you have illustrated.  And,
obviously, this does not take any advantage of the ability to have
pre-initialized static data in your executable file.  Once again,
we're running squarely into "Pascal purity" issues.  And, again, I
would say that "if enough customers wanted it..." we could be flexible
here.  I've got Richard's vote.  Any others?


> 3. Access to external ints in C library routines
>    ---------------------------------------------
> 
>    Whilst attempting to call curses routines from Pascal (yes, Frank, I noticed
>    the flaky curses routines too !), I had to resort to C 'glue' routines to
>    get at external ints inside the curses library, even though HP Pascal *can*
>    call external functions and procedures.

In Shankar Unni's response, he painted a rather bleak picture here,
stating that the s300 and s800 had incompatible implementations.
However, as he now admits, he was thinking of the "bad old days".  The
current situation is getting pretty reasonable.  The following example
from Jim Bigelow works for both compilers.  He does, however, point
out a significant remaining bug (even in 7.0) in the s300 Pascal, that
would still cause problems for Richard's application.

   This can be done by aliasing the variable to its C library name, e.g.,

	{
	    Title: 	errno.p -- access errno in libc
	    Last Mod: 	Thu Oct  5 15:50:15 1989
	    Author: 	Jim Bigelow
			<jimb@hpjb>
	}
	program errno (input,output);
	    var
	    	unix_error_number $alias '_errno'$ :integer;
	begin
	    writeln(unix_error_number);
	end. {Program errno}

    However, these is a bug in the 300 compiler, I will be fixing this
    month where the compiler lower-case's the alias.  This makes it hard
    to access LINES and COLS from the curses library.  Opps :-)


> 4. Executable size seems rather large (300 or 800 Series)
>    ------------------------------------------------------
> 
>    Now I know that there aren't shared libraries in HP-UX 3.1, but even so, a
>    size of 60 to 70 K (300 Series) or 150 K upwards (800 Series) for the most
>    trivial of programs seems a bit on the gargantuan side. And people complain
>    about the size of C executables !

For the s800, while I admit that a problem exists here, I wonder if
you've tried running strip(1) on your executables?  For example,the
"errno" program above produced an a.out of 133KB on my 840 with a
recent compiler.  When I stripped it ("strip a.out"), it was reduced
to less than 84KB.  Still large, but much less embarrassing.

Jim B. says (re the s300):
    With 6.5, file buffers were increased to 8K buffers to match the Kernel
    buffer increase.

I consider the arrival of shared libraries in the 7.0 release on both
systems to be the rest of the solution to this particular problem.


> 5. Series 300 optimisation
>    -----------------------
> 
>    Call me stupid if you want, but I can't understand why pc on the Series 800
>    has a -O option (optimisation), but the Series 300 pc does not...

Marc Sabatella has already pointed out that the s300 compiler does not
have a separate optimizer.  Jim adds:

    On the positive side, there is no -O because all the optimizations
    the 300 provides, is done already.  The negative side is that's not
    much: limited common subexpression folding, constant folding,
    register allocation for with and intermediate bases.  Resources are
    few for optimizations, but the spirit is willing. :-)

> Conclusion
> - ----------
> 
> As I think has already been mentioned, it is clear that Series 300 and Series
> 800 Pascal are written by different people within HP. This does lead to
> differences in HP Pascal behaviour that, whilst not difficult to work around,
> are just a little bit too niggly to go away that easily.

We agree, and thank you for pointing out some differences that became
an issue for you.  Actually, I'd like to see much more from you and
other users along these lines.  The two Pascals have come *much*
closer together in the last two years, and we'd like to see which of
the remaining differences are most important.  But, for now, as I look
back over the issues you have raised, really only two (close(f)
behavior and fussy + operator for strings) describe syntactic or
semantic differences between the two Pascals.  Were those really the
worst ones you encountered?

> Although I have made some negative points about HP Pascal, I am actually
> reasonably impressed, syntax-wise, with it and would be delighted if some of
> the suggestions/bugs were implemented/fixed in some future release.

We're very glad you are finding it useful.  In summary, we hope to
address your bug-1, bug-3, and bug-5 in some fashion in the future
(but this cannot be promised, please understand.  Refer to disclaimer
at top of this note).  On bug-2, we consider ourselves "correct"
as-is.  I don't know what to do about bug-4, and I remain open to
suggestions.  I believe we have already addressed your wishlist items
1, 3, and 4, and functionally addressed item 2, though not as well as
you would like.  Personally, I think a complete solution to
compile-time initialization is not worth the effort, given that we
already have structured constants, but if the demand is sufficient,
well, maybe.  Finally, wishlist item 5 we hope to address in the
future, same caveat as above.

> Richard K. Lloyd,       **** This is a MicroVAX II running VAX/VMS V5.1 ****
> Computer Science Dept., * JANET     : RKL@UK.AC.LIV.CS.MVA or              *
> Liverpool University,   *             RKL@000010500211.FTP.MAIL            *
> Merseyside, England,    * Internet  : RKL%mva.cs.liv.ac.uk@cunyvm.cuny.edu *
> Great Britain.          ****************************************************

References:	[thanks, Jim]

[1]   A. Lincoln

[2]  "HP Pascal Language Reference, HP 9000 Series 200/300 Computers",
      Edition 3, for HP-UX 6.5, Section Strings, Page 216.

mjs@hpfcso.HP.COM (Marc Sabatella) (10/16/89)

>For the s800, while I admit that a problem exists here, I wonder if
>you've tried running strip(1) on your executables?  For example,the
>"errno" program above produced an a.out of 133KB on my 840 with a
>recent compiler.  When I stripped it ("strip a.out"), it was reduced
>to less than 84KB.  Still large, but much less embarrassing.
>
>Jim B. says (re the s300):
>    With 6.5, file buffers were increased to 8K buffers to match the Kernel
>    buffer increase.
>
>I consider the arrival of shared libraries in the 7.0 release on both
>systems to be the rest of the solution to this particular problem.

Woah - no shared libraries in 7.0; you'll have to wait until next summer for
8.0 or whatever they have decided to call the release.

Also, shared library  support for Pascal on the 300 is not currently planned
for that release, although it is on the 800.

There are several things that could be done to improve things even given
archive libraries.  In particular, my pet peeve is that the library is so
poorly structured, a simple "hello world" program results in the "arctangent"
routine being brought in from libpc!

--------------
Marc Sabatella
HP Colorado Language Lab (CoLL)
marc@hpmonk

chip@hpclisp.HP.COM (Chip Chapin) (10/17/89)

There are two amendments I'd like to make to the original posting:

>/ chip@hpclisp.HP.COM (Chip Chapin) /  7:42 pm  Oct 13, 1989 /
>    However, these is a bug in the 300 compiler, I [Jim B.] will be fixing this
>    month where the compiler lower-case's the alias.  This makes it hard
>    to access LINES and COLS from the curses library.  Opps :-)

I should have pointed out that $alias on the s800 has the *same*
property.  In fact, the case-insensitivity is a bona-fide "feature" 
rather than a bug.  Clearly, however, a user also needs a way to make
the external name case-sensitive, and that is why, on the s800, the
default behavior may be overridden using the $LITERAL_ALIAS option.

The "bug fix" that Jim refers to for the s300 is not to change the
behavior of $alias, but to add the $literal_alias option, a la the s800.


And with respect to large executables I said:

>I consider the arrival of shared libraries in the 7.0 release on both
>systems to be the rest of the solution to this particular problem.

I must have been asleep when I wrote that.  Shared libraries are most
emphatically *NOT* in the 7.0 HP-UX release.  "They may be in a future 
release" :-) :-)

Chip