SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-Programming Mailing List Archives

Return to [ 16 | February | 2004 ]

<< Previous Message << >> Next Message >>


Date: Mon, 16 Feb 2004 10:18:55 PST8
From: Peter Skye <pskye@peterskye.com >
Reply-To: scoug-programming@scoug.com
To: scoug-programming@scoug.com
Subject: SCOUG-Programming: PL/I most important statement (was: call(TZ) ? - PL/I)

Content Type: text/plain

Lynn H. Maxson wrote:
>
> There is none so blind as he that refuses to see. Outer
> block. Inner block. Downgrade engineering, upgrade
> programming. Yes, you have to be conscious of inner and
> outer blocks. You not only have to be conscious but you
> have to conscientiously in writing designate them as such.
> You have to conscientiously know when a variable gets
> allocated and when it gets freed, because you have to put
> it in writing. That's programming. You prefer it one way;
> I, another. That's style, but it's still programming.

Sounds like an argument for spaghetti code. I prefer to "think high
level and implement appropriately."

> my example . . . marks the fallacy of saying
> you use begin-end as Greg did to mark separate
> calculation code segments. You can't do it here and
> get the type of dynamic allocation that you want.

Greg's code is fine -- see his Sunday 1 a.m. message which contains his
example.

Note that he's only using _one_ BEGIN block.

I'm starting to wonder what you've been growing in your backyard garden
. . .

> So why not forget the inner and outer blocks, global and
> local variables, about marking code altogether? Why not
> have one block with its local variables and simply use
> allocate and free where you know you would have to use
> begin and end? You don't have to know any more or any less.

See prior messages. It's more organized. The compiler can catch errors
better. Less housekeeping for the programmer. No chance of allocating
new stuff before deallocating old stuff.

> Moreover, if you allocate your matrices as list entries,
> ...nah, I won't pursue that here except that Pascal
> doesn't support aggregate operands.

List processing is possible but it executes more slowly. Think about
the actual machine code difference between calculating an index vs.
maintaining a B-tree of pointers.

Pascal supports ordinal types. Does PL/I?

- Peter

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================


<< Previous Message << >> Next Message >>

Return to [ 16 | February | 2004 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.