|
Next Meeting: Sat, TBD
Meeting Directions
|
Navigation:
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
|
|
Pictures from Sept. 1999
|
|
The views expressed in articles on this site are those of their authors.
|
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 [ 17 |
April |
2005 ]
<< Previous Message <<
Content Type: text/plain
Peter Skye wrote:
> Sheridan George wrote:
>
>
> Four comments:
>
> -- 1. Of great importance to this discussion: at times it is a matter
> of defaults. In PL/I if you don't declare INDEX it becomes the default
> (for I-N names) type Fixed Binary (just like Fortran). In Rexx,
> however, the default (for everything) is an unlimited character
> string. If you want anything-goes defaults then that's fine; if you
> want restrictive defaults then that's okay too. This is as simple as a
> compiler/interpreter option -- declare your data defaults to be PL/I, or
> Fortran/Rexx, or whatever you like. "Choosing the right tool for the
> job" might in part just be what kind of data type defaults you want to
> work with.
This is OK as long as I know enough about PL/I, Fortran/Rexx defaults to know which switch to
choose. OTOH, I don't care if the switches are there if it gives some other programmer useful
flexibility.
>
> -- 2. Sometimes you want to declare a specific data type for inline
> error checking. Rexx has no way of knowing that INDEX is always a
> number, and thus allows INDEX='XYZ'. Some programmers like to catch
> these bugs early rather than at run time.
I, too, prefer to catch such errors at compile time. So, what is wrong with having the ability to
declare a type if you want but not be forced to? Even re-declare it to some other type at some
point if desired?
>
> -- 3. Sometimes a declaration can speed up the execution. In my number
> crunching I'd rather use an 8-bit value in a loop than a 64-bit value
> because I'm convinced it will execute faster. Different hardware can
> affect this, but I'm old-fashioned and prefer legacy support.
See above remark.
>
> -- 4. Sometimes you want to declare a specific data type for
> compatibility with incoming data. If your tape drive or satellite feed
> is supplying you with BCD you may want to declare the variable receiving
> the data as BCD rather than receiving it as binary and then converting
> it.
Same remark.
>
> In Summary: Different languages offer different default data types and
> ways to force specific data types. It would be very simple to allow a
> choice of default data type(s) in a language; alternately you can choose
> a language for a project based on the specific default data types and
> allowed data types that it offers.
>
As you said above, compiler options. (That includes interpreter, too.)
Sheridan
=====================================================
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
"postmaster@scoug.com".
=====================================================
<< Previous Message <<
Return to [ 17 |
April |
2005 ]
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.
|
|