From: james.grosbach@Microchip.COM (James Grosbach)
--IMA.Boundary.069332878
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
     The most common way to handle this sort of construct is to simply 
     regard an assignment as an expression in your grammar (which is what I 
     assume you've done given what you describe).
     
     For example:
        statement:
            expression
            | ...
            ;
     
        expression:
            assignment_expression
            ;
     
        assignment_expression:
            unary_expression '=' assignment_expression
            | logical_OR_expression
            ;
     
        logical_OR_expression:
            /* etc. in order of precedence of operators */
            ;
     
     The assignment_expression will return upwards a value equal to that 
     assigned to the unary expression in the case of an 'a = b' construct, 
     meaning that 'a = b = c' is equivalent to 'b = c' followed by 'a = b'. 
     Implementing option one would break this equivalence, which seems to 
     me to be undesirable and inconsistent with the rest of the language 
     (where an operator returns upwards the finished result of the 
     expression).
     
     Option 1 can also get you into some interesting quandries when 
     considering type converions. For example, if given a = b = c, where 
     the type of c can be implicitely converted to the type of b, but not 
     to the type of a, and the type of b can be implicitely converted to 
     the type of a, option one will produce a type mismatch error, but 
     option two will not. Even if the required type conversions are legal 
     in either case, the results may be different and possibly 
     counter-intuituve.
     
     
     My $.02 anyway.
     
        Jim
     
______________________________ Reply Separator 
_________________________________
Subject: multiple assignments (ADVANCED USAGE).  Opinions.
Author:  Steve  at Internet_Exchange
Date:    10/30/97 10:54 AM
Suppose... I repeat suppose... that SC32 allowed multiple assignments of 
variables such as
     
n = m = p = 1
     
I would assume that the variables n,m, and p are all set to 1.
(For those of you who have already found this advanced feature.... ignore it 
for
now)
     
But how would you expect the following to work?
     
string s[20], t[10], u[4]
     
s = t = u = "12345678901234"
     
Would you expect ? (OPTION 1)
u = "1234"
t = "1234567890"
s = "12345678901234"
     
the longhand version would be:
u = "12345678901234"    // which truncates to "1234" since u is only 4 
characters in size
t = "12345678901234"    // which truncates to "1234567890" since t is only 10 
characters in size
s = "12345678901234"   // which does not truncate at all since s is 20 
characters in size
     
or would you expect ? (OPTION 2)
u = "1234"
t = "1234"
s = "1234"
     
whose longhand is
u = "12345678901234"    // which truncates to "1234" since u is only 4 
characters in size
t = u                              // which sets t to "1234" since u is 
"1234" 
s = t                              // which sets s to "1234" since t is 
"1234" 
     
Put the string slice issue aside for now... Also, ignore the issue of BYTE or 
WORD types which could possibly be added for additional numeric storage... 
I'll 
bring that issue up later if need be...
     
What's your opinion?  Should multiple assignments cause the right-hand value 
to 
be assigned to each left-handle variable (OPTION 1) or should the right-hand 
expression be assigned to each left-hand variable as it passes right to left 
(OPTION 2)?
     
Steve
SemWare
     
     
--IMA.Boundary.069332878
Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers"
Content-Transfer-Encoding: 7bit
Content-Description: cc:Mail note part
Content-Disposition: inline; filename="RFC822 message headers"
Received: from titan.Microchip.COM (172.16.245.37) by chccm2.microchip.com 
with
SMTP
  (IMA Internet Exchange 2.1 Enterprise) id 0003D310; Thu, 30 Oct 97 08:53:46
-0700
Received: from prometheus.Microchip.COM
(firewall-user@prometheus-gate.Microchip.COM [198.175.253.129]) by
titan.Microchip.COM (8.6.12/8.6.12) with SMTP id IAA01570 for
; Thu, 30 Oct 1997 08:49:07 -0700
Received: by prometheus.Microchip.COM; id AA18034; Thu, 30 Oct 97 09:10:42 
ST
Resent-Date: Thu, 30 Oct 1997 10:54:25 -0500
Received: from www.semware.com(206.65.52.161) by prometheus.Microchip.COM via
smap (3.2)
	id xma017988; Thu, 30 Oct 97 09:10:31 -0700
Received: from steve.semware.com (unverified [206.65.52.170]) by semware.com
 (EMWAC SMTPRS 0.83) with SMTP id ;
 Thu, 30 Oct 1997 10:52:17 -0500
Received: by steve.semware.com with Microsoft Mail
	id ; Thu, 30 Oct 1997 10:54:26 -0500
Message-Id: 
From: Steve 
To: "'tsepro@semware.com'" 
Subject: multiple assignments (ADVANCED USAGE).  Opinions.
Date: Thu, 30 Oct 1997 10:54:25 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Sender: tsepro-request@semware.com
Resent-Message-Id: 
Resent-From: tsepro@semware.com
--IMA.Boundary.069332878--
---
---------------