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 [ 31 | October | 2003 ]

>> Next Message >>


Date: Fri, 31 Oct 2003 10:03:38 PDT7
From: "Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To: scoug-programming@scoug.com
To: "SCOUG Programming SIG" <scoug-programming@scoug.com >
Subject: SCOUG-Programming: Distinguishing assertion from assignment

Content Type: text/plain

I thought I might enlist some support in resolving a means of
distinguishing an assertion, the primary processing statement
of declarative programming languages, from an assignment,
the primary processing statement of imperative programming
languages.

I had considered using two different forms, borrowing the use
of the left arrow represented here as a double byte character
'<-' from APL for assignment operator, leaving the '=' for the
assertion operator. Thus you would have 'a <- b + c;' as an
assignment and 'a = b + c;' as an assertion.

Then it occurred to me that the primary difference lies in the
left-hand or target side of the operator.

In the instance of an assignment statement the proof process
produces one and only one true (code generating) result or
the compiler/interpreter fails, producing a false result (in
compiler parlance a "severe" error.

In the instance of an assertion statement the proof process
produces 0 (false, no true instances) or 1 or more true
instances, i.e. a list result.

Perhaps we used a poor example. Instead of 'a = b + c;' let's
use 'a = b > c;'. If b is greater than c, the set a to '1'b (true),
otherwise '0'b (false). Now note that in C, C++, JAVA, and
just about anyone else you care to name 'a', 'b', and 'c' are
'element' variables. However, APL and PL/I allow them to be
aggregate variables, structures or arrays.

As element variables we could have the following
declarations: 'dcl a bit(1);', 'dcl (b,c) fixed dec (7,2);' As
aggregates we could have 'a', 'b', and 'c' as identically
dimensioned vectors: 'dcl a (27) bit(1); dcl (b,c) (27) fixed dec
(7,2);'. Either set of declarations would suffice in PL/I and
APL for 'a = b > c;', although in APL we would write 'a <- b >
c'

So it's possible in PL/I and APL to use aggregate operands to
obtain aggregate (multi-value) results. The result aggregate
'a' would have a '1'b value wherever 'b' is greater than 'c',
otherwise a '0'b, altogether forming a 27-bit result 'a'.

This 27-bit result then we can use as a mask in a reduction
operation against both 'b' and 'c' to provide two (sub-)vectors
where 'b > c'. We could then iterate through each
(sub-)vector producing 'b c' pairs where 'b > c'.

In logic programming these three steps (create the mask,
apply the mask, combine the results) we could achieve in a
single step: '[b c] = b > c;', a list result with the possibility that
we have an empty list, i.e. no 'b > c' exists.

Note that we lost 'a' in this. To get it back we could write 'a
= [b c] = b > c;'. However, 'a' has to have the same attributes
as [b c], i.e. a list. That means we would have to rewrite the
last expression as '[a] = [b c] = b > c;'.

This leads in turn to declaring 'a' as a list: 'dcl a list;' capable
of accepting list members, i.e. [ b c], dynamically. In a sense
this represents the dynamic typing which occurs in REXX and
Python. This would lead us to rewrite the last expression
above as 'a[b c] = b > c;'.

Assuming that I've communicated the previous clearly enough,
it would appear that we could use the same '=' operator for
either assignment or assertion, allowing the left-hand side
expression to indicate which is expected. This is also an
example of operator overload, i.e. using the same operator for
two different purposes relying on context to determine which
applies.

My only remaining problem here lies with '[b c]' itself as
normally PL/I using commas to separate variables in a list. I
would prefer to write it as '[b, c]'. However, it's nothing we
have to cast in stone at the moment.

I would appreciate your comments.

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

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".

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


>> Next Message >>

Return to [ 31 | October | 2003 ]



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.