Re: Strong typing and shared packages

John Shields wrote:
> Hi Kathy,
>
> Sorry I was not able to participate last meeting, but I was on 
> vacation.  My intent first is to define a conceptual model of the 
> requirement for strong typing and gain a shared understanding of it 
> and why it must be a requirement.  It is just wrong for one strongly 
> typed language to subvert its own strong typing requirements by 
> interoperability with another strongly typed language that shares the 
> same rquirement!  It is correct to see strong typing as the 
> requirement and interpret the shared package as an example of how this 
> could be achieved.  If there was any concern that the strong typing 
> concept did not have possible good approaches, the idea of shared 
> packages should have clarified that.  I absolutely want us to consider 
> and accept the requirement or argue its merits appropriately.  This is 
> primary.
>
> To be provocative, I do suggest the shared package concept is a very 
> effective way of making an interoperable definition of strong typing.  
> There is plenty of room for a wide variation of tool flows to achieve 
> practical implementations of this. It is consistent with the 
> requirements we are building, particularly transparency. It doesn't 
> present any flaws to me, though we are not debating details of it as a 
> proposed solution. But, I insist that it is not necessary for us to 
> debate this in order to accept the requirement of supporting strong 
> typing.  Consider it an open invitation to anyone to propose other 
> ways to specify how strong types may be used across language 
> boundaries. Got any?
>
Strong typing is usually required where there is shared memory, and 
sharing memory between different simulation algorithms/threads is 
generally a good source of bugs. Personally I prefer a more 
object-oriented approach with methods and message-passing. Before 
arguing about the typing there should be a semantic model for the 
objects on the boundary and an understanding of the methods they should 
support for simulation to work. IMO typing has more to do with syntax 
than semantics and the semantics are more important.

For an example you can consider the 4-state logic type in Verilog: in 
VCS for DPI functions a 4-state vector (less than int size) is 
represented as 2 ints - the bits of one for 0/1 or Z/X the other 
indicating which (that's all type information), however semantically I 
prefer to look at it as an array of objects which have multiple 
dimensions i.e. value, strength and certainty. So I'd rather see an 
interface that provides methods (functions) for manipulating the value, 
strength and certainty than a way of directly sharing the 2 ints worth 
of memory.

Kev.

> Regards, John
>
>
> Kathy McKinley wrote:
>> I had an action item from last meeting to start an email discussion
>> about a point of confusion. We were discussing the binding requirements
>> type compatibility proposal (http://www.eda-stds.org/sv-xc/hm/0094.html), 
>> and confusion arose from this paragraph:
>>
>>   
>>> Implications of Typing Rules 
>>>
>>> One of the ways in which strong typing is defined and enforced is to say 
>>> a given type is unique and the only way to declare objects of that type 
>>> is to reference that specific type in the declaration of an object.  
>>> Kind of obvious really, but there is no other structurally equivalent type.  
>>> What does it mean to support strong typing in a mixed language environment?  
>>> The same idea applies.  The conceptual model that the user should have is 
>>> that the "same" type should be used to declare objects in each language.  
>>> The practical model is that a single description of the strong type is 
>>> declared by the user and it implies a single equivalent type in the other 
>>> languages. The general requirement for transparency suggests that it 
>>> should not matter which language is used for that description.  A unified 
>>> and practical way to specify this is to support the abstraction of shared 
>>> packages.  Such a package contains types which can be referenced in any 
>>> of the languages. The implementation model is also practical, deriving 
>>> an equivalent package or header file with a namespace.  For now, 
>>> regardless of how it is specified or implemented, one has to accomplish 
>>> this in order to properly support strong typing.
>>>     
>>
>> Some interpreted this paragraph to describe a conceptual model and how
>> it might be applied, and others felt that this paragraph might propose
>> a specific definition of strong typing involving shared packages.
>>
>> John, do you want to clarify your intent when you wrote it?
>>
>> Does anyone have an opinion about either possible direction?
>>
>>   
>
> -- 
> 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.