Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!haven!adm!xadmx!bobd%IHF1.UUCP%CUNYVM.CUNY.EDU@cunyvm.cuny.edu
From: bobd%IHF1.UUCP%CUNYVM.CUNY.EDU@cunyvm.cuny.edu (Bob Dietrich)
Newsgroups: comp.lang.pascal
Subject: Re: Extended Pascal: Lack of Pragmas :-(
Message-ID: <17874@adm.BRL.MIL>
Date: 17 Dec 88 05:08:10 GMT
Sender: news@adm.BRL.MIL
Lines: 63

In article <950013@hpclscu.HP.COM> shankar@hpclscu.HP.COM (Shankar Unni) writes:
>One thing that pisses me off about the Extended Pascal standard is that there
>has been *NO ATTEMPT* to standardise at least a SYNTAX for pragmas within
>the source. Never mind implementing a few like "include" and "if/ifdef" (can
>you see my C bias showing through?)
>...
Sure do.

>---
>Shankar (ex-Pascal hack) Unni.

Sorry, but you're wrong. JPC DID try to standardize on pragmas, but could not
come to a consensus position. So it was left out. Both a generalized
mechanism and an include-only mechanism were considered.

There were various problems that were encountered. The first is that existing
practice varies so widely, someone's toes were going to get mashed. Many
hours were spent arguing over what character(-sequence) should start a
pragma, because no matter what you picked, one or two people would be happy
and the rest would have to go home and change code. Note that standardization
means coming to a consensus position, not a unanimous position, and we
couldn't even achieve that. Other languages that have been primarily
sponsored by a single company or agency do not have such a problem, by
definition.

Another problem was how to define the facility in the standard, with results
similar to the first. As the existing Pascal standard is defined, there is NO
such concept as a program source line. Sure, such a concept could be defined
but it's harder than it seems. Also, requiring a line structure for Extended
Pascal programs would cause upward compatibility problems for programs
written in Pascal.

A third argument, as pointed out by other posters, was that the functionality
was already present. The include file mechanism found in other languages is
usually due to a lack of a strong modularity facility. Extended Pascal does a
good job in this area, so this feature is not necessary. Similarly for
conditional compilation. I might also point out that as languages changes, so
do the paradigms change that are used to construct programs. While a tool
like "make" is useful for a language like C that does not have explicit
interfaces, it is a lot less efficient for languages like Extended Pascal and
Ada. In any event, if you wish to use existing paradigms, you can make use of
an existing preprocessor or write your own.

Finally, there was a question of scope. The Pascal standard and the draft
proposed Extended Pascal standard say nothing about environmental issues such
as the format of a program to be processed. This is according to the program
of work that JPC operated under as a standards committee. I am not saying
that such issues are unimportant; in fact, a plan to address these kinds of
issues and quickly issue technical reports or trial-use standards was
discussed at the last meeting.

Extended Pascal ain't perfect and won't replace every other programming
language in existance, but it isn't supposed to. But from the comments I've
seen, most people feel it is a useful language that answers many of the
drawbacks of Pascal.

                Bob Dietrich
                Intel Corporation, Hillsboro, Oregon
                (503) 696-2092
        usenet:        uunet!littlei!ihf1!bobd
          or        tektronix!tessi!agora!ihf1!bobd
          or        tektronix!ogccse!omepd!ihf1!bobd
          or        tektronix!psu-cs!omepd!ihf1!bobd