assignment constraint check time

[Valentin Tihhomirov]

I read (ashenden) that "The operations produce values of the base type
rather than the sub-type. However, the assignment operation will not
assign a value to a variable of a subtype if the value does not meet the
constraint".

I do not understand when this check is performed. One one hand, VHDL
must do this statically, to stay the statically typed lang. On the other
hand, dynamically, because evaluation occurs in simulation and you
cannot check the result before it is produced. I see no way you can
check the range before simulation starts but after it finishes.

 

[KJ]

On Sunday, January 20, 2013 7:00:11 PM UTC-5, Valentin Tihhomirov wrote:

However, the assignment operation will not assign a value to a variable of a
subtype if the value does not meet the constraint". I do not understand when
this check is performed. One one hand, VHDL must do this statically, to stay
the statically typed lang. On the other hand, dynamically, because evaluation
occurs in simulation and you cannot check the result before it is produced.
I see no way you can check the range before simulation starts but after
it finishes.

Given this definition...
signal xyz: integer range 0 to 2;

The following will be caught by the compiler before the simulation starts...
xyz <= 3; -- Will be caught up front when first compiled

The following will be caught by the simulator at run time
process
begin
xyz <= 0;
for i in 1 to 10 loop
xyz <= xyz + 1; -- Will be caught at run time when xyz is currently three
end loop;
end process;

What are you confused about?

Kevin

 

[Valentin Tihhomirov]

I can easily repeat my question: how do you call a language strongly
typed if it admits assigning values outside the range?

I start to understand. Range check is a subtype feature. Being strongly
typed is not the same as strongly subtyped. VHDL may postpone the
subtype range check until after execution and still remain a strongly
typed because only subtype range may fail at runtime but not type range!
If this is right, then my another question, what is the base type,
starts sounding more important. Can you answer it?

 

[Valentin Tihhomirov]

I can easily repeat my question: how do you call a language strongly
typed if it admits assigning values outside the range?

I start to understand. Range check is a subtype feature. Being strongly
typed is not the same as strongly subtyped. VHDL may postpone the
subtype range check until after execution and still remain a strongly
typed because only subtype range may fail at runtime but not type range!
If this is right, then my another question, what is the base type,
starts sounding more important. Can you answer it?

 

[Brian Drummond]

On Mon, 21 Jan 2013 10:00:13 +0200, Valentin Tihhomirov wrote:

I can easily repeat my question: how do you call a language strongly
typed if it admits assigning values outside the range?

I start to understand. Range check is a subtype feature. Being strongly
typed is not the same as strongly subtyped. VHDL may postpone the
subtype range check until after execution and still remain a strongly
typed because only subtype range may fail at runtime but not type range!

But it doesn't : if it can't prove the range validity at compile time, it
plants a runtime check - which fails AT - not after - runtime. Failure
should occur after the expression is calculated but before the assignment
takes place.

- Brian

 

[valtih1978]

But it doesn't : if it can't prove the range validity at compile time, it
plants a runtime check - which fails AT - not after - runtime. Failure
should occur after the expression is calculated but before the assignment
takes place.

You say that there is no need to make any checks at compile time since
strongly typed runtime prevents us from making an incompatible
assignment. This is not what I call a "strongly typed" system. By
strongly typed I mean not detection but prevention of incompatible
assignments. Am I wrong?

I recall those annoying "outside the range" simulator-firing errors.
Surprisingly, I have never mentioned anything like this in another
strongly typed system - Java. The fact that I can assign a short to into
in java means that short is a subtype of int. Yet, when I assign an
"int"-producing expr to a "short" value, compiler asks me to infer an
explicit cast that prevents errors happening at runtime. Might be this
is because Java follows the following rule that I see in Wikipedia:

Strongly typing means

*Omission of implicit type conversion*, that is, conversions that are
inserted by the compiler on the programmer's behalf. For these authors,
a programming language is strongly typed if type conversions are allowed
only when an explicit notation, often called a cast, is used to indicate
the desire of converting one type to another."

One of the rules says that "Static typing is often confused with Strong
Typing". Dear, it seems to be my case

 

[Brian Drummond]

On Mon, 21 Jan 2013 16:50:13 +0200, valtih1978 wrote:

But it doesn't : if it can't prove the range validity at compile time,
it plants a runtime check - which fails AT - not after - runtime.
Failure should occur after the expression is calculated but before the
assignment takes place.

You say that there is no need to make any checks at compile time since
strongly typed runtime prevents us from making an incompatible
assignment. This is not what I call a "strongly typed" system. By
strongly typed I mean not detection but prevention of incompatible
assignments. Am I wrong?

That's not quite what I said. Compile time checks are greatly preferable,
where they are possible. But they are not always possible.
In which case, runtime checks can be employed - and - having detected
that an assignment WILL be incompatible, they will prevent it at the
point where it would happen.

I recall those annoying "outside the range" simulator-firing errors.

That is what happens when a faulty assignment is prevented.

If you need to prove that such a faulty assignment cannot ever happen,
you are in the realm of proof tools such as SPARK, which would actually
be quite a good fit over synthesisable VHDL...

Yet, when I assign an
"int"-producing expr to a "short" value, compiler asks me to infer an
explicit cast that prevents errors happening at runtime. Might be this
is because Java follows the following rule that I see in Wikipedia:

The explicit cast alone buys you nothing : what happens in your Java
program if the expr is (short * short) but the result at runtime won't
fit a short?

One of the rules says that "Static typing is often confused with Strong
Typing". Dear, it seems to be my case

Indeed. Static typing and strong typing are not the same thing...

- Brian