PL/I (was: IBM Needs to seed the PL/I Compiler) 
Author Message
 PL/I (was: IBM Needs to seed the PL/I Compiler)

Quote:
>> But that is exactly what the PL/S subset is for,

and IBM has never released it for the public. <<

That is a common misconception.  Actually, the PL/AS compiler is
available, and has been for some time (more than a few years, but
I just do not remember exactly).  It is not actively marketed and
it is very reasonably priced.  It is made available by IBM under
the auspices of their "S/390 Partners in Development" program, of
which my employer is a member; companies can join the program at
no charge.  For additional information, see the IBM web site:

      http://www.*-*-*.com/

Once you are a member, you can go to the Tools section, and there
you will find the PL/AS compiler listed.  PL/AS is NOT a "program
product" and can't be ordered as you would another piece of software
from IBM.  But, it IS available, and it DOES work, and companies ARE
using it to write systems programming products. The only reason that
I can imagine that PL/AS is not made available as a regular program
product is that IBM must think that since there are only 20 to 30
customers for it in the first place, it's simply not worth the
overhead of making it one, officially (e.g., it's my understanding
that the team that maintains the PL/AS compiler consists of only 3
people, and in true IBM fashion, if it were made into a formal
program product, they'd have to add that many just to maintain the
documentation plus another set to talk to external customers -- this
according to a personal conversation I had with 1 of those 3 people).

-- William Blair

Quote:



> > ...
> > It's a very versatile language.  It can be used for system
> > programming as well as application programming.
> > ...

> The problem with PL/I (and other high-level languages) used for
> system programming is the requirement for establishing the run-time
> environment. This is unneccessary (and sometimes incompatible)
> overhead when you really need to do simple things.  If you could
> choose to use only the in-line generated code it would be much more
> usable for such purposes.  But that is exactly what the PL/S subset
> is for, and IBM has never released it for the public.

--
=========1=========2=========3=========4=========5=========6=========7==
The two most common elements in the universe are Hydrogen and stupidity.
                                                        - Harlan Ellison
Unfortunately, the observed level of Hydrogen appears to be diminishing.

=========1=========2=========3=========4=========5=========6=========7==


Fri, 04 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)


Quote:
> ...
> It's a very versatile language.  It can be used for system
> programming as well as application programming.
> ...

The problem with PL/I (and other high-level languages) used for system
programming is the requirement for establishing the run-time environment.
This is unneccessary (and sometimes incompatible) overhead when you really
need to do simple things.  If you could choose to use only the in-line
generated code it would be much more usable for such purposes.  But that is
exactly what the PL/S subset is for, and IBM has never released it for the
public.


Sat, 05 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)

Quote:

> The list processing facilities are good too.

For MVS PLI you can allocate storage and set pointers to it; I don't
call that list processing, because you have to do all the work in code,
and you can fubar yourself in no time. There are in fact no list
processing language features.

Had you said /stack processing/ with CTL then I would have agreed.

Roy Gardiner



Tue, 08 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)


Quote:
> For MVS PLI you can allocate storage and set pointers to it; I don't
> call that list processing, because you have to do all the work in code,
> and you can fubar yourself in no time. There are in fact no list
> processing language features.

That depends on how you define 'list processing'.

For example, a list can be a collection of similar data structures chained
together.
In PL/I you can define it like this:

DCL LIST_BASE_PTR POINTER;
DCL 1 LIST BASED(LIST_PTR),
        2 LIST_NEXT_PTR POINTER INIT(NULL),
        2 LIST_ITEM;

The structure will usually contain more items, but one will suffice for
illustration.

Suppose the list is already established, each element pointing to the next,
the last one has a NULL pointer, and LIST_BASE_PTR point to the first
element.

Then the following statement will search the list for a specific element,
where ITEM has the value VALUE.  If found, the LIST_PTR will point to it,
otherwise LIST_PTR will be NULL:

DO LIST_PTR = LIST_BASE_PTR
        REPEAT LIST_NEXT_PTR
        WHILE (LIST_PTR ^= NULL)
        UNTIL (LIST_ITEM = VALUE);
END;

I agree that list processing is not a 'language feature' of PL/I, but this
way of writing it is easily understandable, and it compiles to very
efficient code.

However, if you insist on specifying the above in a more compact way, that
is also achievable with PL/I.  If you define a couple of preprocessor
procedures, you can make life easy:

%DEFINE: PROC(LIST_NAME,ITEM_NAME) RETURNS(CHAR);
%DCL LIST_NAME CHAR;
%DCL ITEM_NAME CHAR;
RETURN('DCL '!!LIST_NAME!!'_BASE POINTER;%SKIP'
        !!'DCL 1 '!!LIST_NAME!!' BASED('!!LIST_NAME!!'_PTR),%SKIP'
        !!'     2 '!!LIST_NAME!!'_NEXT_PTR POINTER INIT(NULL),%SKIP'
        !!'     2 '!!LIST_NAME!!'_'!!ITEM_NAME!!';%SKIP');
%END DEFINE;

%SEARCH: PROC(LIST_NAME,CONDITION) RETURNS(CHAR);
%DCL LIST_NAME CHAR;
%DCL CONDITION CHAR;
RETURN('DO '!!LIST_NAME!!'_PTR = '!!LIST_NAME!!'_BASE_PTR%SKIP'
        !!'     REPEAT '!!LIST_NAME!!'_NEXT_PTR%SKIP'
        !!'     WHILE ('!!LIST_NAME!!'_PTR ^= NULL)%SKIP'
        !!'     UNTIL ('!!CONDITION!!');%SKIP'
        !!'END;%SKIP');

Now you can make the declaration of a structure with:

DEFINE(LIST,ITEM)

and the search for the specific element can be specified as:

SEARCH(LIST,ITEM=VALUE)

The generated source statements will be the same as the first example.

There may be errors in the above, since I have not compiled this particular
example.  I do not have access to a mainframe just now.

--Gunnar.



Fri, 11 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)

Quote:

> > The list processing facilities are good too.

> For MVS PLI you can allocate storage and set pointers to it; I don't
> call that list processing, because you have to do all the work in code,

What?  PL/I has specific list processing facilities.  Suggest
consulting a good PL/I book.
Quote:
> and you can fubar yourself in no time. There are in fact no list
> processing language features.

> Had you said /stack processing/ with CTL then I would have agreed.

> Roy Gardiner



Sat, 12 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)

Quote:

> > The list processing facilities are good too.

> For MVS PLI you can allocate storage and set pointers to it; I don't
> call that list processing, because you have to do all the work in code,
> and you can fubar yourself in no time. There are in fact no list
> processing language features.

Try:

   ALLOCATE node;
   GET LIST (Head -> Value);

The user doesn't "set pointers". This is done automatically
with the ALLOCATE statement.
(The declarations would be:
   DCL 1 node Bades (Head);
         2 Value FIXED;
         2 Ptr   POINTER;
)

To print a one-way linked list, one uses:

   DO Current = Head
      REPEAT Ptr
      WHILE (Current ^= NULL () );
      PUT LIST (cURRENT -> vALUE);
   END;

Quote:
> Had you said /stack processing/ with CTL then I would have agreed.

> Roy Gardiner



Sun, 13 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)
Quote:



> > For MVS PLI you can allocate storage and set pointers to it; I don't
> > call that list processing,(snip)

> That depends on how you define 'list processing'.

(snip lots of very fine PLI)>

Quote:
> --Gunnar.

Exactly. You have to do it yourself.

I define it as when the language does it for you (as in CTL storage's
LIFO stack feature).

--
Roy Gardiner



Fri, 18 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)


Quote:
> > That depends on how you define 'list processing'.
> Exactly. You have to do it yourself.

> I define it as when the language does it for you (as in CTL storage's
> LIFO stack feature).

Well, I do not agree.  I would call that stack processing, which is a very
limited subset of list processing.

If you want to do other forms of list processing, you somehow have to tell
what you want to do.  And you have to tell what you want your list elements
to consist of.  It can't be done much shorter than giving each field a name
and a property.  And some of the simple things you would want to do is to
start a list, add elements, delete elements, modify elements, search for
elements, sort elements, and so on.  You may dislike the syntax of the
statements available in PL/I, but it surely can do the job.  I also
demonstrated how you could extend the language with macro procedures if you
wanted more compact forms of writing certain instructions.  How much
specific programming features do you want in the base language?  PL/I is a
general purpose language, remember.

Gunnar.



Sat, 19 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)

Quote:




> > > For MVS PLI you can allocate storage and set pointers to it; I don't
> > > call that list processing,(snip)

> > That depends on how you define 'list processing'.

> (snip lots of very fine PLI)>
> > --Gunnar.

> Exactly. You have to do it yourself.

> I define it as when the language does it for you (as in CTL storage's
> LIFO stack feature).

If you want stack processing, Controlled storage easily implements a
pushdown stack.


Sat, 19 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)

Quote:


> > I define it as when the language does it for you (as in CTL storage's
> > LIFO stack feature).

> Well, I do not agree.  

You agree, I think. My statement above and yours which follows are the
same; CTL is stack processing.

Quote:
> I would call that stack processing, which is a very
> limited subset of list processing.
> If you want to do other forms of list processing, you somehow have to tell
> what you want to do.(snip a bit)  And some of the simple things you would want to do is to
> start a list, add elements, delete elements, modify elements, search for
> elements, sort elements, and so on.

There is no reason why the language itself could not contain keywords to
do all these things. That's what your macros do, isn't it?

Quote:
> You may dislike the syntax of the
> statements available in PL/I, but it surely can do the job.  (snip a bit)

Of course, but not trivially; if the language contained list processing
keywords such as those you have identified (add, delete, find-in at
least being necessary; modify should not need new keywords) it would
become as straightforward as CTL now is.

Quote:
>  How much specific programming features do you want in the base language?  PL/I is a
> general purpose language, remember.

> Gunnar.

General but not simplistic; excellent block structuring; isub and
correspondence defining; pseudovariables; rich built-in-function set; 6
different storage classes, with execution-time definition of array sizes
and string lengths for some; well-defined conversion paths; well-defined
arithmetic,  and more, which I am sure other people can identify.

But like any language it has faults; lack of list processing is, IMO,
one of the most serious.

--
Roy Gardiner



Thu, 24 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)

Quote:


> > I define it as when the language does it for you (as in CTL storage's
> > LIFO stack feature).

> If you want stack processing, Controlled storage easily implements a
> pushdown stack.

That is precisely what I am saying; pushdown stack exists without any
user code writing, list processing does not.

--
Roy Gardiner



Thu, 24 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)

Quote:

> But like any language it has faults; lack of list processing is, IMO,
> one of the most serious.

PL/I has many list-processing facilities.  It was, after all, the FIRST
general purpose language to have list processing facilities!
Quote:
> Roy Gardiner



Fri, 25 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)

Quote:


> > But like any language it has faults; lack of list processing is, IMO,
> > one of the most serious.

> PL/I has many list-processing facilities.  It was, after all, the FIRST
> general purpose language to have list processing facilities!

In PLI, there are features to enable the programmer to implement list
processing, but that is not the same as providing list processing.

I repeat, PLI does NOT have ANY list processing whatsoever.

It has stack processing, with ALLOC and FREE of CTL storage and the
ALLOCN function.

You can of course, which is what is suspect you mean, program list
processing. The points-at feature -> , the ability to DCL based
variables without related pointers, the ability to use a pointer
variable in a DO-loop, and so on, just help the programmer.

You can program SUBSTR in COBOL too, but it is much easier if a BIF is
available

Roy Gardiner



Fri, 25 May 2001 03:00:00 GMT  
 PL/I (was: IBM Needs to seed the PL/I Compiler)

Quote:

> In PLI, there are features to enable the programmer to implement list
> processing, but that is not the same as providing list processing.

> I repeat, PLI does NOT have ANY list processing whatsoever.

Sorry, I'm a bit out of it here.
Can you explain what you mean, and give an example of a language that
does ?

Quote:
> Roy Gardiner

--
Bub
bub at videotron dot ca
http://alcor.concordia.ca/~sd_fort

        " Hope is the beginning of unhappiness "



Fri, 25 May 2001 03:00:00 GMT  
 
 [ 45 post ]  Go to page: [1] [2] [3] [4]

 Relevant Pages 

1. IBM Needs to seed the PL/I Compiler

2. Mapping local files to FILE declarations in PL/I with IBM VisualAge PL./I for Windows

3. Compiling DR PL/I code with IBM Personal PL/I

4. Current IBM PL/I compilers

5. IBM announces a new PL/I compiler version

6. PL/I - new IBM compiler for MVS ...

7. Logo Komeniusz PL (Logo Comenius PL)

8. Derivation of PL/I (was Usenet group for PL/M language)

9. Difference PL/1 PL/I

10. What is the difference between DEC PL/1 and OS/390 PL/1

11. Initialization Expressions in PL/I (was ANSI PL/I)

12. Migrating from OS/VS PL/I to VA PL/I

 

 
Powered by phpBB® Forum Software