SCOUG-Programming Mailing List Archives
Return to [ 31 | 
October | 
2003 ]
 >> Next Message >>
 
 
 
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.
 
 |