RE: [sv-ac] call for vote on 1601

Hi,
 
I do not agree.
 
I soon as you say that the something subsitutes something else and gets
a type based on the context. 
 
Something needs to be said about the resulting substitution. What are
the rules for doing subsitution?
 
The rules for doing subsitution could determine how the assignment would
be done.
 
I recommend that 1549 focus on "non context" typed assignment of actuals
to formals and 1601 handle the context type assignment.
 
Can someone send examples of a formal argument gets its type when placed
in its context?
 
Thanks
Hillel
 
 
 


________________________________

From: Lisa Piper [mailto:piper@cadence.com] 
Sent: Sunday, January 21, 2007 9:42 PM
To: Bassam Tabbara; Miller Hillel-R53776; Havlicek John-r8aaau;
sv-ac@eda-stds.org
Subject: RE: [sv-ac] call for vote on 1601



Hi all,

 

I agree with Bassam's re-wording.  Thanks Bassam and Hillel.  

 

Regarding the Hillel's 2nd comment on truncation, ...., I also agree
with Bassam that this is not part of 1601. It should be addressed in
1549.  Hillel - are you ok with this?

 

I have updated the proposal on Mantis with Bassam's wording
(1601_context_type_2.pdf).

 

lisa

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Bassam Tabbara
Sent: Sunday, January 21, 2007 12:44 PM
To: R53776@freescale.com; john.havlicek@freescale.com;
sv-ac@eda-stds.org
Subject: RE: [sv-ac] call for vote on 1601

 

Hi Hillel/all,

 

I vote yes with some friendly amendments -- Hillel please suggest how to
improve on top of my suggestions below if you like.

 

1) The description language (quoted below by Hillel) I suggest: "There
are two ways to achieve implicit typing of arguments. The first is to
write the implicitly type arguments first in the list prior to
specifying any type. The second is to use thecontext type. context  is
used to specify that the argument's type is implicitly determined after
the actual is substituted for the formal in the instantiation context."

 

2) Indeed Hillel is right about the ambiguity now of "The assignment
rules ....". I think since this is part of the LRM already that this NOT
be part of 1601 (I don't think it's meant to be anyway). As far as
casting (truncation etc...) we agreed last time I believe that this is
part of the passing semantics and 1601 is just a keyword
selection/description to allow argument mixing.

 

** Again my vote is yes with friendly amendment of (1) [note: change in
the 2 places]. Hopefully (2) clarifies that 1601 should be focused on
the keyword and 1549 is the passing semantics.

 

Thx.

-Bassam.

 

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Miller Hillel-R53776
Sent: Sunday, January 21, 2007 3:28 AM
To: Havlicek John-r8aaau; sv-ac@eda-stds.org
Cc: Miller Hillel-R53776
Subject: RE: [sv-ac] call for vote on 1601

John,

I vote no on 1601

I do not understand what this means "The second is to use the context
type. context is used to specify that the argument can have any type
that is legal for an actual argument."

Sure it needs to be legal within the context it is placed. For example
if an expression was passed to a bit slicing operator.

This is also confusing "The assignment rules for assigning actual
argument expressions to formal arguments, at the time of
sequence instantiation, are the same as the general rules for doing
assignment of a typed variable
with a typed expression (see Clause 4)."

What about padding and truncation?

 

Thanks

Hillel


-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of John
Havlicek
Sent: Saturday, January 20, 2007 7:01 PM
To: sv-ac@eda-stds.org
Subject: [sv-ac] call for vote on 1601

All:

Lisa has updated the proposal for 1601 to use the keyword "context", as
suggested by Bassam, instead of "implicit" (1601_context_type_1.pdf).

I have not seen any discussion in response to Bassam's explanation of
the rationale behind the use of "context"
for this purpose.

Therefore, I am calling for an email vote on the revised
1601 proposal.

Below is the voting eligibility for this ballot.  If you are eligible to
vote then please do, as 80% participation in ballots is required to
maintain eligibility.

J.H.

Ballot on Mantis 1601

- Called on 2007-01-20, final ballots due by 23:59 PST on 2007-01-27.

 n[------xxx------] Shalom Bresticker (Intel)  v[xxxxxxxxxxxx-xx] Doron
Bustan (Freescale)
 v[xxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)    
 n[--x-x-xxx-x---x] Surrendra Dudani (Synopsys)  v[-xxx-xxx-------]
Yaniv Fais (Freescale)  n[--x------x-----] Faisal Haque (Cisco)
t[xxxxxxxxxxxxxxx] John Havlicek (Freescale - Chair)  v[xxxxxxxxxxx-xxx]
Dmitry Korchemny (Intel - Co-Chair)  n[--------xx-xxxx] Manisha
Kulshrestha (Mentor Graphics)  n[x-------x-xx-x-] Jiang Long (Mentor
Graphics)  n[--xx-xxxxxxx-x-] Hillel Miller (Freescale)
n[----xx-xxx-----] Don Mills (Microchip)  v[xxxxx-xxxxxxxxx] Lisa Piper
(Cadence)  v[xx-xx----------] Tej Singh (Mentor Graphics)
n[-----xx-x------] Stu Sutherland (Sutherland HDL)  v[xxxxxxxxxxxxxxx]
Bassam Tabbara (Synopsys)
   |-------------- attendance on 2007-01-09
 |---------------- voting eligibility for this ballot

        Legend:
                x = attended
                - = missed
                r = represented
                . = not yet a member
                v = valid voter (2 out of last 3)
                n = not valid voter
                t = chair eligible to vote only to make or break a tie

--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 


-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.