further discussion on implications of typing rules

At last Wednesday's meeting I expressed confusion about the strong/weak
typing proposal. I think most of my unease comes from not understanding
the context of the discussion. Possibly the rest of this message is
based on a misunderstanding of what was being suggested. If so, I
apologize.

 

If there was a proposal on the table, I wasn't clear on what it was.

 

If the idea was to define strong/weak typing, I have no objection.

 

I heard the idea that we should be careful to define things such that a
if a language enforces strong typing then it should not be possible to
circumvent that by mixing languages. This seems reasonable. I don't know
when it applies, though. Some examples of where we're in danger of
having this problem would help me.

 

I'm also not clear on the definition of strong typing. For example, when
you call a C++ function, you have to pass actual arguments that are
convertible to the formal arguments. You can pass an A to a function(B)
as long there's there an A::operator B or B(A) constructor. I'm not sure
whether you're calling that strong typing or not. 

 

The example of an SC interface was given in  John Shields' message of
April 26, in which he said:

 

For example, SC certainly has strong requirements for matching class
types at its interface.  Defining, generating, and using equivalent
derived declarations to do type checking between SV or VHDL and SC
should be part of the specification and implementation.

 

I'm not sure what was meant by "equivalent derived declarations" here.
My view is that where SC needs an object that implements some interface,
the object has to be, in fact, a C++ object that implements the
interface. There's not much choice, since the C++ code that makes calls
to that interface is compiled by an off-the-shelf C++ compiler and
assumes that the object it's calling is  a C++ object that implements
the interface. This object may not be the same one that user
mentions-for example, if the user tries to bind a verilog class instance
to a SystemC port we might create a behind-the-scenes C++ object that we
bind to the SystemC port, with the behind-the-scenes object somehow
linked to the Verilog class instance. I see no apriori reason why the
Verilog object and the behind-the-scenes C++ object have to be the
"same" type-only that operations on one can be translated to operations
on the other.

 

I'm happy with the idea of coming up with a way to enforce, or create by
construction, "same" types in multiple languages. But I expect we will
also need to come up with a way to populate a library with converters
between types in different languages. In that case, the "same" types
would become a special case in which the converters were automatable so
the user would not have to think about them.

 

If what I've attempted to express here does not conflict with what I was
asked to vote on last Wednesday, then I'm happy to change my vote from
"need more time" to "yes".


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