Re: [sv-ac] P1800 SV-AC: vote on #1549

Hi Lisa,

A) your comment implies a strict typing ... Raffirming that this needs to be agreed on then clarified. And yes assertions and their semantics are not generic.

B) I did not mean "exclusively" per se rather that it's better to introduce elsewhere with types and qualifiers and use here instead of introducing first in our particular context.

THX. 
-Bassam

-----Original Message-----
From: Lisa Piper <piper@cadence.com>
To: Bassam Tabbara <Bassam.Tabbara@synopsys.COM>; sv-ac@eda.org <sv-ac@eda.org>
Sent: Mon Sep 11 08:04:33 2006
Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549 

 

 

________________________________

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Bassam Tabbara
Sent: Friday, September 08, 2006 1:54 PM
To: sv-ac@eda.org
Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549 

 

I vote No. I think voting now is rushed -- we need take back to committee for more discussions on the following:

 

a) Clarify how the new types should be handled in checking and error reporting and also in relation to the "true nature" identification functions that Dmitry proposed (isSequence() etc...). Currently it's not clear at all what compiler *shall* vs. may vs. .... do if the type is different than nature, and what the user expectation might be here .... [Note the proposal currently has a bunch of "may be's" that bug me.]

[Lisa Piper >>>] I did a search and see 3 “may ...” and those statements say that <things> “may” be typed.  They might also be untyped in which case no type checking will occur.    Is this what you are referring to? 

 

How the “new types” should be handled in checking and error reporting is a generic issue that applies to all types in all functions, tasks, classes etc?  Do you see some conflict with Dmitry’s proposal?   

b) "implicit" as we discussed before is handy potentially for SV in general, that said, it should probably be added elsewhere (with other types/qualifiers) and referenced here. So we should check with other committees to find the best way to handle this (incl. double-check on an existing/better way even) rather than add it exclusively here.

[Lisa Piper >>>] does using it here prevent it from being used elsewhere?

 

Thx.

-Bassam.